Product Manager Take-Home Assignment: Example & Presentation Guide

# PM TAKE-HOME DECISION TRACE

## Brief Contract
Objective:
Decision:
Constraints:
Required artifact:
Time boundary:
Explicitly out of scope:

## Evidence
Prompt facts:
Public evidence:
Assumptions:
Hypotheses:
Biggest unresolved unknown:

## Decision-Critical Assumption
Assumption:
Why I can proceed with it:
What evidence would invalidate it:

## Alternatives
Option A:
Option B:
Option C:

## Decision
Chosen direction:
Why:
Strongest rejected alternative:
Why it loses now:
Main downside:

## Measurement
Primary outcome:
Diagnostics:
Guardrails:
Decision rule:

## Next Learning
Highest-value next evidence:
Smallest useful test:

## Reversal
I would change direction if:

## Artifact QA
What must be in main story:
What belongs in appendix:

## Defense Surface
Hardest evidence challenge:
Hardest user/problem challenge:
Hardest alternative challenge:
Hardest metric challenge:
Hardest feasibility challenge:

## AI / Tool Use
Tool/AI assistance used:
What judgment remained mine:
Claims independently verified:

TL;DR:

• A PM take-home should make your product judgment inspectable. A polished deck with no clear decision is weaker than a simple artifact whose evidence, assumptions, alternatives, trade-offs, metrics, and risks can be challenged.
• Start with a Brief Contract: objective, decision, constraints, required output, time boundary, open questions, and explicit out-of-scope work. The employer's instructions outrank any CraftUp template.
• Keep an Evidence Budget, an Assumption Ledger, and a Decision Ledger. Every material claim should be traceable to the right evidence class and every important recommendation should expose a credible runner-up, downside, and reversal condition.
• Use the Take-Home Artifact Audit above to find what becomes fragile when you remove the author's voice-over: unsupported claims, hidden assumptions, research theater, strawman alternatives, metric zoos, appendix burial, and ownerless AI output.
• Treat every major recommendation as part of a Defense Surface. Defend the quality of the reasoning, not the identity of the first answer: if new evidence invalidates the premise, update the recommendation.
• There is no universal slide count or correct number of working hours. Follow the hiring process's actual constraints; if no work-time boundary exists, choose a personal one so research and polish do not expand indefinitely.
• Use CraftUp tools to express reasoning only when the artifact needs them. Tool output is not the decision.

Table of contents

• What a PM take-home assignment is actually testing
• Take-home vs live case interview
• The artifact-quality system
• 1. Rewrite the prompt as a Brief Contract
• 2. Time-box the work with an Evidence Budget
• 3. Build an Assumption Ledger
• 4. Build a Decision Ledger
• Claim → source → decision trace
• Complete worked PM take-home example
• A seven-slide presentation structure
• The Defense Surface: prepare the Q&A before you submit
• Take-Home Artifact Diagnostic
• Weak-to-strong artifact repair
• Common PM take-home mistakes
• Using AI without outsourcing your judgment
• Formats beyond slides
• APM vs PM vs Senior PM
• Copyable take-home templates
• CraftUp tool stack for take-home assignments
• Scope, confidentiality, and take-home boundaries
• Final submission checklist
• What to practice next
• FAQ

What a PM take-home assignment is actually testing

A take-home gives you something a live interview does not: time to choose what deserves attention and an artifact that must communicate without you in the room.

That creates different failure modes from a live case. You can spend too long researching. You can make the deck beautiful before deciding what you believe. You can hide uncertainty behind precise-looking numbers. You can produce a document that sounds coherent only because you are there to narrate the missing logic.

A strong take-home makes these surfaces inspectable:

1. Brief fidelity — you answer the assignment that was actually given and respect its constraints.
2. Evidence provenance — facts, public evidence, assumptions, hypotheses, and derived calculations are distinguishable.
3. Assumption visibility — the reader can see which assumption most controls the recommendation.
4. Decision clarity — there is an answer, not just analysis.
5. Alternative / trade-off quality — a credible runner-up loses for an explicit reason and the chosen option has a real downside.
6. Measurement — outcome, diagnostics, guardrails, and the next decision connect to the product mechanism.
7. Artifact independence — the deck, memo, PRD, or document makes sense without narration.
8. Defense readiness — the candidate can explain and update the work under challenge.
9. AI ownership — AI-assisted material remains sourced, reconstructable, and owned by the candidate.
10. Scope / time discipline — the work reflects the actual capacity and format constraints of the assignment.

