What does a PM take-home assignment look like and how do I pass it?

PM take-home assignments test what live interviews cannot: how you think when no one is watching, how you structure an ambiguous problem, and whether your recommendations are grounded in data and user insight. They are also a test of scope management. You cannot gold-plate everything in 4 hours, and the candidates who try usually produce worse outputs than those who focus.

The 4 Most Common Take-Home Formats

1. Product Critique

The prompt: "Critique a product of your choice. What is working, what is not, and what would you change?"

Some companies specify their own product. Others let you choose. Either way, this format tests product sense, structured thinking, and the ability to balance user and business perspectives.

Example outline:

Section 1: Product Overview (half a page)

Define the product, its target user, and its core value proposition in your own words. Do not regurgitate the company's marketing copy. Show you have formed an independent view.

Section 2: What Is Working (1 page)

Pick 2-3 specific things the product does well and explain why they work from a user and business perspective. Specific is better than general. "The checkout flow reduces friction by pre-filling payment details from prior orders, which directly supports the high repeat purchase rate" is better than "the UX is clean."

Section 3: What Is Not Working (1 page)

Identify 2-3 genuine problems with evidence. User reviews, App Store ratings, support forums, and personal experience all count as evidence. Be specific about which user segment experiences the problem and at what frequency or severity.

Section 4: Recommendations (1-1.5 pages)

Propose 2-3 improvements, prioritized. For each, state the problem it solves, the solution, how you would measure success, and the trade-offs. Use the prioritization frameworks from the complete prioritization guide to make your trade-offs explicit.

What evaluators score: Sharpness of user insight, quality of evidence, clarity of prioritization reasoning.

2. Metric Investigation

The prompt: "A key metric dropped 15% last month. Here is the data. What happened and what would you do?"

This is the most analytical format. Some companies provide real data (anonymized). Others provide a scenario with hypothetical numbers. Either way, you need to demonstrate structured diagnostic thinking.

Example outline:

Section 1: Initial Hypotheses (half a page)

Before diving into the data, state 3-4 hypotheses about what could explain the drop. This shows you approached the data with a framework, not by just scrolling for patterns.

Section 2: Data Analysis (1-2 pages)

Walk through the segmentation you performed: by platform, cohort, geography, user type, or feature. Explain what each segmentation ruled in or out. Show your diagnostic logic step by step.

The complete metrics guide covers the metric tree approach that evaluators expect to see in this section.

Section 3: Root Cause (half a page)

State your conclusion. Be direct. "The drop is concentrated in Android users who installed the November app update, consistent with a bug in the notification delivery system." If you are uncertain, say so and explain what data you would collect to confirm.

Section 4: Recommendations (1 page)

Short-term fix (stop the bleeding), medium-term fix (address the root cause), and monitoring plan (what metrics will you watch to confirm recovery). Be explicit about time horizons.

What evaluators score: Diagnostic rigor, comfort with ambiguity, quality of root cause reasoning.

3. Product Design

The prompt: "Design a new product (or feature) that solves [specific problem or user segment]. Walk us through your thinking."

This is the most open-ended format. The biggest risk is producing a superficial feature list. The best outputs read like a condensed discovery and design process.

Example outline:

Section 1: User Research Summary (half a page)

Describe who you talked to (even if you could only do 2-3 quick conversations or online research) and what you learned. Show that your design starts from real user insight, not assumption. Reference the product discovery guide approach: identify user goals, pain points, and current workarounds.

Section 2: Problem Statement (quarter page)

Write a crisp problem statement in the format: "[User type] struggle to [do X] because [root cause]. This results in [cost/consequence]."

Section 3: Solution Options (half a page)

Describe 3 potential approaches. Do not just pick one and present it as the obvious answer. Show that you explored the solution space before converging.

Section 4: Recommended Solution (1-1.5 pages)

The solution you would build first, why, and the user flow. Include how you would validate the core assumption before building the full version.

Section 5: Success Metrics and Launch Plan (half a page)

Define your primary success metric and 1-2 guardrail metrics. Describe the MVP launch plan (who you would target first, how you would measure, what the go/no-go criteria are).

What evaluators score: User-centricity, quality of problem framing, prioritization of solution options.

4. Strategy Memo

The prompt: "Write a strategy memo recommending whether [company] should enter [market/category]. Include your analysis and recommendation."

This format is most common at senior or leadership levels. It tests market analysis, business judgment, and the ability to make and defend a recommendation under uncertainty.

Example outline:

Section 1: Executive Summary (quarter page)

State your recommendation in the first sentence. "We should not enter this market in the next 18 months, for three reasons." The rest of the document supports this recommendation. Do not make the reader wait three pages to find out what you think.

Section 2: Market Analysis (1 page)

Total addressable market (use a bottom-up estimate, not a top-down analyst number), competitive dynamics, and the company's structural advantages or disadvantages in this space.

Section 3: Key Assumptions and Risks (half a page)

What would have to be true for this to succeed? Which assumptions carry the most risk? Show that you stress-tested your recommendation.

Section 4: Recommendation and Next Steps (half a page)

Restate the recommendation, the 2-3 biggest reasons, and what you would do in the next 30 days to validate or move forward.

What evaluators score: Quality of market analysis, sharpness of recommendation, intellectual honesty about risks.

What Evaluators Actually Score

Most companies score take-homes on these dimensions, even if they do not share the rubric:

Problem framing: Did you correctly understand what problem you were solving? Many candidates answer the wrong question because they did not spend enough time on framing.

User insight: Is your analysis grounded in real user behavior or is it generic? Specific user evidence, even from App Store reviews or a single conversation, signals good PM instincts.

Prioritization quality: When you had to make trade-offs, did you make them explicitly and with reasoning? This is where judgment is most visible.

Clarity of recommendation: Is your recommendation clear? Can someone read your first page and know what you are proposing and why?

Writing quality: PM outputs get read by engineers, designers, and executives. Clear, concise writing is itself a PM skill being evaluated.

Common Mistakes to Avoid

Starting too broad: Do not spend 40% of your document on market context. Evaluators assume you can research a market. They want to see your judgment, which lives in your analysis and recommendations.

No prioritization: Listing 10 recommendations is not a recommendation. Pick the top 2-3 and explain the trade-offs. The discovery guide covers how to prioritize user insights into a focused direction.

Hedging conclusions: "It depends" is not a conclusion. Make a call, explain your reasoning, and note the risks. PMs are hired to make decisions with imperfect information.

Missing metrics: Every recommendation should have a success metric. If you cannot define how you would know whether your proposed change worked, you have not thought it through enough.

Over-designing: Take-homes test judgment, not design skills. A rough wireframe with a clear explanation is better than a polished mockup with no reasoning.

Time Allocation

For a 4-hour take-home:

If you find yourself at the 3-hour mark with no recommendations written, your problem framing section is too long.