How to stand out in a PM interview with a working prototype
Everyone brings opinions about the product. Almost nobody brings the change already working on it — on their real product, not a slide.
Can you build a working prototype for a PM interview?
Yes — on their actual product, in your browser, in about the time it takes to write a paragraph about it. That's what 6to9 does: you describe the change in plain language and it happens on the page as rendered, so what you bring to the interview is their real product with your idea on it.
That matters because of what it replaces. Every serious candidate for a PM role arrives having used the product and formed opinions about it. They've read the same interview prep, they bring the same artifacts: a few slides, an annotated screenshot, a tidy framework applied to a problem they spotted. The interviewer has seen forty of them this quarter. None of it is bad — it just can't distinguish you, because it's what the role's own selection process trained everyone to produce.
What the panel is actually evaluating
An interview about product sense is a proxy. Nobody cares whether your slide is well-designed. They're trying to answer three questions: can you find a problem worth solving, can you reason about a solution without hand-waving, and can you communicate it to people who will have to build it.
The artifact you bring either helps them answer those questions or gets in the way. A description makes them do imaginative work — hold your words in their head, picture the screen, guess at the details you left out. That's ten minutes of effort spent decoding you instead of evaluating you, and the parts you didn't specify are the parts they'll fill in with their own assumptions.
A working version of the change removes that step entirely. They open a link, see their own product with your change on it, and every second after that is spent on the thing you actually want judged: whether it was a good idea.
How to do it
- 1
Pick a surface you genuinely use
Sign in as yourself and go to a screen you have real opinions about, because you've hit the problem rather than gone looking for one. Lived friction is defensible in a way that an audit is not — you can say when it happened to you and what you were trying to do.
- 2
Find one problem, not a redesign
One confusing step, one empty state that teaches nothing, one pricing page that buries the plan you'd have picked. A single change you can argue for in two minutes beats a reimagining you can only gesture at.
- 3
Make the change on the real page
Open 6to9 on the screen and describe the change in plain language — it happens on the page as rendered, with the real content and the real styles around it. That surrounding context is the whole point: it's what shows whether the idea survives contact with the actual product.
- 4
Try it three ways before you settle
Your first version is your first instinct. Since another attempt costs about a minute, generate a couple of alternatives and pick deliberately. Being able to say 'I tried it this way too, and here's why I didn't go with it' is itself a signal about how you work.
- 5
Work out what you'd measure
The prototype answers 'what would this look like'. You still have to answer 'how would we know it worked'. Name the metric you'd expect to move and roughly how much would make it worth shipping — that's the half most candidates skip.
- 6
Bring the link, and bring a question
Share it before or during the conversation so they can open the real page themselves. Then ask what they've already tried. You are the person in the room with the least context about why the product is the way it is, and behaving accordingly is a feature.
What to prototype, and what to leave alone
The choice of change says as much about your judgment as the change itself.
| The change | Good interview material? | Why |
|---|---|---|
| A confusing step in onboarding | Yes | Small, self-contained, and you hit it yourself — the strongest evidence you can bring is your own experience of the friction |
| An empty state that teaches nothing | Yes | Almost always under-owned, easy to show a better version of, and it signals you think about the first-run experience |
| A pricing page that buries the plan you'd pick | Yes | Commercial judgment, and you can reason about it without any internal data |
| A full homepage redesign | No | Too large to defend in ten minutes, and it reads as taste rather than judgment |
| Anything needing new backend behaviour | No | You can show the surface but not the system, so the conversation stalls on feasibility instead of on your idea |
| The logo, the brand, the colour palette | No | Someone senior chose it deliberately, and you'd be arguing aesthetics with no information |
The pattern: prototype the things where a customer's experience is visible and the reasoning is yours to make. Leave alone the things where the answer depends on information only the company has.
The mistake that makes this backfire
Arriving with a verdict.
A prototype is persuasive, and that's exactly the risk. It makes an idea look finished, which makes the person who's lived with the product for three years feel handled rather than consulted. There is usually a reason the screen is the way it is — a constraint, a failed experiment, a partner deal, a lawsuit. You don't know it yet.
Frame it as thinking, not as a recommendation. "Here's the problem I kept hitting, here's one direction, what am I missing?" invites the conversation you want — the one where they tell you why it's hard, and you get to show how you handle new information in real time. That's a much better use of the room than being right.
Why this works better than it sounds like it should
Partly it's the artifact. Mostly it's that almost nobody does it, and the reason is that it used to be expensive: you'd need design time you don't have or front-end skills the role doesn't require, for a job you might not get. So the effort was rational to skip, and the whole field skipped it together.
That cost is what changed. Describing a change takes minutes where building one took days, and the result shares as a link that opens the same change on the same real page — no mockup, no clone of their site, and nothing installed on their end. The person you send it to opens their own product and sees it.
Which is also why the sharing works cleanly here, when it often doesn't elsewhere: a shared change lands on the real page, so whoever opens it needs their own access to that page. Your hiring manager has that. It's their product.
What's different in the room
You stop being a candidate with opinions and become a candidate with a proposal. Those get different conversations.
The best version of the outcome isn't that they agree with you. It's that the discussion moves immediately past what do you mean and into why did you choose that, what would you measure, what would you do if the number didn't move — which are the questions you actually want to be asked, because they're the ones where experience shows.
And if they disagree, you've still had a specific, concrete exchange about their product with someone who will remember it. That beats being the fourth candidate that week with a framework.
If you want the mechanics of what can and can't be changed on a rendered page, how to edit a live web page without changing the code covers it. If you get the job and immediately hit the problem of not owning the template, how to test a page change when you can't edit the template is the sequel.
Frequently asked
Do I need engineering skills to build a prototype for an interview?
No. You describe the change in plain language on the page itself and it happens there. The point of the exercise is your product judgment, not your ability to write CSS — and a hiring manager can tell the difference between a candidate who thought carefully about one screen and one who spent the weekend learning React.
Does this change the company's actual product?
No. The change happens in your browser's view of the page and nothing on their side is touched. That's what makes it safe to do before you work there: you're not editing their site, you're showing what a different version of it would look like.
Is it appropriate to prototype a company's product for an interview?
Yes. Nothing is published, nothing is altered for their users, and you're doing exactly what the role would ask you to do. Candidates already redline screenshots and build decks about a company's product; this is the same act with a better artifact. Use the product as a customer would, and don't imply access you don't have.
What if I don't have an account for the product?
Sign up if it's self-serve — most consumer products and plenty of B2B ones are. If it's genuinely gated, the marketing site, pricing page and signup flow are all real surfaces with real product decisions in them, and a well-argued change to onboarding is often more interesting than one buried three screens into the app.
What if they already considered the change and rejected it?
Then you learn something in the room, which is a good outcome — provided you arrived with a question rather than a verdict. Ask what they tried. A candidate who says 'here's how I thought about it, what am I missing?' looks curious; one who says 'you should do this' looks like they skipped the part where the team has context they don't.
Can I use this for a take-home or case study assignment?
Yes, and it fits those better than anything else — a take-home is explicitly asking for your thinking about their product. Attach the link alongside your written reasoning rather than instead of it. The prototype shows what you mean; the writing shows why.
Published August 9, 2026
6to9 is a Chrome extension — open it on any page you're allowed to change and describe what you want different. Install it for Chrome, or have us walk one of your pages.