By Remi · · 4 min read
Communicating senior-level scope without a management title
You’re preparing for a senior PM interview, but you’ve never managed a team. You’ve made difficult product decisions, worked across teams, and taken responsibility for problems that didn’t have an obvious owner. How do you explain that experience?
Start with the work itself. Describe what made the problem difficult, which decisions you were responsible for, and what changed because of your involvement.
You don’t need direct reports to have examples worth discussing. You do need to make your responsibility clear.
Examples are fictional illustrations, not testimonials or Remi’s in-product prompts. Use your own experience and leave out confidential information.
In this guide
Check what the role actually involves
Read the job description before choosing your stories. Companies use senior titles differently. One role might involve leading a product area as an individual contributor; another might include hiring and managing PMs.
Look for the responsibilities behind the title. Will you be expected to set direction, make investment decisions, work across several teams, or bring depth in a particular area?
Choose experiences that help you discuss those responsibilities. If people management is a requirement you haven’t met, be clear about that. Mentoring a colleague or coordinating a project can be valuable experience, but it isn’t the same as managing someone.
Explain what made the problem difficult
A statement such as “I worked on a strategic initiative” doesn’t give the interviewer much to go on.
What made the work challenging?
Perhaps teams had conflicting priorities. Maybe you had to choose a direction before there was enough data to feel confident. Or a decision that helped one customer group would create problems for another.
For example:
“Three teams were building separate account settings. Customers using more than one product kept encountering different rules, but each team had its own roadmap and little time for a shared project.”
That opening makes the problem understandable. You can then explain what you did about it.
The number of teams alone doesn’t establish the difficulty. Explain what needed to be resolved between them.
Show how your involvement helped the work move forward
Here’s an illustrative answer:
“Three product teams were building separate account settings, and customers using more than one product were running into conflicting rules. I didn’t manage those teams, but I was responsible for recommending how we could make the experience more consistent.
“I mapped the differences with the designers and brought examples from support to the product leads. We considered a full rebuild, but it would have delayed work each team had already committed to. I proposed a shared account model that teams could adopt in stages.
“One team was concerned that the model wouldn’t support its existing permissions. I worked with its PM and engineering lead to understand that requirement and revise the proposal. The leads then agreed on the shared model and the order of adoption.
“Two teams adopted it in their next releases. The third had an unresolved dependency, so I continued working with that team on the transition. We still had an inconsistent experience in part of the product.”
The answer explains the responsibility, the competing needs, and how the PM helped reach a workable decision. It also shows what happened after the agreement.
There’s room for follow-ups about the rejected options, the permissions concern, and the unfinished transition. Prepare those details for your own story.
Explain what agreement led to
“I aligned the teams” is often the point where an answer needs more detail.
What did people agree to do? Did they change their plans, adopt a shared approach, stop duplicate work, or commit time to a dependency?
Describe that change. A meeting where everyone liked the idea is different from a decision that affected what teams did next.
Also explain your part in reaching the agreement. You may have investigated the problem, compared options, worked through objections, or helped people understand the cost of continuing as they were.
Those actions give the interviewer a clearer picture than saying you “influenced stakeholders.”
Use specialist depth if that’s where your experience is strongest
Your best example may sit within one product area. You don’t have to force a cross-team story.
Perhaps you worked through a difficult pricing change, decided how to migrate customers from an older feature, or chose which needs a product should serve over the next year.
Explain why the decision mattered, what made it uncertain, and which consequences you had to consider. Include how you checked the decision over time.
A focused story you know well can give you more to discuss than a broad initiative where your involvement was limited.
Prepare one story in detail
Choose an experience and make notes on these questions:
- What was I responsible for?
- Why was the problem difficult to resolve?
- What options did I consider?
- Who disagreed, and what concerned them?
- What did my approach cost or delay?
- What changed after the decision?
- What remained unfinished?
Then practise explaining the story without relying on words such as “strategic,” “senior,” or “complex.” You can use those words when they help, but the details should explain what you mean.
For help with the decision itself, use this guide to showing product judgment. Bring your responsibility, reasoning, and follow-through into your Remi answer.
This guide covers past-experience PM interview preparation. Interview expectations vary by employer; additional product, analytical, or technical preparation may be needed.