This guide uses a CraftUp practice system, not a claim about any employer's internal evaluation model.

If you need the broader interview map first, use the Product Manager Interview Guide. If you need to reason through an ambiguous case live, use the PM Case Study Interview guide. A live case and a take-home share Product reasoning, but they are not the same hiring-format job.

Take-home vs live case interview

The key test is simple:

Would the artifact still communicate the decision if the author were not there?

A take-home is not “a live case with prettier slides.” It adds two jobs of its own:

• resource allocation — how you spend scarce preparation time;
• artifact architecture — how you preserve context, evidence, assumptions, choice, trade-off, measurement, risk, and uncertainty for an asynchronous reader.

CraftUp does not have a Take-Home Simulator mode. The existing PM Interview Simulator can help you rehearse live follow-up pressure after the artifact is coherent; it is not a take-home grader.

The artifact-quality system

Take-home quality is not document completeness.

A 25-slide deck can be weak. A six-slide deck can be excellent. A polished prototype can hide missing logic. A plain memo can be highly defensible.

The useful question is:

Can another person inspect the chain from brief → evidence → assumption → alternatives → decision → downside → metric → reversal → defense?

Think of artifact legibility as three connected traces:

Decision trace

Why does this recommendation follow from the brief, target, problem, alternatives, constraints, and trade-offs?

Evidence trace

Which material claims are prompt facts, public evidence, assumptions, hypotheses, or real derived calculations? How strong is the source for each claim?

Challenge trace

Which objection is most dangerous, what evidence would change the decision, and can the candidate update rather than defend stale logic?

The Take-Home Artifact Audit above operationalizes those traces with a fictional Relay artifact. It deliberately does not upload or grade your deck, use an LLM, calculate a score, or predict hiring outcomes.

1. Rewrite the prompt as a Brief Contract

Before opening slides, rewrite the assignment as a compact contract.

# BRIEF CONTRACT

Objective:
Decision I need to make:
Constraints / boundaries:
Required deliverable:
Time boundary:
Explicitly out of scope:
Questions that could materially change the direction:

Why call it a contract? Because take-home scope expands invisibly.

A prompt asks you to improve activation and two hours later you are researching market size, rebuilding pricing, designing eight screens, and writing a roadmap for three countries. The Brief Contract gives every section a test:

Does this work help answer the decision the assignment actually asked me to make?

The employer's instructions outrank CraftUp's structure

If the hiring process says:

• no AI;
• no external research;
• maximum five slides;
• one-page memo;
• no mockups;
• use only supplied data;
• stop after a stated amount of work;

follow that instruction.

CraftUp's system is a reasoning framework, not permission to redefine the brief.

If the prompt is ambiguous

Do not invent a private dataset to fill the holes. Instead:

1. state the assumption;
2. explain why it is reasonable enough to proceed;
3. identify what evidence would change it.

That is stronger than hiding the assumption as fact.

2. Time-box the work with an Evidence Budget

If the company gives a working-time limit, treat it like Product capacity. If no working-time boundary is stated, choose one for yourself so research and polish do not become unlimited.

There is no universal “correct” number of hours.

A useful CraftUp practice allocation is percentage-based so it can scale to the time available:

This is a CraftUp practice heuristic, not an employer expectation.

Evidence Budget

Research has value only when it can change a decision or reduce important uncertainty.

Before each research task, answer:

1. What uncertainty am I reducing?
2. What decision does it affect?
3. What result could change direction?
4. What is the stop condition?

Example:

“I need enough product context to understand the collaboration flow and enough evidence to choose among activation hypotheses. I do not need a category market report if the assignment is about first-week invited-user activation.”

Stop researching when the next source repeats what you already know, the next fact cannot change the decision, the key unknown requires internal evidence you do not have, or research is consuming the time reserved for synthesis and defense.

At that point, label the unknown. Do not manufacture certainty.

3. Build an Assumption Ledger

Use evidence classes explicitly:

• Prompt fact — stated in the assignment.
• Public evidence — verifiable external information you actually found.
• Assumption — something you temporarily accept so the case can move.
• Hypothesis — an explanation or product belief to test.
• Derived calculation — optional; use only when the math genuinely follows from known inputs.

Example:

Source strength must match claim strength

Do not turn:

“One public reviewer complains about onboarding.”

into:

“Users struggle with onboarding.”

