In the noise of modern delivery, agile ceremonies, cloud platforms, shifting priorities, it is easy to lose sight of what matters: clarity, structure, and shared understanding. The 6Ws methodology starts from a simple premise. Software planning is not just a technical exercise. It is a human one. Good systems are not just built. They are designed to matter.
This series walks through six questions that we put at the centre of every serious piece of work we do for clients:
- Who are we building this for?
- What needs to happen?
- Why is it valuable?
- How will it work?
- Where will it run?
- When will it be delivered?
Each W is a lens, not a checkbox. Used together, they give product owners, engineers, designers, and sponsors a common language for productive, informed, purpose-driven decisions.
Why another framework at all
Fair question. The internet does not lack for acronyms. INVEST, SMART, RICE, WSJF, the Double Diamond, Jobs To Be Done, BDD, DDD, and a parade of vendor-specific maturity models are all real things with real adherents. Most of them are useful in their lane.
The gap the 6Ws fills is at the very start, before any of the above kick in. You cannot write a good user story until you know who the user is. You cannot size a job until you know what outcome it pays for. You cannot apply domain-driven design to a domain nobody has described. The 6Ws are the upstream work that makes the downstream frameworks useful.
Think of it as the conversation you wish your team had before the first sprint, written down in a form you can reuse.
Where this came from
We did not invent the idea of asking who, what, why, how, where, and when. Kipling put it in a poem in 1902. Every journalist since has used a version of it. Engineering managers have been sketching variants of it on whiteboards for decades.
What we have done is codify the order, the weighting, and the artefacts. The order matters because jumping ahead hides risk. The weighting matters because not every W carries the same cost when you get it wrong. The artefacts matter because a methodology that lives in someone's head dies when that person leaves.
The version in this series is the one we run internally at Enterprise Automation Services and the one we have used on engagements across FinTech, logistics, healthcare, and the public sector. It has survived contact with angry CFOs, regulator audits, and at least one acquisition. It is not precious. It is practical.
What each part covers
A quick preview of the rest of the series so you know where you are heading.
- Who - the actors, stakeholders, and integrators. How to avoid the "everyone is the user" trap.
- What - outcomes and actions. Translating user intent into system behaviour without leaking solutions into the requirements.
- Why - the business benefit. How to turn vague ambition into a number you can measure and defend.
- How - the technical design. Architecture that serves the Who and What, not the architect's CV.
- Where - the hosting strategy. Cost, resilience, and operational reality from day one.
- When - planning, estimation, and prioritisation. Dates that survive contact with reality.
- The 6Ws in practice - a worked example on a real-world problem.
- Looking back - how to embed the framework without turning it into ceremony.
Each part stands on its own. You can dip in where the pain is worst. But the order is the order for a reason, and the series rewards reading straight through.
Who this is for
This is written for cross-functional teams shipping real software. SaaS products, internal platforms, API ecosystems, legacy modernisation. Whether you are a solo founder, a CTO, or part of a delivery squad, the 6Ws help you zoom out before you zoom in.
It is particularly useful if you recognise any of these situations.
- Your team is busy but you cannot articulate what it is shipping towards.
- Sprint reviews feel more like status updates than demonstrations of value.
- Engineering keeps asking "but why" and product keeps answering "because the customer wants it" without evidence.
- Every architecture conversation turns into a platform debate.
- Estimates keep slipping and nobody is sure whether it is a scope problem, a skill problem, or a structure problem.
None of those are unusual. All of them are symptoms of planning that skipped one or more of the six questions.
What makes this different
It is not a new development methodology and it will not replace Scrum, SAFe, or whatever framework is keeping your backlog in order. It is a thinking scaffold that sits above the process. It helps you ask better questions, reduce friction, and design systems that are pragmatic and purposeful.
You will not find buzzwords or theory for the sake of theory. You will find grounded advice, reusable templates, and the voice of experience from an engineering consultancy that has seen the failure modes up close.
Three things in particular set this apart from a generic planning checklist.
- It is sequential and opinionated. The order is not decorative. Swapping How and Where, or Why and What, produces different (usually worse) plans.
- It produces artefacts, not opinions. Each W has a reusable template that outlives the meeting it was written in.
- It is boring on purpose. There is no branded framework, no certification, no quadrant. If you show up to a client meeting waving a quadrant, we have failed.
How to read this series
A few practical notes on getting the most out of the next eight posts.
If you are short on time, skip to the W that hurts most. If sprint planning keeps slipping, start with When. If the team is arguing about stacks, start with How. If stakeholders keep asking what the point is, start with Why. Each post is self-contained enough to be useful in isolation.
If you have time, read them in order. The sequence is deliberate and every post leans on the one before it. Reading out of order will still work but you will notice the back-references hinting at context you skipped.
If you are reading this as a team, treat each post as the prompt for a thirty-minute working session rather than a solo read. The questions each W raises are not ones any individual should answer alone. A Who drafted by product without engineering is a Who that will surprise engineering later. A How drafted by architecture without product is a How that will solve the wrong problem elegantly.
What the 6Ws will not do for you
It is worth being clear up front. A framework cannot fix a team that will not talk to each other. It cannot compensate for a sponsor who will not commit to a Why, or an engineering lead who will not own a How. It cannot turn a six-month research problem into a two-week sprint. And it cannot tell you whether a project should happen at all, only whether the one you have chosen has been thought through.
What it does is make the unknown unknowns smaller and the arguments more productive. Those are modest claims. They are also the ones that matter on a Tuesday afternoon when a slide deck is due.
The promise
By the end of the series you will have a reusable way to:
- Map the scope of a system quickly and accurately
- Align technical effort with real user and business value
- Make smarter infrastructure and design choices
- Plan delivery with confidence and transparency
- Onboard new team members without a week of tribal-knowledge briefings
- Push back on bad briefs with structured questions rather than gut feel
Because in a world of sprints, backlogs, and deployments, the best software still starts with asking the right questions.
If you want this applied to a real engagement, start a conversation and we will walk through it with you.
