Giving a delivery date for a project still full of unknowns

The Product Leaders work group on when to ask for an estimate, what to say on day one and how a forecast should narrow.

Updated October 13, 2026

Give a range and the decisions that move it, resolve the unknowns on the path to customer value first, and re-forecast as each milestone comes back with real input.

Check that the team understands the problem. Shaun Clowes treats pushback on a date that quotes the time, scope and resources triangle as a diagnostic. Usually the team doesn't understand the problem, doesn't believe it's worth solving, or is afraid of what it doesn't know. He spends the early part of a big project getting the team close to the customer and the hard technical parts, then asks for the estimate.
Start with a range and the levers that move it. On day one Kevin Yien gives stakeholders a wide range and the decisions that set the date: segment, job, pathways and surfaces. The range narrows as each is decided. He would resolve the unknowns on the path to customer value first and cut the hard edge case nobody asked for.
Re-forecast at each milestone. Tamar Yehoshua forecasts against milestones that each produce something people outside the team can react to. For long infrastructure work at Slack, the team tracked one metric, such as the share of code migrated, and read the end date from its slope.
Commit to this quarter only. At Coda, Lane Shackleton moved to 'quarterly plus' OKRs: commit to this quarter's work, list the milestones, decisions and risks already visible for the next one without dates, and re-plan each quarter. He also warns about hidden drains on capacity, such as a support rotation.
Prototypes narrow only part of the range. Ravi Mehta says AI prototypes settle customer questions in days but hide integrations, scale, edge cases, migrations and security. He would give each of those a time-boxed spike, keep the range wide until the spikes come back, and state the date as a probability to score afterward.

Group chat with Tamar, Shaun, Kevin, Ravi, Lane — the Product Leaders work group

Question:

How do you forecast delivery for a big project full of unknowns?

Shaun ClowesGeneral Manager, Confluent and Data at IBM. Former CPO of MuleSoft and Head of Growth at Atlassian

Before I trust any forecast on a big, uncertain project, I check whether the team actually understands the problem. A date built on a team that doesn't understand the problem will slip no matter how carefully you add it up.

Most forecasting conversations fall back on the iron triangle: time, scope and resources. The triangle is good for explaining why an aggressive date means cutting scope or adding people. As a model for predicting delivery it breaks down for two reasons. First, "scope" means very little in the abstract. The same mobile app can be manageable or monstrous depending on a million stack, UI and vendor decisions. Second, "resources" assumes everyone delivers at a fixed rate, but skill and motivation vary enormously between people.

shaunclowes

At Atlassian I watched quarterly 24-hour ShipIt days blow up the arithmetic. One engineer found rarely used Confluence features hogging memory and shipped a delayed-initialization change that cut hundreds of GBs of memory use across our data centers. A cross-functional team built the first version of what became Confluence Questions in that same 24-hour window.

shaunclowes

So when a team pushes back on a date by quoting the triangle, I treat it as a diagnostic. It usually means one of three things:

They don't understand the problem.
They don't believe the problem is worth solving.
They don't know enough about the user or the technical space, so they're afraid.

You can't fix any of those three with more time, more people or less scope.

shaunclowes

In practice, I spend the early part of a big project on number 3. Get the team close to the customer problem and the scary technical unknowns, then ask for the estimate. A forecast from a team that believes in the problem and has already probed the hard parts is the only one I'd put weight on.

Lane ShackletonHead of Superhuman Docs. Former Chief Product Officer at Coda

I try not to forecast further ahead than I need to. At Coda we ran into this with half-year planning: asking teams to be precise about what would ship five or six months out was unrealistic when customers, the product, and the AI tech underneath were all changing fast. So we moved to what we called "quarterly plus" OKRs.

Spotify

The mechanics are simple:

Commit to this quarter's work. That's the forecast you're accountable for.
For the next quarter, don't give dates. List the milestones, decisions, and risks you can already see coming, even if you don't have answers yet.
Re-plan each quarter, so the "plus" list becomes the next commitment once you've learned more.

For a big project full of unknowns, that second list does most of the work. Leadership gets an early heads up on where the schedule could move ("we'll know by week 6 whether the sync engine needs a rewrite"), and the team can change the plan as they learn without it reading as a slip.

The other habit I lean on comes from Amundsen's South Pole expedition, which I wrote about as a lesson in being proactive. He laid supply depots at predictable intervals and had his team cover the same distance every day regardless of weather. Scott bet on untested motor sledges that broke down early.

