This is the way most technology products are developed. You start with a product vision.
You write a development plan, including development time and cost.
However, when making something new, there are unknowns.
Since none of us has a crystal ball, assumptions are made to address the unknowns.
The development plan is complete. However, there is almost always intense pressure to release the product sooner. The development team resists, but ultimately acquiesces and agrees to an accelerated schedule–if some additional assumptions are met. The more aggressive the schedule, the worse and more numerous the assumptions become.
This plan is given a green light and the development team gets started.
Early in development, the team starts learning new things. A new technology is not ready or is poorly supported. Your competition releases a better product. Your marketing team lowers the product cost target. You get feedback about what your customers want.
Instead of being excited to incorporate these new inputs, they stress the development team out. Everything has to go exactly as planned or the product will not be released according to plan.
Your plan is so optimized for an aggressive schedule that you can’t change anything and still meet the planned release date. You’ve effectively prevented yourself from responding to new, valuable inputs.
Eventually, an input comes up that cannot be ignored. Marketing is targeting a different user. The competition has released something better and cheaper. Early customer feedback is different than you expected. Incorporating the new input will invalidate one or more of your assumptions.
You need a new plan. What’s the big deal? It turns out the entire organization has been building itself up around the product and release date you outlined in your development plan. It’s costly and painful to make a change with this much momentum around a specific product on a given release date.
Nevertheless, the organization endures the pain of the change it because it has no choice. However, the delayed schedule introduces even more pressure to ship the revised product sooner, so even more aggressive assumptions are made with the revised plan.
You’re even less able to respond to new inputs than you were before, and the cycle repeats. Start-ups run out of money, established companies ship product late, teams burn out, or in many cases the product is cancelled before release.
This outcome is surprisingly common. Why?
- Product development processes have evolved in silos for years. Typically an organization will build its own engineering team, and there is no incentive to share learnings or collaborate with other companies to do product development more effectively.
- Traditional product development processes are the result of what sounds rational to us analytically-minded engineers: come up with a plan, then execute it (we’re the ones developing the processes in the silos). It’s deterministic and comfortable, and the execs love it because they know exactly what they’ll be getting and when. The problem is that you learn new things along the way and the world isn’t standing still around you.
- Technology products have the added complexity of relying on pieces of the product entirely out of your control. It’s not a matter of putting known pieces together to do something new. New technology introduces more unknowns.
We’ve been hard at work developing new engineering and product development methods to address these issues.