The Paradox of Builders & Users

Originally published on: https://hvpandya.com/builders-and-users

Product teams are wired to keep building. Product managers, designers, and engineers are constantly on the lookout for the next feature to add or the next problem to solve. This constant urge to build often turns out to be more harmful and most often leads to bad products over time.

User mindset / builder mindset

Users are creatures of habit. Imagine an average user of you product who opens your product for a quick use case. In the few minutes they’re going to spend with your product, they most likely didn’t come in expecting the product to have changed a lot. They’d expect things to work the same way they did the last time they used it.

Builders are different. Every time they open their own product, they spot problems. They’re constantly thinking of opportunities to change things – arguably for the better. The optimisation brain is on full revolutions.

Why are these mindsets so drastically different? Anecdotally, the user spends probably 4 minutes on the product while the builder spends 40+ hours on it. One expects to find the product exactly how they used it the last time and the other wants to continuously ‘fix’ the product to keep improving it.

So why is it important to keep heeding to the user mindset?

• Users prefer consistency over novelty
• Changes often lead to frustration, not delight
• Stability breeds loyalty, not necessarily new features

This creates a fundamental tension: builders want to build, users want things to stay the same. How do we resolve this?

The art of doing less

Here’s a radical idea: what if the most valuable skill for a product team isn’t knowing what to build, but knowing when to stop?

Good product teams know when to put down the tools and let the product breathe. They understand that not every problem needs a feature, and not everything that looks like a problem to them is indeed one for the users.

Building isn’t just about coding or designing. It’s about judgment. And judgment comes from experience.

• Junior teams often build to prove themselves
• Seasoned teams build only when absolutely necessary

We see way too many products turn into a hot mess because inexperienced teams continue to add features without understanding the cost to the user experience.

It’s useful to look at a few examples of mammoth software and take a page from their playbook:

• Operating systems – change very little
• WhatsApp – core functionality unchanged for years
• Google Search – same basic interface for decades
• YouTube – minor tweaks, but fundamentally stable

These products don’t constantly reinvent themselves. They make small, careful changes. And for every change they make to the core user experience, they bring the users along by ensuring that their established behaviours and muscle memory built over years continue to work.

The role of leadership

In most organisations, we see proliferation of mini-teams that often ‘invent’ problems in the product, justify them with twisted datapoints to eventually add solutions that don’t work well and add to the product bloat.

Building isn’t a right. It’s a responsibility. The responsibility to change a product should be earned through experience and a proven track record of good judgment.

Leadership should establish the right framework for when building something new or changing something in the product is justified. Leadership must also place guardrails to curate what reaches the end users.

The world of software is full of wasteland products marred by the lack of strong leadership that let themselves go awry and built because they had the resources to do so.

If you’re in a position to decide what gets built, ask these questions:

• Is the change truly necessary?
• Does it significantly improve the user experience?
• Is the benefit worth the cost of change for the users?

Remember, the goal isn’t to build the most features. It’s to build the right features, at the right time, for the right reasons.

The most critical muscle in building good software, is restraint.

– @hvpandya