Over the past couple of years, I have had a few product people on my team, received coaching myself, and picked up a lot from conversations with other PMs, founders, and people who think deeply about building products. The contexts are always different. Different industries, team sizes, stages. But two patterns keep coming up with almost eerie consistency.

The best product people are not the ones with the most ideas. They are the ones who are really disciplined about which ideas survive. And the ideas that do survive? They rarely originated from the PM.

Both patterns sound simple. They are not. Both create real tension inside organizations, especially small ones. And getting them wrong does not just slow you down. It creates structural problems that compound as you grow.

Pattern One: The Courage to Kill

Every strong product person I have come across has some version of the same story. There were a hundred ideas on the table. We picked three. The rest had to die.

Steve Jobs put it bluntly at Apple’s 1997 WWDC: “Innovation is saying no to 1,000 things.” What makes the full quote so useful is the part people usually skip. Jobs did not frame focus as saying yes to the right thing. He framed it as saying no to the hundred other good ideas. He followed through on this. When he returned to Apple, he cut the product line from 350 products to 10. Not 350 bad products. Most of them were decent. But decent was not the point.

This is a pattern I keep running into. The discipline is not in generating ideas. Most teams have plenty of those. The discipline is in the killing.

Gary Pisano’s Harvard Business Review article “The Hard Truth About Innovative Cultures” makes a related argument that I think about often. Pisano points out that the behaviors we associate with innovation, like experimentation, psychological safety, and flat structures, only work when paired with their uncomfortable counterparts: rigorous discipline, brutal candor, and individual accountability. A tolerance for failure, he argues, requires an intolerance for incompetence. A willingness to experiment requires the discipline to kill experiments that are not working.

Most teams get the first half right. Few get the second half.

Why Killing Ideas Is So Hard in Small Teams

Here is where it gets personal. In a startup with eight people, an idea does not arrive as an anonymous ticket in a backlog. It arrives attached to a person. Often someone who joined specifically because they were excited about pushing a particular direction. Rejecting the idea can feel like rejecting the person.

I have seen this dynamic play out several times. Someone joins a small team precisely because they want a direct line between their ideas and what gets built. They are not wrong to want that. It is one of the genuine advantages of working at a startup. But the implied contract (“I joined to build my ideas”) collides with the organizational need (“we can only build three things this quarter, and your idea is not one of them”).

I think of this as the Small Team Idea Trap. People who are drawn to small teams because they want influence over the product direction are often the same people who take idea rejection hardest. They did not join a 500 person company where ideas get lost in committees. They joined a 10 person team where they expected to be heard, and “heard” often means “implemented.”

The conflict stays manageable when the team is small. The founder or product lead can maintain personal relationships that cushion the blow of a rejected idea. But as the organization grows from 10 to 30 to 100, the social fabric that made those conversations possible frays. Suddenly you have people who remember the startup days when “we just built stuff” and resent the new process that requires ideas to compete for limited capacity.

How to Kill Ideas Without Killing Motivation

The answer is not to become more ruthless. It is to become more transparent about why ideas die.

The best product leaders I have learned from, either directly through coaching or by reading their work, tend to do three things consistently. First, they make the selection criteria explicit before ideas are on the table. When everyone knows the filter in advance (“this quarter we are only building things that reduce churn by at least 5%”) rejection feels less personal because it is measured against a shared standard, not a manager’s preference.

Second, they separate the person from the idea in the conversation. “This is a strong insight about user behavior, and it does not fit our current constraints” is fundamentally different from “we are not going to do that.” The first acknowledges the contribution. The second dismisses it.

Third, and this is the one most teams skip, they create a visible graveyard. A list of ideas that were good but killed for timing, capacity, or strategic reasons. Not a dusty document nobody reads, but an active reference that gets revisited quarterly. The message this sends is powerful: your idea was not rejected because it was bad. It was rejected because we can only do three things, and these three ranked higher right now.

Robert Sutton captured this well in his HBR piece on the boss’s role in innovation: the job is not just to kill bad ideas, it is to help the team kill most of the good ideas too. The distinction matters. If you are only saying no to bad ideas, you are not filtering hard enough.

An Honest Admission: Selection Criteria Are Still Hard

I want to be transparent about something. Even after internalizing all of this, defining good selection criteria is still genuinely hard for me. As a small B2B team with limited resources, it is difficult to set up proper experiments. The kind of structured A/B testing or rapid validation that bigger teams can run is often out of reach when you have a handful of customers and a small engineering team.

And even when we manage to define an experiment, maintaining the discipline to run it consistently and let the data speak is a real challenge. There is always pressure to ship faster, to just go with the gut feeling, to skip the validation step because the quarter is ending. This is the step where we are right now as a team. Figuring out how to filter ideas rigorously when the classic playbook does not quite fit a resource constrained B2B startup.

I do not have a clean answer for this yet. What helps is being honest about it with the team: we are still figuring out our filtering muscle, and that is okay as long as we keep working on it.

Pattern Two: The Best Ideas Do Not Come from PMs

