“When is it shipping?”

Every product manager has heard it. Every product leader has been forced to answer it.

And they all hate it.

Because the moment that question gets asked, the conversation collapses from business outcomes into delivery timelines.

Here’s why.

Product teams too often respond with what they’re building, when it will ship, and how the process works, instead of showing they understand the business and have a plan to deliver the outcomes that matter.

So the business does what it knows how to do. It asks for dates.

So product teams adapt. They produce roadmaps that answer the question. Timelines. Quarters. Delivery plans dressed up as strategy.

In doing so, they reinforce the very behavior they’re frustrated by. They train stakeholders to keep asking for dates.

In short order, they find themselves in an endless loop.

Fixing this isn’t about getting better at defending timelines. It’s about changing the question, and teaching the organization to ask a better one.

That’s exactly what Janna Bastow does in today’s piece.

She shows how to separate plans from commitments, connect product work to business outcomes, and build a system that holds up under executive scrutiny.

If you’ve ever been stuck answering, “When is it shipping?”, read on.

Shardul's recent piece on the credibility gap in Product Management hit a nerve for a reason. Product leaders are walking into rooms armed with feature slides and sprint velocity, while the rest of the C-suite is asking about revenue, margin, and capital efficiency. Different language. Different scoreboard. He’s right about that.

There’s a structural problem underneath the credibility gap that I want to dig into, because I see it play out almost every week in roadmap clinics with product teams. And it starts with a question that sounds perfectly reasonable.

Every product leader has heard some version of this from a commercial stakeholder. The VP of Sales needs to know when the new pricing tier ships so they can build it into their comp plan. The Head of Partnerships wants to commit a launch date to a channel partner. The CFO wants to know when the thing that’s supposed to move the revenue number is going live.

The question feels urgent and specific. The problem is that it’s the wrong question.

And most roadmap structures are designed to invite it.

A timeline roadmap, by design, puts features on a calendar. Every item has a start date, an end date, maybe a colored bar showing duration. The entire visual language of the thing says: “These features will ship at these times.”

So, of course, commercial stakeholders ask, “When?” The roadmap literally answers that question (or pretends to). And once the conversation is anchored on dates, it stays there. Every review becomes a status update. Every stakeholder interaction becomes a negotiation about whether Q2 really means Q2 or whether it’s slipping to Q3.

The product leader ends up spending more time defending the timeline than discussing whether the work even matters.

I ran a roadmap clinic recently with a company in the medical technology space. Big organization. A hundred people on the commercial side across multiple business units. The product team had adopted a Now-Next-Later roadmap — which organizes work by confidence horizon rather than calendar dates. The Head of Product was feeling good about it.

Then a senior commercial stakeholder leaned forward and asked the question.

The room tensed up. The product team started reaching for feature timelines. “Well, we’re building the new analytics module in Q3, and the compliance workflow is planned for…”

The commercial leader cut them off. “I don’t need to know when you’re building things. I need to know that you understand my number and that there’s a plan to hit it.”

That moment cracked something open for the whole team.

The “when is Feature X launching” question persists because most product organizations have put their commitments in the roadmap. The roadmap becomes the thing that carries the promise to the business: We will build X by Y date and it will do Z for revenue.

This is backwards.

Roadmaps are plans. Plans change. They should change, because you learn things along the way. The whole point of iterative product development is that you adjust as you go based on evidence. Locking commitments into a plan makes the plan brittle and the commitments unreliable. Both sides lose.

The commitment should live somewhere else: In your OKRs.

An OKR says: “We will increase ASP by X% for market Y by the end of 2028.” That’s a business commitment. It has a target, a timeframe, and a measurable outcome. The commercial stakeholder can hold the product team accountable to that. The CFO can build a financial model around it. Sales can plan comp structures against it.

The roadmap, then, shows the plan to get there.

The commercial stakeholder can see, at any point, whether the plan to hit their number looks healthy or whether it needs a course correction.

This separation changes the entire dynamic. The product leader is no longer defending a feature timeline. They’re showing a portfolio of work aimed at a business outcome that the commercial team helped define.

The real unlock (and I’ve watched this land with dozens of product teams at this point) is when stakeholders realize they can read the system in two directions.

Pick any initiative on the roadmap and trace it to the business outcome it supports. “Why are we building this?” has a visible answer. If an initiative doesn’t connect to an OKR, that’s a signal. Maybe it shouldn’t be on the roadmap at all, or maybe there’s a missing objective that needs articulating.

