Product Manager Take-Home Assignment: Example, Rubric & Presentation

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 assumptions, alternatives, trade-offs, metrics, and risks are easy to challenge.
• Start by rewriting the prompt into a Brief Contract: objective, decision, constraints, required output, time boundary, and open questions. Solve that contract, not the much larger problem you wish the company had asked.
• Keep an Assumption Ledger that separates prompt facts, public evidence, assumptions, and what each assumption changes. Never turn desk research into fictional customer evidence.
• Keep a Decision Ledger for the few choices that matter: what you chose, what lost, why, the main downside, and what evidence would reverse the choice.
• Treat every major recommendation as part of a Defense Surface. Before submitting, write the hardest follow-up question someone could ask about it and answer that question without reopening your deck.
• If a recruiter gives a time limit, treat it as a product constraint. Do not silently turn a four-hour exercise into a twelve-hour design project.
• Use CraftUp tools to express reasoning — PRD Generator, User Story Generator, KPI Tree Builder, RICE Score Calculator — only when the artifact genuinely benefits from them. The tool is never the decision.

Table of contents

• What a PM take-home assignment is actually testing
• Take-home vs live case interview
• 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
• Complete worked PM take-home example
• A seven-slide presentation structure
• The Defense Surface: prepare the Q&A before you submit
• CraftUp take-home evaluation rubric
• Weak vs strong take-home work
• Common PM take-home mistakes
• Using AI without outsourcing your judgment
• APM vs PM vs Senior PM
• Copyable take-home templates
• CraftUp tool stack for take-home assignments
• Final submission checklist
• 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.

That makes the artifact itself useful, but it also exposes different failure modes.

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 show ten reasonable ideas and avoid choosing one.

You can produce a document that reads well but collapses as soon as someone asks, “Why this user?”, “Why this metric?”, or “What would make you change your mind?”

A strong take-home usually makes seven things visible:

1. Scope discipline — you solve the assignment that was actually given.
2. Evidence integrity — the reader can distinguish facts, external evidence, assumptions, and hypotheses.
3. Problem framing — you identify a decision-worthy user or business problem rather than jumping to features.
4. Product judgment — you compare credible alternatives and commit to a recommendation.
5. Measurement — you connect the recommendation to an outcome, diagnostics, guardrails, and a learning plan.
6. Artifact clarity — the document or deck communicates the decision without requiring a live narration to become understandable.
7. Defense readiness — you can explain why the recommendation wins, what it sacrifices, and what evidence would reverse it.

This guide uses a CraftUp practice system, not a claim about any company's internal hiring rubric.

If you need the broader interview map first, start with the Product Manager Interview Guide. If your problem is structuring an ambiguous case live, use the PM Case Study Interview guide.

Take-home vs live case interview

The underlying product reasoning overlaps, but the operating constraints are different.

| Live case interview | Take-home assignment | |---|---| | Reasoning happens in conversation | Reasoning must survive asynchronously | | Interviewer can clarify the brief immediately | You may need to state assumptions explicitly | | Limited time naturally prevents over-research | You must impose your own research boundary | | Communication is mostly verbal | Artifact structure becomes part of the signal | | Follow-ups happen during the answer | Follow-ups often arrive after the artifact is submitted | | Recovery is visible in real time | Your debrief must reveal how you would update the work |

The mistake is treating a take-home as “the same case, but with prettier slides.”

A take-home adds two PM skills of its own:

• resource allocation — how you spend scarce preparation time;
• artifact architecture — how you make the important decisions legible to someone reading alone.

1. Rewrite the prompt as a Brief Contract

Before opening slides, write a six-line contract with yourself.

# BRIEF CONTRACT

Objective:
Decision I need to make:
Constraints / boundaries:
Required deliverable:
Time budget:
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 the pricing model, designing eight screens, and writing a rollout plan for three countries.

The Brief Contract creates a boundary you can test every section against:

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

A useful Brief Contract distinguishes four things

Objective

What outcome is the exercise asking you to improve or decide?

Decision

What recommendation must exist at the end?

“Analyze onboarding” is not a decision.

“Choose the first product intervention to improve invited-user activation” is.

Constraints

What is fixed?

Examples:

• one quarter;
• one team;
• existing market only;
• no pricing change;
• mobile only;
• no new operational headcount;
• specific slide count;
• specific presentation duration.

