VC wants product to meet real needs so it is marketable.
VC wants to choose and control risks of team failing to deliver prototypes, features, and product versions on budget and schedule.
But VC wants team to manage itself in sticking to those VC-chosen risks.
VC wants team to report status regularly, thoroughly, and honestly.
Startup team has great ideas but little knowledge of, experience in, or even motivation for:
Determining needs, goals, objectives (NGOs), and requirements.
Prioritizing and scheduling by balancing the above with realistic feasibilities (time, money, people, risk).
Continuously re-evaluating and adjusting all the above.
Team continues to use a freeform development process long after end of the brainstorming and loosely scheduled prototyping stages.
Team has little experience in structured, controlled development processes.
Team will become dispirited and might even quit if process is too complex, slow, laborious, or rigid.
VC wants project's processes to change on the fly to match the project's quick progression through stages.
VC wants quality appropriate for the project and for each stage of the project, for example by reducing risks and increasing quality as final delivery date approaches. VC wants to achieve that with the least burdensome process possible, given the goals of the moment.
VC wants team to become a coherent unit quickly.
Experienced Entrepreneur Starting a Project
Wants new people for this new project, but does not want to go through pains of building those people into a good team using a good process. See our previous section "Venture capitalist funding a novice project team."
Wants his or her previous project's people, but wants them to approach this new project afresh.
Team is not freshly considering needs, goals, objectives (NGOs), and requirements.
Team is not breaking from its previous projects' product ideas, even if it has freshly identified NGOs and requirements.
Team is breaking out of its previous projects' ideas only by flipping drastically into permanent brainstorming mode, unable to transition from there into a feasible, concrete production plan.
Wants this project's design and development process to differ from that of his or her previous projects, by being:
faster and leaner,
and/or better controlled,
and/or changing on the fly to match the project's quick progression through stages (e.g., reducing risks and increasing quality as final delivery date approaches).
Wants this project to flow from the previous project and into the next one, by all projects being parts of a systematic program.
Successful startup wanting to go beyond the first version of their product, or their first product, by creating a strategic program.
Established, not-so-small company:
Wants to create a startup-like project within the larger company.
Wants to change the entire company's culture to be faster, leaner, and more flexible.
Company wants to increase quality, but only to a particular, concrete, rationally determined level that balances the quality-related needs, goals, objectives, and requirements against feasibility and the desire to keep the process fast, lean, and flexible.
Company wants to increase its process's speed, leanness, and flexibility, while increasing quality (no, that's not a paradox), or while decreasing quality to a rationally decided level.
Company wants to create a coherent program for its diverse products.
Wants to maintain or attain appropriate process control and quality, while increasing speed and flexibility.
Wants to break down silos that separate research, advanced development, and regular development.
Wants to create coherent, prioritized, feasible program of work.
Wants to down-select brainstorming results to create proposals that balance realistic feasibility estimates with desirability estimates.
Wants to quickly cost estimate for proposals and subsequent stages of projects.
Wants to streamline workflow.
Ground operations software
Integration of flight software with hardware
Science payloads on spacecraft, UAVs, rovers (land or water), or crewed aircraft