The Build Trap occurs when a software organization favors output-centric measures of progress over true measures of value.
As a result, shipping more software becomes the measure of success rather than delivering real value to customers or users, achieving business goals, or innovating incrementally against competitors.
This results in useless, complex, non-competitive, hard-to-maintain, and scale software because of the:
Inability to achieve long time customer satisfaction which increases churn.
Low-quality software with significant user experience (UX) and technical debts.
Many features should be handled by the user interface (UI), making navigation difficult.
The validity of customer requests will never be checked.
Increasing development costs and decreasing revenue is a result of the mistake of “implementing a feature without considering its value, and not measuring and validating it”.
Therefore, features have to be redeveloped many times to create expected value and help businesses to survive on the market.
A typical manifestation of such organizations is overemphasizing key performance indicators (KPIs), prioritizing features over goals, and putting pressure on development to deliver quickly.
Why does this happen?
Here are five main reasons why software organizations fall into this fatal trap.
Reason 1: Focus on features, not problems
Any Product Owner (PO) aspires to gain the favor of the customers to increase product usage. Therefore, discovering users’ needs, and how to address them are vital goals for building any product.
In order to determine what it should focus on, you need to apply problem-solving and experimentation techniques.
For example, the stakeholder interview assists POs in identifying and understanding the problems.
However, since there are no clearly defined approaches to problem-solving, you tend to be directive rather than questioning or challenging problems, which leads you to go around the shallow problem-solving approach.
The shallow problem-solving approach is firefighting and troubleshooting in which containment measures are applied, rather than a fix for the root causes. This makes you fall into danger of what David Bland calls the "Product Death Cycle".
The Product Death Cycle (PDC) is the vicious cycle of asking existing users for feedback, making exactly what they asked for, and repeatedly failing to gain traction with new customers.
The most crucial part of developing amazing products is understanding your customers well. But, it doesn't mean you should build all the features that customers request.
Your customers may ask you to build a feature they won't use. The cost of building products increases when money and time are wasted on things that will never be used.
Furthermore, the expectation of a customer may not be representative of the expectation of the majority of them. Therefore, the information from the sample customers can be biased.
At the end, the software product may fail and break apart when users who are not familiar with the product ask for a feature as a solution.
In order to be customer centric, you must put yourself in the client's position. However, brainstorming with customers to build and ship features can't measure problem solving success.
Therefore, POs should address problems to tackle this challenge from a product perspective. Moreover, it is essential for them to answer the following inquiries:
How to grow and maintain software products?
How to produce ongoing product value?
How to maximize customer value?
Reason 2: Lack of product goals
David Pereira said, without a clear direction, teams are like dogs chasing their tails. To determine whether we are getting closer to achieving our product initiative, we need to break the success metrics into something we can measure on a shorter time scale. This is what we call a goal, and it measures the success of assumptions and gives us feedback if our assumptions are working as expected.
Features are functionalities within products that help users accomplish specific goals. Once you set goals, you will be able to identify which problems need to be addressed. Moreover, it ties feedback to issues rather than features.
If you don't set the right goals, your organization, and team will be motivated by other priorities.
Thus, the goals help shift the mindset from simply building and launching features to being outcome focused, setting the right direction, and ensuring that they’re achieved via the initiatives pursued.
If you don't follow goals, leadership will want more frequent product updates, the company will want to complete projects, and sales will want to implement new features to help bring in leads and close more sales.
The team can only maintain an outcome-focused mindset by setting the right goals, KPIs, initiatives, and features.
The organization must therefore always be challenged by these whys:
Why are we working on this?
Who asked for this?
How does working on this contribute to achieving long-term objectives (quarterly/yearly)?
Does this initiative raise any risks that we should be aware of?
Does this make sense based on other priorities at this time?
How have we validated this?
Reason 3: Strategic gap
A strategy gap is a discrepancy between an organization's current and expected performance. Poor strategy results from insufficient situational awareness, poor decisions, or lack of a clear idea of how to respond.
Stephan Bungay said that when organizations treat strategy as a plan, they often fail to achieve their expectations due to the friction gaps between outcomes, plans and actions.
These friction gaps include:
The knowledge gap between what management wants to know and what the organization really knows.
The alignment gap which is the difference between what software teams do and what management expects to do to reach the desired needs.
The effect gap is the discrepancy between what we intend for our activities to accomplish and what actually transpires.
A strategy should include operational and strategic frameworks to avoid swirls in planning and execution.
The operational framework outlines how to keep the business' daily operations running smoothly. The strategic framework explains how the products and services can achieve the business vision.
The organization faces severe difficulty due to mistaking these two frameworks or handling them as one.
Reason 4: Confusing building to learn with building to earn
A valuable product can only be produced through experimentation.
Building for learning will help you better understand your customers, demonstrate whether solving a problem is worthwhile, and validate your assumptions.
Because of this, determining how much learning can be accomplished, rather than how quickly features can be added, is the most crucial component of a Minimum Viable Product (MVP).
That's why it's always important to answer:
How quickly do we need to learn the product?
What can we do to avoid it being designed for the long term?
When considering developing and releasing an MVP, it's important to strike a balance between the value you can capture and the release's scope and time constraints. The balance between these factors is difficult to maintain.
This is referred to as an "optimization problem".
Despite the fact that budgeting and value creation should be aligned, tying them together is a common mistake.
The way organizations handle budgeting is one of the variables that contribute to the mindset of output over outcome.
As a result of traditional budgeting, the team is unable to change course throughout the year due to forces on having deliverables and limitations in learning and iterating.
Reason 5: Optimizing outputs
You optimize for outputs when you increase the number of features, the number of releases or the velocity of development teams.
You can find the goal of many leaders is to optimize output to meet more customer demands because measuring outcome is hard, so they measure output instead.
This behavior treats software production as car production. The car manufacturers increase production velocity or capacity to achieve maximum output per production line. In this sense, people are resources for building like cogs in a production line.
However, the process of making software is in no way comparable to that of making a car. Since features for software are added to existing products rather than sold separately, this logic cannot be applied in the software industry.
Instead, we should define and measure value and build products around it. In other words, we look for iterative and incremental value in the software industry.
Thus, the goal is no longer solely focused on developing features in accordance with a specification. It is the process of progressing towards the product's objectives in order to achieve value.
The leaders need to cease thinking of teams as manufacturing units and stop judging them based on the number of features they ship.
Instead of leaders’ classical management perspective of focusing on improving outputs they should think about how teams should be coached to provide correct continuous inputs during an iteration of development in the software development process to have proper outcomes.
Example of a build trap
Here's an example of the build-trap being caused by incorrect input and overemphasizing output optimization.
The leaders who have classical management perspectives translate roadmaps into specifications for delivery teams. They won’t distinguish between roadmaps and lists of features that have to be released.
Then, customers are provided with a Feature-Date driven roadmap showing when the features will be delivered.
The problem is that customers take these timelines as commitments, which means there will be external pressure to deliver on that list, even if the features turn out to be unimportant.
This behavior forces teams to deliver feature after feature even if the strategy, user needs, or behavior changes
Moreover, when there is a plan for when features are to be released, teams won't consider measuring the actual impact of the features to achieve a goal. They only concentrate on building deliverables as soon as possible.
This type of roadmap fails to explain why things are being built, why things have been prioritized, and what the end outcome should be.
This example shows how the development team, due to a lack of proper input and focus on output, has been caught in the build-trap. Optimizing for output results in increased waste production and higher costs. Whereas optimization should increase the proportion of launches with positive values.
Conclusion
It is difficult to measure value well from the perspective of users.
When a team does not understand its users’ problems well or does not take the time to learn them, it cannot possibly define value for them.
Therefore, the value becomes the quantity of features that are delivered, and the number of features shipped becomes the primary metric of success.
The organization will play a game of catch-up—trying to fast-follow its competitors on every feature it releases, and the management insists on parity even though it didn't even know whether these features worked well for competitors.
Consequently, the organization over-promises during the sales process, giving customers whatever it takes to get the contract signed, instead of a strategic choice to build what would scale for many customers, many features are built to satisfy the needs of a few customers.
Moreover, the organization decides to remain in reactive mode instead of analyzing how each of these features provided unique value to its customers.
The company loses sight of what makes its product attractive to customers and what makes the company special.
In order to avoid it, you need to understand your customers and users' needs deeply, and determine which products and services will meet customer and business needs.
To achieve this understanding, organizations need to bring their employees closer to their users, so they can learn from them. This requires the right policies throughout the organization.
Furthermore, continuous product discovery should not be ignored, customer problems should not be misinterpreted, and deliverables and enhancements should not conflict with product strategy.
Bibliography
Melissa Perri Escaping the build trap: how effective product management creates real value. [O'Reilly][2019]
David Pereira Without a compelling product vision, teams become feature factories. [Online][Cited: 2022-10-06]
Itamar Gilad Feature factories vs. Value generators. [Online][Cited: 2022-02-02]
Andrew Chen The product death cycle: why it happens, and how to break out of it. [Online][Cited: 2021-07-15]
Behzad Nazarbakhsh
Read also
Prioritize with confidence