Open questions

Write only questions whose answers could change the recommendation.

A useful clarifying question is not “What is the exact DAU?” unless DAU changes the decision.

If the prompt is ambiguous

Do not invent a complete private dataset.

Instead:

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

That pattern is far stronger than quietly treating the assumption as fact.

2. Time-box the work with an Evidence Budget

If the company gives a time limit, use it.

If no working-time limit is provided, choose one for yourself and state it if useful. The purpose is not to guess the “correct” number of hours. It is to prevent the exercise from becoming an unbounded consulting project.

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

| Work | Practice allocation | |---|---:| | Brief Contract + plan | 10% | | Evidence / research | 20% | | Problem framing + alternatives | 20% | | Artifact draft | 25% | | Defense / rehearsal | 15% | | Final QA + buffer | 10% |

This is a practice heuristic, not an employer expectation.

The important design choice is that research does not get unlimited time, and neither does slide polish.

Evidence Budget

Before researching, decide what evidence could change your answer.

Example:

“I need enough product context to understand the collaboration flow, enough company context to avoid a strategically absurd recommendation, and enough evidence to choose among three activation hypotheses. I do not need a market report if the assignment is about first-week product activation.”

Now research has a stop condition.

Good stop conditions

Stop researching when:

• another source repeats what you already know;
• the next fact is interesting but would not change the decision;
• your biggest uncertainty can only be resolved with internal data or user research you do not have;
• research time is starting to consume the time reserved for synthesis and defense.

The right move at that point is to label the unknown, not fabricate certainty.

3. Build an Assumption Ledger

A take-home becomes much more credible when the reader can tell what kind of statement they are looking at.

Use four labels:

• Prompt fact — explicitly provided in the assignment.
• Public evidence — verifiable external information you actually found.
• Assumption — something you need to believe temporarily to proceed.
• Hypothesis — an explanation or product belief you would test.

Use a simple ledger:

| Statement | Type | Why it matters | What would change it? | |---|---|---|---| | Invited users activate less often than workspace creators | Prompt fact | Focuses the problem after invitation | Better funnel segmentation | | Teams use the product collaboratively | Public evidence / prompt context | Makes shared workflow relevant | Product docs contradict this | | Invitees often lack context for why they were invited | Hypothesis | Supports contextual handoff direction | Funnel/qual evidence points to access friction instead | | One squad can modify invite + landing flow this quarter | Assumption | Defines feasible solution space | Engineering constraints |

Why this matters

Without the ledger, a deck often evolves like this:

“Users are confused when they receive an invite.”

Where did that come from?

Maybe it is true.

Maybe it came from one App Store review.

Maybe an AI assistant generated it.

Maybe you inferred it from the prompt.

Those are very different evidence levels.

The Assumption Ledger does not make your work weaker. It makes the uncertainty inspectable.

Never manufacture customer voice

Do not write fake quotes such as:

“I never know what my manager wants me to do after inviting me.”

unless you actually collected and can appropriately use that quote.

If you need to communicate the hypothesis, write:

“Hypothesis: invitees may lack task context when they first enter the shared workspace. I would validate this with invite-to-first-action funnel data and recent invitee interviews.”

That is rigorous and honest.

4. Build a Decision Ledger

The Assumption Ledger tracks what you believe.

The Decision Ledger tracks what you chose.

For every major decision, record five things:

Decision:
Why this option:
Strongest rejected alternative:
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.

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.

That final field — reversal condition — is especially powerful.

It proves that your recommendation is a decision under current evidence, not a personal identity you need to defend forever.

Complete worked PM take-home example

Everything below is an illustrative CraftUp practice case.

Relay is a fictional product. The metrics are invented solely 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.

Again: the numbers above exist only inside this practice prompt.

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 best predicts repeated value, whether the problem is intent/context/access/product complexity.

Notice what is not in scope yet:

• rebuilding the entire onboarding system;
• a new enterprise strategy;
• market sizing;
• a complete technical architecture;
• redesigning every collaborative workflow.

Step 2 — Frame the user and failure

There are at least two important actors:

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 suggests the interesting failure occurs after invitation, so I would focus the first analysis on the invited teammate.

That does not prove the inviter is irrelevant. It simply puts the first diagnostic boundary in the right place.

Step 3 — Build a hypothesis tree

