Avoid waste and promote rhythm
We've reached session 11 of the product management program at the Tramontana Institute.
A session where we emphasize how, in digital, the HOW determines much of the WHAT.
The third moment of our discovery machine is when we rush the capture and molding moments into construction.
It's a critical moment in digital product development, which is often neglected and ends up being the root of numerous problems that can end up being decisive for the very viability of the business.
The digital product industry tends to be a waste industry.
First, because it doesn't usually implement discovery processes or traffic lights to decide when it's worth delving into conjectures.
But also because when it jumps to execution, it usually does so without establishing a perimeter.
When, in addition, teams work in silos, passing the baton, the problems arising from this lack of limitations multiply.
Agile methodologies cannot improve this situation on their own.
They can even worsen it by creating a false sense of agility, but that doesn't translate into speed or clarity.
> We practice techniques to reduce waste and generate rhythm. Development is unwrapping a scope ----------------------------------------- Working with open problems in a digital product means accepting that we are not good at estimating.
That is, it is not a field where we can move in exact times.
Also, the final scope of what we're designing isn't something we can set as a starting point and then establish its duration.
Scope is a variable.
Developing software is, therefore, developing the scope of what you're designing.
The task is the most common reference when working on something you want to develop.
The delivery mindset is the result of starting from that foundation and addressing complexity from there.
Although the working and organizational methods in consulting provide the best examples of this anti-pattern, digital product companies often operate in an analogous way.
A large solution versus a small solution is simply understood as a larger sequence of tasks.
> The so-called wicked problems are complex problems. In most cases, however, we are faced to open problems, intrinsically complex problems.
Partly due to issues we saw in the first sessions, which have to do with the specific nature of the software.
Partly due to issues we've been seeing about how difficult it is to obtain evidence of what really happens.
Finally, partly because demand—the client, the problem, etc.—is the unknown that we don't know how to solve, and therefore many possible solutions open up to us from the same opportunity.
Modeling is not writing or designing in Figma.
------------------------------------------ The way you approach the development of something, including the tools you use, determines its outcome.
The best antidote to not failing too much is to move at an intermediate frequency between what is too abstract (the word) and what is too narrow (the pixel in Figma).
In this way, you can maintain the connection between the opportunity that originated the decision and the conjecture that led you to move it to that moment of construction.
To a large extent, everything that is usually written in digital product literature about the importance of focusing on the outcome and not the output requires that connection to be kept alive.
[
](https://world.hey.com/inigo/a64786a4/blobs/BAh7BkkiC19yYWlscwY6BkVUewdJIglkYXRhBjsAVGwrBxiuZ3ZJIghwdXIGOwBUS SIMYmxvYl9pZAY7AEY=--69e43609bd8d7c0585dbdd998916780764ec8e77/Screenshot%202025-01-28%20at%2023.31.18.png?disposition=attachment "Download Screenshot 2025-01-28 at 23.31.18.png") ```
You must enter construction at the correct scale.
The key point is all those techniques in which you can combine words with graphic elements; flow circuits where you favor the view of the forest rather than the trees in particular; graphic strips where you represent scenes to connect with the context of the opportunities; heterogeneous materials—photographs, sounds, videos, annotations on screenshots, etc.—that help you connect with the situations in which what you invent is inscribed.
Don't invent like an assembly line -------------------------------------- The moment of shaping helps you avoid conceiving product development as a simple passing of the batons.
It's really a collaboration.
From that very moment of beginning to sketch out the opportunity, its perimeter, and the scope of the different solutions with which you could manage it, you need the participation of different points of view and experiences to contrast and enrich the approach.
Organizing initiatives, and even entire verticals or thematic areas, into teams makes sense from this perspective: you have to give them responsibility so they can make numerous decisions during the construction process itself that will also determine the final outcome.
To avoid falling into the usual spiral of seemingly endless projects, and the resulting feeling that the entire organization is moving slowly and ponderously, you have to avoid falling into the trap of believing in estimates as a way of planning.
Introduce a time limit yourself, so that it forces you to turn the time sock inside out: not how much time you need for something—that "something" in digital can consume all the time you give it—but how much time you give to that something—based on your **appetite**.
[](https://world.hey.com/inigo/a64786a4/blobs/BAh7BkkiC19yYWlscwY6BkVUewdJIglkYXRhBjsAVGwrByDuZ3ZJIghwdXIGOwBUS SIMYmxvYl9pZAY7AEY=--83ce1e1452713ceebc61c962fcb31feb486bab38/Screenshot%202025-01-28%20at%2023.47.53.png?disposition=attachment "Download Screenshot 2025-01-28 at 23.47.53.png") > Giving story points is also a way to deceive yourself and fail. Since your way of starting to build takes a sketch as a starting point, it is important that teams internalize a sense of **urgency and Day 1**: publishing every day in the development cycle itself is a way to gradually uncover unknowns and reduce risk, so that the team can modulate the scope as they discover things.
They must, therefore, show progress and communication from that day 1.
Companies whose business consists of a digital product are, thus, eminently communicative entities, which need to favor profiles that move with ease both asynchronously and synchronously.
Are they perhaps a kind of well-oiled marching band always performing a kind of structured improvisation?