A public review is a signal, not internal research. The precision of the wording should match the precision of the evidence.

Find the decision-critical assumption

A ledger with nineteen assumptions is not necessarily rigorous. Ask:

Which assumption most controls the recommendation?

For Relay, that might be:

Context, rather than access friction, explains the important post-invite non-activation.

For that assumption, state:

• why it is currently usable;
• what evidence is missing;
• what would invalidate it;
• whether the proposed next step actually reduces the uncertainty.

That connects the Assumption Ledger to the Decision Ledger.

4. Build a Decision Ledger

For every major decision, record:

Decision:
Why this option:
Strongest rejected alternative:
Why it loses now:
Main downside / trade-off:
Reversal condition:

Example:

Decision:
Focus the first iteration on contextual handoff at invitation.

Why this option:
It targets the transition from being invited to knowing the first meaningful action and can be tested inside the existing collaboration flow.

Strongest rejected alternative:
A generic guided onboarding checklist.

Why it loses now:
It teaches the product broadly before establishing what the invitee is actually trying to accomplish.

Main downside:
It adds work for the inviter and may not help if the dominant failure is permissions/access.

Reversal condition:
If funnel data shows most failed invitees never reach shared content because of access/configuration errors, prioritize access reliability instead.

A recommendation that improves everything for everyone is usually hiding a trade-off. Ask:

What gets worse if this recommendation works exactly as designed?

Possible downsides include extra user effort, operational cost, engineering complexity, slower workflow, privacy risk, cannibalization, notification fatigue, fragmentation, or support burden.

Claim → source → decision trace

For every material claim that influences the recommendation, make five things inspectable:

Claim → Evidence class → Source / origin → Confidence limitation → Decision affected

Then attach a reversal condition when the claim is decision-critical.

Example:

This is stronger than counting citations.

Cite external facts when they matter: company/product facts, market facts, competitor capabilities, public evidence. Do not cite your own assumption as if it became true, the recommendation itself, or synthetic exercise facts that the prompt already supplies.

Useful source QA:

• Does this source support this exact claim?
• Is it current enough?
• Is a primary source available?
• Am I overstating what it says?
• Does the fact affect a decision?

Complete worked PM take-home example

Everything below is an illustrative CraftUp practice case.

Relay is fictional. The metrics exist only to make the exercise concrete. They are not company benchmarks, customer outcomes, or market data.

The prompt

You are the Product Manager for Relay, a fictional B2B collaboration product.

In the supplied exercise data, 60% of new workspace admins invite at least one teammate in their first week, but only 35% of invited teammates complete a meaningful collaborative action within seven days.

You have one product/design/engineering squad for one quarter.

Propose a product approach to improve invited-teammate activation.

Prepare up to 7 slides for a 12-minute presentation.

The slide and presentation limits belong to this fictional prompt. They are not universal take-home advice.

Step 1 — Brief Contract

Objective:
Increase the share of invited teammates who reach meaningful collaborative value.

Decision:
Choose the first product intervention to test this quarter.

Constraints:
One squad, one quarter, existing collaboration product, no assumption of major pricing/market changes.

Required output:
Up to 7 slides, 12-minute presentation.

Time boundary:
Use the exercise timebox; reserve explicit time for Q&A preparation.

Material unknowns:
Where invitees fail, which collaborative action predicts repeated value, whether the dominant problem is intent/context/access/product complexity.

Explicitly out of scope:
Market sizing, pricing redesign, enterprise GTM and a complete annual roadmap unless new evidence makes one of them decision-relevant.

Step 2 — Frame the user and failure

Two actors matter:

1. Workspace creator / inviter — has context and wants another person to participate.
2. Invited teammate — arrives inside someone else's workspace and may not know what matters yet.

The supplied metric localizes an interesting failure after invitation, so the first analysis focuses on the invited teammate. That does not prove the inviter is irrelevant; inviter friction remains an important guardrail.

Step 3 — Build a hypothesis tree

Possible mechanisms behind low invited-teammate activation:

• Intent — the invitee did not really need the product.
• Access/configuration — authentication, permission, workspace, or setup friction blocks progress.
• Context — the invitee enters Relay but does not know why they were invited or what to do first.
• Product learning — the intended action is clear but hard to execute.
• Value — the invitee acts once but experiences too little value to continue.

That is stronger than “activation is low, so build onboarding.”

Step 4 — State the evidence you would want

Useful evidence would include:

