Going Above and Beyond
Building an unsolicited prototype is one of the highest-leverage ways to set yourself apart, and you don't have to send it to get value from it.
Worst case, you learn a ton about their product and can sprinkle this knowledge into the interview. In the best case, you can show them what you built or speak directly about it to score major points for taking initiative.
Think of this as the new dogfooding. When you sit down to identify a real problem, scope it, and build something that works, you're doing the same thinking your interviewers expect you to demonstrate in the room. You're forcing yourself to make real tradeoffs instead of theorizing about them. The prototype is proof that you did the work, and the thinking is what actually prepares you.
What counts as an unsolicited prototype
One thing: a working prototype of something you'd actually ship.
Not a strategy doc, not a slide deck, not a list of ideas. A prototype. PMs are in high demand, and the companies worth working at know it. What they want to see is that you can identify a real problem, make a call about what to build, and put something in front of them that works.
The prototype doesn't need to be polished. It needs to be specific and real. A three-screen clickable flow that solves one thing well is worth more than a ten-slide deck proposing a product strategy.
Before you build, spend time learning how the company actually works. How do they ship? What does their product feel like? What's the speed and tone of their decision-making? Then match that energy. A scrappy company wants to see scrappy output. A design-obsessed company wants fidelity. A data-driven company wants to see the metric you're moving front and center. The prototype should feel like it belongs inside their product, not like something you made from the outside looking in.
Companies like Perplexity use app critique rounds where they hand you the product and let you talk. One candidate who went through that loop reported being caught off guard: "the app critique, because they just let me keep talking and using the app and I wasn't really sure what they were looking for." Candidates who had spent real time in the product beforehand had a massive advantage.
The best prototypes have a point of view. Not "here's a feature idea" but "here's what I'd ship first, here's the user problem it solves, and here's what I'd cut."
The five-step process
Step 1: Target the signal, not the output
Before you decide what to build, decide what you want to demonstrate. Ask yourself: what does this company care about most right now? What's the one thing I want this interviewer to walk away thinking about me?
Those answers should drive every decision that follows. If the role is about growing a monetization product, build something that shows you think about incentives and retention, not just user delight. If the role is at an AI-first company like Perplexity or Anthropic, show that you understand the underlying model behavior, not just the interface.
Step 2: Scope it to something you can finish in 1-3 hours
Small and sharp beats ambitious and vague. Always.
A clickable three-screen prototype for a single feature is more impressive than something that tries to solve the whole product. Why? Because tight scoping itself signals judgment. It says: I know how to identify the most important surface to work on. I know how to ship something real instead of trying to boil the ocean.
Pick one problem. Solve it specifically. Leave everything else out. Be explicit about what you left out.
Step 3: Build with AI
This is not optional advice. It's table stakes.
Use Claude, Cursor, v0, or similar tools to build a working prototype fast. You don't need to hand-code anything. The point isn't your technical execution. It's your product instinct and judgment. What you build matters far more than how you built it.
That said, don't share something that looks AI-generated without editing it. Interviewers can tell the difference between someone who used AI as a tool and someone who let AI do their thinking. The framing note you write in Step 4 is where you prove which one you are.
If you're applying to a company that works on AI products (OpenAI, Anthropic, Mistral, Perplexity), consider building something that demonstrates how you'd intentionally use model behavior. Think about latency, retrieval, and context windows. Show that you understand the technology well enough to make product tradeoffs around it.
Step 4: Write a one-paragraph framing note
This is where most of the signal lives, whether you share the artifact or just describe it in conversation.
The framing note answers four questions in plain language:
- What problem did you decide to work on, and why this one?
- What did you build to address it?
- What did you leave out intentionally, and what tradeoffs did you make?
- What would you validate or change if you had more information?
That last question is the one that separates a good candidate from a great one. It shows you're not presenting this as a finished answer. You're presenting it as the best thinking you could do with the information available. That's how real PMs operate. And interviewers know it.
"I spent a few hours building a rough prototype of a faster onboarding flow for [Product]. My hypothesis is that the drop-off in the first three steps is driven by users not understanding the core value proposition before they're asked for permissions, so I redesigned those screens to lead with an outcome rather than a setup flow. I skipped account creation until after the first 'aha moment.' I left notifications out entirely for now because that felt like a separate decision requiring data I don't have. Happy to walk through the tradeoffs if it's useful."
That's 88 words. It tells the interviewer everything they need to know and signals genuine product thinking.
Step 5: Mention it in the interview, and offer to share
You don't have to send this work proactively, but you can mention it. When a relevant topic comes up, like a product design question, a discussion about execution, anything touching the problem space you explored: bring it up naturally: "I actually spent a few hours prototyping something in this area. Happy to share it if it's useful."
That offer does a lot of work. It signals initiative and gives the interviewer an easy way to dig in if they're curious. And it gives you a concrete artifact to reference throughout the rest of the conversation.
Tips
Build in response to something they said, not in a vacuum. The best prototypes reference a real detail from an interview round you already completed with this company: a pain point they described, a metric they mentioned, a gap they flagged. When what you build responds to their exact words, it reads like insider understanding.
The framing note matters as much as the prototype. A scrappy prototype with a clear note explaining your tradeoffs beats a polished one with no narrative.
If you can't describe it in one sentence, scope it down. "A three-screen prototype of a new onboarding flow that front-loads the value prop" is shippable. If you're still sketching the concept after two hours, you're building the wrong thing.
Give it a shot
Pick one company you're actively interviewing with, one you’d consider a top choice. Spend 30 minutes learning how they ship: look at their product, their job postings, and their engineering blog. Then identify one real problem you'd solve, and build a working prototype in 2-4 hours. Write the framing note. Then bring it up in an important interview round and see where the conversation leads.