4 Phases of Product Development Re-imagined
Originally posted on DLabs Medium site by Matt in 2018, but the concepts are easily generalized.
At D.Labs we’ve looked at agile product development from many angles and written about them on this blog (X Driven Development, When is agile worse?, Controlling costs in the agile world, What marketing agencies can’t offer startups?,…). This is another angle that could get you faster through validation and save you a lot of gray hair.
Most company founders have an intuition about what the market needs and what is wrong with existing solutions. They then start solving a puzzle in their head around what kind of digital product could solve this problem: features, specifications, perhaps even user layouts. At DLabs, we call this “Intuition Based Development”. It tends to be the least efficient and most expensive way to build business value. Not only is the intuition perhaps wrong, but the only ‘good enough’ point is securely in the head of the designer so everything gets built to a relatively high level (Although it never feels that way to the founder in-the-moment).
While we rarely have pure intuition based development work at DLabs, we do get a lot of the 2nd category: “Experience-Driven Development”. Here the founder/product owner has experience in the industry and can start with stronger assumptions. The founder then starts to “solve the puzzle” is the same way. While product drivers in this phase have clear knowledge about the general market, they are often over-emboldened to assume they know about all subsets of the market and all user groups’ behaviors and will often increase the total development spending before confronting it to the realities of real users and the market.
Both of these phases usually have very poor Business Value / Engineering spend ratios. In fact, improving engineering spend performance through efficiency or cost of the team usually does little to fix the problem, since product owners often see funding as the limiting factor rather than user/market behavior uncertainty or their user/market bandwidth. At DLabs, our goal is to get founders out of these two phases as quickly as possible and start them on the road to the next two phases. In fact, we would argue that it is nearly impossible to achieve product-market fit without moving into these later phases.
The first mature phase is “Marketing Driven Development”. Here the business/customer facing team creates a theory of how to better attract or serve customers. Based on the test design and planned dates, the supporting tech can be planned in sync and scale. The scope of development is only as much as needed. Notice the transition from traditional development-type thinking (feature based) in the first two phases to a full Lean/Agile mode. When developing in this mode, it is easy to quickly reach a development burn rate that exceeds what the business facing side of the business can absorb and follow-through with. For early-stage startups in the first year or so, this is usually between 15 to 40K€ / month. (again your mileage may vary…). So long as no feature is built until the customer-facing side is ready, the basics of agile cost control are built-in even if funding coffers are full, confidence is high, and ambition is high.
The most mature phase is something we call “Analytic Driven Development”. Here, the marketing (business facing) part of the business not only has a theory about how to increase engagement or revenue or customers… , but they verified the assumption with real analytics as well as know which measurement should improve if the theory is right. For example, a marketplace may decide that the customer journey for most users involves checking the pricing elsewhere before buying. They believe that they could increase returning customers, decrease the time between visits, and ultimately have a higher conversion rate if they could actually encourage this behavior and make it easier. They would need supporting tech around measurement + A/B testing tools in place as well as some links to competitor sites that pop up (tech). Two sprints later and they see that we are onto something and should keep improving on this idea or that the theory is flawed and revert the product back as well as re-focus on other improvements. Notice how business value / Engineering spend is far more likely to be higher than in the less mature phases. Also, notice how cost-per-feature is still not that important.
To recap, get to more Marketing/Analytic based development as quickly as possible. Moving through Validation in these more mature modes requires lower engineering spend rate and achieves success far sooner than their less mature approaches. It also transitions effortlessly into the Efficiency and Scaling phases of a startup lifecycle. When delivered in a partner mode (eg. DLabs supplying tech instead of an in-house team), it even scales in size effortlessly.