• invite accepted → workspace opened → relevant object viewed → first collaborative action funnel;
• failures by invite type, workspace maturity, or role if available;
• authentication and permission error rates;
• time from acceptance to first shared-object view;
• recent qualitative evidence from invited teammates;
• what inviters currently communicate outside Relay when inviting someone.

A take-home may not provide these inputs. The rigorous response is to label the missing evidence, not pretend you collected it.

Step 5 — Choose a working hypothesis

For this exercise:

Hypothesis: invited teammates sometimes enter a workspace without enough context to know the first meaningful action expected from them.

Why explore it?

• it sits at the handoff between inviter and invitee;
• it can explain why access exists but meaningful collaboration does not happen;
• it is testable without redesigning the full product;
• it creates distinct alternatives.

Why might it be wrong? Access or permission errors could dominate the funnel.

Step 6 — Generate distinct alternatives

Option A — Generic guided onboarding

Teach main features after invite acceptance.

• Strength: reusable across workflows.
• Weakness: can teach the product before proving what the invitee is trying to do.

Option B — Contextual Handoff

The inviter attaches a reason, shared object, or first action; the invitee lands directly in that context.

• Strength: connects invitation to a real collaborative job.
• Weakness: adds inviter effort and fails if the invite itself is low-intent.

Option C — Reminder cadence

Prompt accepted-but-inactive invitees.

• Strength: cheap to test.
• Weakness: increases prompting without resolving why the user is stuck.

Option D — Workspace starter checklist

Show recommended collaborative actions.

• Strength: creates visible progress.
• Weakness: may become generic task-completion theater.

Step 7 — Make the recommendation

Choose Contextual Handoff as the first direction to validate.

The decision is not the feature name. It is:

Make the invitation carry enough task context that the invitee can enter directly into a meaningful collaborative action.

A first version might let the inviter select the current object/workflow, add lightweight context, land the invitee in that object, make the next relevant action clear, and confirm completion.

Do not combine this with a large onboarding redesign merely to make the submission look comprehensive.

Step 8 — Show the downside

The main downside is inviter friction.

If the inviter must fill six fields, downstream activation could improve while invitations themselves decline. Minimize incremental work with defaults and prefilled context, then measure invite completion/time as a guardrail.

This trade-off belongs in the main artifact.

Step 9 — Define the metric chain

Primary outcome

• % of invited teammates who complete a meaningful collaborative action within seven days.

Diagnostics

• invite acceptance;
• shared-object view after acceptance;
• first collaborative action within 24/48 hours;
• time to first collaborative action;
• activation by invite context or cohort.

Guardrails

• inviter completion rate;
• time to send an invite;
• invitation abandonment;
• notification/spam signals if reminders are involved;
• repeated collaboration so a trivial first click is not mistaken for value.

Decision rule

The next action depends on where the chain moves. If context exposure improves but meaningful action does not, the mechanism is probably incomplete or wrong. If invite friction rises enough to offset activation gains, the design needs simplification rather than a victory declaration.

Every metric earns its place by helping interpret the mechanism or protect against harm.

Step 10 — De-risk before broad rollout

A sensible sequence:

1. inspect existing funnel/error evidence if available;
2. test the context hypothesis with recent inviters/invitees;
3. ship a narrow variant to a limited cohort;
4. compare invitee activation and inviter friction;
5. inspect whether the activated behavior predicts repeated collaboration.

The goal is not an annual roadmap. It is the next evidence-producing product decision.

Step 11 — State the reversal condition

Put the reversal condition in the artifact:

I would change direction if authentication or permission friction explains most non-activation. In that case, access reliability becomes the first intervention and Contextual Handoff moves behind it.

That makes the recommendation falsifiable.

A seven-slide presentation structure

If the employer asks for slides, one illustrative way to turn the Relay reasoning into a concise artifact is seven decision questions. This is not a universal seven-slide rule. Follow the assignment's own format and limits first.

Slide 1 — What should we do?

Answer-first title: Improve invited-user activation by making the invitation a contextual handoff.

Include recommendation, target/outcome, one reason, and what is deliberately out of scope.

Slide 2 — What exactly is the brief?

Include objective, constraints, supplied evidence, material assumptions/unknowns, and any employer-defined time/format boundary.

Slide 3 — Where could failure come from?

Show the smallest useful hypothesis tree and identify which branch you are exploring and why.

Slide 4 — What credible options did we reject?

Compare distinct mechanisms and identify the strongest runner-up. Do not use “do nothing” and “redesign everything” as convenient strawmen.