Here is the second pattern, and it is the one that challenges PM egos: the best product ideas almost never originate with the product manager.

I mean this literally. When I look back at the most impactful features and pivots I have been part of, the spark almost always came from somewhere else. A support engineer noticed a pattern in tickets. A sales rep heard the same objection three times in a week. A customer described a workaround that was more creative than anything we had designed.

The PM’s actual superpower is not ideation. It is synthesis. Taking a signal from sales, a complaint from a customer, a technical insight from engineering, and a data point from analytics, and combining them into a coherent product decision. That is the real work.

Marty Cagan at Silicon Valley Product Group has been making this case for years with his concept of empowered product teams. The core argument is that product discovery is not a solo PM exercise. It is a cross-functional effort where the best solutions emerge from the combined perspective of product, design, and engineering working on problems together. The PM’s job is not to arrive with the answer. It is to ensure the team has the right problem and the right inputs to discover the answer.

Paul Graham makes a complementary point from the founder perspective. His advice on startup ideas is to look for problems, not ideas, and to notice what is missing rather than trying to invent from scratch. The best ideas come from living inside the problem space so deeply that the solution becomes obvious. For PMs, that means living inside customer conversations, support logs, and sales calls. Not sitting in a room brainstorming features.

Building the Synthesis Infrastructure

If the PM’s job is synthesis, then the real leverage is not in being smarter. It is in building systems that make more raw material available for synthesis.

This is where I think most product teams underinvest dramatically. The PM who manually reads every support ticket is working hard but not working smart. The PM who builds a culture where the entire organization feeds structured information into a shared system, that is where the compounding returns show up.

What does this look like in practice? It starts with boring infrastructure work. Encouraging the sales team to log call notes consistently in the CRM. Getting customer success to tag tickets with product areas. Making it easy for engineers to flag technical debt that affects user experience. None of this is glamorous. All of it is essential.

The reason this matters more now than ever is that the synthesis step itself has become dramatically easier. This is where AI tools have changed things for me personally. I use Claude’s product management capabilities to synthesize information across our CRM entries, call transcripts, interview notes, and internal conversations. What used to take me a full day of reading through HubSpot notes and scrolling through interview transcripts can now surface patterns in minutes. A sales rep leaves a quick note about a customer objection. A customer success manager logs a workaround a client is using. An engineer mentions a technical constraint in a standup. Individually, these are just anecdotes. But when you can pull them together and actually synthesize across dozens of these signals, real product insights emerge.

This is a fundamental shift. In the past, a lot of valuable knowledge stayed anecdotal. It lived in someone’s head or in a CRM field that nobody read. Now, with the right tools, even messy, informal knowledge becomes usable input for product decisions. But, and this is the critical point, the tools are only as good as the data going in. If your CRM is a graveyard of empty fields and your support tickets are untagged, no AI can synthesize what is not there.

So the real PM leverage play is not just about adopting AI tools. It is about building the organizational habit of capturing knowledge in the first place. Encouraging everyone in the company to log their observations, keep CRM entries current, and write down what they hear from customers. That is the unsexy groundwork that makes synthesis possible.

I think of it as the Synthesis Funnel: the width of your funnel at the top (how many voices contribute raw input) determines the quality of insights at the bottom. A PM who synthesizes input from five sources will consistently outperform a PM who has brilliant ideas in isolation.

The Organizational Challenge

This pattern creates its own tension, mirroring the first one. If the best ideas come from everywhere, then everyone has a stake in what gets built. And people who contribute inputs expect to see their contributions reflected in outputs.

This is why the two patterns are connected. The more voices you invite into the idea funnel, the more ideas you need to kill. The better your synthesis infrastructure, the more painful the filtering becomes, because the ideas you are killing are better informed, better argued, and backed by real data.

Managing this tension requires explicit communication about the difference between contributing an input and deciding an output. Everyone’s perspective improves the synthesis. Not everyone’s preferred solution makes the cut. This distinction needs to be repeated constantly, because the natural human tendency is to conflate “I contributed to this decision” with “I get to influence the outcome.”

Where These Patterns Meet

The intersection of these two patterns defines what great product work looks like. It is not about having vision, although vision helps. It is not about being the smartest person in the room, although competence is non negotiable.

It is about building an organization that generates more good ideas than it can pursue, and then having the discipline to pursue only the best ones.

This sounds obvious when stated plainly. In practice, it requires two uncomfortable capabilities that most people and organizations resist. First, the humility to admit that your own ideas probably are not the best ones, that synthesis beats solo genius. Second, the courage to disappoint people who contributed good ideas that still do not make the cut.

If you are running a product team right now, here are two concrete things worth trying this week. Run an audit of where your last five shipped features originated. If they all came from the PM or founder, your synthesis funnel is too narrow. And second, look at your idea rejection process. If rejected ideas simply disappear without explanation, you are accumulating organizational resentment that will surface when you least expect it.

The best product people I have come across are not idea machines. They are filter machines with excellent inputs. Building both the filter and the input system is the real work of product management.