Step-by-step guide to bootstrapping your new product development – Part 8, Validation
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 8.
1) Principles
2) Inception
3) Understanding the Beachhead Market
5) Getting to paying customers
8) Validation
9) Iteration
10) Organizational structures to support this model
Part 8: Validation
Right - we're getting close to committing some serious development resource now.
Of course, our R&D team have been closely involved with all of the work so far - helping to ground the proposition, relating it to the landscape, and keeping a close eye on feasibility, while grips with the technical implications of the evolving brief, but their real work is just about to begin.
We've maybe burned between 10 and 80 person days on the work so far, which may seem like a lot, but the upper end of that is what a team of 8 developers would cost in one two-week sprint.
In this validation stage, we're going to tidy up our assumptions list, conduct some more low-cost experiments to satisfy ourselves we know exactly what we're getting into, then take the leap and build something that satisfies some core part of the value proposition, and persuade some customers to buy it.
26) Identify key assumptions (0.5 - 1 day)
First, we're going to take a moment to go back and look at the items on our key assumptions board - both the outstanding ones, and ones we have already addressed.
- Are there any we have missed?
- Are there any critical questions that can be answered without actually shipping real product to customers?
- Where are we making logical inferences in the data you have gathered?
- Where are you relying on someone's 'experience' (or assertions from authority)?
- What might be "unreliable witness" evidence?
- What might not be statistically valid?
27) Test key assumptions (5 – 20 days)
We can now do another round of metrics & experiments to test these outstanding assumptions.
As before, you can use tools like mock-ups, focus-groups, surveys, sign-up websites etc.
28) Define Minimum Viable Product (MVP) (0.5 - 5 days)
The MVP is "the simplest version of a product that can be released that addresses a customer need or set of customer needs, which allows value, engagement and interest to be measured".
I think everyone in the world has seen the wheel → chassis → car v. skateboard → bike → car MVP image, and can see why neither of those is a good way of producing an MVP.
Let's say my value prop is a mode of transport for a particular type of customer, with particular needs. If that customer needs the features of a car, then a skateboard is highly unlikely to cut it for them, and the feedback would be (rightly) strongly negative.
A more popular MVP model is the cupcake → cake → wedding-cake one. Again, this has serious problems. First, the cupcake and wedding cake customers are very different. A wedding cake feels more like a pivot for the business once the cupcake market is fully exploited. And a simpler pivot might be the "lots of cupcakes" wedding cake.
With that in mind, I prefer Holly de Wolf's version of the cupcake analogy.
On this model, we work towards the delivery of the first whole cup cake, through a series of intermediate steps, and focus on validating each of the steps that get there. It's actually a lot more like the "build a car" with wheel → chassis → car model, but with the simplicity of the first "full" end product of the cupcake model.
In the cupcake example, you might test your cake batter recipe on yourself, friends and family, and a few close customers who might understand how the batter should taste; then work on the icing, test that in the same way; try cooking a little bit of cake batter, test that; finally, try bringing it all together, test again, and tweak anything that doesn't quite work.
This is very much like actual dish development in a kitchen, which is no coincidence.
To define the MVP
Refer back to the customer's top 3 priorities and build out those stories
Wireframe & storyboard the simplest path to realising those benefits
Brainstorm non-functional constraints (e.g. performance, security)
Define features and scenarios
(using a specification language like Gherkin is a great way to do this)
Create a backlog and generate some high level estimates
Ruthlessly prune the backlog back to a minimum
Identify the biggest remaining unknowns, and prioritize the backlog according to the ability of that particular deliverable to answer questions about technical risk, market fit, pricing and acceptance.
Even before you build them, you can test the priority of your backlog using our favourite techniques.
You might also like to add an additional, much more expensive technique at this stage: you could run a Kickstarter campaign.
This will require you to put in a more concerted marketing effort, and produce higher-quality marketing materials. You'll need to nail down your first pass at a pricing plan (in their guise as the rewards in the Kickstarter), and engage with real customers, who will be parting with real money.
This is a great way to do a final test of your proposition before actually building the real deal.
What if my Kickstarter doesn't get funded?
Well, clearly that's not great, but you will have some superb data about why it didn't get funded. Was the proposition wrong? Did your channels not reach the target audience? Was the pricing wrong? Branding? Quality of presentation? Communicate with the people who did sign up and find out why they participated; identify some people you reached out to directly who chose not to.
Is my Kickstarter going to fund the business?
No, it probably isn't. Ideally, pitch your Kickstarter at a specific part of the product development process, and set its value at an amount you are fairly confident you can get funded within the first 10 days. You can then declare success and start moving on to stretch goals.
29) Build MVP (10 - 80 days)
Don't spend more than 3 months building your MVP. If you need more than 3 months, look at where you can cut features and focus on the core customer value.
While you are building it, ensure that you define the usability and "customer delight" metrics you are going to use for each component.
Test the output from each sprint with your lighthouse users and focus groups. You don't have to show them the whole thing - in fact, it is often better not to, so that they focus on the bit you are testing. But test something every week, and feed it back into the next sprint (or the sprint after, or the backlog...)
Also, make sure you are testing what you are building against your pricing and manufacturing assumptions. There's no point in carrying on if what you are doing is going to kill the CoCA or lifetime support cost, or detract from the selling price.
30) Demonstrate that "the dogs will eat the food" (30 – 90 days)
The MVP is ready to go – it's time to release it and see if customers will buy and use it.
You're not starting from ground zero - far from it. The work you've already done has identified channels, key customers, word of mouth - maybe your successful kickstarter has even created a small customer base to start with.
Now, we're going to focus on metrics:
- Measure the whole sales cycle against the assumptions in the model (e.g. duration, COCA, resources required)
- Plan and execute studies of "usability" (empirical observations about how well the customers use the MVP, and which features they derive most usage from) and "customer delight" (subjective observations on customers' self-reported happiness with the product)
Next time, we're going to look at how we manage subsequent iterations of the product development lifecycle, and follow the product through to end-of-life.
Read more in the series
