The Why is the soul of a software project. It answers the most critical question any stakeholder, developer, or product manager must understand: why are we building this at all? Without that clarity, delivery drifts, feature creep sets in, and investment quietly loses its justification.
Too often this step is rushed or skipped. Done well, it aligns business goals and technical execution. It lets teams make smart decisions, drop the irrelevant, and drive measurable impact.
What you define here
- The strategic purpose behind each feature or system
- The measurable outcomes and KPIs expected
- The link between technical effort and business value
- The stakeholders or departments who benefit
- How value is delivered, sustained, or scaled
The role of Why in the 6Ws
If Who is the audience and What is the story, the Why is the reason the story needs to be told. It gives you:
- Context for prioritisation
- Evidence for investment
- Motivation for teams
In agile delivery it shows up in epics or initiatives. In traditional shops it maps to the business case. The outcome is the same either way: clear, compelling justification for building something.
Benefits of defining Why
- Prioritisation. Teams can focus on what delivers the most value.
- Buy-in. A well-reasoned Why helps justify time, money, and people.
- Traceability. You can track from idea to delivered value.
- Measurement. Clear outcomes define what success looks like.
- Motivation. Engineers work harder when they understand the impact.
Techniques for capturing Why
Value proposition mapping
Define how the product benefits each user type.
User: [Persona name]
Problem: [What they struggle with now]
Benefit: [What will be better if this feature exists]
Example:
User: Project Manager
Problem: Loses hours each week chasing staff for timesheet approvals.
Benefit: Automated reminders reduce admin time and improve submission rates.
Feature-to-value traceability
| Feature | Business value | Metric or KPI | Frequency of impact |
|---|---|---|---|
| Automated report emails | Saves time on manual exports | 20% reduction in manual reporting | Weekly |
| SSO integration | Lowers adoption barrier | Higher user activation rate | One-off per user |
Objectives and Key Results
Link the feature set to broader business objectives.
Objective: Improve operational efficiency in client reporting.
Key Result 1: Reduce average report creation time from 45 mins to under 15.
Key Result 2: Automate 70% of weekly report exports.
Feature alignment:
- Scheduled report automation
- Reusable dashboard templates
- Bulk export tools
Worked example: leave management
What we are building: a module that lets employees request and manage annual leave.
Why we are building it:
- Reduce HR overhead by 30% on manual request handling
- Improve employee satisfaction through transparent processes
- Ensure compliance with leave policy tracking
How we will measure it:
- Drop in internal HR queries
- Rise in leave requests processed via the system
- Reduction in approval time
Now every story has a line back to a business outcome. A developer deciding whether to polish the approval screen or fix a filter bug knows which one moves a KPI.
Making the Why stick during delivery
A beautiful Why written in the kickoff deck and never mentioned again has done nothing useful. The trick is embedding it somewhere the team looks every day.
Patterns that work in practice.
- Paste the Why into the top of every epic. Not a link, the text. People do not click links.
- Put the KPI on the team's standup board. If the Why claims "reduce approval time to under 48 hours", the current approval time should be visible next to the sprint board.
- Reject new tickets without a Why link. A ticket that cannot name the outcome it supports is either orphan work or a duplicate of something that already exists.
- Ask "and then what" in refinement. For every feature, the conversation continues until the answer is the outcome in the Why, not the next feature.
We have seen teams put their Why on a physical card on the wall. We have seen others pipe the KPI into a Slack channel. The format does not matter. The consistency does.
When the Why changes mid-build
It will. Markets move, strategy pivots, regulators intervene, a competitor ships something and suddenly half the roadmap needs re-justifying. This is not a failure of planning. It is the point at which good planning pays off.
The 6Ws make pivots cheap. If each feature is traceable to a Why, and each Why is traceable to a number, then swapping the Why means looking at a list and deciding which items still pay their way. Items that no longer support a live outcome get dropped, not shoehorned into the new direction.
The teams that struggle with pivots are the teams whose features never had a clear Why to begin with. Everything looks equally important, so nothing can be dropped, so the new Why ends up layered on top of the old one, and the roadmap doubles in size without any extra capacity.
A short counter-example
A client once asked for "a dashboard for the ops team" with the reasoning "because they do not have one". That is not a Why. It is a What without justification.
We asked the real question: what decisions would they make differently if the dashboard existed? After an hour of conversation the answer was clear. Ops were spending forty minutes each morning stitching together three reports before they could decide which incidents to escalate. The Why turned out to be: reduce time-to-escalation on severity-one incidents from roughly forty minutes to under five.
That Why changed the scope of the dashboard completely. Instead of a generic grid, it became a single prioritised queue with two-click triage actions. Half the original feature list evaporated. The remaining half shipped in three weeks instead of twelve, and the new time-to-escalation was tracked daily. The dashboard earned its keep.
Without a real Why, the team would have built the generic version, looked competent in the demo, and been quietly unused within a quarter.
Why templates that work
A handful of formats we return to on engagements.
The one-liner:
We will [measurable outcome] for [audience] by [next date],
because [strategic reason].
The investment case:
Problem cost: [quantified pain today]
Proposed change: [feature or system]
Expected benefit: [quantified improvement]
Confidence: [low / medium / high, with reasoning]
Sunset criteria: [the point at which we would stop investing]
The sunset criteria line is the one most teams skip and the one most worth keeping. Knowing when to stop is as valuable as knowing when to start.
Common pitfalls
- Too vague. "Improve efficiency" does not tell anyone what success looks like.
- Too narrow. Focusing only on technical benefit while ignoring the commercial outcome.
- Disconnected from metrics. No way to measure the claimed value.
- Forgotten after planning. The Why should stay visible throughout delivery, not just in the kickoff deck.
- Too many. If every feature has three Whys, none of them are load-bearing. One primary outcome beats a spray of loosely-connected goals.
- Confusing outputs with outcomes. "Ship the feature" is an output. "Move the number" is an outcome. Only the second is a Why.
Summary
Why is where planning becomes purposeful. It turns roadmaps into business tools and engineering tickets into value-creating steps. A compelling Why inspires the team to build something that matters, not just something that ships.
