The Language of Delivery: Why "Need" is a Four Letter Word
In my previous posts about delivery, we've looked at what makes good delivery and different management approaches. Today I want to focus on something that seems tiny but has an outsized impact on delivery success: the difference between saying you "need" something versus saying you "want" it.
The Problem with "Need"
"I need this feature by Friday."
"We need to add proper logging before release."
"The customer needs this change urgently."
Sound familiar? "Need" is seductive. It feels like it adds weight to our requests. After all, if we *need* something, surely that means it's more likely to happen?
But "need" is actually incredibly damaging to good delivery because it short-circuits proper discussion about priorities and trade-offs. When you say you "need" something, you're essentially saying "there is no possible alternative here" - which is rarely true and often leads to poor decisions.
A Tale of Two Projects
Let me share two stories - with two similar projects running one after the other.
Project A: The product manager said they "needed" every feature in their list delivered for customer success. The team, not wanting to let them down, agreed. And then despite the team being full, the manager asked for more - they really needed a decent regression framework, the team needed to get their annual reviews in on time, they needed to fit in a training course. And the team kept saying yes. They worked overtime, cut corners on function, squeezed testing, crunched themselves to collapse and morale took a huge hit. And right at the end of the release it was obvious that everything didn't really fit and the team had to make a second delivery 6 weeks later to patch up all the damage.
Project B: The product manager said they "wanted" to get all features in but worked with the team to rank them by business value. And then when they came to add extra things that they "wanted" to squeeze in, the team pushed back and worked to identify which features or which set of extra things could wait and where they would spend their precious contingency time. The team delivered a solid set of core features on time, with good quality, and the manager pushed back on behalf of the team moving the rest into subsequent releases, and ring-fencing the team's time for training.
Same company, similar projects, very different outcomes - largely driven by how the requirements were framed. I don't name and shame in my posts, but I'll admit here that both the managers above were me, about6 months apart.
Why "Want" Works Better
When you say you "want" something:
It opens up discussion about priorities
It allows exploration of alternatives
It acknowledges that trade-offs exist
It invites collaboration on solutions
Most importantly, it keeps everyone honest about what's really driving decisions. Very few things in software development are truly "needs" - they're "wants" with different priorities and consequences.
Reframing the Conversation
Instead of: "We need this feature by Friday"
Try: "I really want this feature by Friday because it will help us close the Anderson deal"
Instead of: "The customer needs better logging"
Try: "I want to improve our logging because we're spending too much time on support calls"
Notice how the second version in each case opens up the possibility of finding alternative solutions to the underlying problem? Or indeed doing nothing because while important, it’s less important than what folks are already working on.
But What About My Real Needs?
"But wait!" I hear you cry, "Sometimes things really ARE needs! What about legal requirements? Security fixes? Critical bugs?"
Even here, I'd argue that "want" is more honest:
"I want to comply with GDPR because the fines would destroy us"
"I want to fix this security hole because a breach would cost us customers"
"I want to fix this bug because it's costing us $10k per day in support"
Framing these as "wants" doesn't make them less important - it just makes the reasoning explicit and keeps the door open for discussion of how best to address them.
Making it Work in Practice
As always with these things, it’s “simple” but not always “easy”. Here's how to shift from "need" to "want":
Catch yourself using "need" and ask "Is this really a need, or a high-priority want?" Engage the folks you talk to and ask them to pick you up on using “need” too!
When stating what you want, include the reasoning
Welcome discussion about priorities and trade-offs
Be open to alternative solutions that address the underlying goals
Most importantly, recognize that using "want" doesn't make you less likely to get what you're asking for. In fact, by enabling honest discussion about priorities and alternatives, it often leads to better solutions.
The Impact on Delivery
Remember from the first post about delivery - the real value isn't just in getting things done, but in taking the mental load off by having agreement on what is being done. When everything is a "need", you’re overloading people and not getting that true agreement - and people end up trying to achieve the impossible. When things are "wants", you’re they can focus on finding the best way to deliver value.
This also ties directly to the earlier post on hard state vs soft state management too. "Need" tends to push teams toward soft state management (or worse pushes towards micromanagement) as everyone tries to constantly adjust to unchangeable requirements. "Want" enables hard state agreements because it allows for proper negotiation up front.
---
This is the third in a loosely connected series about delivery. Next time, we’ll look at what this delivery thinking means for making plans.