Case study: one product decision, with and without context

A two-person product team is three weeks from launch. A handful of people on the waitlist have asked, more than once, for bulk export. The team isn’t sure whether to build it before they ship.

They ask an assistant the same question twice. Once with nothing behind it, once with three lines of background added first. Nothing here is trimmed or paraphrased — this is the full exchange, both times.

The decision

“Should we build bulk export before we launch?”

Asked with no context

Bulk export is a common request and can meaningfully help retention, especially among your more engaged users. If engineering time is tight, consider scoping it down — a simple CSV export covers most use cases and is far less work than a full API. If you decide to leave it out of the initial launch, let the people who asked know it’s on your radar, and use real usage data after launch to decide how much further to invest. Either path is reasonable depending on how much time you actually have left.

Nothing here is wrong. It also doesn’t resolve anything. The advice covers every direction at once — build it, scope it down, or skip it — because the assistant has no way to know which of those actually fits a team with three weeks and two people.

The context they added

Before asking again, they paste in three lines:

• Goal: Ship the core workflow so the first cohort can actually use the product on day one. Depth comes after there are real users to learn from, not before.
• Constraint: Two people, three weeks, and a launch date already announced to the waitlist. There is no slack to absorb new engineering scope.
• Past decision: Last quarter, a “nice to have” integration got added two weeks before a launch. It pushed the date back ten days, and almost no one used it in the first month.

No names, no revenue figures, no roadmap details beyond what’s above. Three short facts are enough to change what a reasonable answer looks like.

Asked again, with that context

Don’t build it before launch. You’ve already seen what happens when a late addition gets pulled into a launch window — it cost you ten days last time, for a feature that barely got used afterward. Bulk export is a real request, but nothing here suggests it’s blocking anyone from getting value out of the core workflow on day one, which is the goal you’ve set for this launch. Tell the people who asked that it’s noted and you’re watching how much it comes up after launch. That costs you five minutes, not two engineering weeks. Once you have real usage data — not just requests from your most vocal users — you’ll be deciding with evidence instead of guessing, and you’ll have shipped on time either way.

Same assistant, same question, worded identically. The only difference is the three lines that came before it.

What they kept, what they discarded

The first answer wasn’t wrong, which is what makes it easy to miss how little it did. It offered three options — build it, scope it down, defer it — and left the actual decision exactly where it started.

The second answer discarded two of those three options outright, because the context ruled them out. Scoping down to a simple CSV export still means engineering time the team doesn’t have; the past-decision note already showed what “just a smaller version” costs during a launch window. Building the full version was never realistic to begin with.

What it kept, and sharpened, was the third option: defer, and say so. The first answer mentioned this in passing, as one path among several. The second answer built the case for it directly from the team’s own history — pointing at the ten-day delay as the reason not to repeat the pattern, not as a hypothetical risk.

The team still made the call. The assistant didn’t discover that deferring was correct; it reasoned inside boundaries the team had already set. If the constraint had been different — four people, six weeks, no prior incident — the same three lines would have produced a different answer, and that would have been correct too.

The next action

The actionable line out of this exchange is small enough to check: “Tell the waitlist members who asked that bulk export is noted, and revisit after 30 days of usage data.” Not “consider the tradeoffs” — a single next step, with a date attached.

Once that 30-day window closes, the outcome becomes a new line in the team’s own decision log — the same kind of past-decision note that shaped the answer this time. Turning an answer into one next action covers how to make that translation a habit rather than a one-off.

Run the same comparison on your own decision

Copy this card into a note. Ask the question once without the context block, then start a new chat and ask it again with the three lines included. Keep both answers in the note so you can see which options the context ruled out.

# Context comparison — [decision]

## Question
[Ask one decision question in one sentence.]

## Answer without context
[Paste the complete first answer.]

## Context
- Goal: [What are you trying to achieve?]
- Constraint: [What cannot change right now?]
- Past decision: [What was tried or ruled out, and why?]

## Answer with context
[Paste the complete second answer.]

## My decision
- Chosen option:
- Rejected option and reason:
- Next action and review date:

The test is not whether the second answer sounds more confident. Check whether it uses your goal, respects the constraint, and avoids repeating the past decision. You still choose the option.

This is the same mechanism behind context before prompt polishing. For the handoff sequence — what to write down and when to paste it in — read how to give an assistant the relevant slice.

Join the Starter Kit waitlist if you want one notification when the kit is ready.