How do you fix a disconnect between team velocity and value?

WHAT THIS TESTS: This question tests your ability to think beyond engineering execution and connect your work to business outcomes. It separates candidates who see their job as "closing tickets" from those who see it as "delivering value." The interviewer is looking for evidence of product thinking, leadership, and a data-driven mindset. They want to know if you can diagnose a problem collaboratively without jumping to conclusions or placing blame.

A GOOD ANSWER COVERS: A strong answer demonstrates a structured, diagnostic approach. First, investigate and gather data. Propose talking to the Product Owner to understand the specifics of the stakeholder feedback, and suggest looking at product analytics, user session recordings, or support ticket trends. Second, formulate hypotheses and propose experiments. Instead of big, risky changes, suggest small, measurable actions like A/B testing a UI change or running a survey. Third, suggest concrete process improvements. This could include bringing stakeholder metrics into sprint reviews, dedicating a portion of each sprint to "value discovery" spikes, or adding a "value" or "confidence" score to user stories during backlog refinement.

COMMON WRONG ANSWERS: A major red flag is immediately blaming the Product Owner ("The PO needs to write better stories" or "This is a product problem, not an engineering one"). This shows a lack of ownership and a siloed mentality. Another common mistake is focusing on engineering-only solutions, like "we need to increase velocity" or "we should refactor this module." This completely misses the point that high output is already happening but isn't translating to value. Vague answers like "we need to be more customer-centric" without specific actions are also weak.

LIKELY FOLLOW-UPS: Be prepared for follow-ups like: "What if the Product Owner is resistant to sharing this feedback or changing their process?" or "Tell me about a time you successfully influenced a team to change direction based on value metrics, not just effort." or "How would you measure the 'value' of a non-functional requirement, like a 200ms performance improvement?"

ONE CONCRETE EXAMPLE: Imagine our team shipped a new multi-filter search page. Velocity was high, but the PO reports users are "overwhelmed." I would propose we first instrument the page to see which filters are used most, and which are never touched. Next, I'd ask to shadow two or three users for 15 minutes to see where they get stuck. Based on that data, we might hypothesize that an "advanced" toggle hiding less-used filters would improve usability. We could build this small change, ship it to 10% of users, and measure the impact on task completion time or bounce rate before a full rollout. This links our effort directly to a measurable user outcome.