The Cost of Excellence at the Wrong Scope

Here’s a reframe that transformed my perspective on this problem: the cost of an excellent implementation of the wrong feature is higher than the cost of a mediocre implementation of the right feature.

A mediocre implementation of the right feature can be improved. The direction is correct, the feedback loop is functioning, and the team learns from the experience.

On the other hand, an excellent implementation of the wrong feature creates organizational momentum toward the wrong goal. The code is so well-written, the architecture so sound, that it becomes politically costly to eliminate. People point to the quality of the engineering as evidence that the feature must have been worth building. The TPM who attempts to remove it appears to be undermining a high-performing engineer.

Momentum is a powerful force. Turning it is expensive. Beautiful code in the wrong direction is not merely waste—it’s a gravitational pull away from the right solution. irection is not just waste — it’s a gravitational pull away from the right answer.

The Question to Ask Before They Start Building

The best time to question direction is when the engineer is still excited about the build, not when they’re defensive about the output.

If you wait until there’s a failed feature to revisit whether it was the right feature, you’ve waited too long. By then, the engineer has identity wrapped up in the work. The organization has built plans around the output. The TPM is now the person trying to take something away from someone.

Two weeks into a build — before the engineer has deep ownership — is the moment to ask:

• “Who is this feature actually for, and how will we know if it worked?” — Not “what should this do?” but “what job is this doing?”
• “If this shipped tomorrow and nobody used it, what would that tell us?” — Forces clarity on success metrics before the work begins.
• “Is this still aligned with where the product is going?” — Particularly important for longer-running projects where strategy may have shifted.

These questions are not challenges to competence. They’re the product questions that should accompany any technical work. The framing matters: “help me understand who this is for” invites product thinking. “Why are you building this?” invites defensiveness.

What Most TPMs Get Wrong

The “I didn’t want to interrupt” move.

This is the one I see most often, and I’ve done it myself. A TPM joins a team with an engineer who is six weeks into a complex project. The TPM spends the first month “understanding the codebase” and building rapport. They don’t want to look junior. They don’t want to question a high-performer. They don’t want to have the conversation that might reveal they don’t understand the full picture.

Then, a month later, they finally ask the product question. The engineer pauses and says: “You know what, I’m not entirely sure anymore.”

Two hours of conversation to clarify the actual user need. Six weeks of parallel architecture work that had to be thrown away.

The TPM’s fear of “looking junior” cost more than six weeks of senior engineering time. It cost the trust that comes from catching something early, versus the defensiveness that comes from catching something late.

The TPM’s Actual Job

Here’s what this article is really about: someone needs to own the “are we building the right thing” question. In most organizations, that role is underspecified. Engineers assume PM owns it. PM assumes TPM owns it. TPM assumes it’s been decided somewhere.

The most dangerous organizational state is when everyone assumes the direction question has been answered, and no one has actually answered it.

The TPM’s job is not to have all the answers. It’s to make sure the right questions are being asked — especially by the people least likely to ask them themselves.

The next time you see a brilliant engineer building something with beautiful code, ask yourself: do I know who this is for? Do they? Has anyone asked lately?

If the answer is no, the most valuable thing you can do is ask the question.

Before six months goes by.

Practical Takeaways

1. Check in at two weeks, not at six months. A quick product question early costs two hours. A redirect six months in costs everything.
2. Frame questions as invitations, not challenges. “Help me understand who this is for” works better than “why are you building this?”
3. The “just tell me what to build” engineer is a warning sign. Don’t provide clarity that lets them avoid strategic thinking. Push for engagement, not just execution.
4. Track what “excellent at the wrong scope” looks like in your organization.Name it when you see it. Make it politically safe to kill beautiful code that’s pointed at the wrong problem.
5. You are not responsible for the engineer’s emotional response to being redirected. You are responsible for raising the question. The cost of not raising it is always higher.

One question every TPM should ask a brilliant engineer before they start building: “Who is this actually for, and how will we know if it worked?”