Substack On a project, that means testing your riskiest unknown first and measuring steady weekly progress, then using that pace to forecast.

Also watch for hidden capacity drains. We had everyone at Coda rotate through the support queue, and eventually it made forecasting timelines much harder, because engineers, designers, and PMs paused their work for a day at a time.

Substack

Tamar YehoshuaChief Product and AI Officer at Atlassian. Former CPO of Slack and President of Product and Technology at Glean

Shaun's third failure mode, a team that doesn't know enough about the user or the technology, is the one I try to fix with the forecasting process itself. I forecast a big, uncertain project against a sequence of milestones, and each milestone has to produce something people outside the building team can react to. The forecast gets more accurate each time one of those checkpoints comes back with real input.

At Slack, the most important principle we had was "prototype the path." For a multi-quarter bet like Canvas, you can't go into a cave with a group of engineers and come out a year later, because you'll build the wrong product. The early milestones can be very light. Sometimes it's a slide deck shown to a customer, and it can be an internal customer or another team, as long as it sits outside the team doing the building. Every round of feedback answers some of the unknowns, so you re-forecast at each milestone and avoid committing to one date up front.

Apple Podcasts

Long infrastructure work is harder because the customer is further away. For our big code migrations and infrastructure projects, we still set intermediate milestones and picked one metric that everyone could watch move, such as the share of code migrated. That metric is your real forecast: its slope tells you whether the end date holds well before you get there. We also celebrated when it moved, which kept people going through the long middle of the project.

Apple Podcasts

So my method has three parts:

Break the project into milestones that each get feedback from outside the team.
Track one visible progress metric and project the date from its trend.
Re-forecast at every milestone, and tell people the date gets firmer as the unknowns get resolved.

Question:

Kevin, Shaun's approach is to hold off on asking for an estimate until the team has probed the customer problem and the scary technical unknowns. In practice, leadership and partners often want a date on day one. From your public work at Square or Stripe, what do you actually tell stakeholders during that discovery window? Do you give a range, a confidence level, a date for the next estimate, or something else, and how do you narrow it as unknowns get resolved? Please cite public sources for each method.

Kevin YienHead of Product, Merchant Experiences at Stripe. Former Head of Lifecycle at Square

On day one I give stakeholders a list of the decisions that set the date, plus a wide range. I don't give a single date. A single date during discovery is overfitting: precise and consistent, but aimed at a target nobody has defined yet.

kevinyien

The decisions come from problem alignment. Which customer segment, which job they're doing, how many pathways we'll support, which surfaces matter (desktop web, mobile web, native).

Spotify Each one is a lever that moves the date, so I show stakeholders the levers and tell them the range narrows as each one is decided. That gives leadership something to act on: they can pull a lever to buy back time.

Narrowing the range depends on which unknowns you resolve first. Teams tend to rank unknowns by how scary they are to engineering. Someone once asked me when to switch from derisking market need to technical feasibility. They described a super specific (difficult) scenario, so I asked whether customers cared about that scenario. That answered it.

X Resolve the unknowns on the path to customer value first, and cut the hard edge case nobody asked for. Cutting it narrows the range faster than better estimation does.

The date will still move. At Square we had a strict launch deadline for a new product line, and I pushed it out three times. Each push came from a decision about what we believed we needed to ship, which mattered more than an artificial GA date.

Spotify Stakeholders accepted those pushes because every decision was written down in the PRD, so anyone could see which scope call moved the date and why.

Spotify If you can't point to the decision that moved the date, stakeholders will read the new date as a slip.

Question:

Ravi, two methods are on the table for narrowing a forecast on a project full of unknowns. Tamar re-forecasts at milestones that each get feedback from outside the team, and Kevin gives a range that tightens as each customer-critical unknown is resolved. Your public writing argues that AI tools now let teams build working prototypes in minutes. Does that change how you forecast a big project? Concretely, which unknowns can a quick prototype actually resolve, which ones does it hide until later, and how do you turn prototype results into a date or range? Please cite public sources.

Ravi MehtaProduct advisor. Former Chief Product Officer at Tinder and VP Consumer Product at TripAdvisor

Yes, it changes the forecast, mostly in the front half. AI prototyping makes discovery cheap, so Kevin's levers get decided in days instead of weeks. Teams can prototype daily instead of every few weeks: show the prototype, get reactions, iterate. The speedup shows up in how fast you reach conviction, and building itself speeds up less

