Closure

IN THIS LESSON

Once you have chosen a solution, close the case by reconnecting the argument you just made.

A Product Sense conclusion should make the final product decision easy to understand in one pass: who you chose to serve, which pain mattered most, what you would build, why that solution won, and how it advances the goal you established at the beginning.

The conclusion is the compressed form of the case you already completed.

What this task proves about you

Product managers often have to turn a long discussion into a clear decision that other people can understand and act on.

A strong conclusion shows that you can synthesize rather than merely stop. The interviewer should be able to hear the final recommendation and understand how the customer, problem, product, and objective fit together without mentally reconstructing the entire case.

Lead with the recommendation

Start with what you decided, then reconnect the reasoning that supports it.

For example:

I’d build the adaptive study planner for learners working toward a fixed deadline. Their biggest problem is turning a finite amount of time and remaining work into a realistic plan for what to do each day. The planner addresses that directly by converting the deadline and workload into a daily recommendation that updates as the learner makes progress. I prefer it to the alternatives because it gives us the strongest Impact against that pain without a Feasibility handicap large enough to outweigh the advantage. That gives us the strongest path to helping these learners use their limited study time more effectively.

The recommendation comes first. The rest of the conclusion tells the interviewer why it follows from the case.

Reconnect the causal chain

A useful Product Sense closure reconnects four things:

1. the target customer
2. the selected pain
3. the chosen solution and decisive reason it won
4. the goal

You do not need to repeat every supporting argument inside each stage. Preserve the causal relationship among them.

The customer matters because the pain belongs to someone specific. The pain matters because the solution exists to change that experience. The prioritization matters because it explains why this solution survived the Impact and Feasibility comparison. The goal matters because it explains why solving the problem is worth doing.

When those links are visible, the answer feels like one argument rather than a set of completed framework sections.

Keep the recap selective

Do not narrate the interview chronologically.

A weak conclusion sounds like:

First I set the goal, then I looked at the market, then I identified three customer groups, then I prioritized one, then I found three pain points...

That reports which sections you completed without explaining the decision.

Instead, carry forward only the reasoning that supports the recommendation:

We focused on deadline-driven learners and identified daily planning as the core pain. I’d build the adaptive planner because it solves that problem most directly, and the main Feasibility uncertainty around task-time estimates is not large enough to outweigh that Impact advantage. That gives us the strongest path to helping these learners use their study time effectively.

The conclusion should be short because the case has already done the analytical work.

Include a material tradeoff when it helps

If the chosen solution carries an important Feasibility handicap or uncertainty, one sentence can make the recommendation more credible.

For example:

The main risk is whether the task-time estimates are good enough to make the recommendation trustworthy, so that is the first assumption I would validate.

Include the tradeoff when it changes how the recommendation should be understood. Do not reopen the entire prioritization discussion.

Leave optional depth for follow-up

Once the product decision is clear, the central Product Sense argument is complete.

The interviewer may continue into metrics, MVP scope, experimentation, technical feasibility, launch planning, or a deeper product walkthrough. Those can be useful follow-up discussions when the prompt or interviewer asks for them, but they are not required ingredients in the conclusion.

If new information during probing changes the best decision, update the recommendation. The conclusion should reflect your best current reasoning rather than preserve an earlier choice for consistency.

The point

A Product Sense conclusion turns the full case back into one clear product decision. Lead with the recommendation, reconnect the customer, pain, solution, decisive tradeoff, and goal, and stop when the interviewer can understand why this is the product you would build.