The challenges of strategy in digital product

We have reached session 12 of the product management programme at Instituto Tramontana. A session where we take note of several challenges strategy faces when you work with digital material.

The fourth movement of our discovery machine is when we publish. In this session we also spent time discussing what is usually meant by "validation" in digital products. It is a notion that connects both to the moment of launch and to earlier moments. Our main conclusion: borrowing the term from other disciplines or industries distorts what it really is here, which is closer to testing something against reality than to stamping it with approval.

When you direct product, it is hard not to yield to the pull of the word "strategy". It can make you feel very small while leaving you unclear about what it actually means. It can make you take steps in the wrong direction with the best of intentions, and at the same time pay very little attention to small things. Finally, it can push you to abstract so far that you end up attempting a top-down chain of logic that melts on contact with reality.

We deliberately analyse it after having gone through the other moments, because otherwise we would overlook the many strategic decisions that occur throughout the invention itself. That is one of the most uncomfortable asymmetries of the craft: strategy gets written in documents and gets decided in details. If you hear the word a lot, treat it as a warning sign.

Validating before and while we build

Before you have built anything, it is quite reasonable to try to validate mainly the information you are working with. In that sense, bringing engineering teams in early serves chiefly this purpose: starting to validate whether what is being projected fits what already exists, and starting to form a sense of the risk and uncertainty involved.

During construction, it pays to set validation milestones. The first stretch of any build tends to be a period of discovering everything that could not be known before starting, things that only surface once they are put in play. That already gives you a validation of your prior assumptions, and it can lead to substantially changing the scope. Try to avoid validating projected solutions, because they tend to ruin that scope reference: the moment you show a closed solution, the conversation stops being about the problem. False expectations erode trust.

"The email is not arriving?" "You can try everything in Figma."

But it also pays to establish progressive validations of the solution being built, so that people start interacting with it as early as possible. Ideally both inside the team building it and by bringing in people from outside, so there is at least enough validation to avoid the larger mismatches at launch. When you do not build as a team from day one, you will very likely fall into the trap of extending the timeline, or end up building something half-done, because you never gave yourself those decision points along the way where you can adjust scope around what you consider the epicentre.

Half a product beats a half-built product.

It is the same principle we worked on in the previous session about avoiding waste and favouring rhythm: scope is not a starting point, it is something that unfolds. Intermediate validation is what gives you the footholds to unfold it deliberately rather than by exhaustion.

Validation after launch is largely determined by how we classified the solution. Recalling earlier sessions, we distinguished three types of initiative: customer problems, metric levers, delight. Validation varies substantially depending on that classification. In the first case we can seek it through immediate interaction with customers, or by combining qualitative and quantitative results. In the second, a quantitative observation of how certain metrics behave should be enough. In the third there are many possibilities, and it is not unusual for it to come down to an internal judgement: the marketing director and the CEO like it.

This is worth saying bluntly, because the confusion is common and expensive: asking a delight initiative to prove movement in a business metric, or asking a metric lever to prove qualitative enthusiasm, is a fairly efficient way of making the wrong decisions while feeling rigorous. We encourage patience and good humour as key ingredients of digital product management.

Patience and good humour, session 12.

## Full launches versus progressive launches

Launches can also happen in different ways. Here too, digital gives you a plasticity that once again confronts you with multiple options. The main distinction is usually between launching all at once and launching progressively. This is also used as a form of validation. Mobile development platforms, for instance, have made percentage rollouts a standard, and engineering teams tend to work with the idea that this lets them watch for problems as they appear.

You can also use internal launch versus external launch. If you work on a product that is used internally, features often live inside the company for a while and only go out once they have been validated and even refined.

Note, in any case, that all these possibilities increase complexity. Starting with the instrumentation — someone has to build and maintain the system of flags, cohorts, and measurement — and continuing because they themselves add uncertainty and coordination problems. A product shipped at three different speeds is, for a while, three different products: support answers to three realities, analytics measures three populations, and the team maintains three code paths. A lack of trust often decides rollout culture more than anything else, and it is worth asking whether the progressive mechanism is solving a real risk or administering a fear.

