Fast experiments in a focused domain.
The Discovery Engine (LPKO-R) is an organisation that treats its core business like a focused laboratory. It operates in a relatively narrow and stable domain, but inside that domain it moves quickly, trying out new ideas and adjusting as soon as real-world feedback arrives. The code LPKO-R captures this pattern: it has a low-entropy interface to the world, it is possibility-seeking rather than purely efficiency-seeking, it relies on metrics and explicit tests to decide what to keep, it prefers to keep several options alive rather than locking in too early, and it reacts fast rather than waiting for long review cycles.
From the inside, a Discovery Engine feels energetic and slightly restless. People are always asking “what if we tried this?” and “what did last week’s experiment tell us?”. There is a strong sense that the organisation is not finished; it is constantly probing for better ways to serve its chosen customers, better combinations of features, pricing, and delivery. At the same time, it is not chaos: experiments are logged, metrics are watched, and poor ideas are shut down instead of drifting forever.
Imagine a product company that serves one main customer segment with one main product family. The market is not exploding in every direction, but it is changing quickly enough that simply standing still would be dangerous. Inside the company, there is a small growth team and several product teams. Every week they review a list of experiments: tweaks to onboarding, new feature variants, different pricing bundles, small changes in how the sales story is told.
The rhythm of work is tight. On Monday they decide which experiments will run. During the week, engineers, designers and marketers ship those changes into production for a subset of users. By Friday, the team looks at what happened: sign-up rates, conversion, usage patterns, qualitative feedback. If a change clearly improved things, they roll it out broadly. If it clearly made things worse, they revert it. If the signal is ambiguous, they either run it a bit longer or design a sharper version of the test for next week.
People are not rewriting the whole product every month, but important details keep shifting and improving. From the outside, customers may only notice that “it’s getting easier to use” or “they keep adding small useful touches”. From the inside, people notice that ideas do not sit in slide decks; they are tried in the real world, kept if they work and abandoned if they don’t. There is pressure, because the tempo is high, but there is also satisfaction: a sense that learning actually changes what the organisation does.
Discovery Engines treat their focused market as a place to run many small, fast learning loops. They are disciplined enough to measure, but impatient enough to move on evidence quickly. When a new opportunity or problem appears, the instinct is not to write a long plan but to ask: “What is the smallest change we can ship this week that would tell us whether this idea is worth pursuing?”
This leads to a particular pattern of behaviour. Teams are encouraged to bring forward ideas, but they know that an idea only really exists once it has a clear hypothesis and a way to see if it worked. Leaders care about the health of the experiment pipeline: are we running enough? Are they varied enough? Are we actually killing ideas when they fail? There is also attention on the underlying systems, because the ability to experiment at speed depends on having deployment, data and monitoring that can keep up.
Discovery Engines are strong when value comes from constantly adjusting the details of a focused offer: user experience, pricing, workflows, small product innovations. They are good at squeezing more value out of the same basic shape by learning faster than competitors about what really works in practice. They are often the first to spot that a supposedly “minor” change is actually the seed of a new direction, because they are in close, continuous contact with how customers behave.
The same reactivity and option-seeking that make Discovery Engines powerful can also make them fragile. If the organisation loses its sense of focus, it can start to chase too many ideas at once, fragmenting attention and confusing customers. If experiments are not properly instrumented, it can mistake noise for signal and keep changing course without really improving things. People who care about reliability and coherence can feel ground down by constant tweaks, especially if the tempo of change outstrips the organisation’s ability to absorb it.
When this stamp shows up in a leadership team, a common pattern is that some people feel exhilarated by the constant motion, while others worry that “we never finish anything” or “we are always fiddling instead of tackling the deeper issues”. Without a shared language, those concerns can easily be dismissed as resistance or recklessness, when they are actually pointing to real trade-offs in the Discovery Engine pattern.
If your result points towards Discovery Engine (LPKO-R), useful questions for a team conversation include:
The aim is not to stop being a Discovery Engine, but to do it on purpose: to be clear about when fast, option-heavy behaviour is a strength and when it starts to eat its own tail.