The "Why Are You Doing This?" Question

In one line: For every project, every feature, every change — be able to answer "why?" — and the answer should connect to a real user problem, a measurable outcome, or a strategic priority.

In plain English

A surprising amount of engineering effort goes into work that nobody can justify when asked directly. "Because we always have." "Because someone said so." "Because it would be cool." Make answering "why?" a habit on every change. The act of asking surfaces the work that should not be happening.

The answer should connect to:

• A real user problem.
• A measurable business outcome.
• A strategic priority.

If the answer is "because we always have" or "because someone said so" or "because it would be cool" — pause. Maybe don't.

Forcing functions

• PRDs require a "problem statement" section.
• Engineering proposals require a "motivation" section.
• 1:1s ask "what are you working on, and why?"
• Performance reviews ask "what impact did your work have?"

These force the question to surface.

Worked example: killing a multi-quarter project with one question

A team has been working for two quarters on a "platform redesign." Onboarding the new engineering manager, she asks each engineer in 1:1s: "What problem does this solve, in a sentence?"

The answers vary wildly:

• "Our old platform is hard to use" (which user? what task?).
• "We need a better foundation for future features" (which features?).
• "It's been on the roadmap" (set by whom, why?).
• "Honestly, I'm not sure" (more common than you'd expect).

Nobody can point to a measurable user problem, a measured-and-unacceptable business outcome, or an explicit strategic decision. The project is paused; engineers are reallocated to two features that do have clear motivations. Six months later, neither team misses the redesign.

A single question saved 6+ engineer-quarters of work that nobody could justify when forced to.

Highlight: "why" should be the first slide, not the last

The most common failure mode in tech proposals is starting with the what (the new architecture, the new tool, the new team structure) and burying the why on slide 14. Then in review, everyone debates implementation details, and the underlying motivation never gets scrutiny.

Flip it: state the user problem or business outcome in the first paragraph. Everything else has to justify itself against that. If you can't fit the motivation into a paragraph, you haven't done the thinking yet.

Common mistakes

Where people commonly trip up

• Accepting "the customer asked for it" as a complete answer. One enterprise customer asking for a feature is not a user problem — it's an account demand. Translate it back into a real problem and check whether the rest of your users have it too, or you'll build niche features that bloat the product for everyone else.
• Mistaking activity for impact in your "why." "I shipped 14 PRs this sprint" answers what, not why. The honest impact question — "which user behavior changed because of those PRs?" — often reveals that half the work moved no metric. Connect work to outcome, not output.
• Letting "strategic priority" mean "the CEO mentioned it once." Strategic priorities are written down, reviewed, and re-confirmed — they're not the most recent enthusiasm. If you can't point to where the strategy lives, you're working from gossip about strategy, which dies as soon as the next gossip arrives.
• Asking the question only at kickoff, not mid-project. Projects accumulate purpose drift: by month four, the team is solving a different problem than the one they started on. Re-ask "why are we doing this?" every couple of months. Sometimes the answer is "we should stop" — and that's the most valuable answer the question produces.

Page checkpoint

Checkpoint Quiz

Did 'why are we doing this?' stick?

Required

What's next

→ Continue to The Hiring-Constraint Principle — pick technologies your future self can hire for.