Stop Documenting the Request. Start Finding the Decision.
2216 words/9.5-minute read
“We need to add this feature.”
Great. Why?
And yes, I know. I can practically hear someone saying, “Jamie, we already know why.”
Do we?
Because some of the most expensive work I’ve seen starts with a request that sounds so obvious nobody stops to question it.
It feels like progress.
But documented does not mean understood.
And perhaps even more importantly, documented does not mean decided.
That distinction matters more than ever as organizations invest in AI, automation, new platforms, digital transformation, and increasingly sophisticated technology.
Our tools are getting incredibly good at helping us move faster.
The dangerous part?
They can help us move faster on the wrong work, too.
The Expensive Gap Between a Request and a Decision
Think about a request you’ve heard recently:
“We need a dashboard.”
“We need to automate this.”
“Customers need a new portal.”
“We need AI for this process.”
“We need this field added.”
“We need to replace this system.”
These statements sound actionable.
And that’s exactly why they’re dangerous.
Teams can immediately start talking about features, estimates, vendors, schedules, integrations, configurations, and implementation plans.
But underneath that seemingly clear request are usually a whole lot of unanswered questions.
What problem are we actually solving?
Who is experiencing it?
What outcome needs to change?
What happens today?
Why isn’t that working?
What assumptions are we making?
Who needs to make a decision?
What business rules haven’t surfaced yet?
What happens in the exception cases?
And one of my favorites:
How will we know this worked?
If those questions aren’t answered, documentation can create a false sense of certainty.
We have a requirement.
We have a ticket.
We have a plan.
Therefore, we must know what we’re doing.
Except sometimes we don’t.
Congratulations. We’ve now put our ambiguity in Jira.
We can track it, assign it, put a due date on it, and eventually move it to Done. We still haven’t necessarily figured out what we need.
This Isn't a Documentation Problem
This is where I think leaders need to challenge how they look at project and technology performance.
When work struggles, we often diagnose the visible symptom.
Requirements aren’t detailed enough.
People aren’t following the process.
Teams aren’t using the templates correctly.
Stakeholders aren’t participating.
Projects are taking too long.
Users aren’t adopting the solution.
So we introduce a new template, tool, methodology, training course, or process.
Those things may absolutely be needed.
But sometimes the problem isn’t that people don’t know the process.
The problem is that the organization hasn’t built the behaviors around the process that make it work.
That’s a very different challenge.
Because not every technology problem is actually a technology problem.
Sometimes it’s a process problem. Sometimes it’s a people problem. Sometimes it’s a decision problem. And sometimes—my favorite—we’ve managed to combine all four.
A team can learn how to write acceptance criteria in a class on Tuesday and still struggle to write meaningful acceptance criteria for their own complicated work on Thursday.
A leader can attend a workshop about stakeholder engagement and still have difficulty getting the right people into a decision.
A business analyst can understand how to map a process and then sit down with a real process that has 14 exceptions, three systems, two departments, and one person who says, “Well, technically that’s not how we do it anymore.”
Knowing a technique and being able to use it effectively in a messy organization are two different things.
That’s why I’m increasingly interested not simply in whether people were trained, but whether the organization created the conditions for them to change how they work.
Shift #1: Stop Asking "What Did They Request?"
Start asking:
What are we actually trying to accomplish?
Requests are important. They’re just not always the starting point we think they are.
Imagine a stakeholder says:
“We need to automate this approval process.”
It’s tempting to start discussing automation.
Instead, get curious. Annoyingly curious if necessary.
Because automating a bad process doesn’t magically make it a good process. Sometimes you’ve just created a faster bad process.
What is happening today?
Why does the current approval process exist?
Where are people waiting?
Which approvals actually reduce risk?
Which exist because “we’ve always done it that way”?
What information does an approver need to make the decision?
What happens when the request doesn’t fit the normal path?
Suddenly, “automate the approval process” isn’t a requirement.
It’s one possible solution to a problem we are finally starting to understand.
And that distinction has enormous financial implications.
Because once we start building, buying, configuring, or integrating technology, changing our minds gets increasingly expensive.
Five thoughtful questions today can prevent five months of building something nobody needed tomorrow.
This is one of the reasons strong analysis isn’t administrative overhead.
Analysis protects investment.
It creates the pause between “someone asked for this” and “we are spending money on this.”
For executives overseeing technology portfolios, that pause can be incredibly valuable.
Shift #2: Stop Asking "Is It Documented?"
Ask:
What haven’t we decided yet?
A beautifully documented requirement can still contain an unresolved decision.
That’s why I like to look at requirements, process maps, user stories, and other project artifacts as conversation tools rather than finished products.
Their job isn’t simply to capture what we know.
Their job is also to expose what we don’t know.
Imagine a team reviewing a user story:
As a customer, I want to change my account information online so that my information remains current.
Looks reasonable.
Until we start asking questions.
Which account information?
Can every field be changed?
Does anything require verification?
What happens if the change affects another system?
Does someone need to approve it?
What happens if verification fails?
Should the customer be notified?
What about changes that create regulatory, security, or privacy concerns?
Now we’re getting somewhere.
The value isn’t that we’ve made the user story longer.
The value is that we’ve exposed decisions before developers, testers, users, or operations teams are forced to make those decisions for us later.
That is a completely different definition of “good requirements.”
Shift #3: Stop Asking "How Fast Can We Finish?"
Ask:
What’s the smallest thing we can do that creates useful learning or value?
Organizations understandably care about speed.
So do I.
I just want us to be careful about what we’re measuring.
Finishing more work doesn’t necessarily mean we’re creating more value.
A giant requirement can move from “In Progress” to “Done.”
A project can launch on time.
A new system can go live.
A team can close 400 tickets.
And the organization can still be sitting there six months later asking:
“Why aren’t people using this?”
That is why techniques such as minimum viable progress, prioritization, iterative delivery, demonstrations, feedback loops, and early validation matter.
They help teams stop treating “done” as the finish line.
Instead, we ask:
What did we learn?
Did the outcome improve?
Did people actually use it?
What changed?
What didn’t?
What should we do next?
That’s benefits realization.
And it doesn’t happen automatically because the project plan says “implementation complete.”
Training is The Beginning, Not the Deliverable
I love training (obviously…)!
There is enormous value in bringing people together, introducing new approaches, practicing techniques, challenging assumptions, and giving teams common language.
But I also think we need to be realistic about what training alone can accomplish.
A workshop can create understanding.
It can create energy.
It can give people tools.
It can even create that wonderful moment where someone says, “Oh! That’s why this hasn’t been working.”
But then Monday arrives.
The inbox fills up.
The project is behind.
A stakeholder doesn’t attend the meeting.
The requirement they’re working on looks nothing like the clean example from class.
And suddenly the new technique has to compete with years of existing habits.
That’s the moment where learning either becomes capability—or slowly disappears.
This is why some of the most powerful work I do happens after the formal training.
I call them Collaboration Labs.
Instead of introducing another new concept, we bring the learning into the work people are already doing.
Bring me your requirement.
Bring me the process nobody agrees on.
Bring me that monster user story.
Bring me the stakeholder situation you’re struggling with.
Bring me the backlog you can’t prioritize.
Bring me the project where everyone keeps saying, “That’s not what I thought we meant.”
Bring the messy stuff. Especially the messy stuff.
Because that’s the work. And that’s where we find out whether the technique survived contact with reality.
Now let’s work on it together.
Suddenly, the conversation changes from:
“Do you remember the technique Jamie taught?”
to:
“How do we apply this here?”
That is where behavior starts changing.
The Missing Middle Between Training and Results
Organizations often measure development activities at two ends.At one end:
Did people attend the training?
At the other:
Did business performance improve?
That’s the missing middle. And organizations skip over it all the time.
We go from “We trained them.” straight to “Why aren’t we seeing different results?”
Because knowing isn’t doing.
People have to try something.
They have to discover where it doesn’t quite fit.
They need feedback.
They need to adjust.
They need to try it again.
That’s how training turns into behavior. And behavior is what eventually changes outcomes.
Leaders need to reinforce it.
Peers need to see others using it.
Processes and tools need to support it.
Eventually, the new approach stops feeling like “something we learned in training” and starts becoming:
“This is how we work.”
That middle is where coaching, advisory support, working sessions, observation, and Collaboration Labs become incredibly valuable.
Not because people need someone permanently standing over their shoulder.
Quite the opposite.
The goal is to help an organization build enough internal capability that it no longer needs the outside expert to make every decision.
That’s success.
From Delivering Training to Building Capability
This also changes the conversation leaders should have when they’re investing in professional development.
Instead of asking only:
“How many people can we train?”
Ask:
“What do we want people doing differently afterward?”
That question changes everything.
If you’re investing in requirements training, perhaps the outcome isn’t:
“Twenty-five people completed requirements training.”
Maybe it’s:
“We identify unclear needs earlier and reduce rework caused by misunderstood requirements.”
If you’re investing in Agile training, perhaps success isn’t:
“Teams understand Agile terminology.”
Maybe it’s:
“Teams break work into smaller pieces, validate earlier, and respond to feedback before we’ve invested months in the wrong direction.”
If you’re investing in AI training, perhaps success isn’t:
“Employees know how to write prompts.”
Maybe it’s:
“Employees recognize where AI can create value, use it responsibly, and make better decisions about where human judgment still matters.”
Those are very different measures of success.
One measures delivery of training.
The other measures realization of value.
What Leaders Can Do Differently
If you’re leading a team, department, transformation, or technology investment, try this with one initiative currently underway.
Pull up the requirement, project charter, process map, backlog, business case, or whatever artifact tells everyone what you’re supposedly doing.
Then ask five questions:
1. What outcome are we actually trying to create?
Not what are we building. What should be different because we built it?
2. What are we assuming?
What does everyone think is true that we haven’t actually validated?
3. What decision hasn’t really been made yet?
Look for vague language, placeholders, exceptions, disagreements, and anything everyone quietly hopes someone else will figure out.
4. Who needs to be part of that decision?
Not who needs another status update. Who has the knowledge, authority, experience, or perspective needed to move the decision forward?
5. What’s the smallest next step that would give us useful feedback?
Before investing more time, money, and energy, what could we learn?
Those questions won’t magically solve every project problem.
But they will create better conversations.
And better conversations create better decisions.
We’re entering an era where organizations can execute faster than ever.
AI can generate documentation.
Automation can accelerate workflows.
Platforms can connect data.
Development tools can build solutions at remarkable speed.
That’s exciting.
It’s also exactly why our ability to slow down for the right questions becomes more valuable—not less.
The competitive advantage isn’t going to belong only to organizations with the best technology.
Technology becomes available to everyone eventually.
The advantage belongs to organizations that can look at a problem, bring the right people together, expose the assumptions, make a thoughtful decision, learn quickly, and adjust.
That’s not a tool.
That’s a capability.
And capabilities aren’t created by attending one great workshop.
They’re built when people learn something, apply it to real work, get feedback, practice it again, and eventually teach others to do the same.
So the next time someone proudly tells you:
“We’ve got the requirement documented.”
Don’t stop there.
Ask:
“Great. What decision did it help us make?”
Because the goal was never the document.
The goal was never even the training.
And it definitely wasn’t another box we could check and say, “Yep, everybody attended.”
The goal is what people can do differently because of it—and the value the organization realizes as a result.
That’s the work I’m interested in.
View our article sharing and reuse policy here