Possible mechanisms behind low invited-teammate activation:

A. Intent problem

The invitee did not really need the product; the inviter added them speculatively.

B. Access/configuration problem

The invitee hits authentication, permission, workspace, or setup friction.

C. Context problem

The invitee gets into Relay but does not understand why they were invited or what to do first.

D. Product-learning problem

The relevant action is clear, but the interface is too difficult to learn.

E. Value problem

The invitee completes an action but does not experience enough value to continue.

This is already better than saying:

“Activation is low, so let's build onboarding.”

Step 4 — State what evidence you would want

Before choosing a solution, I would want:

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

Because this is a take-home, I may not have those inputs.

So I would label the next move as a hypothesis, not pretend I ran research.

Step 5 — Choose a working hypothesis

For the exercise, I will explore:

Invited teammates often enter a workspace without enough context to know the first meaningful action expected from them.

Why explore this one first?

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

Why might this be wrong?

If access or permission errors dominate the funnel, the solution direction should change immediately.

Step 6 — Generate distinct alternatives

Option A — Generic guided onboarding

Teach the main features after invite acceptance.

Pros:

• low dependency on inviter behavior;
• reusable across many workflows.

Cons:

• teaches the product before proving what the invitee is trying to accomplish;
• may optimize product knowledge instead of collaboration.

Option B — Contextual Handoff

When inviting a teammate, the inviter attaches a short reason / shared object / first action. On arrival, Relay opens directly into that context.

Pros:

• connects invitation to a real collaborative job;
• makes the first action explicit;
• can use existing shared objects rather than inventing a new workflow.

Cons:

• adds inviter effort;
• fails if the invite itself was low intent;
• requires careful defaults so invitations do not become forms.

Option C — Reminder cadence

Send reminders to invitees who accept but do not act.

Pros:

• cheap to test;
• does not require large UI changes.

Cons:

• increases prompting without resolving why the user is stuck;
• can create notification fatigue.

Option D — Workspace starter checklist

Show a checklist of recommended collaborative actions.

Pros:

• creates visible progress;
• can guide users through multiple features.

Cons:

• can become generic task completion theater;
• may not represent the specific reason the user was invited.

Step 7 — Make the recommendation

I would choose Contextual Handoff as the first product direction to validate.

The important part is not the feature name.

The decision is:

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

Possible first-version elements:

• inviter selects the shared object or workflow the teammate should enter;
• optional short context such as “Review this launch brief” or “Add your estimate here”;
• invitee lands directly in that object;
• the first relevant action is visually clear;
• Relay confirms when the requested collaboration is complete.

I would deliberately avoid building a large onboarding tour in the same iteration.

Step 8 — Show the trade-off

The main cost is inviter friction.

If the inviter has to fill six fields before inviting a teammate, we can improve downstream activation while damaging invitations themselves.

So the product design must minimize incremental work:

• infer the current object automatically;
• offer a lightweight default first action;
• keep context optional where intent is already obvious;
• measure whether invite completion drops.

That trade-off belongs in the main story, not hidden in an appendix.

Step 9 — Define success

Primary outcome:

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

That is directly tied to the prompt, but we still need to define “meaningful collaborative action” carefully.

Leading / diagnostic metrics:

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

Guardrails:

• inviter completion rate for the invite flow;
• time to send an invite;
• invitation cancellation / abandonment;
• notification unsubscribe or spam signals if reminders are involved;
• downstream retained collaboration, so we do not optimize a trivial first click.

Step 10 — De-risk before broad rollout

A sensible sequence:

1. Validate the context hypothesis with existing funnel/error data if available.
2. Test a lightweight prototype with recent inviters and invitees.
3. Ship a narrow contextual-handoff variant to a limited cohort.
4. Compare invited-user activation and inviter friction.
5. Inspect whether the activated behavior leads to repeated collaboration.

The point is not to produce a complete annual roadmap.

The point is to show the next evidence-producing product decision.

Step 11 — State the reversal condition

I would put this directly in the take-home:

I would change direction if the dominant failure happens before invitees can access or understand the shared object — for example, if authentication/permission friction explains most non-activation. In that case, access reliability becomes the first intervention and Contextual Handoff moves behind it.

That sentence makes the recommendation much more defensible.

A seven-slide presentation structure

