UX Trying to Build a Ferrari in a Maruti Factory
- pritamnelapudi
- 2 days ago
- 3 min read
Reflections on ambition, feasibility and collaboration in modern product teams
Over the last 10 years, UX has gone through a massive shift.
Around 2014 - 2015, when UX started becoming popular in the software industry, it was still a relatively new function. Designers were often told that UX was “naive” and that we needed to fight for a seat at the table - the table where business, product managers and leadership made decisions.
Back then, when I was doing my Master’s in Communication Design at IIT Kanpur, this idea was repeated a lot by seniors and industry experts. UX needed influence. UX needed power. UX needed to convince others.
When I started my career in 2016, I honestly didn’t understand this mindset.
In my innocence, I used to think:
Why do we even need to convince anyone?
Isn’t it obvious that better UX leads to a better product, happier users and better business outcomes?
I used to quietly assume that people who didn’t see this were simply not thinking clearly.
I was wrong.
Early Reality: UX in Isolation
My first few years were in a service-based setup where the process was largely waterfall.
UX would design first.
Then development would start months later.
By the time development finished, the product looked nothing like what was originally designed. Not because developers were bad - but because there was almost no collaboration. UX finished and moved on. Development picked up later, with different priorities and constraints.
At that time, I thought this was just bad execution.
Later, I realized it was a process problem, not a people problem.
What Extreme Collaboration Taught Me
Things changed drastically when I moved into a highly collaborative product environment.
Here, UX, PMs, game designers, developers, artists and QA worked together from day one. Concepts were discussed early. Constraints were visible early. Everyone had a voice.
More importantly, I wasn’t just designing flows - I was also building UI inside the actual product engine.
That experience changed my mindset completely.
When you implement what you design, you start understanding:
Technical limitations
Performance issues
Data dependencies
Team skill gaps
Time pressure
Business priorities
I stopped thinking in terms of “my design is right” and started thinking in terms of “what is realistically achievable right now?”
That’s when it hit me:
UX doesn’t win by convincing people.
UX wins by understanding reality.
The Ferrari in a Maruti Factory Problem
Over time, I started noticing a pattern across the industry.
UX ideas are easy to create.
Execution is not.
It’s very easy to imagine a Ferrari-level experience.
But if the factory is built to produce Maruti's, the problem is not ambition - the problem is mismatch.
This mismatch usually ignores four critical things:
Current technical architecture
Skill set of the development team
Time and roadmap constraints
Business priorities right now
When these aren’t considered early, constraints surface late.
And when constraints surface late, UX feels blocked.
Development feels questioned.
PMs feel delayed.
Leadership feels friction.
At that point, UX slowly starts being seen as a debate-triggering function instead of a problem-solving one.
Why UX Pushes So Hard (And Why It Backfires)
UX pushes hard in version one because we’ve all learned a painful truth:
Version 2 is mostly a myth.
Products ship under pressure.
Code is written fast.
Shortcuts are taken.
Teams move on.
Later, when “version 2” is discussed, the cost of change becomes too high. The code is hard to touch. The context is lost. The priorities have shifted.
UX knows this. That’s why we push.
But when pushing ignores feasibility, it stops helping.
That’s when Ferrari dreams inside a Maruti factory start hurting everyone.
Enter AI: The Shift Nobody Expected
Now AI tools have entered the picture.
PMs can prototype.
Flows can be generated.
Screens can be created without UX.
This didn’t happen because UX became useless.
It happened because UX workflows became slow and heavy in environments that needed speed.
When UX adds friction without feasibility, it becomes optional.
I’ve seen products built without UX involvement.
The quality is clearly worse.
But teams still move forward - because it’s faster.
That should worry us.
A Quiet Reflection
After working across different environments - service-based, highly collaborative product teams, and large enterprise setups - I’ve reached one conclusion:
UX doesn’t need to fight for a bigger chair at the table.
UX needs to understand the factory it’s designing for.
Good UX is not about pushing the best possible idea.
It’s about proposing the best possible idea that can actually be built, shipped and supported.
When UX respects reality, collaboration improves.
When UX ignores reality, influence disappears.
That’s not a failure of UX as a discipline.
That’s a reminder of what mature UX really looks like.


Comments