Progressive Discovery

Whenever our house is in disarray, I focus on what I can control. I start cleaning up and reorganizing, reconsidering every layout in the house.

We discussed our kitchen area where we have a TV, seating, and a lot of the kid’s toys. It gets messy. The furniture and rug are old and destroyed by the monsters children. And we’re in a period of time where they aren’t old enough to justify the expense of something nicer yet.

So we do what we can—strategically.

In our discussion of what to do with the kitchen area, my wife suggested some bookcases on either side of the wall-mounted TV. I loved the idea. We have so many books spread throughout the house, and more storage is always welcome.

But there was a problem.

My wife wasn’t only thinking about adding the bookcases. She was also reconsidering the entire room: removing the chairs, the sofa, replacing the rug.

We were on different wavelengths.

She was thinking about the future version of the room.

I was thinking about the next version of the room.

This is what product teams do, too.

They spend time conceptualizing a future version of the product. Designers live in Figma mockups with an imagined future, while engineers toil in the complexity of the current codebase and wrestle with implementing the next version of the product.

Everyone is working on different temporal horizons.

It’s not a bad thing necessarily, but it can breed coherence drift in the product, the team, and the system. You need to coalesce around a shared understanding of:

1. The current reality of the product.
2. The future direction of where you’re going.
3. The next version to improve your understanding.

The current reality of our kitchen is what it looks like right now, including the mess of toys and worn-down furniture. The future direction is the imagined path my wife was envisioning. And the next version was adding just the bookcases and nothing else.

We disagree on the approach.

She wants to do it all at once later and I want to do it strategically in pieces now. And it’s a perfect analogy for the same downfall that happens in software development.

Product teams spend months (or years) in discovery. They look at usage data, talk to customers, and explore options through internal discussions. Eventually they build enough confidence to plan an approach and invest engineering time to build it. The reason they spend so much time in discovery and planning is because building is so expensive. Engineers cost a lot of money, and building stable software is a complex endeavor full of uncertainty.

The paradox of software development has always been, no matter how much time you spend in discovery, you can’t remove the unknowns until you actually write code.

Work is discovered, not imagined. Until reality pushes back, you are only operating with a hypothesis of what could be—a simulation of possibilities.

How does AI change things? A lot, actually.

Execution is cheap, but understanding is expensive. If you’re no longer an active participant in the creation of the outputs, you can’t maintain coherence in the system. Products will drift and the value with it. Don’t excuse yourself from the process. Reapply your leverage in new places.

Discovery of what works and what doesn’t emerges when you test it. You build on your current understanding, capture feedback with real usage, and leverage the learnings to update your understanding and compound knowledge. Instead of defining work containers and filling them with work, discover the work through building. Match the container to what the experiment tells you about the next version of the product.

What if we add the bookcases and they change the entire look and feel of the room such that we need a new seating arrangement? If we change it all at once, the surface area expands past our ability to reason about the changes. We can’t isolate the issues. If, on the other hand, we only add the bookcases and change nothing else, we can get a feel for the change and use that to inform the next change. And the next. Maybe it means we don’t need to change the seating after all. We won’t know until we make the changes strategically, intentionally.

Progressive Discovery is the process of continuously updating your understanding by shipping focused experiments. Don’t replace your understanding. Update it.

The three pillars of Progressive Discovery are:

1. Future Hypothesis → where we’re heading
2. Current Reality → what exists right now
3. Next Experiment → what happens next

Bayesian Reasoning

In the 1700s, the English mathematician and minister Thomas Bayes asked a question:

How should our beliefs change when we encounter new evidence?

This question is the foundation of what’s called “Bayesian Reasoning.”

It’s not really about mathematics. It’s about continuously updating your understanding as reality provides new information.

Imagine you believe there’s an 80% chance of rain tomorrow.

But you wake up to blue skies.

You don’t throw away your prediction and start over; you update it.

When the darker clouds roll in later, you update it again.

The goal isn’t certainty. The goal is making your understanding progressively more accurate as new evidence appears. Certainty doesn’t exist in complex systems.

The future product isn’t a specification; it’s your team’s current best hypothesis. This is the belief there’s an 80% chance of rain tomorrow. Each change to the product is an experiment to produce evidence that updates your team’s hypothesis.

Experimental design becomes the new skill of product builders.

Future Hypothesis

AI writing code is common now. Frontier models can write code instead of an engineer doing it by hand. They’re still there, but to direct and review the work. Focus shifts, like a senior engineer helping a junior engineer plan the work and review the output. Junior engineers can make something work, but they struggle to determine the best approach (the plan) and the cleanest solution (the output).

AI masks that limitation if you’re not mindful.

Engineering output is objective. Code either works or not. The art is in the construction of code and how it integrates into a coherent system. But there’s still an objective truth of functionality. So it makes sense that AI can do it faster and better (when supervised by a domain expert). Also, novelty isn’t a necessity of code. Quite the opposite, actually. The more code is reused, the more it hardens and becomes stable. Predictable behavior.

Design output is subjective. Whether a design works or not is an interpretation. Developing a feel for anything enough to describe why something works is an organic process. It’s participatory. You can’t sit out the process and expect the benefits. And design does value novelty. Being able to blend common patterns in new ways is how you escape homogeneity of the outputs.

If everything looks the same, nothing stands out.

The Future Hypothesis is an imagining of what could come true. It’s a vision.

Every discipline provides a perspective.

Design asks what should this experience become?

Engineering asks what kind of system would enable that future?

Strategy asks is this the future worth pursuing?

All disciplines are involved, but design leads with conceptual design, where the details matter less than the concept. In Figma, you can move and draw the shapes with more fluidity. It’s intentionally divergent as you rapidly explore new concepts. The limits of what’s possible aren’t a constraint yet.