If the prompt asks for slides, make each slide answer a decision question, not merely name a topic.

Slide 1 — What should we do?

Title: Improve invited-user activation by making the invitation a contextual handoff

Include:

• one-sentence recommendation;
• target user / outcome;
• why this problem matters;
• one sentence on what you are deliberately not solving.

The first slide should let a reader understand the answer even if they stop there.

Slide 2 — What exactly is the brief?

Include:

• objective;
• constraints;
• supplied evidence;
• key assumptions / unknowns.

Do not spend half the deck rewriting the prompt.

Slide 3 — Where could the failure come from?

Show the smallest useful hypothesis tree.

For Relay:

• intent;
• access;
• context;
• learning;
• value.

Then say which branch you are exploring and why.

Slide 4 — What options did we reject?

Compare 3–4 distinct mechanisms.

Show:

• option;
• why it could work;
• why it loses right now.

A take-home becomes much stronger when the recommendation visibly defeated credible alternatives.

Slide 5 — What is the product decision?

Show the chosen experience at the level required by the prompt.

This could be:

• a flow;
• a lightweight wireframe;
• a PRD excerpt;
• a roadmap sequence;
• a service blueprint;
• a written interaction.

Do not build detailed UI simply because you have design software.

Slide 6 — How do we know if it works?

Include:

• primary outcome;
• diagnostics;
• guardrails;
• test / rollout;
• riskiest assumption.

Slide 7 — What could break the recommendation?

Include:

• major risks;
• dependencies;
• strongest counterargument;
• reversal condition;
• what you would learn next with more time/data.

This slide naturally opens the debrief.

Appendix

Use the appendix for evidence someone may reasonably ask to inspect but does not need in the main decision story:

• additional research notes;
• deeper metric definitions;
• discarded concepts;
• technical considerations;
• source list;
• detailed wireframes;
• sensitivity analysis.

Do not use the appendix as a graveyard for reasoning that should have been in the main deck.

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.

Create a Defense Surface table:

| Decision / claim | Hardest likely challenge | Your answer | Evidence / uncertainty | Reversal condition | |---|---|---|---|---| | Focus invitees | Why not fix inviter behavior first? | Prompt shows a large post-invite activation gap; inviter behavior remains a guardrail | Need segmented funnel | If low-intent invites dominate, shift upstream | | Context is the working hypothesis | What evidence proves that? | None yet; it is explicitly a hypothesis chosen for exploration | Need funnel + qual | Access failures dominate | | Contextual Handoff | Won't this add inviter friction? | Yes; defaults and prefilled context are part of the design | Measure invite completion/time | Invite friction offsets activation gain | | 7-day activation | Could this reward trivial actions? | Define the action as collaborative value, not any click | Need retention correlation | Metric does not predict repeat collaboration | | One-quarter test | Why not redesign onboarding? | Narrow intervention gives faster causal learning and lower scope | Depends on product architecture | Evidence shows broad learning friction |

The two-level-deeper test

For every key slide, ask yourself “why?” twice.

Example:

Why Contextual Handoff?

Because invited users may lack task context.

Why do you believe context is the dominant issue?

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

That is a much stronger answer than trying to make uncertainty disappear.

Practice hostile follow-ups

Ask:

• What if the opposite assumption is true?
• What if you lose half the engineering capacity?
• Why this user and not the other actor?
• Why this metric and not retention/revenue?
• What did you explicitly decide not to research?
• What would your engineering lead dislike about this plan?
• What would your designer dislike?
• Which part of the recommendation is least supported?
• What if the experiment is neutral?
• What would make you ship anyway?
• What would make you stop immediately?

The goal is not to memorize answers. It is to expose where your reasoning is currently fragile.

CraftUp take-home evaluation rubric

This is a CraftUp practice rubric, not a claim about any employer's internal scorecard.

Score each dimension 0–3:

• 0 — Missing: the work does not address the dimension.
• 1 — Weak: present, but generic, unsupported, or disconnected.
• 2 — Solid: coherent and useful, with explicit reasoning.
• 3 — Strong: specific, decision-oriented, honest about uncertainty, and resilient under challenge.

