The Smartest Idea in the Room Is Worthless Without the Right People

After twenty years of building products, across startups, growth-stage companies, and organizations navigating some of the hardest moments a business can face, I keep coming back to the same observation. Most people think the smartest person in the room wins. The smartest idea. The best code. The best design. The fastest index. The hottest technology. They are wrong.

Every product that has ever been built was built for a person. Even products built for machines, platforms, and enterprise systems. They are really built for the people who use them, benefit from them, or have a problem that product was designed to solve. And the teams that never lose sight of that are the ones that build things worth building.

 Here is what that actually looks like across the stages where it matters most.

Discovery: Stop asking what people want and start watching what they do

The most dangerous thing a PM can say in discovery is "our customers told us they want this." People are notoriously bad at articulating what they actually need. They describe solutions, not problems. They tell you what they think you want to hear. They imagine a version of their workflow that does not reflect how they actually work.

What works instead is getting close enough to watch. Real discovery means sitting with a customer while they do the actual job. Not a demo. Not a feedback session. The real thing, with real stakes, in real time.

I once worked on a platform where the sales team was convinced customers wanted a specific reporting feature. The data said otherwise. Customers were barely using the reports we already had. When we finally sat with them and watched them work, we found out they were exporting everything to spreadsheets because the reports did not match how their teams were actually organized. The problem was not the reports. It was that we had built the entire data model around our assumptions about how their organizations worked, not how they actually did.

 We would never have found that in a survey.

Prioritization: The backlog is not a democracy and it is not a wish list

Every PM has felt the pressure of a backlog that is longer than the team can execute and stakeholders who all think their request is the most important one. The temptation is to prioritize based on who is loudest or who has the most organizational authority. The discipline is to prioritize based on who has the most acute problem and whether solving it moves a metric that actually matters to the business.

A framework I use: for every item in the backlog, I want to know three things. How many people have this problem. How much does it affect them when they hit it. And what happens to retention, conversion, or expansion revenue if we solve it. Not estimated. Known, or as close to known as we can get.

A feature request that came in from one enterprise customer gets weighted very differently than a pattern showing up across sixty percent of support tickets. Both matter. They do not matter equally.

The other thing that rarely gets said out loud: sometimes the right answer is to remove something rather than add something. I have seen products get meaningfully better by cutting features that nobody was using and that were creating confusion for the people who were. Deletion is a product decision. It does not get enough respect.

Design and Build: The person you are building for is not in the room

This is where the most expensive mistakes happen. The team gets deep into building, the design reviews happen with people who know the product intimately, and nobody catches that a first-time user would have no idea what to do on the screen in front of them.

The practice that fixes this is getting real users in front of real prototypes before the build is done. Not after. Not at launch. Before.

I am not talking about a formal usability study with a research firm, though those have their place. I am talking about finding five people who match your user profile, showing them what you are building, and watching where they get confused. Five people will find eighty percent of the usability problems. It takes a day. It saves weeks of rework.

The other thing I push teams on during build is language. What do you call the thing? What does the button say? What does the error message tell someone when something goes wrong? These feel like small decisions. They are not. The language a product uses is often the difference between a user who feels capable and a user who feels stupid. Nobody comes back after feeling stupid.

Launch: Shipping is not the finish line

A lot of teams treat launch as the end of the work. The feature is live, the announcement goes out, the Slack channel gets a party emoji. And then two weeks later nobody is looking at adoption data and the next item in the backlog is already in flight.

Launch is the beginning of learning, not the end of building.

The question I want answered after every launch is not "did we ship it." It is "are people using it the way we expected, and if not, why not." Those are different questions. The answer to the second one usually contains the most important information you will collect in the entire product cycle.

I worked on a feature launch where adoption was half of what we projected. The feature was working. Users were finding it. They were trying it once and not coming back. It took us three weeks of digging to figure out that the feature solved the problem we thought we were solving, but it created a new problem downstream in the workflow that we had not anticipated. Users were abandoning it not because it was bad but because completing it made the next step harder.

We fixed the downstream problem. Adoption recovered. But we lost six weeks we did not have to lose because we declared victory at launch.

The through line

 I am not arguing against technology. I am not arguing against moving fast or building ambitiously. I have built AI-powered features, shipped platform redesigns at scale, and led products through moments where the stakes were as high as they get.

 But across all of it, the teams that built the best things were the ones who treated the person on the other end as the most important variable in every decision. Not the technology. Not the roadmap. Not the stakeholder with the loudest voice.

 The person.

 That is a discipline. It does not happen automatically. It has to be built into how the team does discovery, how it prioritizes, how it reviews design, and how it defines success after launch.

Twenty years in, that has not changed. And I do not expect it to.