What skills does an impact factory need to run?

As you discover impact factories, you come to understand that it is no longer simply a matter of dividing roles according to the classic pattern where the Product Manager and the Product Designer focus on Discovery, while the developers, guided by a Product Owner, take care of Delivery. In an impact factory, the boundary between these areas becomes blurrier and, above all, more systemic.

The reality is that each phase, whether exploratory or in production, calls on specific skills depending on the nature of the test to be run. A usability test on a high-fidelity prototype, for example, can be led by a Product Designer, supported by a UX Researcher for running it and analyzing user feedback. A test of market appetite, positioning or pricing will rather fall to the Product Manager, backed by a Growth specialist or a Data Analyst to interpret the signals. And a technical or performance test in a real environment will naturally be the responsibility of a developer or a Tech Lead, who designs the instrumented solution to collect the data needed to measure impact.

In other words, it is no longer the phase of the project or the sequence that defines who works with whom, but the nature of the problem and of the test. Each question finds its natural owner according to the skills required: understanding the need, designing the solution, experimenting, analyzing data or releasing to production. Product leadership is then distributed dynamically, according to the learning stakes of the moment.

This paradigm shift reveals another, often underestimated reality: in terms of workload, the product disciplines (PMs, designers, data, researchers) produce as much as developers, but in other forms of deliverables: hypotheses, prototypes, mockups, surveys, analyses, decision frameworks. Their output is no less tangible: it feeds knowledge and reduces risk before a single line of code is written.

As a result, the so-called Discovery and Delivery teams tend to be of comparable size and, above all, strongly interdependent. One discovers what the other has to build, the other validates what the first has learned. The goal is no longer to separate the flows but to synchronize them to maximize the overall performance of the system.

In an impact factory, this symmetry becomes a structural advantage: each cycle, whether Discovery or Delivery, contributes to the same learning loop.
The result: an organization that is more fluid, smarter and, above all, more effective than traditional models, not because it works more, but because it learns faster.

The complexity then lies rather on the side of scheduling and choosing the right tools to manage activities.