| Dimension | 0 | 1 | 2 | 3 | |---|---|---|---|---| | Brief fit / scope | Solves a different problem | Restates prompt but scope sprawls | Clear objective and boundary | Ruthless scope discipline; every section earns its place | | Evidence integrity | Invented or unlabeled claims | Assumptions presented ambiguously | Facts / evidence / assumptions separated | Evidence quality changes the recommendation and uncertainty is explicit | | Problem framing | Feature-first | Broad user problem | Specific user / mechanism / outcome | Framing exposes competing hypotheses and what would distinguish them | | Decision quality | No recommendation | Recommendation with little comparison | Credible alternatives + choice | Strongest rejected option, downside, sequencing, and reversal condition are explicit | | Measurement / de-risking | No success definition | Metric list | Outcome + diagnostics + guardrails | Metrics connect to causal mechanism, experiment, and next decision | | Artifact clarity | Hard to follow | Topic-based deck with heavy narration dependency | Clear answer-first story | Each section answers a decision question; appendix supports rather than hides logic | | Defense readiness | Cannot explain choices | Repeats slide content | Handles normal follow-ups | Can update coherently when assumptions, evidence, scope, or constraints change |

Maximum: 21 points.

Do not convert this into a “hire/no-hire” threshold.

Use it to identify the bottleneck.

Illustrative score for the Relay worked case

• Brief fit / scope: 3/3
• Evidence integrity: 3/3
• Problem framing: 2/3 — the dominant mechanism is still hypothetical because no real funnel/user evidence was provided.
• Decision quality: 3/3
• Measurement / de-risking: 3/3
• Artifact clarity: 3/3
• Defense readiness: 3/3

20/21 for the structure of the illustrative answer.

That score does not mean the Contextual Handoff recommendation is objectively correct. The lower evidence/framing certainty is the point: a real team would need data before deciding the hypothesis is true.

Weak vs strong take-home work

Executive summary

Weak

“I analyzed the onboarding experience and identified several opportunities to improve collaboration.”

Stronger

“I would first test a contextual invite handoff for invited teammates because the supplied activation gap occurs after invitation; I would abandon that direction if access/permission friction explains most failures.”

The second version contains a decision and a reversal condition.

Research

Weak

“Users want more personalized onboarding.”

Stronger

“Public product context suggests multiple collaboration workflows, but I do not have direct user evidence for the failure mechanism. My working hypothesis is missing invite context; I would test it against access and intent failures before implementation.”

The strong version does not cosplay internal research.

Prioritization

Weak

“I used RICE and Contextual Handoff scored 742, so it wins.”

Stronger

“The options are not precise enough for a meaningful numerical RICE ranking. I compared them on directness to the hypothesized failure, implementation scope, inviter friction, and time to learn. I would use RICE only if Reach/Impact/Confidence/Effort inputs are genuinely comparable.”

For deeper practice, use the PM Prioritization Interview guide.

Product concept

Weak

Eight polished screens with no explanation of which decision each screen supports.

Stronger

One flow showing how context moves from inviter → invitation → shared object → first collaborative action, with the main design trade-off called out.

Metrics

Weak

DAU, MAU, NPS, retention, revenue, invitations, engagement.

Stronger

Primary: invited-user meaningful collaboration within seven days. Diagnostics: acceptance → object view → first action. Guardrails: invite completion/time and downstream repeated collaboration.

“More time” slide

Weak

“With more time I would do more user research, improve the designs, and build a roadmap.”

Stronger

“The biggest unresolved question is whether non-activation is context or access. My first additional work would be to segment the invite funnel and interview recent invitees from the two largest failure points. That evidence could reverse the product direction.”

Common PM take-home mistakes

1. Solving a larger problem than the prompt

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

Fix: write the Brief Contract and keep one explicit “out of scope” list.

2. Research theater

The deck contains market statistics, competitor screenshots, trend reports, and review quotes that never change the recommendation.

Fix: every research input must answer: what decision did this evidence change?

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 deck starts with mockups.

Fix: make the first product slide explain the user/problem mechanism and why the feature follows.

5. Fake numerical precision

The assignment gives no reliable Reach or Impact inputs, but the candidate builds a sophisticated scoring model anyway.

Fix: use qualitative comparison when the inputs do not support math. Precision is not rigor if the numbers are invented.

6. No losing option

Every idea is “important.”

Fix: name the strongest rejected alternative and why it loses now.

7. No downside

The recommendation appears to improve everything for everyone.