That’s what I need from design.

The current version of the product has a design system to maintain and dictate step-change improvements in each iteration. But the evolution of the product is shaped by the conceptual design. The design is 10-15 versions ahead of where you are now.

To get there, you need to always acknowledge where you’re starting from.

Current Reality

Every designer I’ve worked with maintains a future representation of the product. It looks nothing like the current version. That’s a good thing working through conceptual design, but it’s important to stay rooted in the constraints of the current version.

Begin from what exists today.

Getting from Point A to Point B requires an understanding of Point A in relation to Point B. You also need to understand how Point A arrived at its current state, which means knowing about the historical context.

The Current Reality is what exists now.

In the Coherence Graph, this is your current understanding. You have living proof of what’s working and what’s not working. Constraints emerged from reality. If something’s not working, you can either:

1. Do less of it.
2. Do something else.
3. Stop doing it entirely.

Like the Future Hypothesis, every discipline provides a perspective.

Design asks how does the product actually feel today?

Engineering asks how does the system behave today?

Strategy asks how is the product performing today?

Design leads the Future Hypothesis.

Engineering leads the Current Reality.

Together, they create direction.

Next Experiment

Our team has been working against a strategic body of work centered on three streams. Each stream emerged organically around the signals in the work, not from a rigid roadmap.

The current project is a big one.

We’re moving a feature from the Enterprise level down to the self-serve plans. It requires a lot of thinking about technical architecture, user experience, and business processes. It’s not a trivial change. And when you think about something of this breadth, it’s easy to rethink everything. It’s like wanting to redo the entire kitchen area. Too many threads open up.

I talked to two engineers and we ended up discussing an entirely new product surface.

My intuition told me this wasn’t the right path.

So I stepped back. I thought about what we’re trying to learn. I want to add the bookcases and see how the room feels. I don’t want to redo the kitchen area with wholesale changes that generate more noise than signals.

The Next Experiment is where you determine what should be learned next.

Look for the experiment with the highest expected information gain.

Design defines the smallest experience worth testing.

Engineering defines the smallest implementation capable of answering the question.

Strategy defines the smallest business question worth answering.

Together, they decide what’s the next experiment?

Experiment design in science is critical.

A poorly designed experiment tells you nothing, which is why scientists methodically focus on designing optimal experiments for learning.

Don’t think about functionality. Think about what you need to learn. You’re trying to answer a question to fuel discovery and learning, not satisfy requirements.

Use the Decision Filter.

Before starting an experiment, evaluate it against three questions:

1. Learning: Does this reduce uncertainty?
2. Leverage: Will this improve future decisions?
3. Reversibility: If we’re wrong, how expensive is it?

Choose the smallest experiment that maximizes learning, leverage, and reversibility.

That’s what I did with the new project. I scaled back to a simple experiment:

• Limited usage.
• Scoped to one feature.
• Limited it to an alpha release.
• Only released to a small set of users.
• Decoupled from another billing change.

And then learn. Answer questions to propel the next experiment. Stay curious.

This is the exact philosophy of building new products. Launch an “MVP” as quick as you can and get feedback from real usage. Don’t over-design or over-engineer it. Focus on concentrated bursts of targeted updates.

Yet the same philosophy dissolves once the product hardens. Planning increases, scope grows, and execution stalls. Learning becomes a twice-a-year activity rather than a continual process of discovery and validation.

The Current Experiment is led by strategy, informed by design and engineering.

Use learning to update your understanding.

The Practice

To put Progressive Discovery into practice, you move through five steps:

1. Envision → What do we believe?
2. Ground → What do we know?
3. Design → What’s the next experiment?
4. Observe → What happened?
5. Update → How has our understanding changed?

Envision

Begin with the future in mind. Where are you trying to go? Think big first. And frame your thinking in alignment with the organization.

Our vision is to allow all account types to use a key Enterprise feature, moving a valuable feature downstream. Why? Because it’s regular feedback we receive and will increase usage and, therefore, revenue in the product. It’s also aligned with general themes in customer conversations and market dynamics.

Knowing the why is important.

The vision of the end product is big and requires a lot of moving parts. That’s okay! At this stage, the breadth is valuable.

Ground

Go wide and then narrow. Focus on your current understanding first. Create a picture of everything you know right now.

Enterprise customers have access to the feature, but it’s not self-serve. Someone on our team has to create the tokens so they can use it. The infrastructure is in place, but the experience isn’t fully open. There are also other gaps in the system, but acknowledging them is the key part right now.

Ground your vision in current understanding.

Design

Design the experiment. Figure out the smallest change you can make and learn.

I think of it like drawing concentric circles, starting from the smallest center. You make a small change (the smallest circle). Then you learn what the next circle should be. It all extends out from a focused point.

We decided to go with a small scope to release to a small set of users and let their feedback drive further development. Instead of getting paralyzed by the size of work, we started with a simple question and experiment to run.

Observe

The test matters, but the observation matters more. You can’t learn anything if you don’t look. Review the data; do something about it.

For this feature, I’ll track usage data and connect with each customer I can to learn from them directly.

Update

What did we learn?

This is the Bayesian reasoning at play. Take the learning and feed it back into your understanding. Coherence grows and the future version of the product grows with it.

Viewing usage data and talking to customers will help improve the future hypothesis.

The Throughline

Discovery isn’t something you do before you build. You do it while you build.

Think about where you’re trying to go, where you are today, and what immediate steps you can take right now to move forward.

The Future Hypothesis is your simulated future aligned with your vision.

The Current Reality is the constraints of where your product is today.

The Next Experiment is the focused intervention to learn and discover.

Together, they form a model of Progressive Discovery to shape the work through the process of continual learning.