Worked Product Management reasoning

Product Management Case Studies

Inspect realistic Product Management decisions from evidence to trade-off. Each worked case separates what is known, assumed, and unknown, compares credible alternatives, explains the decision, defines measurement, and shows what new evidence would change the recommendation.

16 deep worked casesAll hypothetical and explicitly labeled7 PM skills7 product domainsNo company-history fabricationNo universal correct answers
Browse case studiesSolve a case yourself first

Choose the right learning surface

Case study ≠ PM exercise ≠ case interview

Product Management case study

Inspect worked reasoning

The reasoning is revealed so you can inspect evidence, alternatives, decision logic, trade-offs, metrics, and reversal conditions.

PM exercise

You decide before guidance

Exercises hide the reasoning guide until you have written your own recommendation. They are active practice, not worked examples.

PM case interview

Hiring-format reasoning

Case Interview content teaches how to structure ambiguous prompts under interview conditions. That search job stays separate from this library.

CraftUp learning loop

Learn → try → inspect → rehearse

Learn

Build the mental model

Use a course or guide when the missing piece is the concept, framework, or product principle itself.

Follow the learning path →Try

Make the decision yourself

Use PM Exercises when you want the evidence and constraint first, then commit to your own reasoning before seeing guidance.

Practice a PM decision →Inspect

Study a complete reasoning chain

Use this library when you want to see how context, evidence, alternatives, trade-offs, measurement, and uncertainty fit together.

Browse worked cases →Rehearse

Reason under interview pressure

Use the Interview Simulator only when the job is interview-style practice with prompts, follow-ups, and feedback.

Practice an interview →

Source and truth guardrail

These are educational scenarios, not disguised company histories

Every initial case is labeled Hypothetical. Real company names, internal customer research, roadmap debates, conversion rates, model scores, legal requirements, or observed outcomes are not invented. If CraftUp later adds a real case, verified facts, CraftUp interpretation, and hypothetical alternatives should be separated and sourced explicitly.

Worked-case library

Inspect the reasoning, not just the answer

Every launch case is explicitly hypothetical. The facts, assumptions, unknowns, alternatives, decision, trade-offs, measurement plan, risks, and reversal conditions are separated so you can challenge the logic instead of memorizing a model answer.

Showing 16 of 16 cases

DiscoverySaaSDiscoveryHypothetical

Feature requests disagree. The underlying workflow problem does not.

A B2B team hears three different feature requests and must decide what to learn before committing roadmap capacity.

Context

A workflow product receives requests for a Slack digest, bulk editing, and mobile approvals. The team has one week for discovery before planning and cannot build three separate bets just to see what sticks.

Evidence map

Known

  • • Support tickets mention the Slack digest often, but many describe the pain as chasing reviewers and losing track of blocked work.
  • • Recent interviews contain several different requested solutions but a repeated complaint about not knowing who needs to act next.
  • • Mobile approval completion is lower than desktop completion.

Assumed

  • • A shared visibility/coordination problem may explain more of the demand than any single requested feature.

Unknown

  • • Whether mobile usability or awareness is the dominant blocker.
  • • Whether the Slack request represents a broad need or one commercially important account.

What would you do?

Should the team commit to a requested feature, or use the week to identify the workflow failure that would make one solution worth building?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

Build Slack digest

Fast response to the loudest request and potentially useful for a high-value account.

Fix mobile approvals

Behavioral data points to a concrete funnel gap with an existing workflow.

Investigate blocked-work visibility

Multiple requests may be symptoms of the same coordination problem.

Worked decision

Use the discovery week to test the blocked-work hypothesis before selecting a delivery channel.

  • The repeated problem signal crosses requested solutions, which makes it more decision-relevant than raw request count.
  • The team can cheaply distinguish awareness, mobile friction, and workflow-state problems before spending build capacity.
  • The recommendation preserves the option to choose Slack or mobile later if evidence points there.

Trade-offs accepted

  • Delays a visible feature commitment by one week.
  • May disappoint the account asking specifically for Slack.
  • Buys information that can prevent three separate symptom-level roadmap items.

Measurement plan

Primary outcome

Completion rate of the target approval/review job after a future intervention.

Leading / diagnostic

  • • Time to identify pending action
  • • Reviewer response time
  • • Mobile approval completion by segment

Guardrails

  • • Incorrect approvals/rejections
  • • Notification opt-outs or overload
  • • Support contacts about missing context

Risks / uncertainty

  • • The apparently shared problem may hide distinct jobs by segment.
  • • Instrumentation may be contributing to the apparent mobile gap.

What would change the decision?

  • • A committed enterprise deal is contingent on a Slack integration and strategically worth the opportunity cost.
  • • Session replay or corrected instrumentation shows a severe mobile interaction defect that directly explains abandonment.

Outcome status

No observed result is claimed. This hypothetical case ends at a discovery decision; success means the next week produces evidence that changes or strengthens prioritization.

What this case teaches

  • • Feature requests are evidence about problems, not automatically roadmap units.
  • • Good discovery reduces the uncertainty most likely to reverse a decision.
PrioritizationSaaSGrowthHypothetical

One onboarding bet, three plausible winners

A SaaS team has capacity for one onboarding investment and evidence that is useful but not comparable enough for fake precision.

