PART 1 OF A 2-PART SERIES
*Not* Building: The Role of Simplicity in Product Management
Eliminating feature factories
Nearly every conversation about product management is about building something: either a new product or adding a feature to an existing one. In fact, many product teams are judged primarily by how many features they ship.
Yet most of the things we’re shipping are failing.
In their 2019 Feature Adoption Report, Pendo — an analytics platform that helps product teams understand and guide their users — determined that 80% of features in the average software product are rarely or never used. This translates into $29.5 billion that publicly traded companies spent on underutilized features in 2018. That’s money and engineering resources that could have been invested in higher-value features.
Why are so many products and features failing? Because we’ve built something that doesn’t solve a real customer problem in the first place, we’ve failed to properly educate users on the new feature, or we’ve made the new feature too difficult to use.
This two-part series will explore solutions to avoid building the wrong product or feature in the first place, as well as how product teams should make simplification (maybe even subtraction by killing features) part of their process in order to improve overall UX.
Part 1: How Product Managers Can Avoid Becoming Feature Factory Managers
Traditional approaches to product management are built around features and timelines. These are important, but when you start there, you end up managing a feature factory rather than shipping products that captivate customers and achieve business objectives. In order to build more successful products and features, we need to make sure we’re building the best possible solution for the right problem.
It’s been nearly three years since John Cutler wrote his now famous post “12 Signs You’re Working in a Feature Factory,” which concisely outlines some of the most common symptoms of feature factories. They include not measuring the right things, rapid shuffling of teams, and infrequent acknowledgment of failures, among others.
In a talk at a Mind the Product conference a year after that post was published, he traced most of these to a root cause of lack of trust. He also ended up writing a valuable trove of 15 follow-up posts to address some of his proposed solutions.
Yes, part of the ultimate solution is to improve trust within product teams and between those teams and the adjacent teams. But how? Improving trust sounds mushy. The good news is that there are tactics we can employ to help improve trust and will have a variety of other side benefits as well.
The tried and true advice here is: prior to building and shipping, start with the problem rather than the solution and you will ship fewer flops and more successes.
Focusing on problems first will allow you to define the right success metrics and enable you to focus on customer outcomes over product team outputs.
In turn, a focus on customer outcomes makes you more likely to achieve desired business outcomes.
(We should clarify the important difference between company outcomes and customer outcomes. The product management world often talks about focusing on outcomes over outputs, but let’s be clear that customer outcomes is the real focus. Company outcomes are a lagging indicator of delivering customer outcomes.)
After a product or feature has been shipped, if it’s underperforming, we have four options for action:
- If low awareness and user comprehension are the problem, we can increase our product marketing efforts.
- If discoverability and usability are the problem, we can improve the onboarding and user interface.
- If the feature is suboptimally built and/or lacks key functionality, we can improve it.
- If these efforts still fail, we should consider killing the feature.
We’ll dive deeper into how to effectively prune your product in the next post in this series.
We can avoid the feature factory fate by implementing the following basket of tactics that ladder up to the strategy of focusing on outcomes over outputs:
How-To:
- Make sure you have a clear answer to why you are building a particular product or feature. Is it a real solution to a real customer problem? More importantly, how do you know? Do you have market evidence? Have you organized and analyzed that evidence?
- Stop evaluating product teams based on how many features were shipped (output)! Instead, evaluate product teams based on customer outcome metrics and company outcome metrics.
- Create a culture of genuine institutional learning. Honestly evaluate what’s already been shipped in order to learn from past successes and failures.
- Connect the evidence from all of your sources of product knowledge to your roadmap decisions. That includes qualitative user feedback, market research, and quantitative product analytics. That means that your customer success, marketing, product and business intelligence/data science teams need to work together and share data.
- Conduct continuous discovery 🔎 and involve the engineering team in your discovery activities so that they fully understand (and have input into) the strategic rationale and customer context for anything they are asked to build.
- Make sure that your roadmap goes beyond the simple Gantt chart function of timelines and projects. A roadmap shouldn’t only be a forward-looking tool. It should be used as a historical database and include the WHY, not just the HOW and the WHEN. The hypothesis and supporting evidence for any given roadmap item should be one or two clicks away. When applicable, link items on your roadmap back to evidence from past launches, both successful and failed.
- Ask yourself before building: is this product or feature simple in terms of both purpose (it’s clear to our customer what value it delivers) and use (it’s easy to use)?
These tactics will take your team much closer to genuinely focusing on customer outcomes.
This strategy can be grouped into two buckets: 1) improve your company’s ability to answer for WHY before the HOW and WHEN, 2) improve your company’s ability to learn from past launches and measure more important things than number of features shipped.
If you put this into action, your team will avoid the feature factory fate by only building and shipping those products and features that will provide real value to your customers. You’ll ship fewer flops. Speaking of which, our next post in this series will dive into how to prune underperforming products and features.
Read part 2 of this series: “Subtracting: The Role of Simplicity in Product Management”.
We also produced an entertaining little video about feature factories:
