Session note: designing a product intake process that doesn't get hijacked by sales

The Situation

You need a product intake process. Sales has requests. Support has requests. Customers have requests. You need a way to collect, evaluate, and prioritize all of this input. But when you create an intake process, sales hijacks it.

Sales has the loudest voice. They have the most requests. They have the most urgency. They have the most influence. Your intake process becomes a sales request queue, not a product decision system.

The problem isn't that sales shouldn't have input—they should. The problem is that sales input is drowning out everything else. You need a process that preserves sales influence without letting it capture the system.

What Most Teams Try (and Why It Doesn't Work)

Most teams try to balance input by giving everyone equal weight, but this doesn't solve the real problem.

Giving everyone equal weight

If you give everyone equal weight, sales still wins because they have more requests. Equal weight doesn't balance influence—it just makes the process slower.

Limiting sales input

If you limit sales input, you're cutting off a valuable signal. Sales has important information. You need their input, but you need it in a way that doesn't hijack the process.

Creating separate queues

If you create separate queues for sales vs other input, you're creating two processes. That doesn't solve the problem—it just creates more process.

How I Approach This in Practice

I design intake processes that separate signal from source. Sales input is valuable, but it needs to be evaluated the same way as other input.

Evaluate requests, not sources

Instead of prioritizing by who asked, prioritize by what they're asking for. What problem are they solving? How many customers does it affect? What's the impact? Evaluate the request, not the requester.

Create decision frameworks, not queues

Instead of creating queues for different sources, create frameworks for evaluating requests. Does this align with what you're optimizing for? Does this solve a pattern? Does this fit within constraints? Use the framework to make decisions, not to organize requests.

Preserve influence without capture

Sales should have influence, but they shouldn't capture the process. Give sales a clear way to submit requests, but evaluate those requests the same way as other input. The process preserves their influence without letting them hijack it.

Build trust, not walls

If sales feels like they're being cut out, they'll work around the process. Build trust by showing that their input is valued, but that it's evaluated fairly. Transparency builds trust.

A Real Example

A B2B SaaS company where sales requests were drowning out everything else. They created an intake process, but sales hijacked it. Every request from sales became urgent. Other input got ignored.

Instead of limiting sales input, we created a decision framework. Every request—from sales, support, customers, or anywhere else—was evaluated the same way. What problem does it solve? How many customers does it affect? What's the impact? The framework evaluated requests, not sources.

Sales still had influence—they could submit requests and see how they were evaluated. But they couldn't hijack the process because requests were evaluated by the framework, not by who asked.

The outcome wasn't less sales input—it was better evaluation. Sales requests that solved real problems got prioritized. Sales requests that didn't got deprioritized. The process preserved sales influence without letting it capture the system.

When This Matters

This is the problem when:

• Sales requests are drowning out other input. Sales has the loudest voice, and other input gets ignored.
• Every sales request becomes urgent. Sales urgency is hijacking the process, and you can't distinguish real urgency from perceived urgency.
• You're building what sales asks for, not what creates value. You're satisfying sales requests, but not creating coherent product strategy.

This isn't the problem when:

• Sales input is actually the right signal. If sales requests are consistently aligned with what creates value, that's not hijacking—that's good input.
• You don't have enough input. If you're not getting enough input from any source, that's a different problem. Get input first, then worry about balancing it.
• You're using this to avoid sales input. If you're using process to avoid listening to sales, that's different. Sales input is valuable. You need to listen, just not let it hijack the process.