Context

A self-serve team can fund one onboarding bet: sample data, a teammate-invite nudge, or a guided import. Design capacity is constrained and the next cycle cannot absorb all three.

Evidence map

Known

  • • Accounts that invite teammates early retain better, but the relationship is correlational.
  • • Support repeatedly reports confusion during import.
  • • Usability sessions show sample data improves initial comprehension.

Assumed

  • • Faster first value is the current strategic objective.

Unknown

  • • Which friction most often prevents first value.
  • • Whether early teammate invites cause retention or simply identify stronger accounts.

What would you do?

Which bet should receive the cycle, and is the evidence strong enough to build rather than learn first?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

Guided import

Repeated user friction directly blocks getting real data into the product.

Sample data

It can shorten comprehension time before users invest in setup.

Invite nudge

Collaboration may be the retained-value mechanism, not just setup completion.

Worked decision

Prioritize guided import, with a narrow scope and an explicit check that import failure is concentrated among otherwise qualified accounts.

  • The evidence is closest to a concrete blocked job rather than an ambiguous correlation.
  • The bet directly removes a step required before real product value can occur.
  • A narrow import intervention is more interpretable than combining several onboarding changes.

Trade-offs accepted

  • Does not test whether collaboration is the true retention driver.
  • May improve setup completion without improving repeated value.
  • Defers a lower-effort sample-data learning opportunity.

Measurement plan

Primary outcome

Qualified-account activation rate after successful import.

Leading / diagnostic

  • • Import start-to-complete rate
  • • Time to first real-data action

Guardrails

  • • Import error rate
  • • Support contacts
  • • Downstream retention by activated cohort

Risks / uncertainty

  • • Support volume may overrepresent complex accounts.
  • • Import completion may be a proxy metric rather than customer value.

What would change the decision?

  • • Segmented analysis shows teammate invitation remains predictive after controlling for account size and intent.
  • • Import friction affects few qualified accounts while sample-data comprehension failure is widespread.

Outcome status

No observed result is claimed. The worked recommendation is a prioritization choice to test, not an assertion that guided import will win.

What this case teaches

  • • Choose criteria before choosing the winner.
  • • A framework should expose uncertainty, not turn guesses into decimals.
MetricsConsumerGrowthHypothetical

Signups are healthy. First value is not.

A consumer app must decide whether activation is failing because of UX friction, weak education, missing capability, or the wrong acquisition mix.

Context

A planning app has stable signup volume, but many new users never create and complete a first plan. The team is debating a tutorial, a simpler creation flow, and a new template feature.

Evidence map

Known

  • • Most abandonment happens before the first plan is saved.
  • • Interviewees often understand the value proposition but hesitate when asked to configure too many fields.
  • • A recent acquisition campaign brought a larger share of casual users.

Assumed

  • • Completing a useful first plan is a reasonable activation event.

Unknown

  • • Whether configuration friction or low user intent explains most abandonment.
  • • Whether templates solve the problem or merely shift complexity later.

What would you do?

Should the team simplify the flow, educate users more, add templates, or change who it acquires?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

Add tutorial

Could reduce uncertainty if users do not understand the workflow.

Simplify first-plan creation

Directly targets the observed point of abandonment.

Add templates

Could reduce blank-state effort without removing advanced configuration.

Tighten acquisition

The funnel may have changed because incoming users have weaker intent.

Worked decision

First segment activation by acquisition source and intent; if the drop persists among qualified cohorts, test a materially simpler first-plan path before adding education or capability.

  • The acquisition mix changed, so aggregate activation is not enough to diagnose product friction.
  • Interviews point to setup burden more than conceptual confusion.
  • Simplification tests the problem with less product surface than a new template system.

Trade-offs accepted

  • Requires analysis before a visible feature ships.
  • A simpler first path may defer configuration users ultimately need.
  • Could miss a template-led opportunity if blank-state anxiety is the true blocker.

Measurement plan

Primary outcome

Qualified-user first-value rate.

Leading / diagnostic

  • • First-plan save rate
  • • Time to first plan
  • • Field-level abandonment

Guardrails

  • • Plan quality/completeness
  • • Day-7 repeat planning
  • • Undo/edit burden after simplified setup

Risks / uncertainty

  • • The chosen activation event may not represent real value.
  • • Simplification could improve completion while creating lower-quality plans.

What would change the decision?

  • • Qualified cohorts activate normally and the drop is isolated to the new campaign.
  • • Research shows users want examples/templates specifically and do not struggle with configuration once a starting point exists.

Outcome status

No observed result is claimed. The case teaches diagnosis before intervention; a later experiment would determine whether simplification improves first value without harming repeat value.

What this case teaches

  • • Activation is a value milestone, not merely an account event.
  • • Segment acquisition quality before attributing a funnel change to product UX.
MetricsSaaSMature productHypothetical

Feature usage rose while retention fell

A collaboration product must separate adoption, repeat value, cohort mix, and causality after a large launch.

Context

A collaboration product launches shared workspaces. Workspace usage and session frequency increase, but the newest account cohorts retain worse than pre-launch cohorts.

Evidence map

Known

  • • Workspace adoption is increasing.
  • • Invite acceptance increased while completion of the first shared task is roughly flat.
  • • The post-launch acquisition mix includes more very small teams.

