“Yes, we can do that, but it changes what we agreed.”
Or,
“We can add this, but something else needs to move.”
That is the leverage good discovery gives you.
“We can’t do that because we don’t have enough time...”
...is what happens when you skip it.
The project that taught me reinforced this
When I was working with RK SWAMY, we took on a project for a public service agency to create and launch a website. The deadline was extremely tight. The site had to be launched in roughly two days, and there was a genuine time constraint behind that requirement.
So we did what teams often do when faced with an urgent deadline: we started executing.
There was no meaningful discovery. There was no detailed agreement about the scope. There was no shared understanding of everything the website needed to contain or how the requirements might evolve. We had a broad idea of what the site should do, including publishing material such as posters that people could download and use at their own premises, and then we got to work.
We worked until around two in the morning to get the site completed.
The frustrating part came from what we had failed to do before we started.
Because we had never established the scope properly, we had no real basis for saying what was inside it and what wasn't. If the client wanted something added, our only meaningful response was that it might not be possible within the available time.
We had no leverage because we had never established the agreement that would have given us that leverage.
Scope cannot be managed if scope was never properly defined.
A brief is a brief. It should lead to a scope.
This is something I have come to believe quite strongly: the first brief you receive is almost never the complete definition of the work.
There is often an information chain inside an organisation or agency. The client speaks to an engagement or account team. That team passes the requirement to the people who will actually execute it. Each transition can lose information.
The people who first speak to the client may understand the business request perfectly well. But they may not know the questions that a designer, researcher, developer or other specialist needs answered before the work can begin.
That is not a criticism of the account team. It is simply a consequence of different people having different expertise.
The problem arises when the execution team treats the brief as complete and starts working without questioning it.
If a design team does not ask questions, it will not discover the answers. And when those unanswered questions eventually surface during execution, they often look like new requirements.
That is how what we call scope creep begins.
A dinner for 100 guests
If you are hosting a dinner for 100 people. You approach a caterer and say, “I need dinner arranged for 100 people.”
Imagine that the caterer simply says yes and starts cooking.
When the guests arrive, you might say, “Where are the welcome drinks?” Then, “We need starters.” Then, “What about dessert?” Then you remember another dish you wanted. Perhaps some items need to be available in larger quantities than others.
At that point, it would be tempting for the caterer to say, “You never told me about any of this.” But that isn't a particularly strong professional position. A good caterer knows that “dinner for 100” is a starting point for a conversation, not a complete specification.
So when you ask for a dinner for a 100 guests, they will ask what is being served, in what quantities, at what point during the event, and what the host expects the experience to be. Only after that he will discuss the price and move ahead.
Design work is no different.
“Build a website” is not a scope. It is the beginning of a discovery conversation.
Discovery is not bureaucracy added before the work. It is the process of turning an intention into an agreement.
The difficult part: time pressure
There is an obvious objection to all of this.
What if the client genuinely has a very short timeline and there simply isn't time for an elaborate discovery exercise?
That is a reasonable objection because I have been on the other side of it.
The answer is not that you should refuse every urgent engagement or insist on a lengthy process before doing anything.
The more practical lesson is this: you should take the time pressure only when you have explicitly agreed to take it.
Until the engagement is agreed, the urgency belongs to the client. It is the client's responsibility to answer the questions necessary for you to understand the work and determine what can realistically be delivered.
Something interesting happens when you have that conversation before saying yes. Clients can be surprisingly willing to make concessions. They may remove requirements, change expectations, simplify deliverables or accept compromises that would have been much harder to negotiate once the team was already working.
But this is much easier to say than to practise.
The pressure does not always come from the client. It can come from inside your own organisation.
The pressure to say yes
There are usually good intentions behind that pressure. The company wants to win the business, or protect the relationship. Someone sees an opportunity to help an important client. Someone else believes the team can somehow make it work.
So the organisation says yes.
And the delivery team inherits the urgency, the ambiguity and the expectations without having had the opportunity to establish the conditions under which the work can succeed.
This can look like excellent client service from the outside.
Sometimes it is anything but.
If you put a team into an engagement without clear boundaries and ask them to absorb every new expectation, they will eventually burn out. The frustration does not stay neatly contained within the team. It leaks into conversations, decisions and interactions with the client.
The relationship the company was trying to protect can end up suffering more damage than it would have if the company had simply negotiated the engagement properly—or said no.
Sometimes saying yes to protect a relationship is exactly what damages the relationship.
Discovery is also a form of leverage
There is another reason discovery matters that is easy to overlook.
It gives the delivery team a basis for making decisions.
Once the client and team have agreed what is being delivered, what is not being delivered, what assumptions are being made and what compromises have been accepted, a new request can be evaluated against that agreement.
You can say, “Yes, we can do that, but it changes what we agreed.”
Or, “We can add this, but something else needs to move.”
That is very different from saying, “We can't do that because we don't have enough time.”
The first is a professional conversation about trade-offs. The second is often just a desperate attempt to survive an engagement that was never properly defined.
The responsibility belongs to the team too
It is tempting to put all the responsibility for poor discovery on the client. After all, the client is the person asking for the work.
I don't think that is fair.
The client may not know what questions need to be asked. That is one reason they are hiring specialists.
A design team has a responsibility to interrogate the brief, expose assumptions and ask the questions that its expertise tells it are important.
That doesn't mean creating unnecessary process. It means recognising that a requirement that sounds simple can contain many decisions that have not yet been made.
The professional value is not simply in executing what someone tells you.
It is also in knowing what needs to be clarified before execution can begin.
Don't confuse urgency with permission to be ambiguous
Projects will always have deadlines. Some deadlines will be unreasonable. Some will be immovable. Some will be genuinely urgent.
The answer is not to pretend that time pressure can always be eliminated.
The answer is to make the trade-offs explicit.
If the project must launch in two days, agree what can realistically be delivered in two days. If something has to be left out, agree that it is being left out. If a decision has not been made, identify it. If the team is accepting a compromise, make the compromise visible.
Then everyone understands what they have agreed to.
That is very different from starting with an ambiguous brief and hoping that everyone will somehow arrive at the same understanding while the clock is running.
That project taught me that what looks like scope creep at the end of a project can actually be a discovery failure at the beginning.
The lesson isn't that every project needs a long discovery phase.
The lesson is more fundamental:
Before you accept the deadline, make sure you understand what you are agreeing to deliver.
You can accept urgency.
You shouldn't accept ambiguity by accident.
