Why don’t the best-performing products always win?

The best-performing products are not always the ones that win. Sometimes, a simple PowerPoint presentation is enough to put them ahead. Why?

Because a product, before being a code or an object, is a promise. A sincere lie, thrown into the void with enough faith to become true. Great products are not born of perfect technology, but of a story strong enough to convince us that it will become so, and then they are realized around four key dimensions:

• The perceived product that attracts
• The embodiment of the product that makes it real
• The product system that makes it reliable
• The impact factory that learns and readjusts the promise

When communication, technology, and management move at different speeds, the product cracks: the promise drifts away from the experience. But when they align, something rare happens: perception and reality merge into a single truth.

1. The perceived product – The story we tell the world

This is the product before the product.

It is born in the collective imagination, shaped by marketing, storytelling, and public relations.

In 1929, in the middle of the Easter parade in New York, a group of young women simultaneously lit cigarettes in front of photographers. Passersby stopped. Journalists captured the scene. The next day, the newspapers ran headlines such as: “Women wave their torches of freedom!”

This gesture, orchestrated by Edward Bernays, a pioneer in public relations and Freud’s nephew, was anything but spontaneous. It was a real-life experiment: testing a hypothesis about perception. Bernays wanted to verify that by associating cigarettes with female emancipation, he could transform a taboo into a socially desirable symbol. The product—the cigarette—had not changed. But the perceived product had just been born. The result: a few weeks later, sales exploded.

Even before touching a pack, the public had bought into the idea. Nearly a century later, startups are using the same levers, often without realizing it. Today’s growth marketing campaigns exploit this same principle to validate a promise before investing in an actual product.

This is exactly what a young team wants to do when launching, for example, a carpooling app for children. Rather than developing a complete app, they create a carefully designed landing page with a clear slogan and a few visuals simulating the service. They spread the message on social media: “Give your children a safe ride, accompanied by parents from the neighborhood.” The campaign is simple: a few visuals, a registration form, and a series of blog posts telling stories of reassured parents. Within a few days, 500 families sign up to “be notified when it launches.”

The product doesn’t exist yet, but the need is confirmed. The narrative becomes a valuable prototype. This approach is based on a simple but powerful idea: the perceived product—the image, the promise, the symbolism—is a product in itself. It can be designed, tested, and measured like any other version of a product.

Even before writing a line of code or building a physical prototype, you can:

• Create a clear promise: “Become the master of your time,” “Simplify your taxes,” “Learn effortlessly.”
• Spread this promise through ads, LinkedIn posts, Medium articles, a mini-video, or a fake product page.
• Observe the signals: registration rates, comments, shares, misunderstandings.

Every click becomes data, every reaction a hypothesis confirmed or disproved. And it’s much less expensive than premature technical development. This phase, often called problem–solution fit, brings together a variety of expertise:

Field Role in testing

• 🎯 Strategic marketing Define the promise and positioning
• 💬 Public relations & storytelling Create a credible and emotional narrative
• ⚡ Growth hacking Quickly test messages and channels
• 🧠 Social psychology Understand the levers of attention and persuasion
• 📊 Data analysis Measure resonance and guide the next steps

This method has a downside. When the narrative precedes reality too much, there is a risk of selling an illusion. Many startups have raised millions on unfulfilled promises: the storytelling was more successful than the product itself. Once trust is broken, it cannot be repaired. But when used correctly, this approach accelerates clarity: it allows you to validate an idea without building it, to better understand your audience, and to prepare fertile ground before investing heavily in technical development.

2. Product embodiment – The tangible experience

This is when the promise becomes reality. Interface, design, customer service, ergonomics: everything that makes value perceptible and credible.

When a team begins to “embody” its product, there is a strong temptation to plan everything: define the technical modules, software architectures, future APIs, and building blocks to be assembled in a logical order. But an Impact Factory does not build a technical cathedral. It erects a scaffolding of hypotheses—temporary functional building blocks that allow learning before investing heavily.

Take Loop, a young startup that wants to reinvent urban delivery with electric cargo bikes shared between merchants. Instead of developing a complete platform from the outset (user accounts, GPS tracking, billing, route optimization), the team chose a different path.

It started with a Google Form and a WhatsApp group. Each retailer reserves a slot, receives a message when the bike is available, and pays via a Lydia link. No infrastructure, no back office, just a series of tests to answer a single question: “Will retailers agree to share a vehicle if it saves them time and money?”

The answer is yes—and more importantly, the team discovers why: trust between neighbors is more important than price.

This discovery changes everything: the “problem to be solved” is not logistical, it is community-based. Rather than building, Loop learns and reorients the rest of its development.

A few months later, Loop undertakes a complete overhaul of its architecture in order to automate what had been empirically validated. This refactoring is not a mistake or a step backwards: it is the logical continuation of a learning process.

The limitations of the first model, often mistakenly referred to as “technical debt,” are in fact product debt: the deferred cost of shortcuts taken in order to learn quickly.

This debt is not a burden, but an investment in knowledge—a way to take the fast track to discovery rather than the long road of unnecessary perfectionism. It marks the moment when the team stops experimenting on a small scale to institutionalize what it now knows to be true.

In this first phase of incarnation, the product is not yet an optimized machine: it is a series of exploratory modules, each linked to a hypothesis.

Hypothesis to be tested:

• Do users understand the promise? Landing page or mini-site -> Test understanding of the message
• Do they actually take action? Clickable prototype or fake “buy” button -> Observe actual behavior
• Does the service deliver on its promises? Partially manual MVP -> Validate the value of use before automation
• Does the business model work? Spreadsheet + manual billing -> Test viability before development