Assumed

  • • Repeated collaborative work, not session count, is the value mechanism.

Unknown

  • • Whether the feature affects retention causally.
  • • Whether small teams have a different retained-value path.

What would you do?

Should the team expand the feature, redesign onboarding, or investigate retention before making another product bet?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

Expand workspace capabilities

Usage suggests users are finding the feature discoverable and interesting.

Redesign collaborative onboarding

Invite acceptance rose without a matching meaningful task completion gain.

Pause and analyze cohorts

Acquisition mix and concurrent changes confound the aggregate retention signal.

Worked decision

Pause expansion and run a cohort/segment diagnosis centered on first shared value before selecting the next product change.

  • Usage and retention point in different directions.
  • The cohort mix changed enough to make aggregate comparisons unsafe.
  • The first meaningful shared action is a more decision-relevant diagnostic than sessions.

Trade-offs accepted

  • Delays roadmap expansion despite visible adoption.
  • May surface that the feature helps only a narrow segment.
  • Creates a cleaner basis for deciding whether onboarding or product depth is the next constraint.

Measurement plan

Primary outcome

Retained accounts completing repeated shared work.

Leading / diagnostic

  • • First shared-task completion
  • • Invite-to-collaboration conversion

Guardrails

  • • Support burden
  • • Notification volume
  • • Single-user workflow regression

Risks / uncertainty

  • • Cohort analysis can still confuse correlation with causality.
  • • A useful feature can coexist with a worsening acquisition mix.

What would change the decision?

  • • A controlled rollout shows the workspace materially improves retention for comparable accounts.
  • • The retention decline disappears after normalizing for acquisition source and team size.

Outcome status

No observed result is claimed. The immediate outcome is a measurement decision: do not call a launch healthy or unhealthy from one aggregate metric.

What this case teaches

  • • Adoption is not retention.
  • • When signals conflict, improve causal and segment understanding before scaling the bet.
StrategyConsumerGrowthHypothetical

Free trial or freemium when value needs setup

A subscription product must choose a monetization path without assuming one pricing model is universally better.

Context

A subscription design tool requires users to import assets and complete a project before value is obvious. The team is considering a 14-day trial, a permanent free tier with limits, or a small free project allowance.

Evidence map

Known

  • • Many users need several sessions before completing a first project.
  • • Storage and export create real variable cost.
  • • Some users arrive with one urgent project while others intend recurring use.

Assumed

  • • Experiencing a successful export is more persuasive than feature-list education.

Unknown

  • • How much free usage is needed to reach value by segment.
  • • How strongly recurring value predicts willingness to pay.

What would you do?

Which access model best lets qualified users experience value while keeping cost and upgrade logic understandable?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

Time-limited trial

Simple entitlement and a clear decision deadline.

Permanent freemium

Lets slower users learn without a clock and can support organic sharing.

Free project allowance

Ties free access to a value unit rather than elapsed time.

Worked decision

Test a limited free-project allowance before a broad permanent freemium model.

  • The product's value unit is closer to completed projects than days elapsed.
  • It gives slower evaluators room to reach value without unlimited variable cost.
  • The boundary is easier to reason about than stripping many capabilities from a free tier.

Trade-offs accepted

  • Urgent one-project users may consume value without paying.
  • Users with unusually complex setup may still fail before the allowance proves value.
  • A project limit requires careful handling of retries and failed exports.

Measurement plan

Primary outcome

Qualified users reaching first value and later converting to paid.

Leading / diagnostic

  • • Project completion before limit
  • • Successful export rate

Guardrails

  • • Variable cost per free user
  • • Refund/support contacts
  • • Paid-user downgrade behavior

Risks / uncertainty

  • • The project unit may not align with value for every segment.
  • • Short-term conversion can improve while long-term fit worsens.

What would change the decision?

  • • Most qualified users can reliably reach value within a short, predictable time window.
  • • Free projects create high cost or abuse before producing upgrade evidence.

Outcome status

No pricing result is claimed. The case recommends a testable access model and explicitly avoids universal pricing rules.

What this case teaches

  • • Monetization design should follow the value journey and cost structure.
  • • Pricing experiments need behavioral and guardrail metrics, not only conversion.
ExecutionEcommerceMature productHypothetical

Checkout drops after a release: rollback or investigate?

An ecommerce team must separate instrumentation risk from customer harm and make a reversible decision within hours.

Context

A checkout release changes shipping-address validation. The next morning completion is down sharply, especially on mobile Safari. An analytics event was also renamed in the release.

Evidence map

Known

  • • Payment authorization remains stable for users reaching payment.
  • • Support screenshots show some users looping between address validation and review.
  • • The release is reversible.

Assumed

  • • Checkout harm is more costly than losing the address improvement for a short period.

Unknown

  • • How much of the dashboard drop comes from instrumentation.
  • • Whether the loop affects all address formats or a narrower segment.

What would you do?

Should the team roll back, disable only the new validation, or keep the release live while investigating?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

Full rollback

Fastest way to reduce possible revenue-sensitive harm.

Disable address validation only

Preserves unrelated release value if the component can be isolated safely.

Investigate in production

Avoids reacting to a potentially broken metric if customer impact is small.

