I spend a fair amount of time in backlog refinement sessions with developers, designers and product owners. Most of them are productive. Occasionally they become debates about things that feel strangely familiar.
Recently it was about search.
Historically, we'd always taken users to a dedicated results page. It was a pattern we'd used elsewhere, it kept the implementation straightforward, and everyone understood how it behaved. This time, the designers wanted the results to appear beneath the search box instead. From a user's perspective it reduced friction. From a developer's perspective it meant rethinking how search worked, introducing additional complexity and moving away from an established pattern.
Nobody was wrong.
The longer I've worked in software, the more I've noticed that these conversations rarely end up being about the thing they're supposedly discussing. They're usually about two groups of people optimising for different outcomes.
Developers tend to think about consistency, maintenance and complexity. Designers naturally think about clarity, flow and reducing friction. Product owners are usually trying to balance both while keeping one eye on deadlines and priorities.
Those are all reasonable positions.
The interesting part is how quickly a preference can start to sound like a principle. Before long, you're no longer discussing one search screen. You're debating the "right" way to build search, as though there has always been a correct answer waiting to be discovered.
It reminds me of the endless arguments about whether the milk goes in before the cereal. Everyone has a preference. Most people can justify it. Almost nobody changes their mind.
Software development is full of these conversations.
Tabs or spaces. Monoliths or microservices. Whether something should be a quick proof of concept or engineered "properly" from day one. We often spend a surprising amount of energy trying to establish the correct approach, when what we're really discussing are trade-offs.
There are good reasons for consistency. It's one of the principles behind Nielsen Norman Group's usability heuristics, and it makes products easier to understand and maintain. Equally, reducing friction for users is a perfectly valid reason to challenge an existing pattern if it genuinely improves the experience.
The difficult part is recognising when we're debating solutions before we've agreed on the problem.
It's not entirely different to what happens when MVPs become exercises in polish rather than learning. We convince ourselves we're making progress because we're refining an approach, when we haven't yet established whether the outcome justifies the effort.
I've noticed that the healthiest product discussions aren't the ones where everyone agrees. They're the ones where people recognise what they're each optimising for, and accept that different priorities can all be valid at the same time.
Sometimes the dedicated search page is the right decision.
Sometimes showing the results immediately is.
The important part is understanding why you're choosing one over the other, not winning the argument about which approach is universally better.
Most software decisions aren't about finding the right answer.
They're about recognising when two reasonable people are optimising for different things.
The milk can go in whenever you like. Just make sure you're all eating the same breakfast.