Shaping the Requirement

These are the positions I hold when working with stakeholders to turn an ask into the right thing to build.

Challenge the Solution to Find the Requirement

Stakeholders instinctively propose solutions. That isn’t a flaw; it’s how most people think. But a solution isn’t a requirement. The architect’s job is to push past the proposed solution to find the underlying need, because the first solution described is rarely the only option, and often not the best one.

I’ve seen this across every organisation and domain I’ve worked in. A stakeholder arrives with a specific ask: “we need a new report”, “we need a button that does X”, “we need to integrate with Y”. The team starts scoping the work. Nobody asks what problem the report is solving, what decision X enables, or why Y matters.

What I push back on

• Feature requests taken at face value without asking what problem they solve
• Requirements documents written around a proposed solution rather than a desired outcome
• “We need to build X” as a starting point for architecture conversations, when the starting point should be “what are we trying to achieve?”

The question worth asking

If we can’t build that specific thing, what are you actually trying to do?

That question tends to surface the real requirement quickly. Often it also reveals that the proposed solution is one of several possible approaches, not the only one.

A Mockup Is a Hypothesis, Not a Contract

Visual designs and mockups are powerful tools for generating conversation, surfacing misunderstandings, and testing assumptions. They aren’t specifications. A mockup is a hypothesis about what the right solution might look like: it should be treated as a starting point for a conversation, not a commitment to deliver exactly what’s drawn.

The problem arises when mockups are treated as contracts. Once a design is presented to stakeholders, it tends to anchor expectations. Every subsequent conversation becomes about the gap between what was shown and what was built, rather than about whether what was built actually solves the problem.

What goes wrong

• Designs are shown to stakeholders before the underlying requirement is agreed, and the design becomes the requirement
• Development is scoped against the mockup (“build this screen”) rather than the outcome (“allow the user to do X”)
• UI choices made in a design tool (layout, label text, component structure) are treated as decisions that can’t be revisited during development
• Edge cases and states that don’t appear in the mockup are treated as out of scope

What I push back on

• Stakeholder sign-off on a mockup being treated as a green light to build it exactly as drawn
• The question “why doesn’t it look like the mockup?” as a default measure of success
• Designs that omit loading states, error states, empty states, and edge cases, and then treat those as unexpected requirements when they surface