There's a certain sting suffered by a developer when they spend months perfecting a feature that users ultimately didn't want and they end up going back to the old version. I've found out that this is a phenomena known as Solution Bias and I have myself fallen into it, even at the most advanced stages of building. If we knew why people actually "choose" software, we wouldn't have to build monuments to our own technical abilities, but focus on building the tools that users really need.
Moving Beyond the Build Trap
There's always been something missing in the engine of digital transformation – particularly in the realm of AI-driven software development. According to the Harvard Business Review (2019), only about 85% of innovations manage to establish a sustainable market position after two years. Moreover, a study conducted by McKinsey (2023) indicates that 94% of executives believe that their organisation's level of innovation can be improved.
I have found in my experience, this is typically the Build Trap, and typically at that point, there is a lack of understanding of the mechanics. This organisational trap is when we're thinking about success by shipping the features (outputs), and not creating value (outcomes). The primary component behind this is what I call the "Solution Bias," which means the tendency to think about how to make the technology work more than what the software is supposed to do for the user. I have experienced this firsthand: sometimes we invest too much time in a complex solution and forget that our users are not purchasing products based on the number of features they offer, but instead, they are purchasing products that will help them make progress in a certain context.
In a product-led method, software is a vehicle of value. Melissa Perri believes that value is created when a product doesn't just exist, it solves a problem. If we forget this, we may end up “feature factories,” who just track velocity or tickets. As mentioned in the book Escaping the Build Trap:
"When companies do not understand their customers’ or users’ problems well, they cannot possibly define value for them. Instead of doing the work to learn this information about customers, they create a proxy that is easy to measure."
To get beyond this model or mentality, the emphasis needs to be shifted from Implementation to Impact. When there's no tangible goal that will be met by a solution, like "improve reporting accuracy by 15%", technical complexity won't be the primary concern.
Hiring for the "Job," Not the Format
We need to take a look at the concept of Causation vs. Correlation to get a grasp of why simpler tech can win. Demographics such as age or profession are used in traditional marketing, but as late Clayton Christensen said, “Demographic doesn't cause a purchase.” Professors don't purchase the New York Times due to their jobs, they "hire" it to keep them up to date. At the heart of Jobs-to-Be-Done (JTBD) is this. It's a trick I have used many times to segment the way customers "hire" products into three parts:
- Functional: The practical task (e.g., "I need to stay dry").
- Emotional: How the user feels (e.g., "I feel confident").
- Social: How the user is perceived (e.g., "I want to be seen as environmentally conscious").
I often refer to this as the Netflix vs. Blockbuster scenario. The previous infrastructure, physical stores and late fees was a key part of Blockbuster. Netflix knew that the job was: convenient, instant entertainment. Whereas Blockbuster worked on optimising the legacy delivery model, Netflix worked on the job of entertainment, and eventually, it included a threat that included competing against cable, video games, and more.
It's happening in modern software evolution, too, e.g. the emergence of ‘Zoom’ over enterprise tools. Over the years, the developers concentrated on enhancing the security and complicated administrative offices. But Zoom realised the core functional job was merely "to join a meeting without friction. They made it easy for users to dial in using just one link, bypassing the need for a required account. It was not the innovations of better video.It was not the innovations of better video. They were able to gain more insight into the truth of the beginning of the working day.
The Paradox of Technology: Navigating Perceived Risk
I've got a mental block that I get all the time, called the Paradox of Technology. A functional benefit increase of a product can also lead to an increase in the user's perceived risk. The research conducted by Darius-Aurel Frank on Negativity Bias indicates that negative attributes (perceived risks, cognitive barriers, etc.) can be more salient to a user's mind as compared to the advantages it promises.
Face ID and the iPhone X is a classic example of this. Though technologically advanced, the adoption of the face recognition tool was met with much resistance, particularly as opposed to the more conventional and well-established Touch ID method. However, today, it is considered a trusted industry standard. The friction generated in such cases often follows a Serial Causal Chain:
New Information -> Increased Perceived Risk -> Lower Trust -> Delayed Adoption
I’ve seen this happen before: users will often stick with a "reliable" or familiar product they trust over a "superior" one that makes them feel uncertain. We see this in Bob Moesta’s "Dining Table Problem" in real estate: buyers often hesitate to move into modern condos not because of the floor plan, but because they can't fit their existing furniture. An emotional attachment can outweigh technical upgrades. If software ignores these contextual realities, it risks being set aside by the user.
Roadmapping for Impact
To avoid Solution Bias in my own work, I’ve moved away from rigid, timeline-based roadmaps, which can often become "feature lists with dates." Instead, I adopt the Now-Next-Later framework focused on Strategic Objectives:
- Now: Address immediate Struggles & Pain Points. Instead of "Add AI Chatbot," the objective is "Reduce support response time by 20%."
- Next: Explore Non-Consumption. Look at why people aren't using your software. Southern New Hampshire University (SNHU) did this by realising adult learners prioritised speed and flexibility over a traditional campus experience, leading to $535M in revenue growth.
- Later: Long-term goals that align with the Product Vision.
Focusing on the Why over the What allows for technical flexibility. If a specific feature isn't achieving the desired outcome, I can pivot without the "sunk cost" of a complex build that the market isn't ready for.
The Practical Question for Product Teams
Innovation is rarely about asking users exactly what they want. As Henry Ford noted: "If I had asked people what they wanted, they would have said faster horses."
The goal of a strategist is to identify the "job" hidden beneath the request for a "faster horse." Products are tools to help us progress. Shipping code is a secondary metric if the primary "job" remains unfulfilled.
As you plan your next sprint, look past the technical elegance and ask: Are you building your magnum opus for its own sake, or are you solving the real-world problems your users are actually facing?