Worked decision

Disable or roll back the new validation path immediately while independently repairing the measurement break.

  • Support evidence independently suggests real user harm.
  • The decision is reversible and the affected surface is revenue-sensitive.
  • Waiting for perfect attribution has asymmetric downside compared with restoring the prior flow.

Trade-offs accepted

  • Loses the intended address improvement temporarily.
  • A rollback may obscure the exact defect if logging is insufficient.
  • Protects customer completion while the team diagnoses safely.

Measurement plan

Primary outcome

Checkout completion by device/browser after mitigation.

Leading / diagnostic

  • • Shipping-step progression
  • • Validation error/loop rate

Guardrails

  • • Payment authorization
  • • Duplicate orders
  • • Support volume

Risks / uncertainty

  • • The rollback could introduce a separate regression.
  • • Broken analytics can make recovery appear better or worse than reality.

What would change the decision?

  • • Independent logs prove customers are completing normally and only the renamed event is broken.
  • • The rollback path is itself high-risk and a safe server-side disable can isolate the defect faster.

Outcome status

No observed recovery is claimed. The worked outcome is the choice to favor a reversible mitigation under asymmetric risk.

What this case teaches

  • • Verify measurement, but do not ignore independent evidence of harm.
  • • Reversibility and downside asymmetry should change execution decisions.
Product SenseFintechGrowthHypothetical

Identity verification friction vs account trust

A fintech product sees conversion loss at verification and must improve the experience without pretending risk controls are optional.

Context

A money-movement app sees a large drop during identity verification. Users complain that failed checks are confusing, while the risk team says some friction is necessary. The PM is not responsible for inventing regulatory policy.

Evidence map

Known

  • • A meaningful share of users fail on document capture and do not understand whether they can retry.
  • • Manual-review cases have much longer time-to-resolution.
  • • Support tickets cluster around failure recovery and status ambiguity.

Assumed

  • • Clear recovery and status can improve completion without weakening the underlying control.

Unknown

  • • Which failures are recoverable in-product.
  • • Which checks are policy constraints versus implementation choices.

What would you do?

Where can the product reduce avoidable friction while preserving required risk controls and honest user expectations?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

Relax verification

Could improve conversion but cannot be evaluated as a product-only decision.

Improve capture guidance and retry

Targets preventable failures without changing the control objective.

Improve review status/recovery

Targets abandonment caused by uncertainty after submission.

Worked decision

Prioritize recoverability: better capture feedback, explicit retry states, and clear manual-review status before proposing any change to risk policy.

  • The evidence points to implementation and communication failures the product team can own.
  • The approach improves user control without claiming that safety checks are unnecessary.
  • It creates better data on true policy-driven versus UX-driven drop-off.

Trade-offs accepted

  • Does not eliminate all verification abandonment.
  • More retry guidance can increase attempts and operational load.
  • Manual-review transparency may expose that some resolution times remain slow.

Measurement plan

Primary outcome

Eligible users completing verification successfully.

Leading / diagnostic

  • • Document-capture success
  • • Recoverable-failure retry completion

Guardrails

  • • Fraud/risk outcomes defined by the appropriate team
  • • Manual-review load
  • • Support contacts

Risks / uncertainty

  • • Retries may create abuse paths if not designed with risk partners.
  • • The largest conversion loss may come from non-UX policy constraints.

What would change the decision?

  • • Analysis shows most drop-off occurs after users receive a clear, non-recoverable decision rather than during capture/recovery.
  • • Risk partners identify a safe policy change with stronger expected impact than UX recovery work.

Outcome status

No compliance or legal conclusion is claimed. This hypothetical case keeps the PM decision on product recovery, clarity, and measurement.

What this case teaches

  • • Separate product friction from policy/risk constraints.
  • • Trust-sensitive products need conversion metrics and risk guardrails in the same decision.
StrategyMarketplaceLaunchHypothetical

Launch a marketplace city without hiding the cold-start problem

A two-sided marketplace must decide whether to launch broadly, seed one dense segment, or wait for more supply.

Context

A local-services marketplace is entering a new city. Marketing can generate customer demand, but provider supply is uneven by neighborhood and service category.

Evidence map

Known

  • • Supply is strongest in two adjacent neighborhoods.
  • • Customer demand is broad but early matching fails when travel distance is high.
  • • Provider churn rises when they receive many low-quality or distant leads.

Assumed

  • • Local density matters more than top-line citywide signups during the first launch phase.

Unknown

  • • Which service category can reach healthy repeat matching fastest.
  • • How much customers will tolerate narrower initial coverage.

What would you do?

Should the marketplace launch citywide, delay until supply grows, or deliberately constrain the first market?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

Citywide launch

Maximizes awareness and demand capture.

Delay launch

Avoids disappointing users before supply is sufficient.

Dense-zone launch

Concentrates both sides where matching quality is most likely to work.

Worked decision

Launch a narrow geographic/service wedge with explicit coverage boundaries, then expand when matching health meets predefined criteria.

  • Two-sided quality depends on density, not only acquisition volume.
  • The constrained launch makes failed matches more interpretable.
  • It protects providers from low-quality lead volume while the system learns.