Slide 5 — What is the Product decision?

Show only the flow, wireframe, PRD excerpt, roadmap sequence, or written interaction needed to make the decision concrete. Mockups should clarify judgment, not substitute for it.

Slide 6 — How do we know if it works?

Show outcome, diagnostics, guardrails, next test, and decision rule.

Slide 7 — What could break the recommendation?

Show major downside, dependency, strongest counterargument, decision-critical assumption, reversal condition, and next evidence.

Main story vs appendix

The main artifact should contain the minimum reasoning needed to evaluate:

• brief;
• recommendation;
• core evidence;
• decision-critical assumption;
• credible alternative;
• trade-off/downside;
• success logic;
• reversal condition.

The appendix can contain:

• deeper source notes;
• discarded ideas;
• sensitivity detail;
• technical notes;
• expanded metric definitions;
• additional mockups;
• supporting calculations.

Use this diagnostic:

If removing the appendix makes the recommendation impossible to evaluate, important reasoning is buried.

Answer-first titles also matter. “Research” is a topic. “The supplied evidence localizes the gap after invitation but does not identify the failure mechanism” is a conclusion. “Solutions” is a topic. “Contextual Handoff targets the working hypothesis more directly than a generic onboarding tour” is a conclusion.

The Defense Surface: prepare the Q&A before you submit

A take-home is not finished when the PDF exports. It is finished when you can defend the surface area of important claims and update the work when the premise changes.

Use a Defense Surface:

Useful challenge classes:

• evidence;
• scope;
• user choice;
• strongest alternative;
• feasibility;
• metric;
• downside;
• strategy;
• new constraint;
• reversal.

Prepare concise reasoning, not memorized rebuttals.

The two-level-deeper test

For every important claim, ask “why?” twice.

Why Contextual Handoff?

Because invitees may lack task context.

Why do you believe context is dominant?

I do not know that it is. It is a falsifiable working hypothesis; the first evidence should compare it against access and intent failures before committing meaningful engineering capacity.

Debrief update test

Suppose the reviewer now gives you a material new fact:

New supplied evidence shows authentication errors explain most failed invitee activation.

Do not defend Contextual Handoff because it is already in your deck.

A stronger response is:

“That evidence directly attacks my dominant problem hypothesis. I would shift the first intervention to access reliability and keep Contextual Handoff as a later hypothesis rather than protecting the original recommendation.”

The goal is to defend the quality of the reasoning, not the identity of the recommendation.

Take-Home Artifact Diagnostic

Use this as a descriptive review. It is not a hiring score, readiness percentage, pass threshold, or reproduction of any employer rubric.

Do not average these states into a total. Use the weakest repeated surface to choose the next repair.

Weak-to-strong artifact repair

Imagine an initial deck with:

• 12 slides;
• four competitor screenshots;
• three market statistics;
• polished mockups;
• no evidence classification;
• no credible alternative;
• nine KPIs;
• recommendation on slide 10;
• the “why” hidden in the appendix;
• AI-generated customer pain points with no source trail.

Repair it in this order:

1. Rewrite the Brief Contract. Cut market work that cannot change the assignment's decision.
2. Relabel unsupported customer claims. Turn them into explicit hypotheses rather than fictional user research.
3. Move the recommendation forward. The artifact should answer before it explains.
4. Add a credible runner-up. Force the recommendation to beat a real alternative.
5. State the downside. Show what becomes worse, more expensive, slower, or riskier.
6. Reduce the metric zoo. Keep one outcome, minimal diagnostics, minimal guardrails, and a decision rule.
7. Move core rationale out of the appendix. Backup should support evaluation, not make evaluation possible.
8. Add a reversal condition. State what evidence changes direction.
9. Audit AI-assisted material. Verify factual claims and reconstruct the judgment independently.
10. Build the Defense Surface. Prepare the hardest evidence, alternative, feasibility, metric and reversal questions.

The transformation is not “make the deck prettier.” It is “make the Product decision inspectable.”

Common PM take-home mistakes

1. Solving a larger problem than the prompt

A candidate sees “activation” and produces a full growth strategy.

Fix: keep the Brief Contract and an explicit out-of-scope list.

2. Research theater

Market stats, competitor screenshots and trend reports never change the recommendation.

Fix: ask what uncertainty and decision each research task affects. If the answer is “none,” cut it.

3. Treating public research as internal truth

