Ruthless prioritization: what to do when requests compete

Suppose a customer wants separate approval rules before bringing another team into your product. Another can’t tell which key the API setup guide means. Then a checkout failure arrives. All three requests land with the founder, but only one may call for a new feature.

Here’s the hack: make two cuts before scoring anything. First, give a customer-blocking failure an investigation owner instead of forcing it into a feature queue. Then make each product bet earn the next test with source-linked evidence, strategic fit, effort, and an honest list of unknowns.

Ruthless prioritization is not an AI-generated ranking or a promise to ignore customers. It is a decision about what to do now, test first, or decline – with a person willing to explain the trade-off.

The short version

• Separate urgent customer obligations from discretionary product bets.
• Cut requests that have no checked customer job, no source you can inspect, or a simpler answer worth testing.
• Choose one next move, name what waits, and record what evidence would change the call.

First cut: which request needs an owner now?

A checkout failure and a proposed workspace feature can compete for a developer’s time. They still need different decisions. First ask whether the reported failure blocks a critical task, affects data or security, or has a safe workaround. A support owner gathers the permitted reports; an engineer accepts the investigation or names the evidence still needed.

That doesn’t mean the cause or reach is known. Two messages may come from one customer. A large customer may deserve a fast response without proving that every account has the same defect. Keep the customer-facing update tied to what the team has actually checked.

Once someone owns the immediate investigation, compare the remaining product investments on their own terms. Don’t make an unresolved incident win or lose against a feature by feeding both into one tidy number. The work may need different owners, timelines, and acceptance tests.

Second cut: what is the customer actually trying to do?

A product option needs more than a feature name. Put the original request beside the customer’s job, what prevented that job, and any observation that weakens your first explanation. The customer feedback management guide covers the wider collection process. This decision starts once your team has a source it can inspect.

For the workspace request, ask whether a person couldn’t find the current approval owner, or whether the product needs different rules. Those lead to different interventions. For the API setup question, check the product version and whether other customers reached the same confusing step. Repeated comments by one person do not establish broad reach.

Record what your team can verify and what it cannot. A ticket-only sample misses customers who never contacted support. If account value, usage, or interview notes are unavailable or permission-limited, mark them unknown. An AI summary cannot turn a missing source into reliable evidence.

Which product bet survives the evidence check?

Compare the next testable decision, not two imagined finished features. In this illustrative example, neither the customer count nor the engineering effort has been verified:

You might test the guidance first because you can check whether it answers the question without committing to a new workflow. That is a test choice, not proof that writing guidance takes less effort or that the feature lacks value. Ask the people who would do either job to assess the real work.

A confidence label should expose uncertainty, not hide it. “We have the customer’s request but haven’t checked the current approval path” tells the team more than a precise-looking score built on guessed reach. A later interview or product test can change the comparison.

When should you say no to the biggest customer?

Their importance belongs in the discussion, but it cannot make the decision alone. Ask how the request fits the product direction, whether other customers share the job, and what commitment the team would displace. If authorized commercial context is available, a product owner can consider it alongside the customer evidence. Do not turn an account label into measured churn or incremental revenue.

A founder can choose to make a strategic exception. Write down the exception instead of disguising it as a score. Name whose need it serves and what will wait. Record who accepts the trade-off and what evidence would trigger a review.

The same record makes a respectful “not yet” possible when the feature is too specific to one customer’s process.

What will you do, defer, and revisit?

At the end of the discussion, the team should be able to read one line and know what happens next. For this illustrative case: Investigate the checkout failure now. Test the API setup guide before committing to a new approval feature. Revisit the product bet after the customer and engineering checks.

Name an owner for each action. Keep links to the original customer evidence, the contrary case, the unknown inputs, and the reason the guidance test comes first. Add the next review date when the team schedules it – don’t invent one to make the plan look complete.

The record is allowed to end with “not enough evidence to build yet.” That is still a decision. It tells support what to learn, engineering what to estimate, and the founder what could change their mind.

Where could Computer help without choosing the roadmap?

The comparison is easier to revisit when the original customer report and related product work stay connected. An authorized teammate must be able to inspect both.

Test whether Computer, by DevRev, can assemble that context through Computer Memory in your configuration, with sources the reviewer can inspect. Can it distinguish repeated remarks from distinct customers and leave missing account fields unknown? A product owner still accepts the evidence and makes the trade-off.

Ruthless doesn’t mean dismissive. Give each request an owner, a next check, or an honest no – instead of letting every ask become a feature.

Explore Computer for Startups and check the benefits and eligibility for your stage.