I used to tell this story in Product Owner trainings.
Usually somewhere after lunch.
With a bit of drama.
Sometimes with a pause in the wrong place — just to see who noticed what was about to go wrong.
It always worked.
Because everyone in the room had seen versions of it.
They just hadn’t seen it laid out this cleanly.
The Setup
We were building a property management system.
Not for a cozy family hotel with twelve rooms and a cat sleeping on the reception desk.
For large hotels and hotel chains.
Multiple locations.
Multiple roles.
Processes refined over decades — sometimes good, sometimes bad, but always shaped by reality.
The application was meant to replace an old character‑based system.
A move to Windows.
Modern UI.
A clean break with the past.
I joined as architect and lead developer after development had already started.
The business analysis came from two people carrying the title Product Manager.
Both were former hotel employees.
- One had worked in a large hotel — but only briefly, straight after Ausbildung.
- The other had only ever worked in a small hotel.
They knew hotels.
Just not this kind of hotel.
They knew the domain — mostly the parts they had personally touched.
That distinction matters more than most organizations are willing to admit.
The Big Idea
Before a single line of code was written, a feature was born.
It wasn’t requested by customers.
It wasn’t demanded by users.
It didn’t come from any concrete pain point in the domain.
The idea didn’t originate in product discovery.
It arrived already legitimized.
The idea was supposed to convince existing customers to migrate from the old system.
And, at the same time, attract large hotels and chains.
Which is already a strange assumption.
Most existing customers were small hotels.
They don’t migrate from a character‑based system to Windows for the sake of “innovation”.
They migrate when something hurts badly enough.
But the idea sounded clever in a meeting room.
Wouldn’t it be cool if…
This could really differentiate us…
The feature wasn’t huge in concept.
But it was ambitious.
Elegant.
Smart.
And dangerously detached from daily hotel reality.
Analysis Without Gravity
The feature became part of the product vision.
Not because it was validated —
but because it made sense internally.
The product managers focused on what every PMS has: reservations, check‑in, check‑out, billing.
Around that, this new idea quietly grew roots.
On paper.
Screen designs followed.
They looked impressive.
Sophisticated.
Full of intention.
They also made the application harder than it needed to be.
Not because hotels are simple.
They aren’t.
But because this feature introduced:
- additional configuration
- new concepts to understand
- more ways to be wrong
The complexity didn’t explode on the screen.
Much of it lived underneath.
Configuration became a project of its own.
Understanding why the system behaved the way it did required explanation.
Gravity was missing.
No force pulling ideas back toward reality.
No one asking uncomfortable questions like:
- Who actually needs this?
- In which situation?
- What becomes harder if we add it?
- What do users now have to trust that they didn’t before?
The domain wasn’t consulted.
It was assumed.
My Role in This
I wasn’t innocent.
I was impressed.
That feature was one of the things that convinced me to join.
It looked smart.
Forward‑thinking.
Ambitious.
I didn’t know the domain.
Not really.
And instead of questioning the reason to exist of the feature,
I mistook its elegance for legitimacy.
And I focused on making it work.
I optimized structure.
I worried about performance and maintainability.
I tried to keep the implementation sane.
What I didn’t do was ask the most basic question:
Why does this need to exist at all?
Once something is labeled “the differentiating feature”,
challenging it starts to feel like obstruction.
So I didn’t.
Reality Enters the Room
Then the software went live.
We brought in pilot customers.
They didn’t praise the innovation.
They didn’t ask for refinements.
They didn’t debate edge cases.
They asked a simple question:
“Can we switch this off?”
That moment was my shock.
Not because they didn’t like the feature.
But because we didn’t even have a switch.
It had never occurred to us that someone might not want it.
They didn’t ask because it was buggy.
Or slow.
They asked because they didn’t need it.
It added configuration effort.
It added cognitive load.
And — most importantly — it required trust.
And trust is expensive in hotels.
In many places, room assignment is still done by hand during night audit.
Not because software can’t do it.
But because the person on duty has the whole night — and doesn’t fully trust what the system decides.
We had built a feature that assumed trust.
Into an environment optimized for caution.
The Quiet Cost
The feature wasn’t a catastrophe.
No company collapsed.
No dramatic post‑mortem followed.
Which is exactly why these stories repeat.
The cost was subtle:
- more configuration
- slower onboarding
- longer explanations
- support tickets that start with “Why does it work like this?”
Death by a thousand cuts.
Later, the product itself disappeared — slowly, quietly, for reasons unrelated to this one feature.
But the lesson didn’t disappear with it.
Why I Still Tell This Story
I tell it because it exposes a pattern.
When:
- ideas come from hierarchy,
- analysis happens without lived context,
- and delivery optimizes for correctness instead of usefulness,
then complexity is not an accident.
It’s a predictable outcome.
This wasn’t a failure of agile.
It wasn’t a failure of process.
It wasn’t even a failure of skill.
It was a failure of contact with reality.
The Uncomfortable Bit
The feature didn’t survive.
The organization did.
And that’s the dangerous part.
Nothing broke loudly enough to force learning.
No one had to stop and ask what went wrong.
The system absorbed the cost and moved on.
Which is exactly how these ideas survive.
They don’t come back as mistakes.
They come back as refinements.
Better phrased.
Better justified.
With better slides.