A review complains about one workflow, so the deck says “users struggle with X.”

Fix: describe the evidence at its real strength. One review is a signal, not a segment-level fact.

4. Feature-first storytelling

The artifact starts with mockups.

Fix: make the problem mechanism and evidence boundary visible before detailed solution output.

5. Fake numerical precision

The assignment gives no defensible Reach or Impact inputs, but the candidate manufactures a scoring model.

Fix: use qualitative comparison when the evidence does not support arithmetic. Precision is not rigor when the inputs are invented.

6. Strawman alternatives

The recommendation competes with “do nothing” and “rebuild everything.”

Fix: require one credible runner-up that could plausibly win.

7. No downside

The recommendation appears to improve everything.

Fix: state what gets worse if it works exactly as intended.

8. Metric zoo

The final section lists ten KPIs with no decision logic.

Fix: outcome → diagnostics → guardrails → decision rule.

9. Polishing before deciding

Hours go into visual design while the recommendation is still vague.

Fix: write the answer-first summary and Decision Ledger before final visual polish.

10. Hiding critical logic in the appendix

The main artifact says “Option B,” while comparison, assumptions and trade-offs are backup material.

Fix: appendix = inspectable support, not missing reasoning.

11. No debrief update behavior

The candidate can defend the slide but cannot change direction when the premise fails.

Fix: practice new evidence that attacks the decision-critical assumption.

12. Ignoring explicit constraints

The candidate silently exceeds the requested format, data boundary, AI rule, or work-time constraint.

Fix: treat instructions as Product constraints, not suggestions.

Using AI without outsourcing your judgment

First, follow the hiring process's AI rules. If AI use is prohibited or constrained, respect that. Do not assume every employer has the same policy and do not add a disclosure requirement the employer did not request.

When AI is allowed, useful jobs include:

• critique;
• counterarguments;
• editing and compression;
• metric-gaming checks;
• objection generation;
• alternative hypotheses;
• clarity review.

Bad uses include:

• fabricated research or customer voice;
• fabricated data or company facts;
• fabricated citations;
• fabricated RICE inputs;
• decision outsourcing;
• material you cannot explain or reconstruct.

AI Ownership Ledger

For important AI-assisted material, record:

AI / tool assistance used:
Factual source supporting the claim:
Judgment that remained mine:
Logic I can reproduce without generated text:
Unsupported assumption AI may have introduced:
Employer disclosure requirement, if any:

The ownership test

Could you rebuild the logic if the slide disappeared?

If not, you do not own the artifact yet.

An AI detector does not solve this problem. Inspectable sources, assumptions, decisions, and reconstructable reasoning do.

Formats beyond slides

The underlying decision trace stays stable while the requested artifact changes.

Memo / written response

Lead with the recommendation, keep evidence and assumptions near the claims they support, show alternatives/trade-offs, define measures and risks, and keep the reversal condition visible.

PRD / product spec

Do not turn the assignment into a requirements dump. Preserve the product rationale, evidence boundary, chosen alternative, metric logic and unknowns.

Roadmap / prioritization artifact

Preserve objective, constraints, allocation logic, what loses, dependencies, and the evidence that would reorder the plan.

Product critique

Separate observed behavior/public evidence from inferred user problems. Do not convert app reviews into invented internal research.

Strategy document

Make the bet, credible alternative, company-specific constraint/edge, downside, key assumption and reversal explicit.

Do not create a separate framework for every format. Adapt the artifact form to the employer's request while preserving the decision trace.

APM vs PM vs Senior PM

This is CraftUp practice depth, not a universal employer leveling rubric.

APM

Emphasize:

• clear brief;
• honest assumptions;
• simple recommendation;
• basic evidence discipline;
• basic metrics;
• ability to accept correction.

PM

Add:

• stronger alternatives;
• realistic constraints;
• stronger metric reasoning;
• explicit downside;
• experiment/rollout logic;
• reversal condition.

Senior PM

Add system consequences, not more slides:

• organizational dependencies;
• business-model consequences;
• multi-team constraints;
• second-order effects;
• decision mechanisms;
• strategic optionality.

Seniority is not “more screenshots, more research, more diagrams.”

Copyable take-home templates

Brief Contract

# BRIEF CONTRACT

Objective:
Decision to make:
Target user / business context:
Constraints:
Required deliverable:
Time boundary:
What is explicitly out of scope:
Questions that could materially change the direction:

Assumption Ledger