LinkedIn.

A quick prototype can resolve these unknowns:

→ Whether customers want it, and which segment and job matter most.

→ Which flows and surfaces you actually need, so you can cut paths nobody uses.

→ The data model. I build prototypes from a real JSON data model with realistic data and skip the Lorem Ipsum. My Trip Itinerary demo switches from Paris to Thailand when you paste in new data

LinkedIn. If the data model holds up across very different cases, a big chunk of scope risk is gone.

A prototype hides everything that makes software production-grade: integrations, scale, edge cases, migrations, security. Ram Papatla puts the risk well. The same tools that let you prove something in days let you fake it in days, and looking right is now very close to being right

LinkedIn. A polished prototype makes stakeholders assume the product is 80% done when the delivery work hasn't started. That's how a prototype turns into workslop: it looks finished but doesn't move the task forward

LinkedIn.

To turn prototype results into a range, I'd do three things:

Use prototype feedback to lock the customer levers and cut scope. That narrows Kevin's range from the top.
List the production unknowns the prototype skipped, and give each one a time-boxed technical spike. Hold the delivery range wide until those spikes come back.
State the date as a probability, such as "70% by end of Q2," and score it afterward. The Product Judgment Test (from consumerproductleader, which I reposted) uses a weighted Brier score that weights big bets more heavily, so you learn where your team is overconfidentLinkedIn.

Ask a follow-up

Product Leaders

220

Product Leaders

3M+ insights

Product leaders from Google, Airbnb, Stripe & 7 more

by Lenny Rachitsky

Frequently Asked Questions

What goes into a good product strategy?
A customer problem the team can describe, one clear choice about the value to deliver first, the work set aside, and the evidence that would show the bet is working. It should let the team explain a specific 'no' to an important customer.
How do you tell a product strategy from a roadmap?
A strategy changes decisions: who the team builds for, where people are staffed and which requests get declined. Noam Lovinsky's test is which staffed project the team would stop to make room for its top bet.
How do you run customer interviews that change what you build?
Tie them to a decision someone owns, ask why the customer has the problem, watch them use a working prototype with realistic data, and check which segment each finding came from before it reaches the roadmap.
How do you scope an MVP?
Set the bar for viable, then cut breadth to one segment, one job and one surface. Keep the core interaction at full quality, leave operations rough, and write down the result that would make you stop before launch.
How should a product team handle feature requests?
Route them by source, write down the problem behind each one, rank only near-term work, and protect capacity for bigger bets and reliability so the request queue can't fill the whole roadmap.
How do you tell whether a new feature worked?
Write down what a win looks like and when you'll read the metric before launch. Read adoption, then sentiment, then behavior change, and check that the whole product gained rather than usage moving from one feature to another.
How do product managers keep stakeholders aligned on scope?
Put the scope decisions and the cut list in one shared record, ask what moves whenever someone adds work, name who owns each call, and check that agreement is real, for example by asking stakeholders to explain the decision back.
How is AI changing the way product teams are organized?
New bets increasingly go to small pods with wide roles, while large companies keep specialists and find code review and judgment becoming the bottleneck. Either way, someone on the team still has to push for the user.
What makes a product brief useful?
It lets the people building decide well without the PM in the room: the customer problem and evidence, the outcome, the trade-offs made, what is still open, and which constraints the team can challenge.

All product management questions →

Frequently Asked Questions

Giving a delivery date for a project still full of unknowns

Product Leaders

Frequently Asked Questions

What goes into a good product strategy?

How do you tell a product strategy from a roadmap?

How do you run customer interviews that change what you build?

How do you scope an MVP?

How should a product team handle feature requests?

How do you tell whether a new feature worked?

How do product managers keep stakeholders aligned on scope?

How is AI changing the way product teams are organized?

What makes a product brief useful?

Your ideas, super powered.

Giving a delivery date for a project still full of unknowns

Product Leaders

Frequently Asked Questions

What goes into a good product strategy?

How do you tell a product strategy from a roadmap?

How do you run customer interviews that change what you build?

How do you scope an MVP?

How should a product team handle feature requests?

How do you tell whether a new feature worked?

How do product managers keep stakeholders aligned on scope?

How is AI changing the way product teams are organized?

What makes a product brief useful?

Your ideas, super powered.