From complexity to a shared product direction
PRODUCT DISCOVERYUsing service blueprinting as a shared decision-making tool to align product, design and engineering — and define the critical path towards an MVP for a complex inspection and documentation product.
From complexity to a shared product direction
PRODUCT DISCOVERYUsing service blueprinting as a shared decision-making tool to align product, design and engineering — and define the critical path towards an MVP for a complex inspection and documentation product.
My role
Product discovery · Service blueprinting · Facilitation · Workflow mapping · MVP scoping
Users
Professionals planning, performing and documenting inspections.
Context
Complex inspection workflows spanning planning, field execution, documentation and follow-up.
Product
Web and mobile product for digital inspections, template builder, documentation and record keeping.
Time
Discovery → MVP definition
2026
The challenge
Replacing a product without simply rebuilding it
The existing product was approaching end-of-life, creating a need to define what should replace it — without simply recreating the current solution.
The product supports a complex inspection process across web and mobile. Different user roles are involved in planning, performing, documenting and following up on inspections, while the product also needs to support different inspection types — from work environment and safety inspections to more specialised professional inspections.
At the same time, the future solution had to account for technical dependencies, product architecture and a new way of developing software.
Before defining individual features or interfaces, we needed a shared understanding of the product as a whole.
The challenge was to turn that complexity into a shared product direction — and identify the critical path towards a viable MVP.
- Multiple user roles
- Connected workflows
- Technical dependencies
- End-of-life product
Key insight
We needed a shared model before we needed screens
Early in the process, it became clear that the challenge could not be solved by looking at individual features or interfaces in isolation.
Decisions in one part of the product affected workflows, data and technical behaviour elsewhere. To make meaningful decisions about the MVP, we first needed to understand how the entire service fitted together.
I therefore used service blueprinting as more than a documentation exercise. It became a shared working model that brought user workflows, product behaviour and technical perspectives into the same conversation.
The blueprint became a shared language for deciding what we were actually building.
From perspectives to a shared model
Building the blueprint together
I drove the blueprinting process in close collaboration with the Product Owner, product specialist, backend developer, frontend architect and enterprise architect.
Together, we mapped the core workflows across different user roles and connected them to the underlying product and technical behaviour.
The process made assumptions visible and allowed different disciplines to challenge each other’s perspectives. Instead of discussing isolated features, we could look at the full flow and understand how decisions in one part of the product affected another.
The blueprint became a living decision-making tool throughout discovery and MVP scoping — not a static deliverable created at the end of the process.
The service blueprint
From user needs to system behaviour
The blueprint mapped the end-to-end inspection process across multiple layers. By connecting these layers, we could trace a workflow from user intent through product behaviour and into the underlying system.
This created a shared model that both product and engineering could reason from — while keeping the user workflow at the centre.
Connecting experience and architecture
From user actions to commands and events
As the blueprint evolved, we extended it with commands and events.
This created a stronger connection between what users were trying to accomplish and what needed to happen within the system.
For example, a user action such as completing an inspection could be connected to a command, system behaviour and resulting event.
That made it possible for design, product and engineering to discuss the same workflow from different perspectives without losing the relationship between them.
The blueprint therefore became more than an experience map.
It connected user intent, product behaviour and technical architecture.
From understanding to prioritisation
Finding the critical path to an MVP
To define the MVP, we mapped a simplified core workflow for each key user role — focusing on what each role needed to accomplish for the product to work end to end.
Looking at the role-based blueprints together gave us a shared view of the product across different perspectives. It helped reveal where workflows connected, which capabilities were shared, and where dependencies existed between roles and system behaviour.
Rather than scoping the MVP as a list of individual features, we could evaluate what was needed to support the minimum coherent workflow across the product. This gave the team a stronger foundation for deciding what belonged in the first version — and what could be introduced later.
The goal wasn’t to include every workflow. It was to identify the smallest set of connected workflows that could make the product viable
An experimental development model
Designing direction in an agentic workflow
The project also explored an agentic AI approach to software development.
This challenged the more traditional sequence where detailed designs are produced before development begins.
When implementation can move quickly from intent towards working software, the role of design changes.
Instead of specifying every interface upfront, the blueprint helped define the intended workflow, system boundaries and expected behaviour.
It provided a common frame that product, design, architecture and development could work from while allowing the implementation to evolve more iteratively.
As implementation became faster, clarity about what we were building became more important — not less.
For me, this reinforced the value of design artefacts that communicate intent rather than simply describe screens.
THE OUTCOME
A shared product model that turned complexity into decisions — and created a critical path towards the MVP.
Key takeaways
Alignment is a design outcome
Design is not only about the interface. Creating shared understanding across product, engineering and domain expertise can be one of the most important outcomes of the design process.
Scope the workflow,not
the feature list
A viable MVP needs a coherent end-to-end experience. Prioritisation becomes stronger when decisions are made around the workflow rather than isolated functionality.
Design artefacts should enable decisions
The most valuable artefacts are not necessarily the most polished ones. They are the ones that help teams understand complexity, challenge assumptions and decide what to do next.