I was in an interview recently and got asked about a project that had been on the books for several quarters without shipping. The question was straightforward “why do you think this project never got prioritized?”
I answered with the things I usually see. Lack of ownership, not enough capacity to deliver in the timeframe needed, or the most common, competing priorities that were more valuable. The interviewer listened and then asked a follow-up “what if the incremental value of doing this project was actually negative for the company?”
My immediate thought was yes, obviously. Of course that’s a primary reason. But as I sat with the question afterward, I realized something had happened in that conversation. We were talking past each other because we didn’t have a shared definition.
When I heard “project,” I understood it as something that had been approved and committed to. When he was asking why it hadn’t shipped, my interpretation was that he was asking why something that was supposed to be valuable hadn’t delivered that value.
As I reflect, what I think he was describing was what I would call a proposal. That’s not a project that stalled. That’s a proposal that should never have become a project in the first place.
I should have led with my own definition. Something like, “my understanding of a project is something that’s already been greenlit and committed to, is that how you’re framing this?” That’s a more natural way to surface the gap without making it feel like you’re questioning someone’s use of a common word.
That missed moment stuck with me, and it pointed to something I’ve learned to pay attention to in how I work. Definitions matter, and they matter most when a group is about to commit to something.
The gate that prevents the problem
The answer I brought up in that interview, after hearing his reasoning, was the quarterly planning cycle.
A project, in my view, is something that has passed a gate. A cross-functional group has looked at it critically, asked hard questions, and agreed that the incremental value is positive. It’s been stress-tested. Someone has had to defend it. Engineering, product, data, and leadership have all had the opportunity to push back.
A proposal is something being considered for that status. It hasn’t passed the gate yet.
That distinction matters because the gate is where definitions get pressure-tested. When a PM presents a proposal to a cross-functional group, the questions that surface are exactly the ones that expose fuzzy definitions: what problem does this actually solve? At what level are we solving it? What are we not doing because we’re doing this? Is the value real, or does it just sound important?
Those questions are harder to avoid in a room full of people with different perspectives and different stakes. A product leader might frame a proposal one way. An engineering leader sees the cost and complexity. A data person asks whether the right signals exist to measure success. That friction is productive. It’s how hidden assumptions become visible before they become expensive. It results in a better product.
Without that gate, proposals land on roadmaps by default. Nobody had to defend them. Nobody had to articulate the value. Then several quarters later, when someone asks why it never got prioritized, the honest answer is often that it was never really a project. It was a proposal that got treated like one. Or worse, it did get built and ends up costing the company.
How I approach it in practice
The quarterly planning cycle is the formal gate. But definition gaps don’t only show up in planning — they show up in kickoff meetings, in design reviews, in conversations where a group is about to align on something and move forward.
In those moments I ask clarifying questions. Not to slow things down. To make sure we’re all talking about the same thing before effort gets committed.
If my understanding of a project is X and I’m not sure everyone else sees it that way, I’ll say so directly: “My understanding is that we’re focused on solving Y, not Z. Do I have that right, or do you mean something different?” In a group setting, done constructively, that question doesn’t create friction. It creates alignment.
Sometimes the clarification happens in the room. Sometimes I follow up directly with the PM or stakeholders afterward. Either way, the work happens before the team starts building, not after.
I make mistakes. Every leader does. What matters is putting a framework in place to keep from making the same mistake again. For me, that framework is the quarterly planning cycle, cross-functional reviews, and the habit of asking clarifying questions — precisely because I know individual judgment has limits. Many eyes, asking hard questions, in a structured process is what catches the things one person misses. It’s not a guarantee. It’s a discipline that makes the expensive mistakes less likely.
The underlying point
The interview question that started this “why do you think this project never got prioritized” has a clean answer when the right process is in place. If a proposal never made it through the gate, it wasn’t a project yet. If it did make it through, the group agreed on the definition and the value before committing.
That clarity doesn’t happen by accident. It requires asking the questions that feel obvious but truly aren’t.