Customer Development 101

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

Great product development is only half of what you need to create successful software products. On Mondays, we focus on the other half, starting with a series called Customer Development 101. It’s based on the approach formulated by Steve Blank and and further articulated and refined by Eric Ries, Brant Cooper & Patrick Vlaskovits, Alexander Osterwalder, Sean Ellis and others.

When you’re developing a truly new product, rather than creating an update to an existing product, you’re dealing with a lot of unknowns and uncertainty. Your problem is an unknown, your solution is an unknown, and whether your product fits the market is an unknown. In a lot of ways, this is what agile software development was meant to address – build working software in small increments, validate it with your customer and adjust based on that feedback. User experience design has a similar objective: research users, build models of them, design for those models, and vet the designs with real users. Combining these two approaches is the current state of the art in software development shops. Rapid iteration and feedback loops using this approach lead to much better products.

The problem is that this approach only covers the product development part of creating products that win. User driven agile development is great at quickly creating outputs that can be used as inputs for other agile processes, and at adjusting to the output of those other agile processes. But if those other processes are not capable of generating and reacting to rapid feedback loops, then there’s limited value. Putting it another way: Building something quickly and getting feedback on it only partially mitigates the risk that you’re building the wrong product.

Customer Development assumes that for new product development, you are starting with unknown or only partially known customers and markets, and that you arrive at defined problems and solutions by rapidly testing hypotheses about the market, pricing and customers with maximum efficiency (and with minimum effort.) After you generate a hypothesis, your next question should be – what’s the most efficient way for me to test this hypothesis? It’s an iterative way of evolving a business model, and it starts well before your development team does. But once that development team starts (on the minimal viable product, which we’ll get to later) the customer development process fits hand in glove with agile development.

Next time: Market Types – the critical input for your product strategy.