Concrete Solution Definition

IN THIS LESSON

A solution can be credible and still be too abstract to evaluate. “Adaptive study plan,” “expert marketplace,” or “AI assistant” gives the interviewer a direction, but not necessarily a product they can picture. Once you have a small set of credible alternatives, make each one concrete enough that the interviewer can understand the customer experience and the mechanism by which it improves the pain you selected.

The useful level of detail is enough to make the essential product behavior visible while preserving time for comparison and decision-making. The interviewer should understand what the customer encounters, what they do, what the product does in response, and why that interaction changes the experience for the better without needing a design for every screen or a complete feature inventory.

What this task proves about you

A product manager has to be able to take an opportunity, form a coherent view of what the customer experience should become, and communicate its essence so the people who would make it real can share the vision. This part of the interview shows whether you can move from an abstract product direction to something concrete enough for other people to reason about and even become excited about: what you would actually ask a team to create, how a customer would experience it, why those choices fit the pain you already established, and how you would inspire people to make it a reality.

Doing this well demonstrates product judgment, storytelling, and creativity because you are deciding which parts of the experience are essential, which details are merely implementation choices, and how much explanation is actually required for other people to understand why the idea is a strong one. A strong definition makes the product legible without mistaking additional detail for additional insight.

Make the experience visible

Before you describe a solution, picture it as though it already exists and imagine the customer encountering it to address the problem you identified. Suppose one of your solutions for a goal-based learner is an adaptive study plan. The label gives the interviewer only a broad category. A more concrete definition might sound like:

I’d build a study planner around the learner’s actual deadline. I want that deadline to feel really present, so the first thing you see is a big countdown at the top—something like “14 days to go”—with a short motivating message. Right below that, I’d show all of the work that is left, broken into specific study tasks with an estimate of how much time each one will take. You’d be able to see that full workload and a rollup of how much time is left, and then the product would give you a very clear recommendation, like, “You need to study 30 minutes a day to finish by your deadline.” As you complete work or lose a day, that recommendation would update.

Now the interviewer can actually see the product: a deadline at the top, the remaining work underneath it, and a clear daily recommendation derived from the relationship between the two. Those details communicate much more than the abstract statement that the product takes a deadline, a schedule, and a list of tasks as inputs. They show what the experience is and which information the product makes most important to the customer.

The amount of detail required to create that impression is surprisingly small because people are good at filling in ordinary product details themselves. You do not need to describe every button, field, state, or screen. A few well-chosen details can create the barest wireframe in words: the countdown is at the top, the remaining work sits underneath it, and the recommendation tells the learner what today requires. Once those objects exist in both of your heads, you have a shared vocabulary for the solution. You can talk about “the countdown,” “the workload,” or “the daily recommendation” later in the case and both understand exactly which part of the product you mean.

That shared mental model is the objective. A marketplace, a recommendation system, a communication tool, and a planning product will naturally require different details, so there is no need to force them through one descriptive template. For a visual product, the right few details may establish the hierarchy of a screen or the important objects and actions on it. For a less visual service, they may establish what arrives, happens, changes, or becomes possible for the customer. In either case, describe just enough that another person can imagine the same product without having to invent the important choices themselves.

Lead with that experience rather than the technology underneath it. If the adaptive planner uses an LLM, a recommendation model, or another technical capability, that may help explain why the idea is feasible or strategically attractive. The customer-facing product is still the planner and the experience around it; technology supports the definition when it matters, but it should not substitute for one.

Explain the mechanism of action

Making a product easy to picture is only useful if the choices you describe have a reason to exist. The concrete details should reveal how the experience improves the pain rather than merely make the product sound polished.

For the learner whose problem is using limited study time effectively, the planner makes the deadline persistently visible rather than allowing it to remain an abstract future constraint. Breaking the remaining work into tasks and time estimates exposes how much work is actually left. Rolling that workload up against the remaining time lets the product translate a vague sense of being busy into a concrete daily requirement. Updating the recommendation as the learner completes work or falls behind keeps that guidance useful when reality diverges from the original plan.

Those details create a causal argument. The product helps because the experience makes the learner’s constraint legible and turns it into an actionable plan, not because a countdown, task list, and recommendation happen to appear on a screen. This is Why-Anchoring applied inside the definition: describe the behavior or capability that matters, provide the explanation needed to understand it, and close the loop on why it improves the selected pain. Once that relationship is clear, the unit is complete and you can move to the next important part of the product or the next alternative.

The same test applies to familiar product patterns. If you propose a marketplace, explain what it makes newly available or easier for this customer and make the exchange concrete enough to picture. If you propose recommendations, show what the customer would actually receive and explain what information makes that recommendation better than the choice they can make today. If you propose an assistant, explain what work the assistant takes on, how that help appears in the customer’s experience, and why transferring that work changes the outcome. The category tells the interviewer what family of product you have in mind; the definition and mechanism explain what this particular product actually is and why it belongs in your case.

When you have several alternatives, define them one at a time rather than bouncing among their features. Give the interviewer enough of one product to see it and understand why it works, land the why, and then move to the next alternative. The later prioritization can then compare actual products rather than labels.

Keep the definition proportional

Once you can see the experience clearly, choose the few interactions and capabilities that make the idea understandable and establish how it creates value. Peripheral settings, account management, edge cases, secondary screens, and ordinary platform behavior usually do not improve the decision, so describing them consumes time while giving the important parts of the product less attention.

For the adaptive study planner, the prominent deadline, remaining tasks, time estimates, workload rollup, daily recommendation, and updating behavior explain most of the product. You probably do not need to describe the profile page, notification settings, navigation, colors, typography, or every way the learner can edit an item. Interface detail is useful when it carries the product idea—the countdown belongs because making the deadline present is part of the experience—but decorative or routine UI detail does not earn airtime simply because it makes the description more specific.

The standard is therefore not completeness but sufficiency. Once the few distinctive elements have created a shared picture, additional ordinary detail has rapidly diminishing value. A useful editing question is whether removing a detail makes the product materially harder to picture, removes part of the shared vocabulary you will need later, or weakens the explanation for why it solves the pain. If none of those things happen, the detail probably does not need airtime in this stage of the interview.

This discipline also prevents accidental scope expansion. A solution can contain several supporting capabilities when they work together to produce one coherent experience, but adding features that solve unrelated problems makes the idea harder to understand and compare. Keep the definition centered on the pain that earned the solution a place in the decision set.

Some demand-side experiences also require another user or supply-side capability to work. When that dependency is essential, explain enough of it to make the primary experience believable without turning the case into a second product design exercise. If your solution gives learners targeted access to experts, for example, you may need to establish that a pool of qualified experts can be matched to the learner’s topic and timing. You do not need to redesign the expert’s entire workflow unless the viability of the solution depends on it. Supporting systems and user roles matter to the extent that they explain how the promised customer value can actually be delivered.

The point

A strong solution definition lets the interviewer see the product and understand why it works. Use a small number of concrete details to create a verbal wireframe and a shared vocabulary for the solution, then explain the mechanism connecting that experience to the selected pain. When the interviewer can picture the product, refer back to its important parts, and fill in the ordinary details without guessing at how value is created, the definition is complete.