Solution Prioritization

IN THIS LESSON

Once you have defined a few credible solutions, choose one.

Keep this section simple. Product Simply uses Impact and Feasibility as the default comparison because inventing a bespoke prioritization scheme usually proves very little. The useful signal is whether you can judge the upside of each solution, recognize what may prevent that upside from being realized, and make a clear choice.

A useful mental model is:

Impact, discounted by Feasibility.

Impact is the upside. Feasibility is the handicap on realizing it.

What this task proves about you

Product managers routinely choose among several plausible ideas. The interviewer is looking for whether you can identify the important differences, make a tradeoff, and decide rather than preserve every option indefinitely.

The prioritization framework itself is low-signal. Spending several minutes inventing criteria, assigning weights, or narrating a matrix consumes time without necessarily showing better product judgment. Impact and Feasibility give you a stable basis for comparison so you can spend your attention on the products themselves.

Impact: how much value could this create?

Impact asks how much the solution could improve the selected customer’s problem if it works well.

You already did the hard work of choosing a customer and pain. Use that context rather than creating a new model of value at the end of the case.

Suppose the selected customer is a learner preparing for a fixed deadline, and the pain is not knowing how to turn the remaining workload and time into a realistic daily plan. You have three solutions:

• an adaptive planner that converts the remaining workload and deadline into a daily recommendation
• a calendar scheduler that reserves study blocks automatically
• an accountability service that notices slippage and pushes the learner back on track

The adaptive planner has strong Impact because it attacks the planning problem directly. The calendar scheduler can help by protecting time, but it still leaves the learner to decide what belongs in that time. The accountability service can improve follow-through, but it acts more on execution after a plan exists than on the planning problem itself.

You do not need separate criteria for severity, frequency, reach, goal alignment, and every other possible contributor to value. Those considerations can inform your judgment of Impact when they matter. The question remains simple: how much customer value could this solution create against the problem we chose?

Feasibility: what handicaps that Impact?

Feasibility is deliberately broader than cost or engineering effort.

A solution can have enormous theoretical Impact and still be a poor choice if something materially reduces the chance, speed, scale, or quality with which that Impact can be realized. Feasibility is the bucket for those handicaps.

Depending on the case, the important handicap might be cost, engineering effort, technical uncertainty, operational complexity, unavailable data, scarce supply, a dependency on another team or partner, legal constraints, trust or safety risk, adoption risk, or something else entirely.

You do not need to turn each of those into another criterion. Ask:

What materially handicaps our ability to realize this solution’s Impact?

For the study-planner example, the adaptive planner may depend on estimating how long the remaining tasks will take. If those estimates are poor, the recommendation becomes less trustworthy. The accountability service may require a large network of qualified human coaches, creating a substantial supply and cost handicap. Those are different constraints, but they both belong inside Feasibility because they reduce how much of the potential Impact the product can realistically deliver.

Feasibility should stay grounded in what the case gives you. If a dependency is obvious, discuss it. If you are merely guessing that one ordinary software feature takes six months and another takes three, do not invent precision just to fill the bucket.

Compare the products, not the scores

Impact and Feasibility are a way to organize the comparison. The explanation is still the substance.

You can use high, medium, and low as shorthand if that helps you think, but do not spend the section serially announcing ratings. Tell the interviewer why the solutions differ.

For example:

I’d choose the adaptive planner. It has the strongest Impact because it solves the planning problem itself by turning the deadline and remaining workload into a daily decision. Its main Feasibility risk is whether we can estimate task duration accurately enough to make that recommendation useful. The calendar option is probably easier to deliver, but its Impact is lower because it still leaves the planning decision with the learner. The accountability service could create a lot of value, but the human-coach dependency is a much larger handicap.

That is the prioritization. The interviewer can see the upside, the handicaps, and why one solution still wins after both are considered.

Make the tradeoff and choose

A good recommendation makes clear what you are gaining and what handicap you are accepting.

You do not need certainty. If two ideas are close, state what makes the difference and pick one. If an experiment or additional evidence would help resolve uncertainty in real product work, you can say what might change your mind without retreating from your current view.

For example:

I’d start with the planner. The biggest uncertainty is the quality of the task-time estimates, so that is what I would want to validate first. If those estimates are too unreliable, I’d reconsider the calendar approach because it can still create value without depending on that input.

That remains a decision.

If the interviewer introduces a new fact, update the same comparison. If the company already has a large coaching network, the accountability service becomes more feasible. If reliable workload estimates are impossible, the planner becomes less feasible. The same Impact and Feasibility comparison still applies as the evidence changes.

The point

Use Impact and Feasibility because choosing a prioritization framework is not the interesting part of the case. Impact captures the upside. Feasibility captures whatever materially handicaps your ability to realize that upside.

Judge both, explain the decisive tradeoff, and choose.