Before the first line of code, there’s a better question.
A good product is not one big reveal. It is a sequence of decisions: understand the problem, find the essential, connect the system, make it real and learn from what happens next.
Let's follow an illustrative product idea through the process. This is a teaching example, not a claim about a delivered client project.
The first instinct might be to open a design tool or choose a framework. But “easier” means very different things to the person booking, the person managing the calendar and the team supporting both.
So we look at the journey before proposing the product. Where does information get lost? Where do people repeat themselves? What makes them unsure about the next step?
The starting point is not “build an app.” It is make the booking status clear for everyone involved.
FROM A REQUEST TO A CLEARER PROBLEM
MessagesA calendarFollow-up calls
“Is my booking confirmed?”THE UNCERTAINTY THAT CONNECTS THE JOURNEY
A clear request. A visible status. A next step.
02 / LOOK FOR THE PATTERN
Listen to the people. Trace the friction.
Discovery connects three kinds of context. The overlap gives us a problem we can explain, test and make decisions around.
PEOPLEWho is trying to do what?
Goals, expectations and the moments that feel uncertain.
JOURNEYWhat happens today?
Actions, handoffs, repeated work and missing information.
CONSTRAINTSWhat must we work within?
Existing systems, timing, budget and operating realities.
SHARED UNDERSTANDINGA problem worth solving.
A useful direction names the person, the friction and the change we want to make.
Scroll through the chapters. The map tracks the current stage, while each chapter explains the work, the decision and what we leave with.
01
Understand
First, make sure we’re solving the right problem.
A request often describes a solution before it explains a need. I want to understand what people do today, where they get stuck and what a useful outcome would change for them.
BACK TO OUR BOOKING EXAMPLE
In our booking example, the problem may not be a missing app. It may be that customers cannot tell whether their appointment is confirmed.
Walk through the existing journey
Identify the users and constraints
Agree what success would mean
THE DECISION GATE
Is the problem clear enough to choose a direction?
The question becomes specific.
02
Simplify
Then, find the smallest experience that matters.
Bring the important journey into focus. Separate the essential actions from the features that can wait, and make the first useful version small enough to learn from.
BACK TO OUR BOOKING EXAMPLE
Start with choosing a time, sending a request and seeing a clear status. A loyalty programme or a complex analytics dashboard can wait until the core journey works.
Map the core user journey
Prototype the important interactions
Make the exclusions explicit
THE DECISION GATE
Does every part of the first release support that journey?
The idea becomes a direction.
03
Architect
Give the product a structure that makes sense.
Define responsibilities before connecting the pieces. The interface, business rules and data model should tell the same story, including what happens when a request cannot be completed.
BACK TO OUR BOOKING EXAMPLE
A booking needs an owner, an available slot and a status. Decide where availability is checked, how conflicts are handled and what the user sees when a slot changes.
Trace the request and its data
Choose the simplest suitable tools
Make risk and failure paths visible
THE DECISION GATE
Are the boundaries, data and failure paths understandable?
The direction becomes a system.
04
Build
Make one complete slice work. Then build on it.
Connect the interface and implementation in small increments. A working slice gives us something useful to review, test and improve before more scope is added.
BACK TO OUR BOOKING EXAMPLE
Build the booking request from input to saved status. Test the valid path, an unavailable slot and a failed request—not just the happy screenshot.
Implement a complete user journey
Test critical paths and edge cases
Review the experience together
THE DECISION GATE
Can someone complete the task, and recover when it fails?
The system becomes something real.
05
Improve
Let real use shape the next decision.
Release creates a new source of evidence. Observe the behaviour, listen to feedback and choose the next improvement based on the friction that actually remains.
BACK TO OUR BOOKING EXAMPLE
If users still ask whether a booking is confirmed, improve the status language and notifications before assuming that more features are the answer.
Observe the experience in use
Separate symptoms from causes
Choose and validate the next change
THE DECISION GATE
What change would make the next version meaningfully better?
The release becomes the next question.
04 / UNDER THE SIMPLE SCREEN
A small interaction. A connected system.
The interface is one part of the journey. In our conceptual booking workflow, each layer has a clear responsibility and the response returns to the person who started it.
01 / THE PERSONChoose a time. Send a request.WEB OR MOBILE INTERFACE
INPUT + CONTEXT
02 / THE BOUNDARYValidate the request.CHECK INPUT, IDENTITY & ACCESS
IF SOMETHING IS MISSINGExplain what needs to change.Return helpful feedback to the interface.
IF THE REQUEST IS VALIDApply the booking rules.Check availability and handle conflicts.
VALID, AVAILABLE REQUEST
03 / PERSISTENCESave the booking state.THE AGREED SOURCE OF TRUTH
→
04 / THE RESPONSEMake the status visible.CONFIRMATION + THE NEXT STEP
