The PM loop as it is actually run: product sense, analytical, execution, and strategy rounds, each with its own scoring rubric.
22 published across 7 topics.
Improve-this-product and design-for-this-user questions, and structuring an answer around a real user problem.
Separate what the design costs users from what you personally dislike, then reconstruct the constraint that produced it: a business model, an organisational boundary, a regulatory rule or a migration nobody can finish. Any change you propose has to survive that constraint or it is not a proposal.
It is a structure test, not a creativity test: state the product's goal and how it earns money, name one segment and one unmet need, generate several options before choosing, then commit to a metric and the risk that would prove you wrong.
Argue from the cost the feature imposes on everyone who does not use it — surface area, decision load, engineering drag — then quantify who depends on it, find where their need lands afterwards, and stage the removal so you learn before you are committed.
RICE, Kano, cost of delay, and defending a roadmap cut to an unhappy stakeholder.
Separate the leverage from the merit: the renewal makes the request urgent, it does not make it valuable. Work out the real problem underneath the requested solution, test whether it generalises to other accounts, and price the full cost including permanent maintenance rather than the build estimate. Then choose deliberately between roadmap, configuration, services and no.
A framework's job is to make the trade-off legible, not to produce a verdict: ring-fence hard-dated and reliability work first, score the discretionary remainder on one agreed model, and communicate each no as what it displaces plus the condition that would reverse it.
Stop ranking by value, which you cannot know, and rank by uncertainty instead: sequence the work that would most cheaply tell you the whole idea is wrong. Scoring frameworks fed with invented numbers launder a guess into a decision, and their real cost is that nobody revisits the guess.
Convert the migration into the units the roadmap already uses by pricing its carrying cost and the cost of delaying it, then rank it on the same scale as features rather than arguing for it as a special category that deserves exemption. Use this prioritisation answer to show the decision, trade-off, and evidence rather than a memorised definition.
Choosing a north-star metric, diagnosing a drop, guardrail metrics, and estimation questions.
Ratios improve when the denominator shrinks and averages improve when the mix shifts, so a rate can rise while every underlying cohort worsens; you catch it by pairing every rate with its absolute counts, decomposing by segment, and defining guardrails before launch.
Rule out instrumentation before behaviour, then segment along the dimensions that isolate a cause — platform, geography, cohort, and acquisition channel — to distinguish a broad drop from a concentrated one, since those have entirely different explanations.
Build the number from a baseline and named mechanisms rather than accepting it, because a target with no route attached is a wish that will be met by lowering the definition. Decompose the growth into drivers, state what each is worth, and say plainly which portion of the gap has no plan behind it.
Opportunity solution trees, interview technique, assumption testing, and avoiding confirmation bias.
You look for evidence of the behaviour, not enthusiasm for your idea: interviews about past specific episodes rather than hypothetical futures, triangulated against what usage data, support tickets and lost deals show people already do.
Treat blocked access as a research design problem rather than a blocker. Make the account team's job easier so they open the door, triangulate the proxies you can reach against behavioural evidence, and state explicitly which decisions your sample cannot support.
Establish whether the test could ever have detected the effect you cared about, because an underpowered null tells you nothing; then read the confidence interval rather than the verdict and decide whether to extend, test a larger change, or accept that the assumption was wrong.
Scope cuts under a deadline, launch readiness, working with engineering, and handling a slipped date.
Find out what the date is being used for, then commit to something you can actually control — a timeboxed discovery end, a date for the date, or a narrow first slice — and never issue a single-point estimate for scope that is still undefined.
Find out what the six weeks is made of before negotiating anything, then choose between cutting scope, splitting the release, launching to a limited cohort and moving the date — and tell everyone who depends on the date the same day you know.
Re-plan around the dependency before you escalate: price the delay, find the smallest thing the other team could give you, and design a version that ships without them. Escalate only with a costed choice between two named options, and never as a complaint about the other team's judgement.
Segmentation, competitive positioning, build-buy-partner, and pricing and packaging reasoning.
Establish whether anything changed for your customers before changing your plan, then choose deliberately between accelerating, differentiating, ignoring it and reframing the category — and treat the competitor's launch as evidence about the market rather than an instruction.
Absence of requests is a demand signal you have to explain before you price anything; once you know whether the need is latent or absent, choose the packaging first — core, tier upgrade, or add-on — and price against the buyer's alternative rather than your build cost.
Diagnose why growth stopped before choosing a direction, because saturation, a distribution ceiling and a retention leak each point at a different answer. Then choose on which of your existing assets transfers, and name the evidence that would kill the option before you commit engineering to it.
Full cases worked end to end with the interviewer's evaluation criteria stated up front.
Work out who owns the customer after the deal, because that decides whether this is distribution or the slow loss of your product. Price the engineering the partner's requirements will consume, and set the conditions under which you would walk away before you see the revenue figure.
A product market sizing case should define the revenue pool, work top-down from households to willingness to pay, sanity-check penetration, then turn the estimate into a build-or-don't-build recommendation. It also connects estimation to the point an interviewer is testing.
Equal revenue hides unequal quality of revenue, so compare the two on retention, expansion, cost to serve, cost to acquire and headroom, then pick the one whose limiting constraint you can actually change in a year and name the condition that would reverse the choice.