Preparing with limited PM experience

Look for moments when you had to figure something out

Think about a time when you had to understand a problem, choose an approach, or get people to agree on what to do.

For example:

• In support, you noticed the same customer problem coming up and helped the team investigate it.
• In operations, you changed a process that was creating repeated errors.
• In engineering, you helped reduce the scope of a request while still meeting the customer’s need.
• In a student project, you changed your idea after seeing people struggle with an early version.

The setting gives the interviewer context. The useful part is what happened within it: what you noticed, what you did, and why.

Choose a specific moment. “I worked in customer support for two years” describes your background. A story about one recurring problem gives you something to discuss.

Explain the work without changing its label

You don’t need to describe an operations project as a product launch or give yourself a PM title you didn’t have.

Introduce the setting and your responsibility, then move into the story:

“I was working in customer support, and I helped investigate why new customers kept getting stuck during account setup.”

That’s enough to establish your role. You can now explain how you investigated the problem and what happened next.

Avoid repeatedly saying “I was only…” or “This was just…” Those phrases can distract from the work you’re trying to describe.

Build an answer from an experience you already have

Here’s an illustrative example:

“I worked in support for a scheduling tool. New customers often contacted us because their available hours weren’t showing correctly.

“I grouped recent conversations by the step where people got stuck and noticed that many had missed the time-zone setting. I checked that pattern with another support colleague and brought examples to the PM. I suggested making the setting more visible during setup.

“The PM and designer chose to add a confirmation step. I helped test the wording and reviewed support conversations after release. We still received setup questions, but I saw fewer about that particular setting in the conversations I handled.”

The candidate can explain a customer problem, how they investigated it, and how they contributed to a change. They also make clear which decisions belonged to the PM and designer.

An interviewer could ask why they grouped the conversations that way, whether they considered other causes, or how they checked the result. Those are useful details to prepare.

Use the role description to choose your examples

Look at the responsibilities in the job description. Which ones can you connect to work you’ve done?

If the role emphasizes understanding customers, prepare an example where you investigated a need or changed your view after listening to someone. If it emphasizes delivery, look for a time you handled a dependency, reduced scope, or helped a team meet a commitment.

You won’t necessarily have an example for every responsibility. Be clear about the gaps.

For instance:

“I haven’t owned a roadmap yet. I have helped compare customer requests and recommend which problems needed attention first.”

Then explain that experience. It gives the interviewer something concrete to discuss while keeping your level of responsibility clear.

If most of your experience comes from study or volunteering

Choose projects where you did more than follow a set of instructions.

Perhaps you spoke with people before deciding what to build, tested an idea, resolved a disagreement, or changed direction when something didn’t work.

Explain who used the result and what you learned. If you tested it with classmates, say so. If it never reached real users, talk about what you completed and what remained untested.

You don’t need to make the project sound bigger. You need enough detail to explain the choices you made.

Prepare a small set of stories

Start with three experiences:

1. A problem you investigated or helped solve.
2. A time you worked through a disagreement or constraint.
3. Something that went wrong and changed your approach.

For each, write down your responsibility, one important action, why you took it, and what happened afterward. Use different experiences where you can, so you have options for different questions.

These stories cover the past-experience part of your preparation. Ask the recruiter what else the interview includes so you can also make time for any product cases, analytical questions, or technical discussions.

If you’re struggling to recall examples, use these prompts for remembering your work. Then choose one experience and develop the details in Remi.