These building blocks are disposable: they exist to produce knowledge, not to last. And it is precisely because they are not made to last that they allow us to learn quickly. This stage requires hybrid profiles:

Field Role

• 🎯 Product management Define and prioritize hypotheses to validate
• 🧠 UX/UI & design thinking Prototype usage scenarios
• 💻 Pragmatic engineering Create temporary and modular solutions
• 📊 Data & analysis Measure results and formulate learnings
• 🤝 Service & customer relations Observe actual user behavior

Each iteration aims to reduce uncertainty—not to deliver a “feature.” Once the hypotheses have been validated, an inevitable moment arrives: the overall technical overhaul. This is not a waste of time, but an investment in clarity: we now know what to build, for whom, and why. The previous code was not waste, but a temporary learning tool, a succession of experiences crystallized in code.

But every refactoring, however well thought out, carries within it the seeds of its own obsolescence. What seems like a “sustainable” architecture today will remain so until the next wave of learning renders it, in turn, unsuitable. This is the very nature of a living product: it evolves at the pace of the team’s discoveries.

The mistake would be to aim for a “fixed” refactor, thought of as a stable end point: a supposedly definitive architecture.

Because by freezing the product, we also end up freezing the organization. And according to Conway’s law, a structure that no longer evolves its product reveals an organization that no longer learns.

Thus, refactoring is not about achieving an ideal state, but about starting from a new balance between what we know, what we don’t yet know, and what we must continue to discover.

3. The system product – The invisible engine

This is the structure that makes the experience possible.

The technical infrastructure, processes, data, logistics—the hidden part of the iceberg.

When we talk about a product, we often think of what the user sees: an elegant interface, a smooth application, a responsive service. But this visible product is only a narrative surface: a deceptively simple embodiment of a much larger system, where technology, processes, and humans come together.

Take Brewly, a startup that promises “the perfect coffee delivered to your office every morning.” On its website and app, everything seems magical: you choose your type of coffee, click, and every morning a steaming cup awaits you at 9 a.m. sharp. The storytelling is impeccable, the experience seamless. But beneath this apparent perfection lies a much more organic mechanism.

The first “automated” deliveries are actually based on a patchwork of humans and DIY tools:

• A Google Sheets spreadsheet to manage orders,
• A Python script to send confirmation text messages,
• And above all, a team of three people who, at 6 a.m., manually fill the thermoses and check the addresses.

For the user, it’s magic. But for Brewly, it’s a choreography between humans and machines, where every technical glitch is compensated for by a manual gesture, every unforeseen event by a human decision.

What Brewly reveals is the true nature of the product system: it is not perfect code, but a shifting balance between what is automated, what is tooled, and what still relies on people.

In any organization, this distribution evolves over time:

• What starts out manual becomes automated.
• What is automated sometimes has to become human again in order to adapt.
• And some areas will remain deliberately vague, as they allow for flexibility.

The illusion of the “embodied product” — the one that seems to work on its own — is based on this hybrid infrastructure.

In other words: the product is a well-organized mirage.

In this approach, product and tech teams don’t just build a technical system: they orchestrate a socio-technical system.

They decide:

• what needs to be automated (for speed and reliability),
• what needs to remain human (for flexibility and quality),
• and how the two fit together.

This is where ops, support, finance, data, product, and design come together: each becomes a link in the overall system.

Customer service, billing, and maintenance are all “micro-products” that extend the promise.

The classic mistake is to believe that a product becomes “mature” when everything is automated. In reality, maturity lies in the awareness of compromise: knowing where humans remain more relevant than machines, and accepting that certain areas of imperfection are the price of continuous adaptation.

4. The impact factory – The learning organization

This is the product from the teams’ point of view.

The impact factory is the human and cultural machine capable of learning, adapting, and reinventing the previous three.

According to Conway’s Law, the product always ends up reflecting the structure of the organization that designs it. But the reverse is also true: when the product evolves, it reshapes its organization.

At first, Nova was just a small startup with three people. Their ambition was to create a file-sharing tool that was “as easy as sending a text message.” In the first few weeks, the team was completely immersed: a designer who coded, a developer who talked to customers, and a CEO who provided support. The product was fluid, communication was instantaneous, and decisions were made in the same room.

But six months later, Nova had 25 employees. The product was working, but support was exploding, security was becoming critical, and customers were demanding complex integrations. What was yesterday a prototype is now an infrastructure; what was a Slack channel becomes an organization. As the product expands, the organization cracks. Tensions arise: slowness, duplication, divergences. In reality, the product has become faster than the team that designed it.

The classic mistake is to believe that the organization is a stable foundation on which the product rests. In practice, it is the product that dictates the shape of the organization:

• when the product diversifies, it requires specializations;
• when it becomes critical, it calls for support functions;
• when it goes international, it requires new cultural and linguistic skills.

Thus, R&D teams can never be static: they are the beating heart of this evolution. They must learn to move from exploratory tinkering to industrial rigor, without losing the curiosity that drove them in the first place. Certain skills then become obsolete, not because they fail, but because they have accomplished their mission. The organization must then redeploy, retrain, or replace them—not out of rejection, but out of natural adaptation.

A learning organization is not one that has found the right model, but one that knows how to transform itself when the model changes.

It observes, adjusts, and rebuilds itself based on what it learns from the product.

Some companies, in search of stability, seek to “freeze” their organization once the scale-up phase is reached: they adopt processes, titles, and boundaries. But by freezing their structure, they also freeze their ability to learn.

The product becomes rigid, decisions slow down, and cultural agility wanes. It is an attempt to standardize a system that is still alive, which ultimately renders it inert.