Waste, validations, and launches

In the twelfth session of the Instituto Tramontana product management programme we crossed the threshold that had been left open in the previous session. After having covered the moments of capture and shaping, and having designed the traffic lights that regulate the discovery flow, the time has come to address what happens when a conjecture reaches the development space. And this is where one of the most persistent problems in our industry appears: waste.

The digital product industry is, all too often, a waste industry. Not only because it rarely implements discovery processes or traffic lights to decide when it is worth going deeper into a conjecture, but because when it does jump into execution, it usually does so without setting a perimeter. When, on top of that, teams work in silos passing a baton from one to the next, the problems that stem from that lack of boundaries multiply. Agile methodologies cannot improve this situation on their own. They can even make it worse by creating a false sense of agility that translates into neither speed nor clarity.

Open problems, not sequences of tasks

The task is the most common reference when working on something to be developed. The delivery mindset is the result of starting from that base and treating complexity from it. A large solution versus a small solution is understood simply as a longer sequence of tasks.

In most cases, however, we face open problems — intrinsically complex problems. Partly because of the specific nature of software, which we explored in the first sessions. Partly because of how difficult it is to obtain evidence of what is actually happening. And finally, because demand — the customer, the problem — is the unknown we cannot solve for, and therefore many possible solutions open up from a single opportunity.

Experience is full of situations that confirm what the literature on software project management has been synthesising: increasing resources — in every dimension: people, tools, materials — when dealing with open problems can end up making the problem even larger.

From output to outcome

The rationale for an open problem begins with its conjecture. The effect of that conjecture — that is, the expected benefit — is what should serve as a guide throughout the entire process. It is not about delivering features, but about pursuing an outcome.

When we work with open problems, the question should not be "what list of things do I need to deliver?" but rather "what benefit am I pursuing?". This changes the conversation: instead of negotiating what I must sacrifice from a closed list, I ask myself what effect I want to produce and how I can get there. It is the difference between a team receiving tasks and a team receiving an objective.

This shift in perspective has direct consequences for how scope is managed. If the team understands the expected benefit, it can make decisions about what to build, what to simplify, and what to discard. If it only has a list of tasks, it executes without any criteria for deciding what is essential and what is not.

Shaping is not defining requirements

Shaping a solution is not the same as defining requirements. The difference is fundamental to avoiding waste. Shaping means moving between words and pixels: giving an idea enough form for a team to understand it and start working, but without closing it off so much that there is no room left for the decisions that can only be made while building.

There is a balance between too open and too closed. If the solution is framed too openly, the team has no clear starting point and can get lost exploring. If it is closed too tightly, it becomes a list of requirements that eliminates the team's ability to adapt to what it discovers.

Good shaping involves four things. First, establishing a bounded contour, not an exhaustive list of items. It means saying "this is what's in and this is what's out", not specifying every detail. A list of bullets is not shaping: it is a requirements document in disguise. Second, noting potential risks. Before a team starts building, it should be clear what could go wrong or what questions remain open. Third, explaining the solution as a whole, not its individual pieces. Good shaping conveys the complete experience you want to create: how the parts relate, what the flow is, what the user is expected to feel or do. And finally, moving between words and pixels: combining narrative description with enough sketches to make the intention understood, without reaching the level of a finished design.

Time as a firebreak

Time is the most effective resource for putting limits on waste. Instead of estimating how long something will take — which is a way of fooling ourselves when dealing with open problems — the question should be: "how much time would we give this?". This is the concept of appetite: how much you are willing to invest in a conjecture, given what you know and what you do not know.

Appetite works as a firebreak. If a solution is shaped to fit within a fixed time cycle, the team has to make scope decisions: what is essential and what can stay out. Without that time constraint, scope tends to grow indefinitely.

This differs from sprints as they are commonly used. The problem with many teams is not that they don't do sprints, but that sprints are chained together with no clear horizon: "if it doesn't fit in this one, we'll do another". After eight sprints, nobody really knows how much has been invested or whether the result justifies the investment. Fixed time with a defined appetite avoids that chain: a specific cycle is given to a specific conjecture, and at the end of that cycle it is evaluated.

Constraints are not obstacles. They are the way to reduce uncertainty. They force you to prioritise, to trim the inessential, and to focus on what truly matters for validating the conjecture.

Collaborate instead of passing the baton

One of the biggest generators of waste in digital product is the baton-passing model: one role defines, another designs, another builds, another validates. Each step is a handoff where context is lost, interpretation accumulates, and misalignments multiply.

The alternative is to hand full responsibility to the teams. It is not about one person thinking up the solution and others executing it, but about the team that will build participating from the start and having the capacity to decide how to solve the problem within the defined contour.

This means building and touching from day one. The team should start making tangible things — even rough ones — as soon as possible. It also means showing progress continuously, without waiting to have something "presentable". And when feedback is received, it must be treated with the same rigour applied to the initial shaping: evaluated, contoured, and decided upon — whether it enters or not — rather than automatically added as an additional task.

To develop is to unfold

Working with open problems in digital product means accepting that we are not good at estimating. The final scope of what we are projecting is not something we can set as a starting point to then determine its duration. Scope is something that moves. Developing software is, therefore, unfolding the scope of what you are projecting.

Since it is a process, we cannot understand validation as something that only happens at the end. We cannot follow a printing-press model: an input is established, then an output is expected, and only then do you validate whether what comes out matches what went in. We have validations before we start, while we build, and also when we launch.

One of the keys to executing well is accepting that done means launched. Published. Not "the code is ready" or "the branch has been merged", but users are actually using it. Teams must be the ones to decide when something is finished enough to ship.

Validations in three acts

Before building has even started, it is reasonable to try to validate the information we are working with. Bringing engineering teams in early serves primarily to start validating whether what is being projected fits with what already exists, as well as to begin developing a sense of risk and uncertainty.

During construction, the initial start-up is usually a phase of discovering all the things that could not be known before building began. The unknown unknowns. That first validation can lead to substantially modifying the scope. It is important to note that you should not validate projected solutions — Figma mockups, static prototypes — as if they were the real solution. There are fundamental aspects — the email that never arrives, the latency of an API, the real flow with real data — that can only be validated with working software.

After launch, validation is determined by the classification of the solution. If we are dealing with a customer problem, we can seek it through immediate interaction. If it is a lever, a quantitative observation of certain metrics' behaviour should suffice. If it pursues delight, we will probably need some kind of survey, interview, or close attention to what customers are saying across different channels.

Launching is a design decision

Launches can also take different forms. The digital realm offers a plasticity that opens up multiple options. The main distinction usually runs from total launches — all at once — to progressive rollouts. Mobile development platforms have established launching by percentages as a standard, and engineering teams operate on the idea that this allows them to validate as they go whether problems are emerging.

A distinction can also be made between internal launches and external launches. If you are working on a product used internally, it is common for features to spend time inside the company first, shipping externally only once they have been validated and even refined. The progressive rollout is, in itself, another form of validation.

---

Session practice

Case study: Shaping a real bet. The exercise for this session involved taking one of the bets that emerged from the discovery board and giving it form following the principles of shaping: a combination of words and fat-marker prototype, an exposition of the problem, the solution, the perimeter — what is out of scope — and the potential risks or most uncertain areas. The time we would dedicate to it is set based on the objective and its impact, without falling into calculations of complexity or feasibility.

Homework: Complete the shaping exercise and find a couple of people outside the company, potential or current customers, so that from the document they can share their impressions: whether they agree with the problem, whether they see value in it, whether they understand the solution. Along the same lines, find a way to shorten the distance with what is being created: sign up, perform operations with the product, test the real flows. Do not leave it for later.