Exploring the reasons that a product might fail in the market is a useful way to triage and assess what you need to do to prevent the failure of your product. Instead of taking the “do these things” approach as a prescriptive recipe for product managers, I’m approaching the exact same topic from the opposite direction. I was inspired in part to explore this approach when thinking about the Remember the Future innovation game. Instead of asking “What will the system have done?” in order to gain insights what it could be built to do, I’m asking “Why did your product fail?” in order to prevent the most likely causes of failure.
Exploring Causes of Product Failure
In the first article on why products fail, I started with the top-down categorization of sources of product failure.
[Within that framework, we started diving in to the causes of product failure that could be broadly described as “[the product] does not solve the right problems.”
[Breaking this down involves exploring why the problems are not the “right” problems to solve.
[One branch of the Ishikawa involves failing to solve the problems that are important to the user personas. That’s what we’ll explore in this article.
[There are several ways in which you could reach the conclusion that user personas have failed to realize value.
[The specific reasons roll up to the following categories (read it as “The product …” :
- … Does not target the right users – you may have solved someone’s problems, but not the right someone.
- … Does not focus on the important goals of target user personas – you may have picked the right users, but you failed to focus on the most important goals that they have.
- … Insufficiently addresses the user persona’s needs – even with your eye on the ball – the right problems for the right people – you may not solve those problems “enough.”
- … Does not account for user persona’s level of experience – as people use a product, the nature of the problems they face evolves – did you take that into account?
- … Does not incorporate the context of usage – solving the right problems, sufficiently, for the right people is not enough – you have to account for the context in which they care.
When looking at the details under each of these categories, we get to the root causes of failing to enable your users to realize value from your product.
[Focusing on the Right User Personas
Developing a set of user personas to guide the development of your product is important for several reasons. It provides a framework for focus – only building what is needed by the people who will actually use the product, not building what someone thinks “would be cool.” It provides a framework for prioritization – yes, some users will do that, but most won’t, so we’ll do that later. It provides context for the team to avoid a common manifestation of not having defined users – the elastic user problem. It gives you an opportunity to build a product that people love – creating loyal customers.
The first challenge is to make sure you identify the right users. The approach I describe here may only make sense in the context of the customer-centric market model that I use for thinking about markets – I’m not sure, it is so wired into my approach now that I may fail to clarify why I make some statements (if so, go read the earlier article). In a nutshell, this approach defines a market as follows:
Markets are made up of market segments, which represent groups of customers who share common problems that people will pay to solve. The notion of “customer” is combining both buyer personas and user personas to simplify the model.
Many products are relatively straightforward – within a given market segment, there is only one important user persona. For many B2B and enterprise software products, there are multiple user personas who collaborate to solve business problems. You need to understand the ecosystem of how your customer operates in order to identify the user personas that are important. Sometimes, the important user personas are not the people who directly interact with the system – they can be people who “use” the outputs of the system. In an article on visualizing stakeholder analysis, I show how to use an onion diagram.
In a nutshell, there are direct users of the system, other employees (of your B2B customer) who are part of the containing system, and still other actively involved “users” in the wider environment. You identify these “non-user users” by understanding the interactions and goals of the [traditional] users. You could choose to focus only on the actual users, or identify the “other” users that make up part of the ecosystem. Both approaches work. The same user story would be syntactically different:
As the pest control company admin, I need to be able to quickly see the history of our relationship with a customer when she calls me, so that I can deliver personalized service, so that I can improve our customer’s satisfaction with our service.
As a pest control company customer, I want to know that my company cares about me, because I’m willing to pay a premium to support local merchants as long as I get personalized service.
I suspect it is a matter of personal (team) preference, but I prefer treating the non-user users as first class citizens. I believe you are more likely to generate insights about the problems the user-users should care about solving, when you start getting inside the heads of their customers – a key approach to developing B2B2C products.
Once you’ve identified the users, you need to identify the relative importance of each group of users. Choosing who to satisfy – or who to satisfy first is a manifestation of your go-to-market strategy. Selection of the “right” strategy is a little too broad of a topic to cover here, a thousand words into an article on user persona prioritization. As part of a series on comparing products, I made the case that you have to compare products from the perspective of users, and that the comparison should be weighted based on the relative importance of the users. In that article, I touch on market size, cross-market influences, higher-level strategy, risk mitigation, and ease of entry (into the market) as key areas of focus in strategy formulation.
The methodology for weighting the comparison in the context of user goals and the relative importance of users can also be used to prioritize investment decisions in your product.
Summary
As the detailed Ishikawa implies, there is more to come about failing to address the needs of your users. More to come in future articles. To summarize this installment,
- Your product failed because you failed to solve the right problems.
- You failed to solve the right problems because you did not enable the users to realize value.
- You failed to enable users to realize value because you either (a) failed to identify your users, or (b) failed to prioritize solving problems for the right users.
To avoid product failures that stem from these root causes, identify your users, and their relative importance in the context of your particular strategy.
Great stuff Scott!
This aligns with what you stated, but too often, companies with early stage products are unwilling to even select a target market and try to sell to anyone that looks like a potential fit. This happens because they never did the market validation work to understand which segment has what problem, as you describe here.
Thanks, Tom! I definitely just saw exactly that scenario recently.