# ASSUMPTION LEDGER

| Statement | Type: prompt fact / public evidence / assumption / hypothesis / derived calculation | Why it matters | What would change it? |
|---|---|---|---|
| | | | |

Decision Ledger

# DECISION LEDGER

Decision:
Why:
Strongest rejected alternative:
Why it loses now:
Main downside:
Reversal condition:

Defense Surface

# DEFENSE SURFACE

| Claim / decision | Hardest challenge | My answer | Evidence / uncertainty | Reversal condition |
|---|---|---|---|---|
| | | | | |

Executive summary

# EXECUTIVE SUMMARY

Problem / opportunity:
Target:
Recommendation:
Why this over the strongest alternative:
Primary outcome:
Main trade-off:
Decision-critical assumption:
What would change my mind:

The interactive Artifact Audit above also provides one integrated PM Take-Home Decision Trace with brief, evidence, assumption, alternatives, decision, measurement, next learning, reversal, artifact QA, defense, and AI/tool ownership fields.

These are preparation artifacts. Do not force every employer submission to literally use these labels.

CraftUp tool stack for take-home assignments

Use a tool only when its output earns a place in the actual decision.

Problem framing

Problem Statement Generator — useful when the problem statement contains the solution or misses the user/context/outcome.

Research plan

Interview Script Generator — useful when the assignment asks what research you would run next. A generated script is not evidence that interviews occurred.

Prioritization

RICE Score Calculator — useful only when Reach, Impact, Confidence, and Effort inputs are meaningfully comparable. If the inputs are speculative, use the PM Prioritization Interview guide to make the judgment explicit instead.

Metrics

KPI Tree Builder — useful when metric decomposition helps expose the product mechanism and diagnostics. Do not add a decorative tree.

PRD

PRD Generator — useful when requirements clarity is part of the requested artifact. It is not automatically useful for a market strategy take-home.

User stories

User Story Generator — useful when execution detail matters after the main decision is clear.

Strategy

Product Strategy One-Pager — useful when the assignment is fundamentally a market/company/product bet.

Stakeholders

Stakeholder Map Builder — useful when the recommendation depends on incentives or sequencing across teams.

Again: tool output is not the decision.

Scope, confidentiality, and take-home boundaries

Avoid unbounded free-consulting scope

Take-homes vary widely, and a demanding assignment is not automatically improper. Reasonable questions to clarify when scope feels disproportionate include:

• What effort is expected?
• What is the intended evaluation scope?
• Is the requested output an assessment artifact or production-ready work?
• Are additional rounds of uncompensated work expected?
• Is there a clear time boundary?
• Does the assignment ask for proprietary information or unusual IP transfer?

If you are uncomfortable with the scope, ask the recruiter or hiring manager to clarify it. This is practical interview guidance, not legal advice.

Protect former-employer confidential information

Do not expose a former employer's private roadmap, customer data, internal research, confidential metrics, or proprietary deck merely to make a take-home look credible.

Use sanitized examples, public information, synthetic examples, or a description of your method instead.

This is also why a take-home and a Product Manager Portfolio have different jobs:

• Portfolio — persistent evidence of past Product judgment, with confidentiality handled appropriately.
• Take-home — prompt-specific hiring artifact created under a bounded assignment and later defended.

Do not turn every take-home into a portfolio project, and do not copy protected prior work into a hiring exercise.

Final submission checklist

Brief

• [ ] I can state the exact decision in one sentence.
• [ ] I followed the employer's actual format, data, research, AI, and time constraints.
• [ ] I have an explicit out-of-scope boundary.
• [ ] Every major section earns its place against the Brief Contract.

Evidence

• [ ] Prompt facts, public evidence, assumptions, hypotheses, and derived calculations are distinguishable.
• [ ] Important external claims have defensible sources where appropriate.
• [ ] Source strength matches claim strength.
• [ ] I removed research that does not affect a decision.
• [ ] I did not fabricate quotes, metrics, company facts, market evidence, or citations.

Decision

• [ ] The recommendation is obvious early in the artifact.
• [ ] I considered at least one genuinely credible alternative.
• [ ] I state why the strongest alternative loses now.
• [ ] I state the main downside of my recommendation.
• [ ] I identify the decision-critical assumption.
• [ ] I state what evidence would reverse the recommendation.

Metrics

• [ ] One primary outcome matches the objective.
• [ ] Diagnostics explain movement through the proposed mechanism.
• [ ] Guardrails expose predictable harm or gaming.
• [ ] A decision rule says what result changes the next action.

