Are We Still Building the Same Product?
When prototyping becomes cheap and change becomes constant.
We haven’t changed our release cycle.
We haven’t changed our team size.
But over the past year, the product feels different.
And I’ve started asking myself —
are we still building the same product?
Earlier, prototyping was the hard part
.
Not because we didn’t have ideas. We always had ideas.
But turning those ideas into something tangible required effort — discussions, alignment, trade-offs.
We would sit, debate, come to a middle ground.
Only after enough agreement would something move forward.
A prototype wasn’t just a draft. It was a commitment.
Now that has changed.
With AI, we prototype outside our enterprise app first. Quickly. Sometimes roughly. We review internally, refine thinking, and only then bring it into the core product.
The prototype is no longer the result of agreement.
It’s the thing that creates agreement.
We build to negotiate.
For me personally, this shift has been huge.
UI/UX was always the hardest part.
Logic didn’t scare me. Architecture didn’t scare me.
But UI — the actual experience — always felt high stakes.
You could spend days discussing layout decisions.
You’d hesitate before touching flows that were already working.
Now, UI is no longer something we’re scared of.
Not because AI makes design perfect.
But because it makes exploration cheap.
When iteration costs less, fear reduces.
Earlier, you had to be reasonably sure before you built something.
Now, you can build to see.
And that changes product thinking at a fundamental level.
Our team size hasn’t changed.
Every biweekly cycle, I sit with the CTO and we create a 2–3 week roadmap. That rhythm remains disciplined.
We were already shipping fast.
What has changed is what fits inside that roadmap.
Earlier, prioritization meant sacrifice.
Big initiatives would dominate. Urgent items would push everything else aside.
There were always smaller enhancements we knew should be done:
Slight UI improvements
Better defaults
Reduced friction in certain flows
Guardrails that would prevent future mistakes
But when effort is expensive, nuance gets postponed.
Now, those smaller improvements are getting built.
Not because we suddenly became more strategic.
But because building and refining has become cheaper.
And small changes compound.
The release cycle itself hasn’t changed.
What has changed is what reaches it.
Earlier, some bugs would slip through because:
Implementation took time
Reviews were slower
Testing windows were tighter
Edge cases were easier to miss under pressure
Not because the team lacked skill.
But because compressed timelines compress thinking.
Now, with AI in the workflow, more gets caught earlier.
At review stage.
During testing.
Sometimes even while implementing, because the feedback loop is shorter.
When you can explore variations quickly, inconsistencies become obvious.
When refactoring is less painful, cleanup happens earlier.
We’re not perfect.
But fewer avoidable mistakes survive long enough to stress production.
The release cycle feels calmer.
Not slower.
Calmer.
That’s a different kind of speed.
And this is where the deeper question starts.
If we are continuously replacing small parts of the product —
tiny UI tweaks, minor logic improvements, small feature additions —
are we still building the same thing?
My CTO once mentioned the Ship of Theseus.
If you replace parts of a ship piece by piece over time,
at what point is it no longer the same ship?
That thought hasn’t left me.
Because what we’re doing isn’t dramatic reinvention.
It’s quiet evolution.
No big pivot.
No massive redesign.
Just constant refinement.
Individually, none of these changes redefine the product.
Collectively, over months, the experience changes meaningfully.
The product users signed up for last year is technically the same.
But experientially, it may not be.
And maybe that’s fine.
Or maybe that requires more intention than we realise.
AI didn’t just increase speed.
It reduced friction.
And when friction disappears, direction becomes more important.
Earlier, effort acted as a natural filter.
Now, we can build almost anything we think of.
The constraint is no longer capacity.
The constraint is clarity.
Maybe the role of product management is shifting.
From deciding what we can afford to build
to deciding what we should choose not to build —
even when we easily can.
Because when prototyping becomes cheap
and change becomes constant,
someone still has to decide
what the product is supposed to remain.