Building Features vs. Solving Problems
Every industry has its own language and way of working. You might even say different teams in software development have their own dialects. Depending on your organization and what methodology your team follows, you might speak in terms of standups, points, spikes, tasks, and of course features. But even your most passionate users do not care about the technology and process behind the product. They care about how well your product solves their problem.
Customers rarely think of the product in terms of how it was built, but instead the benefits they gain from using it.
Most of us get into product development because we want to build something useful. We want to solve real problems for real people. But the enormity of that requires distillation. So we break it down into the discrete efforts needed to solve part or all of the problem.
New technology is fun to work on and build. But over time teams can drift further from the high-level customer need and closer to the “feature set.” There are a variety of reasons for this. The product development team might not really understand the ecosystem within which the product exists — the world of the customer. Some folks prefer to operate in the safety of what they know, prioritizing work they feel confident they can produce rather than digging into what will make the most impact.
The mistake here is forgetting that what you build, customers have to buy. If you embrace a wholly product-centric perspective, you might neglect the gap between build and buy. That gap widens if you do not truly empathize with your end users. Imagine if your marketing team wrote about product benefits in the same way that product and engineering discussed features during backlog prioritization sessions. No one wants to buy background jobs with batched data and limited runtime. We want software to work fast.
You might have heard the cliché that product builders should fall in love with the problem, not the solution. So how exactly do you do it?
The truth is that you need the team to fall in love with both (and build something lovable in turn). It is not just about building for the sake of building something new. I wrote about many of these same concepts using my own terminology — ”lovability” — in our 2017 bestselling book of the same name. Back then I posited that “love is the surprising emotion that companies can no longer afford to ignore.” And I still think that is true.
Long-term product success relies on people who are deeply devoted to understanding and solving big-picture problems for others. The product must serve a cause much greater than the team and itself. Love is not easy. So if you are interested in helping your team focus on building what customers will love, here is some guidance:
Courage to solve
Finding meaningful problems to solve is difficult. You might think: "Hey, wait a second — the world is full of problems." Yes that is true. But realistically, most of the problems that necessitate a new product or enhancements to an existing one have some solution already, even if it is not ideal. Your theory for solving has to be grounded in actual need and promise an exceptional experience.
Depth of understanding
Finding a problem does not equate to understanding it. And unfortunately, clearly framed problem statements are rare in most organizations. Sometimes people get twisted inward and end up making business goals the problem. Put customers at the center of conversations. Instead of “How important is this feature?” narrow in on “What problems are our customers trying to solve in this scenario and why?”
Regard for value
Deciding what to build next can be difficult. Features are often prioritized based on a variety of factors, including internal pressures such as resourcing or stakeholder influence. But you need a complete view of product value that includes how well the features you build solve the problems your customers have. Choose a scoring system that encourages honest conversation and the ability to measure the realized value of shipped features over time, collectively and in isolation.
Eagerness to evolve
Product development teams ship software. Pressure to continually release new things can lead to a “ship it and forget it” mentality. What you want is a “ship it, measure it, and evolve it” mentality. If your team has the opportunity to solve a real problem, understands the customer's pain, and wants to deliver the most value to all — then you can earnestly engage in iterative improvement. You will be energized to look back and forward at the same time.
None of us want to build an exciting feature-rich product that no one uses — or worse, that no cares about.
Software waste is prevalent when user needs are unclear. Without a deep understanding of your customers' problems, you are unable to build solutions that truly matter. If you have a mature product development discipline in your organization, then strengthen it by bringing a healthy perspective to planning and prioritization discussions. A focus on sustainable value and tangible benefit to users is the crux of lovable products.
Anything is possible with the right team and the right software development tools.
