If you have followed this series end to end, you now have:
- A clear set of user actors and business outcomes (Who, What)
- A detailed breakdown of system behaviour and value (What, Why)
- A technically grounded architecture built around real-world goals (How)
- A secure, scalable, cost-conscious deployment plan (Where)
- A realistic, transparent roadmap (When)
And a worked example showing it all in action.
That is not just a design. That is a delivery-ready plan.
Why the order matters
The 6Ws are sequential for a reason. Swap two of them and the plan starts leaning.
Start with Who and every subsequent decision has a human to anchor it. Jump to How first and you end up architecting in a vacuum, then retrofitting users to the stack you already fell in love with. We see this constantly in discovery calls: a team has picked Kafka, Kubernetes, and an event-sourced ledger before anyone has asked which actor actually needs real-time data. That is not engineering, that is cosplay.
What and Why belong in a pair. What without Why produces feature lists no one can prioritise. Why without What produces aspirational decks no one can ship. Together they give each story a purpose and each purpose a behaviour.
Where must follow How, not precede it. Hosting choices should be driven by the workload, not the other way round. A team that picks "serverless" as a religion ends up forcing stateful services into stateless containers, or paying eye-watering cold-start premiums on a workload that could have happily lived on two VMs.
When sits last for a reason too. Dates without scope are fiction. Sequence them after the other five Ws and the timeline falls out of the work, instead of the work being crushed to fit a deadline.
What the 6Ws are not
It is worth being honest about what this framework does not do.
- It does not replace discovery. Customer interviews, usability testing, and data analysis still need to happen. The 6Ws give you a place to record what they produced.
- It does not replace delivery process. Scrum, Kanban, Shape Up, or whatever rhythm your team runs on still runs on. The 6Ws sit above the process, not inside it.
- It does not replace architecture review. A senior engineer still needs to look at the How and push back where it is weak. The 6Ws make their job easier, not optional.
- It does not guarantee success. A team can write beautiful 6Ws answers and still ship the wrong thing if the inputs were wrong. Garbage in, elegant-framework-shaped garbage out.
What the 6Ws do is reduce a very specific failure mode: the one where smart people build the wrong thing because no one wrote down what "right" looked like.
How to introduce this to a team
Rolling out a thinking framework without performative ceremony is an art.
- Do not rename tickets. No one wants "Who ticket 42" in their backlog.
- Do not make it a compliance exercise. If every doc needs a 6Ws table to get signed off, you have just added overhead without adding clarity.
- Do embed it in the artefacts you already produce. A one-page project brief that happens to answer the six questions is much easier to adopt than a new template with six mandatory headers.
- Do use it to unblock stuck conversations. When a meeting spirals, asking "which W are we actually arguing about?" usually lands the plane.
Our own consultants use the 6Ws as an internal checklist more than an external deliverable. By the time the client sees the output, it looks like a normal proposal. The thinking underneath is just tidier.
What comes next
The 6Ws are not a one-off workshop. They are a reusable framework. Use them:
- When scoping a new feature
- During technical discovery for a greenfield project
- When troubleshooting an architecture misalignment
- In retrospectives and design reviews
- When you inherit a legacy system and need to reverse-engineer its logic
Over time they become second nature. The quiet logic in your planning docs, architecture diagrams, sprint plans, and stakeholder decks.
Signals you are doing it right
You will know the 6Ws are embedded when a few things stop happening.
- Kick-off meetings stop running over. The questions that used to derail them are answered before anyone opens a calendar invite.
- Architecture reviews stop becoming scope debates. The scope is already settled, so the review can focus on the engineering.
- Estimates stop being argued down. The Why gives each item a measurable value, so cutting it means losing something specific, not something vague.
- Stakeholders stop asking what the team is doing. The planning artefacts already tell them.
- Post-mortems stop blaming individuals. The failures point to a specific W that was skipped, which is a much more useful lesson than "Dave should have tested more".
None of these changes are dramatic on their own. Together they compound into a team that spends less energy explaining itself and more energy shipping.
A short vignette
One engagement we inherited had four months of effort, two architects, a cloud bill north of five figures a month, and no user. The brief had been "modernise the customer portal", and the team had heroically modernised the customer portal. The problem was nobody had asked which customers used it, which parts they relied on, or which parts could safely be retired.
We ran a 6Ws pass over two afternoons. Who turned up twelve distinct personas, eight of which were already using a different tool and did not need the portal at all. What reduced the feature list from forty-three items to eleven. Why produced a single measurable outcome (reduce inbound support tickets by a quarter in ninety days). How simplified from four microservices to two. Where collapsed a multi-region setup to a single region with a warm standby, cutting the cloud bill by sixty percent. When replaced a vague "Q3 launch" with a concrete two-week MVP and a staged rollout.
The team did not need better engineers. They needed the six questions answered before the engineering started. Most teams do.
A short reflection exercise
If you have a project in flight right now, try this in under ten minutes.
- Write the Who in one sentence. If you need more than a sentence, you have multiple projects pretending to be one.
- Write the What as a bullet list of outcomes, not features. If an item reads like a UI element, rewrite it.
- Write the Why as a single measurable number. "Reduce approval time from five days to one day" is a Why. "Improve efficiency" is a wish.
- Write the How as a three-line paragraph a non-engineer could understand. If it reads like a job ad for a specific cloud provider, start again.
- Write the Where as the three things most likely to fail in production and what happens when they do.
- Write the When as a pair: the earliest date a user can get value, and the date the team believes the full scope can ship. Protect the gap between them.
If any of the six are hard to write, that is where your project actually needs attention. The 6Ws do not tell you the answer. They tell you where the thinking has not happened yet.
Final thought
Designing software is more than writing code or picking cloud services. It is about connecting purpose to people, decisions to value, and work to outcomes. The 6Ws give you a way to do exactly that.
Not rigid. Not heavyweight. Just clear, adaptable thinking that scales with ambition.
Now you have the tools. What will you build with them?
If you want us in the room when you try it, start a conversation and we will walk the 6Ws with you on a live piece of work.