Trade-offs accepted

  • Smaller initial top-line demand.
  • Some interested customers are intentionally excluded.
  • Creates a clearer learning loop for expansion instead of masking poor liquidity in citywide averages.

Measurement plan

Primary outcome

Successful match/completion rate in the launch wedge.

Leading / diagnostic

  • • Time to match
  • • Qualified provider response rate

Guardrails

  • • Provider churn
  • • Cancellation/refund rate
  • • Customer support complaints

Risks / uncertainty

  • • A narrow wedge can look healthy but fail to generalize.
  • • Marketing may create expectations outside supported coverage.

What would change the decision?

  • • Supply becomes reliably dense across the city before launch.
  • • Demand evidence shows the wedge is too small to sustain provider economics even with strong match quality.

Outcome status

No marketplace result is claimed. The case demonstrates sequencing around liquidity and two-sided incentives.

What this case teaches

  • • Marketplace growth can be harmed by spreading supply and demand too thin.
  • • Expansion criteria should include both sides of the market.
Product SenseAIDiscoveryHypothetical

AI support triage or deterministic rules?

An AI product decision weighs quality, ambiguity, review cost, latency, and failure handling instead of treating AI as the default.

Context

A support platform wants to route incoming tickets to the right queue. Existing keyword rules handle common cases but fail on ambiguous requests. A team proposes an AI classifier.

Evidence map

Known

  • • Most high-volume ticket types already have reliable deterministic patterns.
  • • Ambiguous multi-intent tickets create the largest manual triage burden.
  • • Wrong routing is recoverable but adds delay and staff work.

Assumed

  • • AI may add value mainly on the ambiguous tail rather than all tickets.

Unknown

  • • Quality on representative ambiguous tickets.
  • • Latency/cost at expected volume.
  • • Whether confidence can identify when human review is needed.

What would you do?

Should the team replace rules with AI, augment only ambiguous cases, or improve deterministic routing further?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

AI for every ticket

One system could handle wider language variation.

Hybrid routing

Keep high-confidence rules and use AI only where rules are weak.

Rules only

Lowest operational complexity if the remaining tail is small.

Worked decision

Prototype a hybrid path: deterministic routing for known cases, AI evaluation on the ambiguous tail, and human review for low-confidence outputs.

  • It targets the actual failure surface instead of replacing a working system.
  • It creates a bounded evaluation set before production dependence.
  • Failure is recoverable, so human review can be used selectively while quality is learned.

Trade-offs accepted

  • More system complexity than a single classifier.
  • Human review remains part of the workflow.
  • The team must define evaluation and escalation rather than shipping on demo quality.

Measurement plan

Primary outcome

Correct routing on representative ambiguous tickets.

Leading / diagnostic

  • • Human-review rate
  • • Re-route rate

Guardrails

  • • Routing latency
  • • Cost per ticket
  • • Critical-category miss rate

Risks / uncertainty

  • • Evaluation data may not represent production language shifts.
  • • Confidence scores may not be calibrated enough to drive review safely.

What would change the decision?

  • • Rules cover the ambiguous tail with acceptable maintenance cost.
  • • AI quality or economics fail the agreed threshold on representative data.

Outcome status

No model performance is invented. The outcome is an evaluation plan and bounded product architecture, not a claim that AI wins.

What this case teaches

  • • Choose AI only where it improves the product system, not because the capability exists.
  • • AI PM work requires evaluation, failure handling, and cost/latency trade-offs.
PrioritizationPlatformScalingHypothetical

Ship the customer feature or invest in a shared platform capability?

A platform team weighs immediate revenue pressure against repeated integration cost and future extensibility.

Context

Three product teams need slightly different external integrations. One enterprise opportunity needs a custom connector soon; engineering proposes a shared integration framework instead.

Evidence map

Known

  • • Teams have built similar authentication, retry, and mapping logic several times.
  • • The enterprise connector has a near-term commercial deadline.
  • • A shared framework would take longer before the first customer value appears.

Assumed

  • • Integration demand will continue across multiple teams.

Unknown

  • • How much common behavior can truly be standardized.
  • • Whether the enterprise opportunity justifies bespoke work even if it creates debt.

What would you do?

How much near-term feature delivery should be traded for a shared capability that may reduce repeated future cost?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

Custom connector now

Fastest path to the committed customer opportunity.

Platform framework first

Reduces repeated engineering and creates consistency for future integrations.

Thin shared core + connector

Extract only proven common needs while meeting the immediate use case.

Worked decision

Build a thin shared core only around already-repeated capabilities, then deliver the priority connector on top of it.

  • Repeated auth/retry/mapping work is real evidence for standardization.
  • The team avoids designing a broad platform from hypothetical future requirements.
  • The commercial deadline remains visible rather than hidden behind platform purity.

Trade-offs accepted

  • The first connector takes longer than fully bespoke work.
  • The shared core may need refactoring as the second/third connector exposes differences.
  • Avoids a large upfront platform bet without evidence.

Measurement plan

Primary outcome

Time and defect rate for subsequent supported integrations.

Leading / diagnostic

  • • Reusable component adoption
  • • Connector delivery lead time

Guardrails

  • • Platform incidents
  • • Migration burden
  • • Bespoke escape-hatch usage