Artifact

• [ ] The first slide/page gives the answer instead of a suspenseful setup.
• [ ] Major titles communicate conclusions, not only topics.
• [ ] The artifact makes sense without narration.
• [ ] Essential reasoning remains in the main story.
• [ ] The appendix provides inspectable support rather than missing logic.
• [ ] Visual polish improves comprehension rather than compensating for weak reasoning.

Defense

• [ ] I can answer two levels deeper than each important claim.
• [ ] I can explain the strongest rejected alternative and the weakest assumption.
• [ ] I can explain what I would do after a neutral or negative result.
• [ ] I can update the recommendation if new evidence invalidates the problem hypothesis.
• [ ] I can say what additional evidence has the highest decision value rather than promising generic “more research.”

AI / tools

• [ ] I followed the hiring process's explicit AI/tool rules.
• [ ] I can reconstruct everything AI helped create.
• [ ] Material factual claims have independent support.
• [ ] I checked whether AI introduced unsupported assumptions.
• [ ] I followed any disclosure requirement actually stated by the employer.

No final numeric score is needed. The purpose of the QA is to expose fragile surfaces before submission.

What to practice next

Choose the next route based on what the audit exposed:

• Weak live ambiguous-case reasoning → PM Case Study Interview.
• Weak user/problem reasoning → Product Sense Interview.
• Weak allocation or trade-off logic → PM Prioritization Interview.
• Weak metric chain → PM Metrics Interview.
• Weak strategic bet → Product Strategy Interview.
• Weak diagnosis under changed evidence → Product Execution Interview.
• Need historical proof of past Product judgment → Product Manager Portfolio.
• Need broad PM interview preparation → Product Manager Interview Guide.
• Need question breadth → Product Manager Interview Question Bank.
• Artifact is coherent; debrief is weak → practice live follow-up pressure in the PM Interview Simulator using the supported underlying mode that matches the weakness.

The Simulator does not have a Take-Home mode. It supports live practice for its actual interview modes.

FAQ

What should a product manager take-home assignment include?

Follow the prompt first. In general, the reader should be able to inspect the objective, constraints, evidence, assumptions, user/problem, credible alternatives, recommendation, downside, measurement, risk, and reversal condition. Do not add sections merely because a template contains them.

How many slides should a PM take-home presentation have?

Use the assignment's stated limit if one exists. If it does not, optimize for the decisions you must communicate and the presentation context. The seven-slide Relay structure here is an illustrative practice pattern, not a universal rule.

How long should I spend on a PM take-home assignment?

Respect any working-time guidance from the company. If none is provided, choose an explicit personal timebox so research and polish do not expand indefinitely. CraftUp does not know a universal “correct” number of hours.

Should I include wireframes?

Only if they clarify the Product decision at the fidelity the prompt requires. A simple flow can be more useful than polished screens when the real question is problem framing, strategy, prioritization, or metrics.

Should I build a PRD for a take-home?

Only when the prompt asks for one or a concise PRD is the clearest artifact for the decision. Do not let requirements detail replace the recommendation, alternatives, evidence boundary, trade-offs, and success logic.

Should I use RICE in a PM take-home?

Use RICE when the inputs are meaningfully comparable and defensible. If Reach or Impact is invented, qualitative trade-off reasoning is more rigorous than a precise-looking fake ranking.

What should I put in the appendix?

Put deeper sources, expanded analysis, discarded concepts, metric definitions, technical notes, sensitivity checks, calculations, or additional screens there. Keep the minimum logic required to evaluate the recommendation in the main artifact.

How should I prepare for the take-home presentation Q&A?

Build a Defense Surface for important claims and decisions. Practice evidence, scope, user-choice, alternative, feasibility, metric, downside, strategy, new-constraint, and reversal challenges. Practice updating the decision when new evidence changes the premise rather than memorizing rebuttals.

Can I use AI for a PM take-home assignment?

Follow the employer's instructions first. If AI is allowed, use it as an editor, critic, counterargument generator, or rehearsal partner. Verify factual claims independently and do not submit reasoning you cannot reconstruct and defend.

What if I do not have enough data to make the recommendation?

State what is known, classify the missing evidence honestly, identify the decision-critical assumption, choose a working hypothesis when necessary, and make the next evidence-producing step part of the recommendation. The goal is disciplined decision-making under uncertainty, not false certainty.