Fix: state the cost. Additional inviter effort? Engineering complexity? User confusion? Revenue cannibalization? Slower learning?

8. Metric zoo

The final slide lists ten KPIs.

Fix: start with one primary outcome, then add only diagnostics and guardrails that help interpret it.

9. Polishing before deciding

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

Fix: write the one-sentence recommendation and Decision Ledger before opening the final presentation format.

10. Hiding critical logic in the appendix

The main deck says “we chose option B,” while the comparison and evidence are buried in backup slides.

Fix: the main story must stand alone. Appendix = inspectable support, not missing reasoning.

11. No debrief preparation

The artifact is polished but the candidate has never said the recommendation aloud.

Fix: rehearse the presentation and the Defense Surface separately.

12. Ignoring the time constraint

If the exercise gives a working-time boundary, exceeding it massively can produce an artifact that is impossible to compare fairly and signals weak scope discipline.

Fix: treat the time limit like product capacity.

Using AI without outsourcing your judgment

First, follow the instructions of the hiring process. If AI use is prohibited or constrained, respect that policy.

When AI is allowed, the useful distinction is:

Use AI to improve the artifact; do not let AI become the hidden owner of the decision.

Useful AI jobs:

• critique whether your recommendation actually follows from your evidence;
• generate counterarguments you may have missed;
• compress a slide without removing the trade-off;
• identify undefined terms;
• test whether your metric can be gamed;
• role-play Engineering / Design / Sales objections;
• proofread structure and clarity;
• generate alternative hypotheses for you to evaluate.

Bad AI jobs:

• invent customer research;
• invent market/company facts;
• invent citations;
• choose a target segment because “it sounds strategic”;
• generate precise RICE inputs from nowhere;
• write a recommendation you cannot reconstruct independently;
• produce a deck you have not read closely enough to defend.

The ownership test

For every slide, ask:

“If someone removes the slide and asks me to rebuild the reasoning from memory, can I?”

If not, you do not own the work yet.

The one-level-deeper test

Take any AI-assisted claim and ask one deeper question.

Why this metric?

Why this segment?

Why not the alternative?

What evidence supports this assumption?

What would reverse the decision?

If you need the model to answer those questions for you after submission, the take-home is fragile.

APM vs PM vs Senior PM

This is a CraftUp practice lens, not a universal leveling rubric.

APM

Strong signal:

• clear structure;
• honest assumptions;
• sensible user/problem selection;
• explicit recommendation;
• simple metrics;
• learning orientation;
• good response to feedback.

Do not inflate scope to appear senior.

PM

Add:

• better alternative comparison;
• stronger prioritization;
• realistic execution constraints;
• guardrails;
• clear trade-offs;
• experiment/rollout logic;
• a defensible reversal condition.

Senior PM

Add system consequences, not more slides.

Examples:

• organizational dependencies;
• platform implications;
• incentive conflicts;
• business-model consequences;
• sequencing across teams;
• second-order effects;
• when a local product win harms the broader system;
• what decision mechanism should persist after the immediate project.

A Senior PM take-home should not simply contain more research and more diagrams.

It should demonstrate a richer decision surface while remaining concise.

Copyable take-home templates

Brief Contract

# BRIEF CONTRACT

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

Assumption Ledger

# ASSUMPTION LEDGER

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

Decision Ledger

# DECISION LEDGER

## Decision 1
Choice:
Why:
Strongest rejected alternative:
Main downside:
Reversal condition:

## Decision 2
Choice:
Why:
Strongest rejected alternative:
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:
Biggest assumption:
What would change my mind:

CraftUp tool stack for take-home assignments

Use tools only when the prompt needs the artifact they produce.

Problem framing

Problem Statement Generator

Useful when your problem statement still contains the solution or does not name the user/context/outcome.

Research plan

Interview Script Generator

Useful when the take-home asks what research you would run next. Do not pretend you ran interviews simply because you generated a script.

Prioritization

RICE Score Calculator

Useful when options have comparable inputs. If the inputs are speculative, use the PM Prioritization Interview guide to make the judgment explicit instead.

Metrics

KPI Tree Builder

Useful when you need to show how an outcome decomposes into product mechanisms and diagnostic signals.

PRD artifact

PRD Generator

Useful if the prompt explicitly asks for a written product requirements artifact or if a concise PRD appendix makes the recommendation more concrete.

