Navigating Ambiguity and Adaptive Planning Questions

Direct answer

Assess the impact by measuring what actually changes downstream, not just describing the change; replan by cutting the lowest-value remaining piece first rather than sliding the whole date by default; give a specific revised estimate, not a vague one; and keep a durable, written record of the decision so the trade-off doesn't have to be relitigated later.

STAR skeleton to fill in

• Situation: the project, and exactly what a stakeholder changed (a metric definition, added or cut scope, or a new constraint).
• Task: what you owned delivering.
• Assess impact: what you measured to know how big the change actually was.
• Replan: what you cut, reordered, or descoped, and why that piece specifically.
• Estimate and documentation: the specific added-work estimate, the revised timeline, and where you recorded the decision so it's not lost.
• Communicate trade-offs: the options you gave the stakeholder, with numbers attached.
• Outcome: what actually shipped, when, and how you validated it was correct.

Worked example instance

Situation: five weeks into an eight-week project building a customer-health-score dashboard, the sponsoring VP changed the definition of "active customer" (a core input) from "logged in within 30 days" to "logged in within 30 days OR made an API call within 30 days," to better reflect API-heavy accounts. Assess impact: I pulled the actual data. Under the old definition, 62,000 of 90,000 customers counted as active on the same day; under the new definition, 74,000 did, a 19% increase (74,000 minus 62,000, divided by 62,000), both counts measured the same way, as a point-in-time snapshot of the same 90,000 customer base. That meant four of the dashboard's seven downstream metrics that use the active-customer denominator needed re-derivation, and two already-built visualizations needed re-validation. Replan: rather than push the whole delivery date, I cut one "nice-to-have" segmentation view that didn't depend on the changed definition, and sequenced the redefinition fix first since everything else depended on it. Estimate and documentation: I estimated three additional engineering days (roughly 0.75 days per affected metric, based on the team's own history with definition changes of similar scope) plus one day of quality-assurance (QA) re-validation, moving the ship date from week eight to week eight plus four working days. I logged the change in the team's existing requirement-change log, a shared record of what changed, who requested it, the impact assessment, and the decision made, including the sponsor's explicit sign-off on cutting the segmentation view. Communicate trade-offs: I gave the VP two options with the numbers above: slip under a week and keep full scope, or hit the original date by cutting the segmentation view. She chose the slip. Outcome: we shipped four working days late, with the corrected definition applied consistently across all seven metrics, validated by hand-checking 20 customer records against both definitions before sign-off. A month later, a different stakeholder asked why an old cached export didn't match the dashboard, and the change log was the exact record that answered it without re-litigating the decision from scratch.

Second example (different discipline): a recruiting operations lead running a hiring-pipeline redesign gets a new mid-project constraint: legal requires a specific data-retention limit on candidate records that wasn't in the original scope. She assesses impact (three of nine pipeline stages store data past the new limit), estimates two extra days of rework, documents the change and legal's sign-off in the project's decision log, and tells the hiring stakeholders about the two-day slip rather than silently absorbing it.

Trade-offs and pitfalls

The mediocre move is skipping the actual measurement of impact ("it affected a few things") and skipping the estimate and revised timeline entirely, jumping straight from "the requirement changed" to "we adjusted and it worked out." That's exactly the vague trade-off reasoning that fails to show real judgment. A subtler pitfall is treating the conversation as the record: without a written log, the same trade-off gets re-argued the next time someone notices the discrepancy.

The checklist question that decides everything else. Before picking among a full demo, a model proof-of-concept, or a paper wireframe, spend the first 30 minutes trying to get the PM to state one specific thing the prototype needs to prove. 'Prove users understand what the feature does without instructions' is a very different answer from 'prove the model can do this reasonably well on real inputs,' and that answer, more than anything else, determines which of the three you build. If the PM genuinely can't name even one thing to prove, that itself is a signal: don't spend model or engineering time on an ask nobody can yet articulate a test for, and start with the cheapest option instead.

Mapping the unknown to the option.
If the biggest unknown is whether users will understand or value the feature (UX risk), and the underlying technical capability is reasonably well understood (built on an existing, well-characterized model or API): build a paper wireframe or a clickable mockup. It's the cheapest possible test of the UX unknown, hours to a couple of days, no model or engineering time spent.
If the biggest unknown is whether the underlying capability can hit acceptable quality, and what users want is already reasonably clear: build a focused model proof-of-concept, an offline evaluation disconnected from any real interface, spending zero time on UI polish.
If both are genuinely live unknowns and there's a hard external commitment on a fixed date (an executive review, a customer demo): build a full end-to-end demo, but scoped narrowly to a single golden-path scenario rather than general-purpose, since an audience reacting to the whole experience at once needs a partial answer to both questions more than a complete answer to only one.

Time and resource considerations. A paper wireframe: hours to 1 to 2 days, no engineering or model infrastructure cost. A focused model proof-of-concept: days of offline, notebook-level work, needs representative sample data or labels, no production infrastructure. A full end-to-end demo: a week or more, needs both a UI slice and a working backend call, meaningfully higher cost, justified mainly when the decision riding on it, a go or no-go on a larger, multi-quarter investment, is big enough to warrant that spend.

Worked example. A product manager (PM) asks for a prototype of a new AI resume-tailoring feature, 'see what people think.' Applying the checklist: asked what the one thing to prove is, the PM says, 'whether users would actually trust AI-edited resume text enough to use it.' That's a UX and trust question, not a capability question, and it's reasonable to assume an off-the-shelf model's underlying text-editing capability is adequate for this purpose. Decision: build a paper wireframe or clickable mockup showing fake but representative before-and-after resume text, no model integration at all, and test it with 5 users within 2 days. Contrast: if the PM had instead said 'whether our model can actually tailor a resume well for a marketing role versus just applying a generic template,' that's a capability question, and the right build is a focused offline proof-of-concept scoring output quality against, say, 20 sample resumes across a few target roles, with no UI involved at all.

A different-discipline version, briefly. The same checklist applies outside AI features: a PM asking for a prototype of a new, non-AI checkout flow starts from the identical first question, what's the one thing to prove, whether it's a UX question about a new step's clarity or a technical question about whether a payment integration can actually support it.

The trap. Defaulting to 'build the full demo, it's the most convincing to show' regardless of what's genuinely unknown wastes engineering and model time proving something, usually UI polish, that nobody actually doubted, while leaving the real risk, whether users trust it or whether the model can do it, untested until much later and at much higher cost.

STAR skeleton to fill in. (STAR: Situation, Task, Action, Result.)
Situation: the analysis requested, the deadline, and specifically what was left undefined (which scope, which comparison, which depth).
Task: what 'done' nominally meant by the deadline, even though the request didn't fully specify it.
Action: the choices you made to prioritize what to cover, and how and when you communicated the resulting trade-offs to whoever was waiting on the analysis.
Result: what was actually delivered, on time or not, and the lesson, stated specifically rather than generically.

Worked example. Situation: given 3 business days to analyze 'why is Q2 sales down' for a board meeting, with no defined scope, no named product line, region, or baseline comparison given. Task: produce something board-ready by day 3. Action, prioritizing: spent day 1 morning getting 30 minutes with the VP of Sales to scope, then pulled top-line numbers across all regions to find where the shortfall concentrated rather than digging evenly everywhere; found that roughly two-thirds of the total shortfall traced to one region, EMEA. Spent day 2 doing a genuine deep dive only on EMEA rather than splitting the remaining time evenly across all regions, a deliberate trade-off. Action, communicating: sent a written update at the end of day 1, stating plainly that the analysis would concentrate on EMEA since it explained roughly two-thirds of the shortfall, that APAC and the Americas would get directional numbers only rather than a full breakdown given the timeline, and asked for explicit confirmation rather than assuming silence meant agreement; got that confirmation back within the hour. Result: delivered a 5-slide EMEA-focused deck with 3 ranked root-cause hypotheses by end of day 3, on time, plus directional figures for the other two regions. The board accepted the framing and requested a follow-up APAC deep dive the next week, which validated that the triage call had been right rather than just convenient. Lesson: sending the scope trade-off in writing before the deadline, not after, is what let the VP redirect early if they'd disagreed; finding out about a scope cut only at delivery is a much worse conversation to have.

A different-discipline version, briefly. A product manager gets an ambiguous 'competitive analysis' request with a 2-day deadline. Rather than an exhaustive market scan, they prioritize the 3 competitors sales actually loses deals to most often, pulled from CRM loss-reason data, and communicate that narrowing choice to the requester before starting, not after handing over the finished deck.

What separates a strong answer from a mediocre one. The mediocre version is 'I focused on what mattered most and delivered on time,' which never says how 'what mattered most' was actually determined or when the stakeholder learned about the resulting trade-off. A strong answer names the actual data-driven triage logic (a real number, like the two-thirds concentration), and shows the trade-off was surfaced to the stakeholder proactively, before the deadline, so they had a chance to redirect if the call was wrong, rather than only discovering the scope was cut when the deliverable landed.

There's a menu of lightweight ways to de-risk an ambiguous ask, and the named ones (a spike or POC, a scoped ticket built on stated assumptions, deferral, a quick prototype) aren't the whole list; techniques like a fake-door test, a Wizard-of-Oz stand-in, a small pilot, or simply looking at data you already have all belong on the same menu. The skill isn't memorizing the menu, it's matching the technique to what kind of ambiguity you actually have, and then keeping whatever you pick from quietly turning into the real build.

Match the technique to the unknown.

• If you don't know whether the question is even still open: check data you already have first, always, before building anything new. Support tickets, existing analytics, a past retrospective; this costs close to nothing and sometimes the question is already answered.
• If the unknown is demand (will anyone want this): a fake-door test, a button, link, or landing page for something that doesn't exist yet, measuring click-through, tells you demand without building the thing.
• If the unknown is the shape of the interaction, not whether people want it: a Wizard-of-Oz stand-in, a human manually doing what the automation would eventually do, tests the experience without building the automation, which is usually the expensive part.
• If the unknown is technical feasibility, can this even be built the way we're imagining: a timeboxed spike or proof of concept.
• If the ambiguity is small and low-stakes: skip the experiment entirely, write a scoped ticket on a stated assumption, get a quick nod from whoever owns the area, and move.
• If you need real usage signal at modest scale before deciding to go further: a small pilot.
• If the cost of being wrong is low and nobody is actually blocked waiting on you: defer, explicitly, rather than spending effort now.

How you know a lightweight prototype is enough, and don't need something bigger. Three signals: the decision is reversible and low blast radius if you're wrong, the disagreement is about one narrow factual question rather than a whole strategic direction, and a small number of examples or users would plausibly settle it either way. If any of those isn't true, for example the decision is expensive to undo, escalate to a bigger test rather than trusting a five-user prototype.

If it succeeds, what you hand to engineering isn't the throwaway code, it's a one-page brief: the assumption that got validated, the specific approach that worked, the known limitations the prototype deliberately skipped (auth, scale, error states), and a link to the throwaway artifact clearly labeled "not production," so engineering rebuilds the thing properly instead of hardening code that was never meant to survive contact with real load.

Keeping it bounded, in three dimensions.

• Time: a hard calendar boundary with a decision meeting already on the calendar, not "we'll know when we're done."
• Cost: a person-hour ceiling stated up front, for example one engineer for three days, 24 person-hours, and an explicit rule that production-grade requirements (auth, scaling, full error handling) are out of scope for this round.
• Scope: a written "won't do" list next to the "will do" list, and a rule that any request to expand scope becomes a separate, newly-approved ticket rather than silently absorbed into the current one.

Worked example. A PM has an ambiguous ask: would users want a saved-search alert feature. Retrospective check first: support tickets mentioning this over the last quarter are frequent but not conclusive enough to build on their own. Fake-door test: a "Get notified" button on the search results page for 2 weeks to 5% of traffic. Threshold set before launch: above 3% click-through, build it; below 1%, shelve it; between 1 and 3%, run one more cheap check. That check is Wizard-of-Oz: manually send a hand-built digest email to the people who clicked and see if they actually open and engage with a manual version before building the automated one.

A different discipline. An SRE has an ambiguous ask: would customers notice if a non-critical endpoint's data freshness degraded. Instead of building automated degradation logic, they Wizard-of-Oz it, manually holding one internal dashboard's data stale for a day and watching whether anyone notices or complains, before writing a single line of the real feature.

The trap: defaulting to the fanciest technique available, a full pilot or a real prototype, when five minutes checking data you already have would have answered the question. The opposite trap is just as real: using a spike to avoid ever writing an assumption down in a ticket and getting a quick answer, when the ambiguity was small enough that asking didn't need an experiment at all.

Direct answer

Use a STAR structure (Situation, Task, Action, Result), but shape it around five things this question specifically names: the original plan, how you discovered the assumption was wrong, how you revised the approach, how you communicated the change, and what you did afterward to prevent a repeat. A strong answer also shows you chose a revision that tried to protect the delivery commitment rather than defaulting to "we pushed the date," and that your communication included not just the fact of the change but its impact on outcomes and on how future decisions would be made.

STAR skeleton to fill in

• Situation: the plan, and specifically which assumption it was quietly built on.
• Task: what you were responsible for delivering, and by when.
• Action, discovery: what surfaced the assumption was false, and how far into execution you were.
• Action, revision: the alternative you chose, including one option you considered and rejected, and whether you managed to protect the original delivery expectation or had to renegotiate it.
• Communication: who you told, what you told them (not just "the plan changed" but the quantified impact), and what it meant for how they, or you, would make similar calls in the future.
• Result and prevention: the outcome, and the specific, durable process change you made, not just a personal resolution to be more careful.

Worked example instance

Situation: I was building a fraud-screening integration into a checkout flow. The plan assumed the vendor's screening call would return within their documented service level agreement (SLA, a contractual performance guarantee) of 500 milliseconds at the 95th percentile (p95, meaning 95% of calls finish at or under that time), which let us call it synchronously before confirming an order. Task: ship a synchronous fraud check inside a 5-week build, without adding noticeable checkout latency. Discovery: two weeks in, a load test against the vendor's sandbox with 10,000 requests showed a real p95 of 4.2 seconds, 8.4 times the documented SLA (4,200ms divided by 500ms), measured on the same basis as the SLA claim: p95 latency under concurrent load. The synchronous assumption was dead. Revision: rather than slip the ship date, I moved the screening call to run asynchronously after the order was placed, holding the order in a short pending-review state, with an auto-approve fallback under a defined risk threshold if the vendor hadn't responded within 3 seconds, matching the checkout's original latency budget. I considered and rejected simply raising our timeout to 5 seconds and keeping it synchronous, because that would have made every checkout feel slow, not just the small share that actually needed review. Communication: within 24 hours I told the product lead, the risk owner, and engineering: the change affected roughly 3% of orders (our historical flag rate) with up to a 3-second delay to their confirmation instead of zero, and I was explicit about the trade-off it created (a small false-approve risk in exchange for keeping the ship date) and what it meant going forward: our next vendor evaluation would need a load-tested p95 number, not just the vendor's advertised SLA, before we could use it to lock an architecture decision. Result and prevention: we shipped on the original date. I added a load-test-before-build gate to our vendor integration checklist so any assumed external latency or throughput number gets independently verified under realistic load before it's allowed to anchor a design decision.

What separates a strong answer from a mediocre one here

A mediocre answer blames the vendor or the documentation instead of examining why the assumption went unverified, describes the revision vaguely ("we adjusted the approach") without a concrete alternative, and treats communication as simply informing people after the fact rather than explaining the quantified impact and what it changes about future decisions. A strong answer picks a revision that tries to preserve the delivery commitment where reasonably possible, is explicit about the option it rejected and why, and turns the incident into a specific, checkable process change.

Second, shorter example (different discipline): a program manager planning an in-person conference assumed a venue's listed capacity of 500 was accurate. A walk-through three weeks before the event revealed fire code actually capped it at 350. Rather than move the date, she added a second overflow room with a livestream, told sponsors the exact new capacity split and what it meant for marketing claims within a day, and afterward added an on-site capacity verification step to the vendor-booking checklist before any date is announced publicly.

Trap to avoid

Don't answer this as a generic "time something went wrong" story. The question is about a load-bearing assumption specifically, so be ready to say plainly why the plan wouldn't have made sense without it, and don't let the discovery and revision sections blur into a single vague "we figured it out."