Revisiting the build trap — how debts slowly kill your product
In “Escaping the build trap”, one of the greatest books about Product Management in my opinion, Melissa Perri explains how teams get stuck by being obsessed with building always more features.
4 years later, little things have changed from what I can see or hear. I am no better than the others : on my new project WILL, I myself fell into this build trap, whereas I was highly aware of it, plus I was funding my project with my own money. But yet, I definitely fell into it during the first time of the project.
Fortunately, after crashing a first company, I was lucid enough to escape the build trap before it was too late. I started iterating deeply on one “feature” that had some traction. What I became really aware of, and that I missed before, is how much we fail to make an impact by jumping from one feature to another.
I didn’t realize that, without many iterations, a feature will never reach more than 20% of its full potential. So you end up with a broad range of mediocre features that not only don’t make any difference for your users, but also create massive debt that slowly but surely kills your product.
Enjoy the read !
Entering the build trap
Here is the common starting point of any product team entering the build trap: the team is under a lot of pressure, there is no real market fit. Many business stakeholders are waiting desperately for features they promised to their clients, or have been asking for months. The team is feeling the urge to deliver! And here is what happens…
Feature #1 : everyone (in the company) is happy
The product team starts with the most prioritarian feature (probably the one being asked for by the CEO, see this article).
They have been asked for a solution, not a problem to solve, least again a need to answer. They don’t have time to do a proper discovery. So they rush into building the solution. Yet, once released, they try to do what they think is Discovery but which is nothing else than usability testing. This is great, but useless if the feature is not valuable. Nevertheless, it allows the team to correct a few basic bugs, both technicals or functional.
The developers ask for time to clean the code because to ship fast, they had to make a trade off on code quality. The PM answers they don’t have time, showing the never ending backlog they still have. “We’ll do it later”. The CEO shows up, congratulates the team for the long awaited feature they just shipped. Everyone feels happy, thinking they are on their way.
Energized, they move to Feature 2 instead of cleaning the code. Other business owners keep knocking on their door…
Feature #2 : velocity increases
The team moves to the next feature, the one from the team yelling the most loudly. On the graphics above, the second feature’s “outcome potential” starts lower than the previous one. The PM does not really realize it, they have even less time to think about the feature from a customer perspective, it’s only a pure business perspective dictating the choice of the feature to ship.
The developers code this new feature at an even lower code quality standard because they are still under a strong pressure and because the PM had less time to clarify the problem space and think about edge cases that allow the dev team to properly design the architecture.
It doesn’t matter. Features are shipped faster than before, and everyone in the company is happy with that.
Feature 3 : velocity keeps increasing (but not the impact)
In the meantime, a new developer finally joins the team after months of head hunting. The dev is onboarded, quickly. The dev is a bit anxious when digging into the code, everything is a mess. “We’ll fix that later ‘’ answer the other developers. “We have a “fix the debt” ticket waiting in the backlog”.
The PM becomes stressed because the dev team is shipping fast, preventing them from doing discovery and properly designing new features..
The PM needs to make shortcuts, creating shadow designs since no UX designer is available to work with them. Indeed, the designers try to set a design system so that the app is more homogeneous, but this kind of shadow design keeps undermining their efforts…
The PM doesn’t have time to iterate, even on the usability testing parts. On this third feature, they hardly iterate twice… The developers are shipping code like hell, the PM needs to keep the pace and feed them with new things to do… The team had managed to increase its velocity so that they shipped the third feature in less than 2 weeks
Feature 4 : first signs of overheating
The PM now only writes specs, especially since the latest dev has joined. They hardly have time to test, the cycle time of iteration reduces. The relevance of the features also, some of them were lying in the backlog for months but became irrelevant in the meantime, because the context changed without business owners being aware of it.
Newly released features add complexity, both functional and technical, to the feature being developed. This fourth feature takes more time to develop. From 2 weeks on the last feature, the time to ship this new one raised to four weeks…
Feature 5 : the feature factory starts seizing up
The debt has been accumulating and becomes impossible to ignore, making everything new very slow to develop. Bugs pop from everywhere at any time. The velocity drops insanely. Dependencies with features 1 or 2 appear and make the whole thing way more complex to develop and to maintain…
Worst thing : features 1 and 2 are hardly used, as the PM notices filling his weekly report for the business owners. Hardly no real value has been created for the end-user. No profound impact was made, creating no value for the company’s product.
The team feels demoralized, back to the starting point. Business owners are becoming mad again because everything is so slow…
Some root causes of the build trap
How is it that we all are so deeply attracted to the build trap ? By taking a step back, explanations popup, that are not always easy to deal with…
It’s rooted in our own biology
Human beings need to “do” stuff. Left alone in a room for 15 minutes with nothing else to do than the opportunity to self administer electrical shock (!), more than 50% of the people in the experiment hurt themselves with these shocks…
Every time we do something, our organism relieves dopamine that pleases us. Something very useful at the beginning of humanity when we needed to go out from our caves to hunt, it now tends to become irrelevant in our economies where quality and relevance matter more than quantity.
Not enough discovery
We usually don’t do the right thing, because of a lack of discovery. We end up doing what we think our customers want instead of what they really want.
Thus, the features we ship we do dont make any differences. So, we try to do ship features with the hope to make a difference. Since no more discovery is done, same results happen. The vicious circle is on.
We focus on problems rather than needs
Many people define Product Management as “solving problems”. Since problems are endless, you are up to enter the build trap ! People should rather climb up to the above level in the product pyramids and answer needs rather than solving problems (more info about this in the Product Pyramid).
We should talk about “obstacles” rather than problems. You have an obstacle if you have a goal to reach (user’s need). Otherwise, you just solve problem for the beauty of solving problems.
We want to do things fast
Another strong belief in Product Management is that velocity matters. So instead of improving existing features to their full potential, product teams move very fast from one feature to the next, as soon as they release it. It results in a broad range of poor features creating a lot of debt but no outcomes.
We have too many developers
You read well. I know everyone complains not having enough techies inside product teams, but think about it…Some teams have up to 6 developers for one PM. This is insane ! The PM hardly has time to fill their backlog to feed the developers with things to eat.
To feed their backlog, PMs enter a vicious circle where features become less and less qualitative, both in terms of outcome and code quality, creating always more debts (functional and technical). These product teams are doomed to ship features, again and again. It leaves not enough time to wonder if the features already built were relevant because you are already thinking of what you should ship next to feed the tech team.
It’s easier to measure outputs than outcomes
Outputs are easy to measure. You can track the velocity of each of your teams, this might reassure the CEO and the company. Outputs are tangible : it is easier to say we “released X features this quarter” than “We created X impact this quarter”. But outputs are vain, they might never create any impacts…
Escaping the build trap
Is there another way ? Fortunately, yes. It might be hard, especially when having multiple stakeholders to deal with, for instance in large organizations. Besides, you need time to prove the efficiency of this different way of doing, a time you might not have… If you want to make time, this another story, just come and join us at the WILL Academy to learn how to make time for what matters !
Iteration #1 : far from perfect
The team has identified, after some user research, a real need to tackle. The team has identified one main obstacle (problem) preventing users from fulfilling this need and has come up with a feature (solution) that might tackle it.
The team quickly codes a prototype enabling them to get feedbacks from users. Once this first feature is shipped, the team spends significant time on the field observing how the users interact with this first prototype. Many learnings pop up. The PM has time to truly investigate the way people use the product and if it is valuable for them, not only check if it is usable.
Iteration #2 : getting better
The conclusion is that there is a lot of room for improvement. The PM makes a recap to the team of what they observed and the whole team is in the starting blocks for a first iteration. Again, the team develops quickly to adapt and make quite big increments instead of just usability improvements.
Going back on the field, the PM sees the product has become more valuable for the users even if some new insights pop up as the product has evolved. There is still room for a new iteration. While the PM is on the field, the developers fix the broken code and make it cleaner. The technical debt remains under control.
Iteration #3 : on the way to full potential !
The PM has it clear now about what to do to reach the full potential of the feature. The developers start working over the feature for the third time. It’s been more than two months the team is on this feature but everyone is deeply convinced of the impact it will have on the users.
The PM is back on the field to check this last evolution was right. The tech team starts polishing the code and killing the remaining technical debt. The PM knows the feature is close to its full potential and that it is possible to move on to the next need/obstacle/feature. It took 3 months to reach that potential but no doubt it was worth it and will make a difference with the competition !
A few words over debt
Debt is the cancer of your product. It grows with compound interests. At the beginning, you might not realize it, and all of the sudden, you get stuck. Every new development takes weeks or even months. Companies often react to this kind of situation by hiring more developers, which makes the situation even worse.
Finally, you reach a dead end where your app becomes a dinosaur that cannot move anymore. Developers start leaving the company because no one wants to work on such a mess, then PMs. Only then do business people realize that tech teams were complaining for good reasons.
Let’s have a closer look at the two main kinds of debt and see how to handle them.
Technical debt
The most obvious kind of debt is technical. Business people usually don’t understand what is at stake: code entropy, growing complexity of code base killing developers’ enthusiasm and productivity. Technical debt is invisible to them. Event storming might be a great solution to create awareness amongst business people of the code complexity while making things way clearer for developers.
The most difficult aspect of software engineering to me is to choose the right balance between quality and productivity. Sometimes you might need to go fast and lower the quality but then, you need to be able to make a pause at some point and clean the mess you created. By decoupling parts of your code (even without any micro services architectures), you can adapt the balance between quality and productivity on some pieces of your app without threatening the whole system.
Functional debt
Functional debt is more visible than technical debt. It starts with heterogeneous design among all your app screens, with some different design components used for the same functional goal. It creates mental load for your users, confusion. It creates overwork for your PMs, devs and designers that get confused to know which version to use. The solution would be a clear design system, but designers might be overwhelmed trying to design hacks for urgent features…
A more subtle form of functional debt comes from features that once might have been useful but for some reasons are no more relevant. A tiny portion of users still use them, but they create technical dependency, over testings and extra maintenance every time you develop new features. The solution would be to kill these features, but it is often very hard to do so !
Conclusion
As you went through this article, you might have realized that the takeaway is always the same : just do less. Less is always more. Less is more impactful. Less is simpler. Simpler to understand for users, simpler to maintain for developers, simpler to test for QAs, simpler to market…
It’s only when you get no more resources that you realize that your product does not need continuously new features to be better. It’s only when you have really limited resources that you find better ways of doing… Because you need to focus on what really matters for your users.
If you liked this article, feel free to subscribe to my newsletter “Opale is the new black” and avoid the filters of social networks’ algorithms.
If you want to support me (as I am not a writer), feel free to have a look at my latest venture, WILL, an amazing method to solve your most common work problems (conflits, misalignment, overload, collaboration…)
