Domain Prototyping · Phases
Doing the right thing
at the right time
Building software products is a complex endeavor. 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 try it. But building a market-scale product without knowing it will succeed is a huge risk, and 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.
Chapter 0 — Navigating complexity
The product lifecycle.
A typical software product lifecycle from the first idea to market success can be charted as a succession of four phases:
- 1.Inception: Where we have an original idea
- 2.Conception: Where we turn our idea into a marketable product
- 3.Concretization: Where we hone and improve our product to make it lovable
- 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 fast 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, to evolve and easily adapt to changes.
Not a template.
What's important is that this is not meant as a template model: we can't just plan each phase to be three weeks long and set a release date for three months from now. It is more like a compass to get our bearings.
When we find ourselves having answered enough questions, validated enough assumptions, completed our Value Proposition Canvas, and feeling confident that our idea is a great prospect for hitting the unicorn jackpot — that's when we move to phase 2. When we've compared different ways of implementing it, explored multiple ways of monetizing (subscription, one-off, ad-based, platform sales percentage?), verified pricing schemes, and developed a good understanding of the materials, organizational and legal structures, personnel, and other costs required — that's when we move to phase 3. And so on.
We can also go back, should we find that there are blind spots or missing information, or if we need to pivot. You get the idea: it is up to us to reflect and assess our current situation. It is a good idea to set aside time to do this frequently, with the entire team.
Phase 1 of 4
Inception
- Focus
- Idea verification
- Key question
- Should we be doing this — at all?
- Target deliverable
- Throw-away experiments: paper prototypes, click-dummies, concierge products
- Team strategy
- 1 team, Software Teaming
- Change strategy
- Rewrite
- Test strategy
- Interviews, user tests
- Aligns with
- Problem/Solution Fit (Lean Startup), Explore (3X), Genesis (Wardley Mapping)
UX Design Activities
- ·Qualitative interviews
- ·Observing SMEs at work
- ·Building personas to empathize
- ·Value Proposition Canvas
- ·Working Backwards / PR-FAQ
Important learnings
- ·Is there a user need or problem worth solving?
- ·Would people pay to have the problem solved?
Domain-Driven Design Activities
- ·Event Storming
- ·Domain Storytelling
- ·Develop ubiquitous language / glossary
- ·Create a simple (naive) executable domain model
- ·Write BDD tests directly against the domain core
Phase 2 of 4
Conception
- Focus
- Idea precisioning
- Key question
- Should we be doing it — like this?
- Target deliverable
- Wireframes + Simple UI attached directly to the domain core; run locally for rapid feedback
- Team strategy
- 1 team, Software Teaming
- Change strategy
- Rewrite / Modify
- Test strategy
- User tests
- Aligns with
- Problem/Solution Fit (Lean Startup), Explore (3X), Custom (Wardley Mapping)
UX Design Activities
- ·Wireframe and simple UI prototypes
- ·User-journey walk-throughs with SMEs
- ·Iterative refinement of personas + actors
Important learnings
- ·What are particular gains and pains to be addressed?
- ·What are potential risks and obstacles?
Domain-Driven Design Activities
- ·Attach thin prototype UI directly to domain core - fully functional, no click-dummies
- ·Keep additional technology to an absolute minimum
- ·Run on a local machine for immediate feedback
- ·Start building tooling around CI / CD (build scripts, linting, automated tests)
Phase 3 of 4
Concretization
- Focus
- Feature precisioning
- Key question
- What will make customers love it?
- Target deliverable
- Simple design + alternative experiments; API, adapters, persistence emerge
- Team strategy
- 1 team, Software Teaming
- Change strategy
- Modify
- Test strategy
- User tests, A/B tests
- Aligns with
- Product/Market Fit (Lean Startup), Expand (3X), Product (Wardley Mapping)
UX Design Activities
- ·Simple design — refine and curate features
- ·A/B tests on alternative flows
- ·User tests against fuller prototypes
Important learnings
- ·Compare different ways of building the product - which one resonates best with customers?
- ·Explore different growth engines (sticky, viral, paid) - which one has the most potential?
- ·Explore monetization strategies (subscription, one-off, ad-based, platform sales percentage) - what would customers like best?
Domain-Driven Design Activities
- ·Continuously refine and improve domain model
- ·Introduce adapters around the domain core (hexagonal architecture)
- ·User repositories to gradually move storage from in-memory to external db
- ·Connect to legacy systems via dedicated adapters
Phase 4 of 4
Realization
- Focus
- Infrastructure / Technology
- Key question
- How do we make it scale?
- Target deliverable
- Production-ready components: separate UIs, managed services, security, backup & restore
- Team strategy
- Software Teaming, Agile methods, team mitosis
- Change strategy
- Modify
- Test strategy
- Exploratory tests, performance tests, penetration tests
- Aligns with
- Scaling (Lean Startup), Extract (3X), Commodity (Wardley Mapping)
UX Design Activities
- ·Elaborate design
- ·Split monolithic UI to match personas
- ·User tests with full product
- ·RUM analytics
Important learnings
- ·Build up infrastructure and organization
- ·Build up hiring and recruiting skills
- ·Invest in onboarding and knowledge transfer
- ·Learn how to scale culture
Domain-Driven Design Activities
- ·Split monolithic backend via bounded contexts
- ·Deploy to a monolith server with dedicated DB + search infrastructure
- ·Optionally extract modules into microservices
- ·Move to managed services as scale demands
- ·Introduce security, backup & restore, and operational tooling/observability
- ·Use Team Topologies to design team structure and communication