failure
pivot
iteration
jtbd
How to set yourself up for failure
Failure Porn: Fail fast, fail often.
The underlying, implicit assumptions with this frame of thought is: 1) we can iterate quickly, and 2) we can learn what works by learning what doesn't work.
Wow, that sounds like a long road to nowhere. Consultants, authors and agilistas alike subscribe and prescribe to this approach. What are the results? Depending on who's numbers you use, Clay Christensen shared a metric that 95% of product innovation efforts fail.
Read that again...
95% of product innovation efforts fail.
Staggering. While that number seems very high, and we're not sure what is in that number, there's no denying there's a massive problem. There is, furthermore, no evidence to show that recent process changes ( fail fast/iterate, lean startup, agile, design thinking, etc) have improved success rates.
In this post, we'll show how this is a horrible way to approach product development and innovation. Then, we'll offer a different way to think about success of innovation and product management.
We can iterate our way to success!
In recent years, most companies have made significant investments to improve how products and services are developed. There are many such process and practices including the adoption agile, design thinking, business model innovation, lean startup, Tech Stars etc. A core component of these practices include iteration in some form. Some iterations are short like sprints, others might be longer timeframes like a design process changes such as design thinking/double diamond. The benefit of iteration is there is a feedback loop built into them. It's assumed that at the end of the iteration, we look for feedback from our customers to validate what we've produced helped them. Unfortunately, in many organizations, getting feedback doesn't happen in every sprint and so we kick the can down the road to when we can get feedback.
In the event we are able to talk to a customers, we often ask them how they like this feature or that one. What they don't like, etc. We don't have a common way to look at and evaluate to think about, determine, and learn about what the customer needs really are. Therefore we often bring back customer needs that miss the mark with a few sprinkles of what the customer says they like and would use.
But it gets worse...
The team continues to iterate on the feedback they heard from the customer. What is really happening is that more tech debt accumulates. The agilistas will tell you that the definition of tech debt is most often due to past poor tech decisions, aging frameworks, and limited refactorings of the code base. But the biggest source of tech debt is maintain parts of the product that the customer doesn't care about. Those features that are never used, those features created with limited understanding of the customer's needs.
But we can learn what's not working to figure out what will work!
Controversial statement: you don't learn from iteration alone.
As I already mentioned, you need a common set of language, definitions, mental models and tools - a cohesive system to think about the customers' needs and how to invest.
Don't think this is a problem? Ask everyone on your team(s), independently to define what a 'need' is.
Cohesion is critical, you can not have a set of tools without knowing what they do and when to apply them.
How often have you seen product theater like "Idea Jams" or "Brainstorming" where 'there are no bad ideas'? They aren't even forming hypothesis to think about and define what's a success or failure.
(Truth be told, there are an infinite number of bad ideas).
The most foundational mental model is that a customer doesn't care about your product, they care about what they are trying to do, their goal, or their Job-to-be-Done.
We've got to reorient our mental models, our tools, our goals and priorities around this basic fact.
Most teams talk about pivoting, and they are doing the best they can. Often there is a 'delivery-oriented' culture that has them focused on shipping. Delivery is important, but is also the source of massive waste. Teams perform discovery activities that aren't working. What should we do?
Here are some starters:
- Determine who is the customer?
- What problems are they trying to solve, in their language?
- How are they measuring what success looks like?
- What other solutions have they tried?
- Build a mental model off of this data