Risks / uncertainty

  • • Commonality may be overstated.
  • • A thin core can become a de facto platform without clear ownership.

What would change the decision?

  • • The priority connector is truly one-off and future demand is weak.
  • • Several committed integrations share a stable contract that justifies a larger platform investment now.

Outcome status

No productivity gain is claimed. The case teaches evidence-based standardization and incremental platform investment.

What this case teaches

  • • Platform work should solve repeated product-team problems, not abstract elegance.
  • • Standardize proven repetition before speculative extensibility.
ExecutionConsumerLaunchHypothetical

Launch now, delay, or reduce scope?

A release has one unresolved reliability risk and a fixed marketing window; the PM must sequence rollout rather than argue from optimism.

Context

A consumer feature is scheduled for a public launch. Core behavior is stable, but one optional import path has intermittent failures. Marketing assets are ready and the import path can be disabled independently.

Evidence map

Known

  • • Core flows pass release checks.
  • • The import failure is intermittent and recoverable but confusing.
  • • The feature flag can exclude the import path without delaying the rest of the release.

Assumed

  • • The optional import path is not essential to the primary launch promise.

Unknown

  • • Root cause and time to permanent fix.
  • • How many launch users would choose import.

What would you do?

Should the team delay everything, launch with known risk, or narrow scope and stage the risky path later?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

Delay full launch

Avoids knowingly shipping any unstable path.

Launch everything

Preserves the full promise and marketing schedule.

Launch core, hold import

Uses reversibility and feature isolation to protect the primary job.

Worked decision

Launch the stable core to a staged audience and hold the unreliable import path behind its flag until the team can validate the fix.

  • The risky capability is separable from the primary value proposition.
  • Staged rollout creates a smaller blast radius and clearer monitoring.
  • The choice avoids both false binary thinking and knowingly exposing a confusing failure path.

Trade-offs accepted

  • The initial release has narrower capability than planned.
  • Launch communication must avoid implying import is available.
  • The team still carries follow-up work after launch.

Measurement plan

Primary outcome

Successful completion of the core launch job.

Leading / diagnostic

  • • Feature adoption in staged cohort
  • • Error-free completion

Guardrails

  • • Crash/error rate
  • • Support volume
  • • Rollback/pause triggers

Risks / uncertainty

  • • Marketing or in-product copy may promise the held capability.
  • • The staged cohort may not represent broader traffic.

What would change the decision?

  • • Import is essential to the core user promise for most launch users.
  • • The core flow shows a separate reliability issue during staging.

Outcome status

No launch performance is claimed. The worked decision is a scope/rollout choice with explicit pause criteria.

What this case teaches

  • • Launch timing is not always a binary ship/delay decision.
  • • Use scope isolation, rollout, and pause criteria to make risk manageable.
StrategySaaSScalingHypothetical

Three growth directions, one strategy

A B2B product must choose between self-serve depth, enterprise administration, and an adjacent workflow instead of calling all three strategy.

Context

A B2B product has strong small-team adoption. Leadership is considering deeper self-serve collaboration, enterprise admin/security, or expansion into an adjacent planning workflow.

Evidence map

Known

  • • Small teams activate without sales help and some expand organically.
  • • Larger prospects ask for admin controls that are expensive to build.
  • • Adjacent planning is used today through spreadsheets and other tools.

Assumed

  • • The company cannot credibly execute all three directions in the same planning horizon.

Unknown

  • • Enterprise willingness to pay relative to the cost of the missing controls.
  • • Whether adjacent planning creates differentiated value or feature sprawl.

What would you do?

Which target/customer problem should define the next strategic chapter, and what should explicitly not be pursued now?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

Deepen self-serve collaboration

Builds on observed adoption and expansion behavior.

Move enterprise

Potentially larger contracts and clearer requested capability gaps.

Expand workflow

Could increase frequency and product breadth for current users.

Worked decision

Choose self-serve team expansion as the primary strategy while running targeted commercial discovery on enterprise demand; defer the adjacent workflow.

  • It builds on the strongest observed product behavior rather than the largest hypothetical market.
  • Enterprise discovery can test willingness to pay before a deep admin build.
  • Deferring workflow expansion keeps the strategy focused on one value loop.

Trade-offs accepted

  • May leave large deals on the table in the short term.
  • Does not broaden the product's category footprint.
  • Concentrates investment where current product pull is most evidenced.

Measurement plan

Primary outcome

Expansion and retained value among target self-serve teams.

Leading / diagnostic

  • • Multi-user activation
  • • Organic seat/workspace growth

Guardrails

  • • Support burden
  • • Churn by team size
  • • Sales pipeline loss reasons

Risks / uncertainty

  • • Current self-serve strength may plateau.
  • • Enterprise controls could be a strategic prerequisite rather than a niche request.

What would change the decision?

  • • Validated enterprise willingness to pay and pipeline concentration justify the control investment.
  • • Self-serve expansion stalls despite strong activation, weakening the current advantage.

Outcome status

No revenue outcome is claimed. The case demonstrates a strategy as a choice with target, non-goals, evidence, and sequencing.

What this case teaches

  • • Strategy is a set of choices and non-goals, not a list of initiatives.
  • • Use sequencing to learn about the second-best direction without funding everything.
ExperimentationConsumerGrowthHypothetical

