What is the simplest thing
we could possibly build?

Building software products is a complex problem. That means we can't solve it by analysis, we can't break it apart into smaller pieces, and we won't know if we're right until we actually try it. But building a market-scale product without knowing it will succeed is also a huge risk, and it requires significant investments upfront.

We can't eliminate the complexity, but we can adjust our behavior to reduce the risk — by answering the most critical questions first.

The key to deciding what to do is knowing where we are.

A typical software product lifecycle from the first idea to market success can be charted as a succession of four phases:

1. 1.Inception: Where we have an original idea
2. 2.Conception: Where we turn our idea into a marketable product
3. 3.Concretization: Where we hone and improve our product to make it lovable
4. 4.Realization: Where we make our product work at scale

In each phase, making progress on the path to success means asking and answering the right questions, verifying assumptions, and learning from customer feedback. But the kind of questions to ask, and the breadth and scope of the topics to work on differ significantly.

To answer the key questions, we must adjust our strategy to always develop the best-suited deliverable for immediate and actionable feedback. Earlier in the journey, prototypes are fast and throw-away — we will try things out and change our mind often, so building for the long term means wasting time and resources. Later in the journey, as we get closer and closer to our target product, we will focus on details and variations, and the knowledge built into our solution will grow continuously. Rebuilding then becomes more and more expensive — so we need to create prototypes that stay with us, that evolve and easily adapt to changes.

If we are going to evolve a product continuously, and without handovers or gaps in the process, we must integrate the two core aspects of a software product — UX design and systems design — into a single feedback loop. This requires us to apply the same core strategy to both disciplines (with different vantage points), and combine the collected feedback into shared understanding.

Historically, this has been quite challenging.

The Cynefin framework gives us the general approach for solving complex problems: probe, sense, respond. In other words, we must first do the things we think will lead to progress, in order to find out whether they will work. We achieve this by running a series of controlled experiments, each with one or more hypotheses to validate.

When software teams implement this approach, it becomes more specific:

• Try. Put something real in front of reality. A prototype, a release, a running system — anything that produces an observable response from the world.
• Observe. Watch what actually happens. Not what was supposed to happen; what did.
• Learn. Update the next attempt based on the gap between the two. And repeat.

UX research does this with users. The object is the product; we observe user behavior; the learning feeds back into product design. Short cycles, real contact, small bets.

System design must also do this, with a running system. The object is the current solution; we observe system behavior — under load, under failure, under integration with the estate, under evolution of the product it supports; the learning feeds back into the architecture.

Domain-Driven Design (DDD) — the practice of modeling software around the business domain it serves — implements try, observe, learn. The development team and subject-matter experts ‘crunch knowledge together’ (Eric Evans) to develop a shared understanding of the domain, build an executable model that represents that knowledge, and then use that model to reflect and shape the next iteration. It does for architecture what UX design does for the value proposition.

Tightly integrating UX design and DDD significantly improves the chances of creating a better product. Together, they see the product and the system it embodies as one thing, not two. They share the same feedback loop, use the same prototypes, integrate their feedback, and grow a coherent product, with a cross-functional team.

In practice, this means applying principles and methods of either DDD or UX design, as they fit the current situation. Each bring a rich catalogue of workshop formats, modeling techniques, and mental concepts that shape a common understanding and continuously move the product forward on its journey. Each activity will yield data and insights. Combining these outcomes allows us to reliably build the most effective next iteration of experiments, prototypes, and ultimately, the market-ready product.

Building a product is like shaping a statue out of clay. Every round of user contact reshapes it — first, very broadly, then the details. The question that decides whether the work is possible at all is whether the clay stays malleable — whether, on the hundredth pass, we can still reshape the hand without the arm falling off.

Most architecture does not stay this malleable. It solidifies. Early prototypes become permanent; early abstractions outlive the assumptions they rested on; the system becomes something that can only be changed under duress. Once that has happened, try-observe-learn at the architecture level stops working, because the cost of try has grown larger than the value of learn. The loop breaks.

Self-similar patterns are how the architecture stays malleable. The idea, stated simply:

1. We start with a small-scale domain prototype.
   No infrastructure dependencies. Just the business logic, expressed as code, with whatever the simplest possible representation of the surrounding world is. An in-memory hashmap instead of a database. A function call instead of a service boundary. A local eventbus instead of a broker.
2. We refactor it with the same rigor we'd apply to production code.
   Good patterns at the code level — clean interfaces, separated concerns, honest abstractions — are the same patterns we want at the architecture level. If we keep the code clear and well-tested, the system will already have the right shape — on a smaller canvas.
3. We "extrude" to larger-scale patterns only when the load demands it.
   When the prototype needs to accommodate multiple users, it's time to separate client and server. When user sessions need persistence, we go from in-memory to local storage. When users need undo/redo, we may want to introduce event sourcing. When the in-memory queue starts to need durability, we replace it with an external message queue. Whatever the driver — the code at a small scale already knows how to accommodate the mechanism in the large; the shape is the same. When a function call needs to cross a process boundary, it becomes a service call, and the caller doesn't care that the implementation moved.

The payoff is that Architecture can be evolved along with the product. We try something small, see it behave, reshape and improve based on insights gained — and only refactor toward a more elaborate version of the pattern, when the load demands it (and by then we know it's the right structure). The clay stays malleable. The statue can be reshaped on another pass.

Because we cannot really be sure what the best end result of a product journey will be, we cannot resort to the usual KPI to track our progress, and assess our success. Story points are not a reliable measure, when we a) don't have any stories, and b) can't be sure which and how many features we will need to build in the first place. The only thing we know for sure is that the game will be won by whoever can try-observe-learn the most often, with the best insights.

That is why we need to optimize our entire development process for it:

1. Stay aware of our assumptions and what we need to verify.
   This means reflecting and rethinking often.¹
2. Learn and practice methods to find and build the simplest possible experiments that could confirm or negate those assumptions.
   There are plenty of resources from the UX community - we must make a habit of trying new ones, and growing your toolkit.²
3. Hone our ability to conduct experiments with, and collect feedback from, real customers.
   User tests can provide an extremely rich source of insights.³ But writing good qualitative interview questions, test moderation, data collection, and coming up with good scenarios, are all skills that won't just come without practice.