A lack of trust tends to decide much of the rollout culture.

## Strategy is more about NO than YES

The commonplaces the strategy literature has arrived at give us useful footholds for situating strategy in our digital product context. It is a literature that has often been built out of examples of what strategy is not. The first reference Michael Porter used to frame the question, for example, was companies pursuing operational effectiveness. Doing the same as everyone else slightly better is not a strategy: it is a race towards convergence in which everyone ends up offering the same thing and competing only on price.

If you are watching your competitors closely, you are not cultivating your strategy.

Strategy therefore has to translate into a set of specific actions — specific because they are differential — and those actions have to be the result of a process of discovery and creativity. When a company puts its strategy in play, it is putting its positioning in play, which is usually articulated in terms of who it addresses (target) and what competitive advantage it brings to bear. From the combination of those factors come the various models of strategy, and also the model considered "non-strategy". Which happens to be the usual situation.

If strategy is the creation of a unique position involving a characteristic set of activities, making that advantage sustainable has a great deal to do with sacrifice. Selecting trade-offs is therefore the main exercise through which strategy is realised. And this is where the digital material works against us: the plasticity and versatility of digital products only worsen our poor relationship with sacrifice. When everything seems possible, giving something up looks like a management failure rather than a decision.

The plasticity of digital products only worsens our bad relationship with sacrifice.

There are many reasons that explain the habitual absence of strategy. Most of them are internal — that is, organisations are their own problem.

First, many companies simply imitate others: habits oriented towards active listening and discovery, which we saw in earlier sessions, are good medicine for such a persistent disease. The desire to grow also tends to subordinate everything else, especially in a moment dominated by PLG. A lack of visibility into competitors' positioning, and organisational failures that obstruct articulating a position, are also frequent causes.

Finally, the inability to make sacrifices — very common in management cultures where this is read as weakness rather than strength — becomes especially serious in digital terrain, where options multiply, the material is poorly understood, and the perception of false abundance grows.

Managers who do not sacrifice cannot be strategic.

One confusion deserves a stop, because it sustains much of this problem: the one between goals and strategy. A goal describes a state you want to reach; a strategy describes how you will deal with the difficulty standing between you and it. When an organisation states "we want to double retention" and calls that a strategy, it has skipped over the only work that mattered: identifying which concrete obstacle is producing the churn and which coherent set of actions addresses it. That skip is comfortable because a goal demands no renunciation.

Roadmaps as a way of articulating strategy

We finish with a tour of the roadmap toolbox as instruments for making a strategy tangible and operational. We take the DHM model — delight, hard to copy, margin — as a reference, because it combines narrative, planning, and strategy quite sensibly. Its virtue is that it forces you to answer three questions that are normally answered separately, and often by different departments: what makes this exciting to someone, what makes it impossible to copy within a quarter, and why this leaves money behind. An initiative that only scores on the first is marketing; one that only scores on the third is extraction.

It also helps you avoid the usual roadmaps in the shape of a project-management timeline, where companies run spectacularly aground. We spent a good while looking at this great waste our industry swims in, and where so many CEOs drain teams of creativity and morale.

Once again: the problems we work with are not technical lego bricks you can decompose into a temporal sequence of boxes, thereby turning the roadmap into a pure status tool. Doing that will not only make you fail at execution — deadlines will slip, because the nature of software works against you — it will also deprive you of the most interesting part: turning that technical piece into a story.

If you combine it with a hasty OKR rollout, you are trying to succeed while sinking the ship. OKRs only work when there is something prior to frame; applied to an organisation without a position, all they do is accelerate the dispersion that was already there and lend it an appearance of rigour.

A roadmap should not be a still photograph.

Is strategy in digital product so slippery that we are condemned to live badly with it?