How do you prioritize features when you have limited engineering capacity?

The complete answer guide: what this question really tests, two example strong answers in different angles, the common weak answer rewritten, and the trap most candidates fall into. This is a ambiguity archetype question — see the broader pattern guide for the structural shape.

What this question is really testing

The interviewer isn't evaluating whether you know a prioritization framework—they assume you've heard of RICE or MoSCoW. They're testing whether you can make hard trade-offs under constraint while maintaining strategic clarity. Specifically, they want to see if you default to political appeasement ("let's ask stakeholders what they want") or if you can articulate a clear point of view rooted in business impact, then defend it when challenged. The binary read: are you a project manager who coordinates requests, or a product leader who shapes direction?

The deeper signal they're extracting is how you handle the tension between short-term delivery pressure and long-term product vision when you can't have both. Weak candidates treat limited capacity as a temporary problem to be solved with better estimation or resource negotiation. Strong candidates recognize it as the permanent state of product development and demonstrate a mental model for navigating it systematically. The interviewer is also watching for whether you acknowledge the human cost—engineering morale, technical debt, stakeholder disappointment—or whether you optimize purely on paper without considering the second-order effects of your prioritization choices.

Two strong answers, two angles

Angle A: Impact-driven with explicit trade-off framework

"I start by mapping requested features against two dimensions: business impact and strategic alignment. At my last company, we had four engineering teams and twelve feature requests for Q3. I scored each on revenue potential and whether it moved us toward our north star of becoming the default tool for mid-market sales teams. Three features had high revenue potential but would make us a Swiss Army knife product, so I killed them despite pressure from our largest customer. Instead, we shipped two features that had 60% of the revenue upside but reinforced our core positioning. Six months later, those features drove a 40% increase in qualified pipeline because they made our differentiation story crystal clear."

Angle B: Capacity-first with stakeholder management

"When I joined my previous company, we had a two-quarter backlog and engineering was demoralized from constant priority whiplash. I implemented a simple forcing function: each quarter, engineering capacity was fixed at what we could deliver with 80% confidence, and I'd only commit to features that fit within that budget. For everything else, I personally called stakeholders to explain what we chose instead and why. In Q1, this meant telling our VP of Sales we wouldn't build his dashboard because retaining existing customers—who were churning due to performance issues—was worth 3x more than his projected new deals. He pushed back hard, but when churn dropped 15% that quarter, he became my biggest advocate for ruthless prioritization."

The common weak answer

"I'd work with stakeholders to understand their needs, use a framework like RICE to score features objectively, and then align with engineering on what we can realistically deliver. I'd also look for quick wins that we could ship fast to show progress while working on bigger initiatives."

This answer fails because it signals you'll be a consensus-seeking coordinator rather than a decision-maker. The phrase "work with stakeholders to understand their needs" suggests you'll treat all input as equally valid rather than filtering it through strategic judgment. "Use a framework to score objectively" reveals a misunderstanding—prioritization is never objective, it's about making defensible bets with incomplete information. The "quick wins" mention is a red flag that you'll optimize for visible activity over meaningful progress. A stronger reframe: "I'd evaluate features against our revenue goals and product strategy, make clear trade-off decisions even when stakeholders disagree, and communicate the business rationale behind what we're not building."

The one trap most candidates fall into

The trap is demonstrating your prioritization process without showing you've actually killed something important. Most candidates describe their framework in detail—how they score features, how they gather input, how they communicate decisions—but they never reveal what they said no to or who they disappointed. This makes interviewers suspicious that you've never actually operated under real constraint, or worse, that you avoid conflict by finding ways to say yes to everything through scope negotiation and timeline extensions.

The counterintuitive truth is that interviewers are more impressed by what you didn't build than what you did. When you say "we decided not to build the executive dashboard our CEO requested because it would delay our mobile launch by six weeks, and mobile was critical for our SMB expansion," you demonstrate three things simultaneously: you can say no to power, you can articulate trade-offs clearly, and you're willing to take heat for strategic decisions. Without a specific example of something you killed—ideally something that was politically difficult to kill—your answer sounds theoretical. The interviewer needs evidence that you've actually been in the arena making hard calls, not just theorizing about how you'd make them. Name the feature you killed, name who wanted it, and name why you were right to kill it.

Common questions

Other ambiguity questions