Someone asks it in almost every project kickoff:

It sounds like a reasonable place to start. After all, requirements give teams something to build against. But requirements are rarely where a great project begins. 

They are where a set of decisions gets documented. And there is a big difference.

A requirement isn't the problem

Requirements aren't bad. We need them. 

The problem is that a requirement often represents a decision that was made before anyone really understood the problem. 

A stakeholder says, “We need a new dashboard.” So the team starts documenting what the dashboard needs to show. 

Or someone says, “We need a new onboarding flow.” So the team starts figuring out what the flow should walk people through and what systems it should connect to. 

Before long, everyone is working toward the same thing. The problem is, being aligned around the wrong thing is still being wrong. 

You can have great requirements for a solution that doesn't actually solve the problem.

This is where projects get expensive

The earlier we lock into a solution, the more expensive it becomes to question it. 

At the beginning, changing direction is relatively easy. A conversation changes. A stakeholder realizes something. Research tells us something we didn't expect. We learn that customers aren't actually struggling with the thing we thought they were. Great. We adjust.

But six weeks later, we've got requirements, designs, estimates, a backlog and a team ready to start building. Now changing direction feels like failure. 

So we keep going. 

I watched this happen on a project a while back. The team had been asked to build new features for a specific group of users. Discovery turned up something nobody expected: those users didn't actually want more for themselves. What they cared about most was how well the tool helped them take care of someone else's need, and that wasn't anywhere in the original brief. If we'd built what was asked for, we'd have shipped the wrong assumption. It just would have looked like progress the whole time. 

I've seen some version of that happen more than once. Same root cause each time: teams writing requirements reactively, sprint to sprint, because nobody owned defining the actual problem before the work started. The stories get vague. The scope creeps. The demo gets scrambled together at the last minute. Nobody planned any of that. It's just what happens when understanding the problem isn't anyone's specific job. 

Not because people are careless. Because organizations are built to create momentum. 

Once a project has a name, a budget, a team, and a deadline, it's really hard to stop and say, “Wait. Are we solving the right problem?” 

That's exactly why the work before requirements matters.

Start with the problem, not the answer

Before we ask what we should build, we should understand what's happening today. What isn't working? Who's feeling the pain? What are they doing instead, and what is that costing the business? What would actually be different if we solved this?

Those questions might lead to the feature someone originally asked for. They might lead to somewhere else entirely. And sometimes they lead to the conclusion that we shouldn't build anything at all. 

That's not a bad outcome. That's the point.

Discovery should be allowed to change your mind

This is one of the things I think gets lost when we talk about “discovery.” 

Discovery isn't the homework you do before the real work starts. It is the work. It's how you figure out whether the problem is real, whether you understand it, and whether the thing you're about to spend time and money building is actually worth building. 

And good discovery should be allowed to make you uncomfortable. It should uncover things you didn't know. It should challenge assumptions. It should create conversations between people who weren't seeing the problem the same way. And yes, sometimes it should change the scope. 

That's a good thing. 

If we already know exactly what we're going to build before we've talked to customers, looked at the data, understood the business process and explored the constraints, then we're not really discovering anything. We're validating a decision that's already been made. 

So where do requirements fit?

Later. 

Once we understand the problem and have made some decisions about how we're going to address it, requirements become incredibly useful. They give the team something concrete to work from, and clarity about what we're not doing. 

But the requirements shouldn't be the thing telling us what problem we're solving. They should reflect what we've learned and the decisions we've made. 

I think about it less as: 

and more as: 

That second version leaves room for the thing that matters most: learning something along the way. 

The question I'd ask at your next kickoff

When someone says, “Do we have the requirements?” don't necessarily push back. Just ask one question first:

If everyone has a clear answer, great. Now you have something to build toward. If you get five different answers, that's useful too. You just learned that you're not ready for requirements. 

And honestly, I'd rather find that out in a kickoff meeting than six months and a lot of money later. Great projects don't start by defining what to build. They start by understanding what needs to change.