For most of my career, I have worked with requirements.
Sometimes they came as a document. Sometimes as a conversation. Sometimes as a Figma design, a Slack message, or a short sentence like:
"We need a dashboard for this."
As a developer, the natural response is to start thinking about implementation.
What should the API look like?
How should the database be structured?
What components do we need?
Which library should we use?
How long will it take?
Those are all useful questions.
But there is another question that I have started asking much earlier:
"Why do we need this in the first place?"
That question changed the way I approach software development.
A requirement is not the problem
A requirement usually describes a solution.
The problem is somewhere underneath it.
Consider a simple example.
Someone asks:
"We need a dashboard showing campaign performance."
A developer can take that requirement and start building:
- charts
- filters
- tables
- date ranges
- exports
- API endpoints
- database queries
You can build an excellent dashboard and still fail to solve the actual problem.
Maybe the marketing team does not really need another dashboard.
Maybe they are spending hours every week collecting information from different places and putting it into a spreadsheet.
The real problem might be:
"We don't have a reliable way to understand what is happening across our active campaigns."
Now the solution space looks very different.
Maybe a dashboard is part of the answer.
Maybe automated reports are more useful.
Maybe alerts are more valuable than charts.
Maybe the information simply needs to be available in the right workflow at the right time.
The requirement told us what someone thought should be built.
Understanding the problem tells us what actually needs to change.
This is where product thinking starts
I don't think developers need to become product managers to think this way.
For me, it is simply about taking more responsibility for the outcome.
Instead of asking only:
"How do I build this?"
I try to ask:
"What are we trying to achieve?"
"Who is this for?"
"What problem are they experiencing?"
"What happens today without this?"
"What would a successful outcome look like?"
"Do we need all of this right now?"
These questions do not replace engineering.
They make engineering more useful.
The ticket is only the starting point
A ticket is a useful unit of execution.
It is not always a useful unit of thinking.
A ticket might say:
"Add subscription management for dealers."
That sounds straightforward.
But before writing any code, there are several things worth understanding.
Why do dealers need subscriptions?
What are they subscribing to?
Who manages those subscriptions?
What happens when a subscription expires?
What features are affected?
Can a dealer have multiple plans?
What does the internal team need to see?
What information needs to be surfaced to the dealer?
Are subscriptions tied to a tenant, a product, or both?
Some of these questions are technical.
Some are product questions.
Most are both.
If you skip them and go straight to implementation, you can end up with software that technically satisfies the ticket but makes the underlying business workflow harder.
A small example from AutoLEAD
I experienced this while working on AutoLEAD, a multi-tenant automotive platform made up of several connected products.
The system supported different automotive experiences, including AutoSHOWROOM, AutoMALL, AutoFINANCE, and carbuy.ae. Behind those products was a shared platform handling things such as inventory, content, dealer subscriptions, and CRM workflows.
One of the important decisions was not simply how to build each individual product.
It was how to avoid rebuilding the same business capabilities again and again.
If inventory was managed separately in every product, the business would eventually have multiple versions of the same data.
If dealer management was handled independently, operations would become fragmented.
If subscriptions were disconnected from the rest of the platform, it would become harder to understand which products and capabilities each dealer actually had access to.
The better solution was to think about the underlying business capabilities first and then design the platform around them.
That led to a shared operational system that could support multiple products instead of treating every application as an isolated project.
The interesting part was not the code itself.
The important decision happened before the code.
Product thinking changes architecture
This is one of the reasons I think product thinking is especially valuable for engineers.
Architecture is often presented as a purely technical decision.
In reality, architecture is heavily influenced by the product.
What the business is trying to do affects:
- what should be shared
- what should be separate
- where data should live
- how tenants should work
- which workflows need to be flexible
- which parts need to scale
- what should be configurable
- what should be hard-coded
You cannot make good architectural decisions if you don't understand what the product is trying to accomplish.
That doesn't mean every developer needs to understand every part of the business.
It means we should understand enough to avoid designing the system around assumptions that are not actually true.
It also changes how I think about scope
Another thing I have learned is that requirements tend to grow very easily.
A feature starts as:
"We need X."
Then it becomes:
"We also need Y."
"And users should be able to configure Z."
"And maybe add reporting."
"And we should support another workflow."
Before long, the original feature has turned into a small product.
This is where I think engineering judgment becomes important.
Sometimes the best contribution a developer can make is not writing another hundred lines of code.
It is asking:
"Do we really need this part right now?"
There is a difference between being resistant to requirements and helping keep a product focused.
The goal is not to build less for the sake of building less.
The goal is to spend engineering effort where it creates the most value.
The questions I try to ask now
When I receive a new requirement, I try to think through a few things before getting into implementation details.
What problem are we solving?
Who experiences it?
How are they solving it today?
What is the smallest useful change we can make?
What assumptions are we making?
What could make the solution much more complicated than it looks?
What should we deliberately leave out?
And finally:
"How will we know that this actually worked?"
I don't always have the answers immediately.
That is fine.
Sometimes the most useful thing I can do is identify what we don't know yet.
This does not mean stopping development
There is a danger in taking product thinking too far.
You can spend weeks discussing users, problems, workflows, edge cases, and business models without actually building anything.
That is not what I mean.
There is a point where you have enough understanding to make a reasonable decision.
Then you build.
The goal is not perfect certainty before writing code.
The goal is reducing the kind of uncertainty that can make the entire project head in the wrong direction.
From implementation to ownership
I think this is the bigger shift for me.
Earlier in my career, success often meant:
"I implemented the requirement correctly."
Now I increasingly think about success as:
"I understood the problem, helped shape the solution, built it, shipped it, and made sure it actually worked in the real world."
That is a much broader definition of engineering responsibility.
It also makes the work more interesting.
You are not just solving programming problems anymore.
You are solving product problems, business problems, workflow problems, and technical problems together.
Final thoughts
I still care deeply about writing good code.
Architecture still matters.
Performance matters.
Testing matters.
Deployment matters.
But those things are means to an end.
The purpose of all that engineering work is to create something useful.
That is why I have started to think less about individual tickets and more about the products and problems behind them.
A requirement tells me what someone wants.
My job as an engineer is to understand why they want it, help figure out what should actually be built, and then build it well.