If you were already a PM on this team, what would you do and why?

[INTERVIEWER] If you were already a PM on this team, what would you do and why? This question is doing two things at once, and you have to pass both. Did you actually do the homework on their product, and do you have a real point of view about it? The strong answer names one specific opportunity, says why it beats the alternatives, and states the first thing you'd measure.

That's it. Vague enthusiasm fails this one instantly, because "I love the product and I'd make it even better" tells them nothing except that you didn't prepare. Specificity is the entire signal here. They're testing whether you'd be a PM who has opinions or one who waits to be told what to build. It's the closest thing to a job audition in the whole loop, because they're literally asking you to be a PM on the team for two minutes.

What they want to see is judgement under uncertainty: you picked one thing out of many, you can defend why it matters most right now, and you'd validate it with evidence before betting the roadmap on it. Over the next few minutes I'll give you the five-part structure, a worked example on an AI coding assistant, and the specific traps, a list of five ideas and empty praise, that quietly tank strong candidates.

Treat the whole thing as a mini-memo delivered out loud. Same discipline as a written memo: lead with the point, back it fast, don't ramble. Step one, show the homework in one line. Name the real product surface, a real gap you found by using it, or a real number from their public materials. "I used the feature for a week and here's what happens" earns you the right to have an opinion.

Do this fast, then move on, because the homework is your ticket in, not the main event. Step two, commit to one top opportunity. Not three. One, named specifically, with a reason it matters most for that team right now. Committing is the entire point of the question. A list of five ideas reads as no point of view at all, because if you rank nothing, you've decided nothing, and deciding is the job.

Step three, say why, against the alternatives. Briefly name what you considered and rejected. Something like "I'd prioritise this over that, because that serves a smaller audience and this sits on the main activation path." Naming the road not taken is what turns an idea into a point of view. Anyone can want something. A PM chose it over the other things they also wanted.

And you don't need the alternatives to be exotic. The obvious ones are fine, a bigger model, faster responses, more integrations, because rejecting the obvious candidates for a specific reason is exactly what shows you thought past the first idea that came to mind. Step four, state the first thing you'd measure. One metric, and what you'd expect it to do.

This shows you think in evidence, not vibes, and it signals you wouldn't ship on a hunch. For an AI feature, tie it to a quality or task-success metric, not just raw usage, because usage can go up while the feature quietly gets worse. Step five, sketch a rough 30/60/90. Not a detailed plan, just a shape. First 30 days: talk to users and read the eval data to confirm or kill the hypothesis.

Next 30: ship a scoped v1 to a small cohort. Next 30: measure against the metric and decide to scale or cut. That shape shows humility and direction at the same time, which is the exact blend they're listening for. You're confident enough to commit and humble enough to check before you scale. Say the 30/60/90 loosely, as a direction of travel, not a Gantt chart, because over-planning a feature you haven't validated yet is its own kind of naivety.

Let me make it real. Say the team owns an AI coding assistant. **On-screen reference block (the answer, out loud):** - **Homework:** "I used it on a side project for two weeks. The completions are strong, but every time it suggests a change across three files, I accept them one by one and lose the thread. Multi-file edits are where it breaks down for me." - **Top opportunity:** make multi-file, cross-referenced edits a first-class flow, with a single review-and-accept step.

- **Why, against alternatives:** "I considered faster single-line latency and a bigger model, but latency is already good and quality isn't the bottleneck for me. The bottleneck is the workflow around multi-file changes, which is where real work lives." - **First metric:** multi-file suggestion acceptance rate, plus edit-distance between what the assistant proposed and what the developer finally committed. - **30/60/90:** interview 15 heavy users and pull the logs on abandoned multi-file suggestions, ship a grouped review UI to an internal cohort, then measure acceptance and edit-distance against baseline and decide.

Walk it through. The homework line is doing the heavy lifting, and notice it's not praise, it's a specific friction I hit personally, with a number, two weeks, three files. That earns the opinion. Then I commit to exactly one thing: multi-file edits as a first-class flow with a single accept step. Not "improve the assistant," one named opportunity. The why is where I show it's a real POV and not a wish.

I explicitly considered faster latency and a bigger model, and I rejected both, and I said why: latency's already fine and quality isn't my bottleneck. The workflow around multi-file changes is. By naming what I turned down, I'm proving I ranked, not just brainstormed. The metric is tied to quality, not vanity. Multi-file acceptance rate tells me if people use it, but the edit-distance between what the assistant proposed and what the developer actually committed tells me if it was any good.

If the assistant is genuinely right, that distance shrinks version over version, and that's the number I'd hold the feature to. And the 30/60/90 shows I'd learn before I build. First month, talk to 15 heavy users and pull the logs on where multi-file suggestions get abandoned mid-flow, to confirm the pain is real and not just mine. Second month, ship a grouped review UI to an internal cohort.

Third month, measure acceptance and edit-distance against the baseline and decide to widen or cut. Direction and humility in the same breath. Let me do a second, faster one, so you see the structure isn't tied to coding tools. Say the team owns a consumer AI chat app. Homework: "I used it daily for a fortnight, and the answers are good, but there's no memory across sessions, so every morning I re-explain the same context about my project." Top opportunity: lightweight per-user memory, scoped to facts the user explicitly saves, not silent background capture.

Why, against alternatives: I considered a bigger model and more integrations, but the thing that made me reach for a competitor was re-explaining myself, not answer quality or missing connectors. First metric: return-session task-completion rate for users with memory on versus off, plus how often saved memories actually get used in a later answer. 30/60/90: interview heavy daily users about what they re-type, ship an explicit "remember this" affordance to a small cohort, then measure whether memory users complete follow-up tasks faster and decide.

Same five beats, different product, and I got there because the structure carries the thinking. That's the point: you don't need the perfect idea, you need a defensible one, delivered in the shape they can score. Here's what makes them lean in. Concrete evidence you actually used their product, a specific friction with a number, not a generic pitch that would fit any company on earth.

One opportunity, committed to, with the alternatives named and rejected out loud, because that's what a point of view sounds like. And a first metric tied to quality plus a plan that starts with learning before building, which tells them you'd de-risk a bet rather than swing blind. Put together, it reads as "this person already thinks like a PM on our team," which is precisely the impression the question is fishing for.

Now the ways it goes wrong. The first is a list of five ideas with no ranking, which is the exact opposite of a point of view, because you've refused to choose and choosing is the whole test. The second is praise with no evidence of real use, "I love the product, it's amazing," which reads as flattery and tells them you didn't open the thing.

And the third is jumping straight to a build plan with no metric and no first step of talking to users, which signals you'd ship on a hunch and skip the learning. Each one feels safe and each one quietly says "not ready." So the shape, one more time. Prove you used the product, fast, with a specific friction. Commit to one opportunity, named.

Say why it beats the alternatives you considered and rejected. Name the first thing you'd measure, tied to quality. And sketch a 30/60/90 that starts with learning, not building. Confidence to commit, humility to check. Carry this line into the room: prove you used the product, commit to one opportunity, say why it beats the alternatives, and name the first thing you'd measure before you build.