Test a notification idea when a clean A/B test is not the first move

A small consumer product wants to test a weekly digest without pretending every decision needs statistically powered experimentation immediately.

Context

A habit product believes a weekly progress digest could improve return behavior. Traffic is modest, notification permission is incomplete, and the team is not confident users find the digest content valuable yet.

Evidence map

Known

  • • Users who manually visit progress views tend to retain better, but selection bias is likely.
  • • Interviewees say progress visibility can be motivating when it feels specific.
  • • The team can prototype the digest without building a full notification system.

Assumed

  • • The digest could create a useful return trigger if the content itself is valuable.

Unknown

  • • Whether users understand and value the proposed summary.
  • • Whether a notification adds value beyond an in-app progress view.

What would you do?

What is the cheapest credible learning step before investing in a production notification experiment?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

Build full A/B test

Directly estimates causal impact if traffic and instrumentation are adequate.

Prototype content first

Tests whether the value proposition works before notification infrastructure.

Do nothing

Avoids adding re-engagement noise without stronger evidence.

Worked decision

Run a small content/prototype validation first, then instrument a controlled test only if users can interpret and act on the digest.

  • The largest uncertainty is the content's value, not the notification channel's incremental lift.
  • A lightweight test avoids engineering work that would not resolve that uncertainty.
  • If the concept survives, the later experiment has a clearer hypothesis and outcome.

Trade-offs accepted

  • Does not produce a causal retention estimate immediately.
  • Qualitative enthusiasm can still overstate real behavior.
  • Saves build effort while improving the later experiment design.

Measurement plan

Primary outcome

If production-tested later: incremental return to meaningful product action.

Leading / diagnostic

  • • Prototype comprehension
  • • Intent/action after digest

Guardrails

  • • Notification opt-outs
  • • Complaint rate
  • • Low-value opens without downstream action

Risks / uncertainty

  • • Prototype behavior may not translate to recurring notifications.
  • • Small traffic may still make later effect estimation noisy.

What would change the decision?

  • • Existing traffic and infrastructure make a cheap, well-powered production experiment possible now.
  • • Prototype sessions show the digest is confusing or not actionable.

Outcome status

No uplift is claimed. The worked decision is about experiment sequencing and matching method to uncertainty.

What this case teaches

  • • Experiments are tools for specific uncertainties, not rituals.
  • • Resolve concept/value risk before investing in channel or infrastructure when that is cheaper.
Product SenseEcommerceMature productHypothetical

Search conversion is fine. Product discovery is still weak.

An ecommerce PM distinguishes search success from category discovery and avoids optimizing only the users who already know what they want.

Context

An ecommerce site has healthy conversion for exact product searches, but category browsers often refine repeatedly, bounce, or abandon after opening several product pages.

Evidence map

Known

  • • Exact-name queries convert well.
  • • Broad category queries produce many refinements and product-page backtracking.
  • • Interviews suggest some shoppers know the use case they need but not the product attributes that matter.

Assumed

  • • The weak job is guided discovery, not basic search retrieval.

Unknown

  • • Whether filters, comparison, merchandising, or education is the strongest intervention.
  • • How behavior differs between novice and expert shoppers.

What would you do?

What should the product improve for users who have a need but cannot yet translate it into a specific product query?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

Add more filters

Can narrow large catalogs when users understand attributes.

Guided needs-based discovery

Helps users who know the job but not the vocabulary.

Improve merchandising

Curated groups can reduce choice complexity without a questionnaire.

Worked decision

Prototype needs-based guidance for one high-friction category and compare it with simpler merchandising improvements before adding a large filter taxonomy.

  • The problem appears strongest among users lacking attribute vocabulary.
  • A single-category prototype limits scope and tests whether guidance changes decisions.
  • More filters would increase interface complexity without proving users can use them.

Trade-offs accepted

  • Guidance adds an interaction before product selection.
  • A category-specific solution may not generalize.
  • Merchandising may be cheaper and nearly as effective, so it remains a credible comparator.

Measurement plan

Primary outcome

Qualified category sessions reaching a confident product selection/purchase.

Leading / diagnostic

  • • Backtracking/reformulation rate
  • • Comparison or product-detail progression

Guardrails

  • • Time to product for expert users
  • • No-result rate
  • • Return/cancellation signals

Risks / uncertainty

  • • Guidance can steer users toward the wrong product if questions are weak.
  • • Purchase conversion alone may hide increased returns from poor fit.

What would change the decision?

  • • Experts and novices show the same failure pattern and attribute filters clearly explain abandonment.
  • • Simple merchandising tests resolve most of the backtracking without added interaction.

Outcome status

No conversion gain is claimed. The case teaches segmentation by shopping job and product discovery quality, not a predetermined UI pattern.

What this case teaches

  • • Search and discovery are related but distinct jobs.
  • • Optimize for decision quality as well as immediate conversion.
ExecutionSaaSScalingHypothetical

A roadmap bet collides with an infrastructure dependency

A SaaS PM must decide whether to split scope, re-sequence work, or protect a date when a hidden dependency changes the cost of the plan.

Context

A reporting initiative is committed for the quarter. Engineering discovers that one requested slice requires a data-model migration that also affects other teams. The core report can ship without it.