Do not turn every take-home into a full PRD.

User stories

User Story Generator

Useful for translating the chosen workflow into implementation-ready user value after the main decision is clear. This is now part of the Get Hired take-home workflow, not a substitute for the strategic/product reasoning.

Strategy

Product Strategy One-Pager

Useful when the take-home is fundamentally a market/company/product bet rather than a feature-design exercise.

Stakeholders

Stakeholder Map Builder

Useful when the recommendation depends on incentives or sequencing across Sales, Engineering, Design, Operations, Legal, or another team.

Final submission checklist

Before you submit, check the artifact in this order.

Brief

• [ ] I can state the exact decision in one sentence.
• [ ] I followed the requested format and scope.
• [ ] I have an explicit out-of-scope boundary.
• [ ] I did not quietly invent constraints or data.

Evidence

• [ ] Prompt facts, public evidence, assumptions, and hypotheses are distinguishable.
• [ ] Every important external fact has a trustworthy source in my working notes / artifact where appropriate.
• [ ] I removed research that does not affect a decision.
• [ ] I did not fabricate user quotes, metrics, company facts, or market evidence.

Product judgment

• [ ] I chose a target user/problem rather than designing for everyone.
• [ ] I considered at least one genuinely credible alternative.
• [ ] I state why that alternative loses now.
• [ ] I state the main downside of my recommendation.
• [ ] I state what evidence would reverse the recommendation.

Measurement

• [ ] There is one clear primary outcome.
• [ ] Diagnostic metrics explain movement rather than decorate the slide.
• [ ] Guardrails protect against predictable gaming or harm.
• [ ] The next test produces evidence for a future decision.

Artifact

• [ ] The first slide/page contains the answer, not a suspenseful setup.
• [ ] Each major section answers a decision question.
• [ ] The artifact makes sense without narration.
• [ ] The appendix supports the main story instead of hiding it.
• [ ] Visual polish improves comprehension rather than compensating for weak reasoning.

Defense

• [ ] I rehearsed the presentation within the actual time limit.
• [ ] I can answer “why not the strongest alternative?”
• [ ] I can explain the weakest assumption honestly.
• [ ] I can say what I would do if the result is neutral/negative.
• [ ] I can update the recommendation if the interviewer changes a constraint.
• [ ] I can explain what I would do with more time without saying “more research” generically.

What to practice next

• Your artifact lacks a decision chain → PM Case Study Interview.
• You jump to features → Product Sense Interview.
• You cannot choose between plausible bets → PM Prioritization Interview.
• Your metrics are generic → PM Metrics Interview.
• The assignment is strategic → Product Strategy Interview.
• You have a good deck but weak Q&A → rehearse the debrief with the Mock Product Manager Interview guide.
• You need real proof-of-work practice → build a Product Manager Portfolio project.

FAQ

What should a product manager take-home assignment include?

Follow the prompt first. In general, a strong artifact makes the objective, assumptions, user/problem, alternatives, recommendation, trade-offs, measurement, risks, and next learning step easy to inspect. Do not add sections simply 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 time you have to present and the number of decisions you need to communicate. The seven-slide structure in this guide is a useful 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. Scope discipline is part of the exercise.

Should I include wireframes?

Only if they clarify the product decision. A simple flow can be more valuable than polished screens if the main question is about problem framing, strategy, prioritization, or metrics. If the prompt explicitly asks for product design detail, increase the fidelity appropriately.

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. A PRD should not replace the executive recommendation, alternatives, trade-offs, and success definition.

Should I use RICE in a PM take-home?

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

What should I put in the appendix?

Put inspectable support there: sources, deeper analysis, alternative concepts, metric definitions, technical notes, sensitivity checks, or additional screens. Keep the essential decision logic in the main artifact.

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

Build a Defense Surface for every major recommendation. Practice the strongest counterargument, the main downside, the weakest assumption, the rejected alternative, and the evidence that would change your mind. Then rehearse with interruptions rather than only repeating a perfect presentation.

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. Do not use it to fabricate evidence, citations, user research, company facts, or product metrics, and do not submit reasoning you cannot independently defend.

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

You usually will not have internal-company evidence. State what is known, label assumptions, choose a working hypothesis when necessary, and make the next evidence-producing step part of the recommendation. The goal is not false certainty; it is disciplined decision-making under uncertainty.