Stop building features & start solving problems
Congratulations, you just launched another solution desperately searching for a user problem — because clearly, what the people really need is yet another shiny button they’ll never click. Stop playing “Feature Bingo” and start solving actual user problems please. Unless you enjoy watching your hard work gather digital dust (with the other 80% of features that are rarely or never used).
The tension between Design, Product, and Engineering is one I have tremendous respect for. With the proper balance, these tensions can create exceptional products that are easy to use, fill market gaps, make money, scale, and launch quickly. In other words; they can harmonize better than George Michael’s Careless Whisper. You’re welcome for that.
This idea of balancing desirability, feasibility, and viability isn’t new, and design strategy is only one aspect of overall product success. However, there is a common trap well-meaning individuals (usually Product partners if we’re being honest here…if my PM is reading this I don’t mean you, you’re great) and teams looking to create high impact features fall into, and it happens more often than we think: Subconsciously asking “What is our product missing?” rather than “What problems are we solving?”
The Feature Trap
As mentioned above, what I’ve seen happen time and again, perhaps not blatantly but in subtext, is that the question being asked in a project kick-off is not “what are users struggling with?” or “what do our users need”, it’s “what don’t we have?”
This can take many tactical forms, often using business analytics or behavioral data as a foundation for justification. It can look like a drop-off rate on a particular page, a feature gap, or the dreaded “our biggest competitors have it, so we should too.”
Now rarely, if ever, do these assumptions rear their ugly heads so blatantly, but the sentiment is the same; so what we end up with is products full of features and little value.
I’ll admit there are instances where adding features might be necessary for market competitiveness. However, even in these cases, the addition should be driven by validated user needs and anecdotes rather than market trends. Even looking at behavioral data in isolation is a huge pitfall for furthering this patten of thinking. The key is to maintain a balance between innovation and simplicity is always keeping the user’s core needs at the forefront. This will inherently lead to better business metrics too…
The Data Speaks
A study by Pendo found that 80% of features in the average software product are rarely or never used. This translates to considerable unnecessary expenditure in development and testing resources. The same study claims that up to $29 billion (yes, with a big ‘B’) was spent on developing these features.
More recent research supports this as well: A 2021 study by ProductPlan found that 51% of product managers struggle with feature bloat, and then there is the Standish Group’s CHAOS Report which consistently shows that unused or rarely used features contribute to project failures.
By pushing our businesses to move faster (too fast) we’re encouraging and launching products dripping with features, and leaving unimpressed customers in our wake.
Ultimately, by framing product opportunities as customer problems, we risk creating solutions in search of problems.
This approach leads to feature-bloat and decreased user satisfaction. And seriously, no one wants to be associated with the word ‘bloat’.
A Better Approach: Hypothesis-Driven
Instead of assuming that a feature deficit is inherently a customer problem, teams should adopt a hypothesis-driven approach. Consider this scenario: A product team muses that “customers want to purchase items directly from search results.” They may even go so far as curating a customer problem sounding something like “customers have no way to make a purchase from search today”.
While this might sound like a customer problem, it’s actually a product opportunity masquerading as a problem. The true issue may be:
- “Customers struggle to find and complete purchases efficiently.”
- “The current purchasing process is perceived as overly complicated.”
- “Users are unsure of where to go to find a product they want to purchase”
- “users would like a way to purchase content sooner in the journey”
By reframing the issue, we automatically open a wide range of potential solutions beyond simply adding a purchase option to search pages. Sure thats ONE solution, but is it THE solution?
Using the same example, we could write a hypothesis: “If we simplify the purchasing process, and make it accessible from more placements (e.g., search results, landing pages, or deep links), we will see an increase in completed transactions and customer satisfaction.” Or if the problem is “Customers struggle to find and complete purchases efficiently” then is it a discovery problem, or a purchase problem? Based on this statement alone, it’s unclear. We need to generate a hypothesis as to why the problem is happening (based on, you guessed it: data)
This approach allows for a much more flexible and targeted set of potential solutions, and possibly leading to innovations that may not involve adding features at all. In fact, sometimes the solution involves removing features.
It’s crucial to emphasize that effective hypothesis-driven development needs user research (uh, duh?). Understanding needs, motivations, and pain points is essential for identifying REAL problems and crafting meaningful solutions. The “Jobs to be Done” framework by Clayton Christensen comes to mind as an example on how to understand motivations beyond surface-level feature requests.
Measuring Success
When focusing on solving user problems rather than adding features, success metrics need to shift beyond the behavioral data, and instead of tracking the number of features launched, or how many a/b tests we’ve run — teams should focus on user satisfaction, task completion, as well as overall product adoption as a KPI, not just $$ based metrics (gasp!). The Kano Model for product development and customer satisfaction comes to mind as a great way to identify and prioritize features that truly matter to users.
A Call to Action
As we move forward in an increasingly competitive product landscape, it’s essential to challenge these assumptions when we see them, and dig deeper into what users actually need. Only by doing so can we create products that not only meet market demands but also provide real value. This means you (yes, you) need to start critically looking at the requests that appear in front of you. It’s way easier to be the design monkey that bangs out exactly that was requested, but then you’re just a big a part of a problem. Think critically about the problems you encounter, and identify if it’s a customer need, a feature gap, or even worse: just a thing someone wants to do cause they need to meet a project-count goal.
In my opinion (which may be implied since I’m writing this specifically to share my opinion, which no one asked for) The distinction between product opportunities and customer problems is crucial for creating high-impact, user-centric products. And who wants to build or create products with low impact!? By focusing on genuine customer problems, forming testable hypotheses, and conducting thorough user research, we can avoid the pitfalls of feature bloat and create truly innovative solutions. This will however, force us to think beyond the obvious gaps, and be intentional about every pixel our users see.
For a little extra reading, and because citing your sources is sexy:
- Pendo study on feature usage and development costs: https://www.pendo.io/resources/the-2019-feature-adoption-report/