Evidence map

Known

  • • The core report solves the most repeated customer job.
  • • The advanced slice is important to a smaller enterprise segment.
  • • The migration has cross-team dependencies and uncertain timing.

Assumed

  • • The core report remains independently valuable without the advanced slice.

Unknown

  • • How many target customers truly require the advanced slice before adopting the report.
  • • Whether the migration can be reused by other roadmap work.

What would you do?

Should the team hold the entire initiative, split the release, or absorb migration risk to preserve the original scope?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

Hold for full scope

Avoids a partial product experience for enterprise users.

Ship core, sequence advanced later

Delivers the repeated job while isolating dependency risk.

Prioritize migration now

Could unlock multiple future capabilities if reuse is real.

Worked decision

Split the release: deliver the independently valuable core, make the advanced slice an explicit follow-on dependent on migration evidence and enterprise need.

  • The core job has stronger repeated evidence.
  • The dependency changes the cost/risk profile of one slice, not the whole outcome.
  • The plan makes the scope trade-off visible instead of hiding it in a slipping date.

Trade-offs accepted

  • Enterprise users may wait for the complete workflow.
  • The team must communicate a narrower first release clearly.
  • Avoids coupling customer value to an uncertain platform change.

Measurement plan

Primary outcome

Use of the core report for the target job.

Leading / diagnostic

  • • Report completion/export
  • • Adoption by intended segment

Guardrails

  • • Requests blocked by missing advanced slice
  • • Migration incidents
  • • Support confusion about scope

Risks / uncertainty

  • • The advanced slice may be essential to the buyers who matter most commercially.
  • • Splitting can create duplicated work if interfaces change after migration.

What would change the decision?

  • • Validated target customers cannot adopt the core without the advanced slice.
  • • The migration is already funded by several teams and becomes a low-incremental-cost prerequisite.

Outcome status

No delivery speed or adoption is claimed. The case illustrates re-sequencing under dependency uncertainty.

What this case teaches

  • • A roadmap is a decision sequence, not a promise to preserve every original scope item.
  • • When dependencies change, re-evaluate value boundaries instead of only dates.
PrioritizationSaaSScalingHypothetical

More permissions or simpler workspace adoption?

A scaling SaaS product weighs enterprise controls against setup complexity and user-level adoption.

Context

A team workspace product is adding larger accounts. Admins ask for more granular permissions, while ordinary members already struggle to understand which workspace to join and what they can do there.

Evidence map

Known

  • • Permission requests are concentrated among larger accounts.
  • • Member support issues about access and workspace choice occur across segments.
  • • The current permission model supports the most common small-team workflows.

Assumed

  • • Adoption friction and admin-control gaps are separate but interacting problems.

Unknown

  • • Whether missing controls block purchases or mainly create sales friction.
  • • How much complexity new permission layers would add for members and admins.

What would you do?

Should the next cycle deepen enterprise controls or simplify the existing access model for broader adoption?

Commit to your own recommendation before opening the worked reasoning. There is no universal correct answer; a different choice can be defensible when its assumptions and trade-offs are explicit.

Show worked reasoning

Alternatives considered

Granular permissions

Can unblock larger customers with governance needs.

Simplify workspace/access UX

Improves the job for a wider set of current users.

Segmented admin mode

Could add controls without exposing every member to extra complexity.

Worked decision

Validate which permission gaps are purchase/adoption blockers, while prioritizing a clearer member access model that is required regardless of enterprise depth.

  • The member problem is observed across segments.
  • Permission demand has high potential value but needs stronger blocker evidence before broad complexity is added.
  • A clearer model reduces the risk that future controls amplify existing confusion.

Trade-offs accepted

  • May delay features requested by high-value prospects.
  • Simplification work can feel less differentiated than new enterprise capability.
  • Improves the foundation on which later segmented controls can be built.

Measurement plan

Primary outcome

Successful workspace activation for invited members.

Leading / diagnostic

  • • Invite-to-join completion
  • • Access error/help usage

Guardrails

  • • Enterprise deal loss reasons
  • • Admin setup time
  • • Permission-related incidents

Risks / uncertainty

  • • Commercial opportunity may justify prioritizing a narrow enterprise control sooner.
  • • Simplification may require data-model changes that are not actually low effort.

What would change the decision?

  • • Several high-confidence deals are blocked by the same specific permission capability.
  • • Member confusion is mostly documentation/support rather than product-model complexity.

Outcome status

No adoption result is claimed. The case emphasizes account-level and user-level behavior in the same SaaS decision.

What this case teaches

  • • SaaS decisions often have both account/buyer and end-user layers.
  • • Do not treat enterprise feature requests as automatically more strategic than cross-segment adoption friction.

For your own work

Borrow the reasoning pattern, never the story

Use the structure—context, evidence, decision, alternatives, trade-offs, outcome/measurement, learning—to make your own product work more inspectable. Do not present a CraftUp scenario as personal experience or portfolio evidence.

Build your own PM portfolio evidence

Need stronger fundamentals?

Learn the discipline behind the decisions

If the cases expose a gap rather than reinforce a skill, use Product Management Foundations for broad PM reasoning or Product Discovery for deeper evidence and problem-framing work.

Product Management FoundationsProduct Discovery