Endjin spend a lot of time working with start ups and businesses who are pivoting into new product areas. They are usually operating under fierce resource constraints, and this has an impact on the way in which they can approach their development program.
We've evolved a principles-based approach to the new product development process which can be applied to a wide variety of businesses. It's based on the MIT disciplined entrepreneurship approach, incorporating great tools like the Value Proposition Canvas and the Business Model Canvas.
In this series, we're going to look at an example of a "lean" new product development process, applying these principles, and looking at some of the caveats.
There are 10 parts in the series, of which this is part 9.
Part 9: Iteration
OK - we've put our MVP out into the market, and we can start refining the information we have about our product, its fit to the market, and the real drivers and buying behaviours of our clients.
Hopefully, they're not a million miles away from the research we did - but it is highly unlikely that we were bang on the money the first time.
So, we keep iterating: measure the results of our MVP, learn some lessons, build a new feature, or fix a bug; tweak our proposition, or change it to address the needs of a new market, and measure its effects on our key metrics.
To ensure that this doesn't become chaotic, and so that our engineering and sales teams are working within a strategic framework, we start out by developing a product plan.
31) Define a product plan (0.5 - 5 days)
First, develop a high-level backlog to address the customer's remaining priorities in the beachhead market.
Then, develop a product plan that maps product features and releases to opportunities to increase penetration of an existing segment, increase revenue, or lower COCA and/or lifetime maintenance costs.
Using the bowling pin model that we developed earlier, you can also look a little further ahead, and identify opportunities to adapt the product to new markets, and set out your story to enter those markets, either because you have the resources to do so, or because you need to pivot out of your beachhead (due to saturation, hopefully!)
The example above shows a team delivering at a regular cadence of 1 feature every 8 weeks over a two year road map.
We don't add features because they would "be great", or even "because customers are asking for them" or (especially) because a sales person guarantees a sale if we just add this feature.
(Or, "C'mon, ol' Gil really needs this sale" syndrome).
Instead work out some metrics which determine what the impact of adding a feature will be on our business model e.g.
- Lower the Cost of Customer Acquisition
- By increasing customer value & product desirability
- By improving competitive position and increasing win rate
- Lower cost of maintaining install base
- Reduce support calls
- Automate ops processes
- Increase revenue
- By upselling
- By accessing a larger Total Addressable Market in adjacent markets
- By introducing new pricing options
32) Build/Measure/Learn (for as long as it takes!)
So, build it, record the metrics, learn and iterate. Keep using the techniques developed in steps 1-31 to evaluate, elaborate and execute on your product plan. As my friend @goodcoffeecode says: "Live the life of the Founder. Sit back, and let the easy money roll in."
(Can I hear hollow laughter? I think I can.)
And don't be afraid to spin significant changes right back through the whole NPD process, building on the information gathered from the previous stages.
The information you're building up about the market is getting more detailed - backed by more evidence. Even if ideas aren't working and you need to pivot, you are building the evidence to understand why and make better choices next time.
The rate of iteration, the length of the sales cycle, the capital investment in product development, and your business model will determine how long it takes to get to profitability.
Cost of product development
You'll notice that we haven't been talking much about the cost of product development so far. All our metrics have been about Cost of Customer Acquisition, Customer Lifetime Value and Cost of Customer Maintenance - i.e. all the operations stuff. For most products, the R&D costs are way less than 10% of the expected lifetime value of the product you're developing, and so the investment will pay off very quickly. There are exceptions, of course. Pharmaceutical companies, for example, invest a huge amount in R&D (an average of $1.2bn per new medicine in 2011), but see a very low return. The majority of their income comes from the best performing decile of products, and the average return is only ~11% over the lifetime of the drug. This depends for success on a huge pipeline, with an expectation that some will turn into "blockbuster" drugs like Viagra, Lipitor and Zoloft. If you think about it, this is rather like the VC portfolio - they invest in a pipeline of companies, the average return is only about 10%, and that comes from the "blockbuster" success of the top decile of performers!
33) Sunsetting & End of Life
One thing that we often forget about (especially when bootstrapping the business) is the product's end-of-life. You may have to think of this earlier in the cycle than you think. What happens if you have, say, 1,000 happy customers on a platform, but you're not profitable, and want to pivot to something else. Do you keep supporting those customers? Do you cut them off overnight? Or do you plan a sunsetting period?
It is helpful if we define metrics at the start, that help us to recognize when the cost of development is no longer delivering a significant positive impact on revenues (e.g. Incremental Total Lifetime value is 10x+ R&D cost).
If we plot those on a graph and extrapolate, we can see if/when we are tending towards an end-of-life point.
We need to plan for sunsetting and end-of-life well before you reach that point - and make sure it is clear on our product roadmap.
There are three common stages in the end-of-life of a product (or product version)
- Maintenance mode
- Fix critical bugs only
- Special (expensive!) support contracts only
- Service is discontinued/switched off
- Work customer base into the sales plan for other products: migration/upselling opportunity
It's critically important that you think carefully about managing your product's end-of-life. You don't want to terrify the customer base (it is all too easy to lose trust in these circumstances), but you must be open and honest (for the same reasons).
Well, we've covered the whole lifecycle, from α to ω. In the next part, we're going to look at some organizational structures, both in startups and in larger organizations, which can support this kind of innovation process.
Read more in the series