In [this presentation], you focused on the ways in which learning from potential failures can help produce higher quality projects. You identified several possible root causes for failure, but said that they all ultimately stem from a product that doesn't allow users to realize its value. Can you explain what you mean by this?
That presentation discusses how to perform a mental experiment designed to stimulate some critical thinking. Instead of thinking about what should be added to the product, imagine that, in the future, the product has already launched (and failed). Then perform a hypothetical root cause analysis to try and understand why it failed.
The strategy that I've found to guide the best product decisions is for product managers to think about what problems customers are trying to solve and then decide how the product can best help them solve those problems. Your product is not "the solution;" it is just one tool that they can use, and they have alternatives.
For users to choose your product to solve their problems, they need to realize value, defined in terms of addressing those problems, from the product. When performing the hypothetical root cause analysis, a product manager will identify reasons that users might not realize a product's value, assess the risks of those reasons and address them in advance of a product launch, instead of afterwards. There are five categories for assessing why users don't realize value from a product:
- You did not target the right users. Specifically, you built capabilities into your product that some users might value, but not the capabilities the important-to-your-success users would value. Make sure the capabilities you plan to add are valuable to the users who actually solve the problems.
- You did not focus on the important goals. You know the important users, but do you know which problems they consider important to solve and which they consider less significant? Make sure that you are building the capabilities into your product that address the important problems, and ask yourself, should you really invest in solving the unimportant problems?
- You insufficiently addressed the user's needs. This can play out in two ways, either you only solve a portion of the important problems, or you solve the important problems incompletely. Make sure you understand how users define success, and make sure your product enables them to achieve it.
- You failed to account for user expertise. Users learn how to use your product. Initially, they have to invest (mentally) in learning how to use your product. They will quickly become competent, shifting their (mental) focus back to addressing their problems. Some users will become experts with higher expectations for how they might use your product to solve their problems. Make sure your product takes into account how the nuances of user's needs change as they gain expertise.
- You did not incorporate the context of usage. Many user goals are contextual -- they only apply at certain times, in specific physical environments or when using particular devices. Other user goals always apply, but are approached differently or have different success criteria in different contexts. Ignoring how user goals change with context is almost as bad as ignoring how the goals change from one user to another. Make sure you are explicit in the selection of contexts in which your users will be using your product to address their problems. Make sure the capabilities you build for your product are effective in those contexts.
One way to approach applying this thought process is to ask, "Who are my (product's) important users?" Mentally separate the people who definitely use the product from those who might use it, and specify the rationale for excluding certain groups. Ask yourself how you know you've selected the right users. If you aren't confident, figure out how to determine which users are the right ones, and explicitly identify why the other people are not target users. Extend this line of thinking to addressing the other potential root-causes of product failure.
The primary benefit of taking this approach is that it enables product managers to create a better product. A secondary benefit is that it enables more intentional and effective decision-making and promotes more effective communication with the rest of the development team and stakeholders. When someone wants to know why their "pet feature" is not on the roadmap, give them a clear and accurate answer. This approach works because imagining a future-- then deciding how to improve it -- exercises the brain differently, allowing managers to develop insights that fix existing oversights.
Dig Deeper on Topics Archive
Related Q&A from Scott Sehlhorst
Application performance monitoring fixes a system before it breaks. IT strategist Scott Sehlhorst offers insight into preventive performance testing. Continue Reading
'Continuous development' is still a relatively new and confusing term. Find out what it means beyond the hype. Continue Reading
Scott Sehlhorst offers strategic guidance on how to approach application portfolio management with a focused vision. Continue Reading