Skip to content
PMcademy
Career

Career prompts

Portfolio, interviews, and surviving the first ninety days somewhere new.

The stage

The stage where the work you did has to become a case someone else can evaluate in twenty minutes.

  1. 01

    Turn a project into a portfolio case study

    A finished piece of work needs to become something a hiring manager can read in five minutes and actually understand.

    The prompt
    I'm going to describe a product project I worked on: the situation, what I did, and the outcome. Help me turn this into a portfolio case study structured as: the problem (with a number if I have one), my specific role and what I actually decided versus what others decided, the approach I took and why, the outcome, and what I'd do differently now.

Be specific about pushing back on vague ownership claims: if I describe something as "we decided," ask me whether it was actually my call, and if it wasn't, help me phrase my actual contribution honestly rather than inflating it.

Project: [describe the situation, what you did, and the outcome]
    Where it lets you down

    It happily accepts and even sharpens an inflated ownership claim, turning "I was involved in the decision" into confident first-person language like "I decided," because that reads as a stronger case study. Read the draft back and mark every claim of ownership that a former teammate could dispute if asked.

  2. 02

    Rehearse a behavioural interview answer against the actual question asked

    Before an interview, to check whether a prepared story actually answers the specific question rather than a nearby one.

    The prompt
    The interview question is: [paste the exact question, for example "tell me about a time you disagreed with an engineering lead"]. Here is my draft answer.

Check whether my answer actually addresses this specific question or a nearby, easier one (for example, answering "tell me about a disagreement" with a story about a disagreement you didn't actually have to resolve, or where the other person just came around on their own). Point out the exact sentence where my answer drifts, if it does.

Then ask me one follow up question an interviewer would likely ask to probe the weakest part of my answer.

Question: [paste it]
My draft answer: [paste it]
    Where it lets you down

    It's generous about whether the answer fits the question, treating an adjacent story as close enough because the topic overlaps, when an actual interviewer would notice the story didn't require you to do anything hard. Ask it explicitly to name the exact skill or tension the question is testing for, and check if your story actually demonstrates that, not just a related topic.

  3. 03

    Draft a 30-60-90 day plan grounded in what you don't yet know

    Before starting a new role, when a generic 30-60-90 template would say nothing specific to the actual company.

    The prompt
    I'm starting as a PM at [type of company, stage, and what little I know about the product]. Instead of a generic 30-60-90 day plan, help me draft one built around the specific things I don't know yet and need to learn before I can make a real recommendation.

For the first 30 days, list the specific questions I should be able to answer by the end (about the users, the metrics, the team, and how decisions currently get made), not generic activities like "meet with stakeholders." For 60 and 90 days, keep the commitments conditional on what I learn in the first 30, rather than pre-deciding what I'll ship.

What I know so far: [describe the company, product, and role]
    Where it lets you down

    It writes a plan full of specific-sounding deliverables for day 60 and 90 ("launch a new onboarding flow") that are actually just generic PM activities dressed up with a deadline, committing to outcomes before you've learned anything the plan itself says you need to learn first. Check that nothing in the 60 or 90 day section is decided before the day 30 questions have actually been answered.

  4. 04

    Prepare for a product sense interview with a real product

    Before a product sense or product design interview, practising on a product you don't work on.

    The prompt
    Act as a product sense interviewer at a mid-size tech company. Ask me to improve [a real product, for example "the checkout flow of a grocery delivery app"]. Do not tell me what's actually wrong with it. Instead, ask me the follow up questions a real interviewer would ask as I answer: who is the user I'm designing for, how would I prioritise among the ideas I generate, and how would I measure success.

Push back if I jump straight to a solution without first stating who the user is and what problem they have. Keep the conversation going for at least four exchanges before summarising how I did.
    Where it lets you down

    It's too quick to validate an early, underdeveloped answer as good, moving on before pushing on the parts a real interviewer would drill into, like an unstated assumption about the user. Ask it afterward what a stronger candidate would have said that you didn't.

  5. 05

    Write a case study close that survives a hard question

    A portfolio case study reads well until someone asks what actually went wrong, and the ending currently avoids that.

    The prompt
    Here is the ending of a portfolio case study: the outcome and what I'd do differently. Ask me the hardest question a skeptical interviewer would ask about this outcome, specifically about anything that sounds like it went perfectly, since real projects rarely do.

Then help me rewrite the closing paragraph to include one honest limitation or thing that didn't work as well as the rest of the case study implies, without undercutting the overall result.

Case study ending: [paste it]
    Where it lets you down

    It's reluctant to genuinely challenge a case study that already sounds like a success story, offering a soft, easily answered question instead of the one that would actually expose an unaddressed weakness. Ask it directly what part of this story sounds too clean to be believable, and press on that specifically.

  6. 06

    Draft your first week questions before you ask them live

    Before day one at a new company, to walk in with sharper questions than "tell me about the product."

    The prompt
    I'm starting as a PM at [company type and what you know]. Help me draft specific questions for my first meetings with the founder, an engineer, and a support or sales person, each tailored to what that specific role would actually know that the others wouldn't.

For each question, make sure it couldn't be answered from the company website or a pitch deck. Flag any question in my draft that's too generic (something any new hire would ask regardless of role) and suggest a sharper version specific to what only that person could tell me.

What I know: [describe the company and role]
    Where it lets you down

    It generates polite, generic first-meeting questions ("what does a typical day look like") that any new hire could ask anyone, rather than questions specific to what only that person's seat would reveal. Check each question against whether the answer would actually differ if you asked a different person in a different role.