As developers, we understand abstraction. We don’t design systems around today’s implementation because we know the future will change.
Yet when writing requirements, we often do the exact opposite.
Take RedBus and Cleartrip.
One is defined by a specific solution: a bus.
The other is defined by a broader outcome: a trip.
Today the difference may seem subtle. But if a new mode of transportation appears tomorrow, whether it’s a flying taxi, hyperloop, or something entirely new, which product is better positioned to adapt?
The one built around bus booking or the one built around travel?
That’s the power of abstraction.
The same principle applies to requirements. The moment we define a problem in terms of a specific solution, we limit the future possibilities of the product.
Instead of asking:
How do we build bus booking?
We should ask:
How do we enable travel?
That shift in thinking is what I call Abstract Requirements: defining the outcome we want to achieve without prematurely locking ourselves into a particular solution.
What is an Abstract Requirement?
An Abstract Requirement describes the outcome that needs to be achieved without prescribing the solution.
It sits one level above a feature and one level below a user need.
For example:
Requirement
Allow customers to book a bus.
This already assumes the solution is a bus.
An abstract version would be:
Allow travellers to reserve transportation between locations.
The first requirement leads to a bus booking system.
The second leads to a transportation platform that can support buses, trains, flights, taxis, hyperloops, or anything that comes next.
The goal of abstraction is not to make requirements vague. The goal is to remove unnecessary assumptions.
A good abstract requirement answers:
What problem are we solving?
rather than:
How are we solving it?
Another Example
Instead of:
Send OTP via SMS.
Think:
Allow users to verify their identity through a secure communication channel.
The first locks you into SMS.
The second allows SMS, email, WhatsApp, authenticator apps, passkeys, or future authentication methods.
A Simple Test
When reviewing a requirement, ask yourself:
If technology changes tomorrow, would this requirement still be valid?
If the answer is yes, the requirement is probably abstract enough.
If the answer is no, you may be describing a solution rather than the actual need.
In essence, Abstract Requirements focus on intent, while features focus on implementation. They give products the same flexibility that abstraction gives software.
From Good Requirements to Great Products
At this point, you might be thinking:
“Don’t we already do this through user stories and requirements?”
Sometimes we do. But more often than we realise, requirements arrive wrapped in customer terminology, current technology, or a specific solution. Teams then spend their energy implementing that solution rather than understanding the underlying need.
The challenge is not writing requirements.
The challenge is distinguishing between a requirement and an implementation disguised as a requirement.
That’s where Abstract Requirements become valuable. They act as a filter, helping teams strip away assumptions and uncover the real outcome they are trying to achieve.
Before looking at how to write them, let’s first learn how to recognise when a requirement is truly abstract and when it’s simply describing a solution.
Spotting a Solution Disguised as a Requirement
One of the biggest challenges in product development is that solutions often arrive wearing the clothes of requirements.
A stakeholder says:
“We need OTP via SMS.”
A customer asks:
“Can you add WhatsApp notifications?”
A business team requests:
“We need a PDF invoice.”
These sound like requirements, but are they really?
More often than not, they are solutions.
The real requirement lies beneath them.
| Solution-Driven Requirement | Possible Abstract Requirement |
|---|---|
| Send OTP via SMS | Verify a user’s identity through a secure channel |
| Add WhatsApp notifications | Notify users through their preferred communication channel |
| Generate a PDF invoice | Provide customers with a readable billing document |
| Allow bus booking | Enable travellers to reserve transportation |
The pattern is simple:
If the requirement already contains the technology, channel, interface, or implementation, it may not be a requirement at all.
A useful question to ask is:
“Why?”
For example:
Requirement: Send OTP via SMS.
Why?
To verify the user’s identity.
That is closer to the actual requirement.
Now ask another question:
“Would this still be valid if SMS disappeared tomorrow?”
If the answer is no, you’re probably looking at a solution.
If the answer is yes, you’re getting closer to an Abstract Requirement.
This doesn’t mean concrete requirements are bad. Eventually, products need concrete features and implementations. The key is ensuring that we’ve first captured the underlying intent before committing to a specific solution.
Because once a solution enters the requirement, it tends to influence everything that follows: design, architecture, roadmaps, and even how people think about the problem.
And sometimes, a single word in a requirement can quietly limit the future of an entire product.
The Abstraction Ladder
One of the challenges with Abstract Requirements is knowing how far to abstract.
Too little abstraction locks you into a solution.
Too much abstraction becomes meaningless.
The answer lies in climbing the abstraction ladder one step at a time.
Consider the following progression:
Book a RedBus
↑
Book a Bus
↑
Reserve Transportation
↑
Enable Travel
↑
Enable Movement
Every step upwards becomes more abstract.
Every step downwards becomes more concrete.
The trick is to stop at the level where the requirement still provides direction while remaining independent of a specific implementation.
For example:
❌ Too Concrete
Allow customers to book a Volvo bus.
❌ Still Too Concrete
Allow customers to book a bus.
✅ Good Level of Abstraction
Allow travellers to reserve transportation between locations.
❌ Too Abstract
Enable movement.
The first two are tied to specific solutions.
The last one is so broad that it provides little guidance.
The middle statement captures the intent without constraining future possibilities.
This same pattern applies everywhere.
Send OTP via SMS
↑
Send OTP
↑
Verify Identity Through a Secure Channel
↑
Establish Trust
The sweet spot is often somewhere in the middle.
Not so specific that technology choices are baked into the requirement.
Not so abstract that teams have no idea what to build.
A useful rule of thumb is:
Abstract until you remove the implementation, then stop before you remove the intent.
That balance is where the most effective Abstract Requirements live.
They are broad enough to survive change, yet concrete enough to guide product decisions.
Conclusion: Think Like an Architect, Before You Start Building
As developers and architects, we instinctively look for abstractions in code. We create interfaces instead of implementations, models instead of concrete classes, and frameworks instead of one-off solutions. We do this because we know requirements change, technology evolves, and the future rarely looks like the present.
But somewhere between understanding the problem and building the solution, we often abandon that principle.
Requirements become filled with customer terminology, current technologies, preferred channels, and specific implementations. What starts as a need gradually turns into a solution, often before any real design thinking has happened.
Abstract Requirements encourage us to pause and ask a simple question:
What outcome are we really trying to achieve?
By focusing on intent rather than implementation, we create products that are more adaptable, more reusable, and better positioned for opportunities we cannot yet anticipate.
This does not mean every requirement should be abstract. Eventually, products need concrete features, user stories, and technical solutions. The goal is not to avoid specificity. The goal is to introduce it at the right time.
Abstract first. Implement later.
Just as good software is built on the right abstractions, great products are built on the right requirements.
Perhaps the next time you encounter a requirement, instead of asking:
“How do we build this?”
Try asking:
“What problem are we really solving?”
The answer may lead to a much bigger opportunity than the original requirement ever imagined.
Abstraction 
Leave a comment