Nobody Can Estimate a Theme. Stop Asking a Strategy for a Ship Date.
A new direction tells a team what to build, not when it'll ship. A date pinned to a theme is a cheap yes. Here's what to ask for instead.

When a team finally has a direction it believes in, the very next question from the CEO is almost always the same: great, when will it ship?
It's a fair question, and the honest answer is that nobody knows yet. A good direction tells a team who it's building for, which problems matter most and which ideas are worth exploring first. That's enough to start writing epics and user stories. It isn't enough to estimate, because nobody can estimate a theme. Estimates come later, once the themes have been broken down into stories that engineers can actually look at, and in my experience that's roughly another three or four weeks of work.
I'd rather say that limit out loud at the start than pretend otherwise, because a date pinned to a theme is one of the most expensive promises a product team can make.
Why a theme can't be estimated
A theme is something like "help new users get value in their first week" or "make reporting usable for finance teams." It's the right altitude for deciding where to invest. But nobody yet knows which of the dozen possible solutions you'll pick, what the existing system will make easy or hard, or what you'll learn from the first customers who try it. An estimate on a theme is a guess about all of those things at once, presented as a number.
The research on planning says those guesses run optimistic, and in a predictable direction. Daniel Kahneman and Dan Lovallo described the pattern as the "inside view": we build a forecast from the details of our own plan and ignore how similar projects have actually turned out. McKinsey's summary of the research notes that comparing against a reference class of similar projects "can reduce estimation errors by 70 percent." Most product teams don't have a reference class for a brand-new theme. They have a plan and some optimism.
That changes once a theme has been broken into stories. Engineers can look at specific, small pieces of work, compare them to things they've built before and give ranges they actually believe. The estimate isn't any less of a guess in principle, but it's a guess about something concrete enough to be wrong in small, recoverable ways instead of big ones.
A date on a theme is a cheap yes
Giving the CEO a date feels like progress. It ends an uncomfortable meeting, it lets everyone put something on a slide and it costs nothing to say. That's what makes it a cheap yes, and a cheap yes leads to an expensive no.
The no comes a few months later, when the date slips and the team spends its time explaining the slip instead of doing the work. And dates set early have a way of hardening. In ProductPlan's 2026 State of Product Management report, product leaders said more than 60% of their prioritization frameworks get overridden by leadership escalations. A date that was a guess becomes the thing those escalations defend, and the team starts protecting the date instead of the outcome.
I've seen the end state of that. When I joined Stride's Career-as-a-Platform team as its director of product management, the 80-person team was five months past its launch date and making only about half of its sprint commitments, every sprint. Engineers were coding before anyone understood what they were building. Part of the fix was simple and unglamorous: requirements had to be defined before work started, and we moved to a now/next/later roadmap with realistic estimates for the work that was actually ready. Within 90 days the team was hitting its sprint commitments consistently. Nobody got better at guessing. We just stopped estimating things that weren't ready to be estimated.
The CEO isn't wrong to ask
It's easy for a product team to treat "when will it ship?" as impatience. Usually it isn't. A founder has a board that wants to know when the new direction will show up in the numbers, a sales team that wants something to tell prospects, hiring plans that depend on what's coming, and a cash runway that doesn't care about the difference between a theme and a story. Those are real needs, and "it's too early to say" doesn't meet any of them.
But a guessed date doesn't actually meet them either. It gives the board a number that's likely to move, gives sales a promise they may have to walk back with a customer, and sets the hiring plan against a timeline nobody really believed. The founder ends up spending credibility on the slip instead of on the strategy.
The good news is that every one of those needs can be met honestly before the work is estimable. A board can be told how much the company is investing in the new direction and when the first evidence will be in. Sales can be told which problems the company is going after, which is often more useful to a prospect than a feature list anyway. And the runway can be planned against a budgeted amount of time, which is exactly what an appetite is.
What to give the CEO instead
When the question comes, "I don't know" sounds like nobody's in charge, and a made-up date is worse. There are better answers available.
The first is an appetite. Basecamp's Shape Up draws the distinction cleanly: "Estimates start with a design and end with a number. Appetites start with a number and end with a design." Instead of asking how long a theme will take, leadership decides how much time it's worth – six weeks, a quarter – and the team shapes a solution that fits. That's a real commitment you can make on day one, because it's a decision about investment, not a prediction about software.
The second is a date for the next decision. You can't promise when the theme ships, but you can promise when the team will know enough to estimate it, and what you'll show at that point. A recent piece on outcome-driven delivery put it well: for the work further out, "do not attach precise scope or dates before the organization has earned that precision." For the next increment, you can be quite precise, and you should be.
The third is the near-term work. While the themes are being broken down, there's usually a piece that's already clear enough to start and estimate honestly. Starting it gives the CEO real progress to look at, which is more reassuring than a date anyway.
You don't need the whole map
One of the maxims I try to live by is that you don't need to know the whole roadmap. You just need to do the next right thing. That isn't an excuse to skip planning. It's an admission that the plan for month six depends on what you learn in month one, and pretending otherwise mostly produces dates nobody believes.
For a founder, the useful version of "when will it ship?" is really three questions: how much is this worth to us, when will we know enough to commit, and what are we doing this week? All three have honest answers on day one. The ship date doesn't, yet, and that's not a planning failure. It's what a new direction looks like before anyone has built the first piece of it.
More from Consulting Operations

Docs Were a Top-5 Reason Customers Cancelled. Three Years Later, a Top-5 Reason They Bought.
At Adaptavist, documentation went from a top-five reason customers cancelled to a top-five reason they bought. No new features required.

51% of Software Operators Say Fewer Than 1 in 4 Customers Use the AI They Built
Half of software operators say fewer than a quarter of customers use the AI they built. Building got cheap. Building the wrong thing didn't.

Perdue Tested Concept, Pack and Price Before Air Fryer Wings Shipped. The Platform Crossed Nine Figures.
Perdue validates platform bets with full rigor and runs trend bets in a single batch. Most software teams use one speed for every bet.
Want help running a sharper practice?
The reading and synthesis behind your client work, handled – a living deliverable kept current, so more of your time goes where your name is actually on the line.
See how this works for advisors