Digital Product

Yes, and several at once too. During the diagnosis we agree on where to start: sometimes it is one front, and often a combination, because a single problem usually has causes in more than one.

It is common that, as work moves forward, new priorities show up in another front. At Technisys, for example, we started with how the product area's teams worked. Once they were delivering every three weeks, the brake became the product installation: several days per release, with lots of manual tasks. We automated it together with the teams, and it went down to hours.

At the review every four weeks we decide together whether to add another front or keep going deeper on the current one.

It is a way of organizing the work in two tracks that move at the same time: one explores what is worth building (talks to users and tests ideas with cheap experiments) and the other delivers what has already been validated.

They are not two teams. They are the same people from business, product management, design and technology, deciding together what moves from one track to the other.

What it is for: so the team learns without stopping deliveries. And it is what ties the three fronts together: what is discovered about what to build reaches how the team works and how it is built, with no handoffs or handover documents.

If you want to know more: the Product Discovery guide (in Spanish).

It depends on the size, and it is defined during the diagnosis.

We always work with a fixed core: the trio (product management, design and technology) and their leaders, because that is where the decisions everyone else follows are made.

With a team of five or ten people, we work with everyone. With fifty, we pick one or two teams to work with directly, and the trio carries what was learned to the rest.

On your side, we ask for weekly time from the trio and their leaders. In large organizations that time is greater, because they are the ones who multiply the change.

They are four indicators that came out of years of research on software development teams (the DevOps Research and Assessment program):
· Lead time: how long a change takes to reach production.
· Frequency: how often you deliver.
· Failure rate: what share of changes causes a problem.
· Recovery: how long it takes to get back to normal when something fails.

What they are for: they anticipate. Research links them to better organizational performance, so they show whether the team is doing well before it shows in the business.

How we use them: as a starting point, adapted to each product. Not every team needs all four, and sometimes it is better to measure something closer to its reality.

It is work on your real product, with the team, in its daily operation. Training is built in, and it changes with the moment the organization is in:
· At the start, when there is no agreement yet on what to change: a short workshop with leaders, to build a common language and decide where to begin.
· With the first teams, learning happens on the job: short capsules on a topic right when the team needs it, and immediate practice on its own backlog, code or agreements.
· When a whole team needs to go deeper on a topic, we add an in-company training. Each front has its own, and you will find them on its page.

The same goes for adopting AI as for adopting new ways of working: what helps at the beginning is not what helps once there are experienced teams.

If you want to know more: Corporate training: kickoff and pilots (in Spanish).

No. We do not take the role of whoever manages the product or leads the technical side, and we do not add people to build.

We work with the people in those roles, on their real work, so they carry on by themselves once we are gone.

Largely, yes. Deciding what to build and organizing how the team works does not depend on the product being software. Before Digital Product we did this under the name Innovation Team, also on physical products and processes.

The path is the same: opportunities, solutions and implementation. What changes are the prototypes: plant trials, models or 3D printing instead of software. For example, with a team at a consumer goods company that brought together production, quality, marketing, logistics and product. We have implemented industrial changes in under four months.

The front about how it is built, on the other hand, is specific to software.

If you want to know more: Corporate training: kickoff and pilots (in Spanish), which tells how that team got started.

Yes. We work with the stack, the tools and the processes the team already uses.

If part of the work is bringing in AI agents, we choose the tools together according to the company's security policies and the kind of data it handles.