Pick any business target and see every initiative that’s contributing to it, laid out by confidence horizon. “Are we on track to hit our number?” becomes a question you can answer by looking at the board. If all the initiatives supporting a year-end revenue target are sitting in Later, you don’t need a status meeting to know there’s a problem. The signal is right there.

This is the part that made the commercial stakeholder in that clinic click. She didn’t need to know when any single feature was shipping. She needed to see that her business target was understood, prioritized, and progressing. And she needed to see it whenever she wanted, without scheduling a meeting.

“When is Feature X launching?” is a question about output. It asks when a thing will be done. It tells you nothing about whether that thing will actually move a business metric.

The better question is:

➜ “Are we on track to hit our target for market Y?”

That question is about outcomes. It forces the conversation toward impact rather than activity. And it can be answered honestly, because the OKR has measurable key results with status tracking, and the roadmap shows the shape of the plan behind it.

This reframe is especially useful in regulated industries (health-tech, fintech, insurance) where commercial milestones are real and immovable. Annual training events. Regulatory approval windows. Buying seasons where if you miss the window, you wait 12 months. Those deadlines belong on the OKR, attached to a key result with a hard date. The roadmap respects that constraint without turning every line item into a false promise.

I track this in ProdPad, where the OKR-to-roadmap connection is built into the system. But the structural principle works regardless of what tool you use. Commitments go on OKRs, plans go on the roadmap, and every stakeholder can trace the connection between the two.

Shardul’s piece made a strong point about product leaders failing to prove business impact. The “you spent $16 million, I don’t know what you did with it” board meeting. That failure usually comes from the same structural gap.

When commitments are scattered across roadmap items and slide decks and Slack messages, there’s no system for going back and checking what worked. Did that analytics module actually move the ASP needle? Did the compliance workflow contribute to the deals that closed? Nobody knows, because nobody connected the work to the target in a way that could be measured after the fact.

OKRs linked to roadmap initiatives create a retrospective loop. Over time, you build a history: which bets paid off, which didn’t, and what you learned. Product leadership stops being a matter of opinion (“I believe this was valuable”) and starts being observable (“Here’s the data on what moved the number”).

This is what separates a product leader who’s treated as a strategic partner from one who’s treated as a project manager. The retrospective loop is the evidence base for future investment decisions. It’s also, frankly, the thing that makes budget season less awful, because you walk in with receipts.

One more thing worth calling out, because it comes up constantly. Loads of teams think they’ve solved the dates problem by switching to quarterly roadmaps. Q1, Q2, Q3, Q4. It looks modern. It looks flexible. And it’s the friendliest trap in product management.

A quarterly roadmap is still a timeline roadmap. It still puts work into time boxes. And those time boxes become commitments the moment a commercial stakeholder sees them. “You said Q2,” is functionally identical to “you said June.” You’ve just made the false precision slightly blurrier.

Now-Next-Later works differently because the columns represent confidence horizons, not time periods.

This maps honestly to how product development actually works. And it gives commercial stakeholders something more useful than a date: it gives them a reading on certainty.

A commercial leader can look at a Now-Next-Later roadmap and calibrate their own plans based on how much confidence to put behind each initiative. That’s more operationally useful than a fictional Q2 date that everyone knows is going to slip.

If you’re a product leader who’s been on the receiving end of the “when is Feature X” conversation and you want to change it, the structural moves are pretty clear.

Business targets go on OKRs with measurable key results and real deadlines. The roadmap shows the work that contributes to those targets, organized by confidence, not calendar.

Every initiative on the roadmap should link to at least one OKR. Every OKR should have visible initiatives behind it. If a stakeholder can’t see the connection in both directions, the system has a gap.

After each quarter (or cycle, or whatever cadence you run), go back and look at what moved. Which key results progressed? Which initiatives contributed? Which bets didn’t pay off? This is where you build the evidence base that earns executive trust over time.

Actively coach your stakeholders toward the better question. Most commercial leaders, once they see the OKR-to-roadmap view, prefer it. It gives them what they actually need: confidence that their number is being pursued, and early warning when it’s at risk.

The credibility gap Shardul diagnosed is real. Product leaders are being held to a business scoreboard they weren’t trained to read. The fix is not just learning to speak the language of capital allocation, but also building a system where the connection between product work and business outcomes is visible, traceable, and retrospectively provable.

When that system is in place, “when is Feature X launching?” stops being the question. And the conversations that replace it are ones product leaders can actually win.

That’s all for today.

Have a joyful week, and, if you can, make it joyful for someone else too.

cheers,
shardul

Shardul Mehta
I ❤️ product managers.

​Follow me on LinkedIn