Frequently asked questions

No. But it increases the chances of success by giving you tools to navigate complexity. You still have to do the work and make the decisions — this is a compass, not a map with an x at the spot.
Still better than randomly stumbling around in the wilderness in the dark.

True complexity can't be eliminated. It can be navigated — by distinguishing essential complexity (inherent to the system) from accidental complexity (avoidable, a product of poor design), and by applying the right problem solving strategy: probe-sense-respond.

In practice, we improve results by cutting waste, deferring one-way-door decisions as long as possible (until we've learned more), and running fast, frequent feedback loops. None of that removes the real complexity — but it helps us to steer clear of distractions, and learn to live with uncertainty.

Residuality's Incidence Matrix assumes stressors are applied to anaive system design — and that has to come from somewhere.

Domain Prototyping embraces Residuality and actively recommends using it in the Realization phase. The earlier phases are used to inform that initial system: they are the core product idea itself.

Compared to going straight to the goal line? Yes. But we can't actually know where that goal line is, can we. Not when we start, and probably not for a while down the road.

Until we figure that out, the only good way forward is to try, learn, evolve, and repeat — as quickly as possible, again and again. That's the fastest and most resource-efficient way to locate the right goal line.

The key difference is the "gated".

Domain Prototyping is not a template approach. That means, we cannot set a timeline or Gantt chart that determines when or under what conditions we will transition from Inception to Conception, or from Concretization to Realization. There is no approval process, and no gatekeeper, and most of all: no finish line.

So, when should we switch? There is no million dollar secret, unfortunately. When to switch is a decision that often determines the fate of a company. Haste is often the enemy of success — moving on while important assumptions are unverified means accepting the risk of total failure. On the other hand, getting stuck in analysis paralysis means missing the window of opportunity.

Ideally, the decision should come from the team, and it should emerge from a reflection of what we have learned vs what is still unknown. Best case, this will lead to gradual transitions, where some of our work is still part of the earlier phase, while other parts are already anticipate the next phase — and it will feel natural and intuitive.

Democracy, however, will very likely reach its limits over the course of a product journey. Neither time nor budget is unlimited, and even the best-aligned teams will get stuck in arguments. It is advisable to choose a decider when you embark — to break ties and make hard choices, when the time comes.

Yes, absolutely. In fact, it is a perfect match, and we have been doing it for many months. Coding agents allow us to build and iterate on prototypes much faster and with less effort than we could using traditional methods. Instead of working with low-fidelity prototypes, we can use AI to go to actual applications with sophisticated interactions right-away.

Conversely, Domain Prototyping encourages highly modular and readable designs, which are a great match for long-term development using LLMs. In general, the better the existing code base, the better the LLM-generated code. Investing in clear boundaries, good naming, and well-defined patterns will pay off significantly, the more our products grow.

Why didn't we make mention of this earlier? Well, because Domain Prototyping is not an AI methodology. It is entirely agnostic toward AI, and can be used with any tooling, language, or libraries that your organization and team are comfortable with.

Yes, but it requires a fundamental decision that comes with consequences.

Domain Prototyping requires us to explore and iterate on a product, quickly and efficiently. Chances are, we will simply not be able to do that while dealing with legacy architecture and code. We must avoid carrying the weight of history with us, without losing its value. That means, our new product must live in a separate environment, growing over time, while making use of the legacy system in a non-intrusive way.

We achieve that by connecting to the legacy system via adapters and APIs, like we would to any other external system. That doesn't mean it cannot look like a single, unified product — there are a lot of useful UI patterns that help us to create that impression. But in order to move quickly, we cannot have both systems entangled beyond well-defined (and mockable) APIs. In systems that don't have such APIs, this means we need to set aside capacity to build one, endpoint by endpoint, as the new system requires it. This does mean extra effort — but it's one that most legacy modernization approaches recommend. And it's worth the investment.

Starting with the Realization phase - absolutely. Before that: It might. But you would not get the full value.

The long answer is: Scrum has a place in delivery mode, when the business model has been decided, and the organization and the system must scale to meet demand - but it just isn't a good fit for product discovery.

The fundamental principle during the Inception, Conception and Concretization phases — the phases that focus on discovery — is to maximize learning by accelerating the try-observe-learn feedback cycle. This works best if the team is small (one team, cross-functional, self- organized), and collaborative, i.e. everyone working together on the same thing. In a setting like this, the structure and ceremony that Scrum provides don't add value - they impose overhead: You don't need to have daily standups to sync team members, when they're working together all day. You don't need to groom your backlog, if you don't have one. You don't need to do estimations and formal prioritization, if there always is only one task in progress: Building the next prototype to test assumptions.

Instead of investing in structure, teams should optimize for true collaboration — by using collaborative modeling techniques and workshop formats, along with software teaming.

Simply put: No.

Fixed scope or timeline imply we know exactly what we're going to build, and the focus is on timely delivery. If you're in such a situation, you should consider other approaches, such as the ones we recommend for the Realization phase (XP, DevOps, Residuality Theory — just to name a few).

The same way that a car is just an engine and four wheels, with extra parts.

Figuring out how to put all these methods together in a way that works seamlessly, trying it in practice, observing teams at work and assessing their efforts against results, evaluating what should have been done vs what actually happened, and not least finding and adding those extra steps has been a journey of many years. That is not an easy feat. And it stands on its own.

Domain Prototyping is the synthesis of many ideas and practices, including Domain-Driven Design (DDD), Lean Startup, Minimum Viable Product (MVP) thinking, and others, with the addition of self-similar patterns as a way to keep architecture malleable. There is no secret about where it came from, and noone here pretends they invented any of these original methods — they are the sole work of their originators, and credit should always go where credit is due. We have tried to name and respect them all on this page.

However, if we were to ask any of these people, they would probably tell us the same thing: They took whatever good techniques, practices and models were out there, combined them, and added some of their own work on top. That's how progress works — we are all just standing on the shoulders of giants.

Is that worth giving it a name? You be the judge of that. We think it is.