By Lesia Yanytska 12-01-2021
Good products don’t start badly. At least no one builds something thinking, “Yeah, that’s going to fail spectacularly.”
In the tech industry, we’re all too familiar with projects going sideways—the epic delays. The code rewrites. The user complaints and stakeholders are disappointed by outcomes that just aren’t what they expected.
But often, things go bad much earlier than you think. It starts with requirements.
Requirements sound great — until you look closer.
That’s where a subtle lack of clarity lurks: business needs that don’t line up, information that’s too vague, or just a little too optimistic.
“I know we can do it faster.”
“The user should be able to…”
“We just need to add X feature.”
“He probably doesn’t want the extra info.”
It’s human to assume. All of us jump to conclusions at times.
But sometimes it’s the other stakeholders or subject matter experts. We just don’t call it out.
It’s easy to nod along when a request sounds reasonable. It’s harder to be the one to ask the clarifying questions.
When I started as a BA, I made this mistake early on.
Teams worked fast, skipping over too much. Trusting they were aligned when they really weren’t. Good intentions only go so far.
A Better Approach: Shared Understanding
Before we talk about great requirements, we should agree on the role they play.
They’re not a record of inputs. They are the curated result of a process that builds shared understanding.
The requirements development process is the process of discovery, negotiation, and alignment, where we explore:
- User pain points in enough detail to know what success looks like.
- Stakeholder objectives are in enough detail to know why success matters.
- Technical feasibility is detailed enough to know how to achieve success.
- Product vision is in enough detail to understand the level of effort involved in the context of what’s next and where it’s all heading.
They’re not a carbon copy of someone’s words. Great requirements are a translation of the meaning behind what people say into a clarity that connects teams all the way from discovery to delivery.
Imagine a “report” feature.
One org may use that as a static PDF for analysis. Another builds reports as interactive visualizations. Teams may not know the difference and build it based on assumptions — until it’s too late.
This is why I say this role is more than just gathering or note-taking. It’s about bridging the different perspectives and languages across:
- Users who think in workflows and tasks
- Engineers who think in code and constraints
- Executives who think in goals and outcomes
And of course, each of us has our own assumptions, too.
Where does ambiguity cost you?
Too much ambiguity in requirements causes many of the familiar issues that happen downstream. Missed scope. Expensive rework. Low-quality products.
Features need to be rebuilt or scrapped.
End-user experience suffers — or it’s just not what was expected.
The team misses the mark on key goals.
Engineers get frustrated with unclear or changing requirements.
Stakeholders lose trust in the delivery team.
That’s what happens when requirements aren’t clear enough up front.
It doesn’t take a rocket scientist to figure out that a clearer, specific requirement will help the team build.
What might that clear up for them?
I’ve been in projects where an unclear requirement led to adding weeks of work to a development cycle and thousands of dollars down the road.
That’s because a simple field did not include basic logic like “the following choices are available” and “this option is displayed if these conditions are met.”
Better requirements come from more intentional conversations
Conversations make requirements better. The richest requirements do not come from living in a spreadsheet.
They come from talking to people. Real, live conversations between users, stakeholders, and delivery teams often challenge assumptions and surface the gaps.
Workshops. User interviews. Informal conversations can surface those weird edge cases. Pain points. Key business drivers that don’t fit in a template.
Those are the conversations that lead you from “what do you want” to “what problem are we trying to solve”.
A change in mindset that gets teams further from feature factories and towards solving real business and user problems.
Meaningful innovation lives there.
The Analyst or Product Manager as Translator
An analyst, PM, or PO will be either a translator and often, a mediator of sorts between these groups of people, ideas, and perspectives.
How can you spot them?
By helping identify and surfacing user pain points that people didn’t know how to articulate
By reframing requests into actual, precise, and testable outcomes
By tempering what the business needs vs what the delivery team can deliver
By challenging assumptions without people getting defensive
Translating is more than simple one-to-one word or sentence equivalencies. It’s building real alignment.
It requires active listening, curiosity, and at times, just asking “wait, let me unpack that”.
Which means building trust with the teams you work with as well. Developers need to know your intent is not adding busywork or micromanaging.
Stakeholders need to know you are actively listening to and understanding their needs.
Level of detail
I think there’s some magic around the level of detail. Things too general can’t be built, but neither can things that are too fine-grained.
Don’t be afraid to drill down.
Requirements need context:
Why is this important? Why are we building this? Is it worth it?
What constraints must be considered? E.g., integration must be backward compatible with X vendor’s software.
Requirements need outcomes.
How will we measure success?
Not: “Send alerts when something goes wrong.”
Instead: “When sensor value is above threshold X for more than 30 seconds, send a notification to the appropriate operators using Slack or email. This must happen within 3 minutes.”
Requirements Done Right Inform More Than Scope
Clear requirements do more than outline what needs to be delivered. They help inform the technical architecture, roadmap, and trust among people.
Requirements done right inform much more than the code.
In fact, I’ve seen it change the direction of larger, more complex projects.
One experience comes to mind with a project with multiple vendors and factories spread across multiple regions.
The requirements document was critical. It helped the technical architecture, the development team, QA, and ops understand what was being built, why, and how.
It wasn’t fast-tracked or “subject to change”. The requirements were worked through collaboratively among engineers, QA, DevOps, and even some end users.
As a result, when changes occurred (inevitably), the requirements could adapt without becoming a bottleneck. It scaled across teams. And even delivered the product value much earlier than expected.
Requirements, when done correctly, are a form of leadership.
Final Thoughts
For some reason, many teams started cutting corners on requirements. Jumping from problem to solution before they were ready. Speed was often confused with agility.
I’ve learned the hard way that most of the painful times in my career came when things started falling apart because no one had bothered to slow down and ask the right questions earlier.
Recovering the lost art of writing and translating good requirements is not about slowing down your team. It’s about not being wasteful. It’s about giving your team the information they need to have the confidence to push forward.
Let’s stop treating requirements as busywork. Let’s start treating them for what they can and should be: the first draft of product success.