How do you prioritise features when you have more requests than capacity?

I use a combination of frameworks depending on the context. For early-stage products I often rely on RICE (Reach, Impact, Confidence, Effort) to create a shared scoring system across the team. For more mature products I layer in strategic alignment, asking whether each feature moves a key metric we have committed to. I also run regular stakeholder syncs to surface conflicting priorities early, and I keep a clearly documented "not now" list so nothing gets lost. The goal is not just to pick the highest-scoring item, but to sequence work so that foundational pieces unlock future value. I revisit priorities every sprint and adjust when market signals or data change the picture.

How do you define and measure the success of a product?

I start by aligning on the outcome the product is meant to drive, not just outputs like features shipped, but real user and business results. I work with stakeholders to agree on a primary success metric and two or three supporting metrics before we build anything. For a growth feature this might be activation rate plus 30-day retention. For a monetisation feature it could be conversion rate and average revenue per user. I also define a counter-metric to catch unintended side effects: for example, watching support ticket volume when we simplify onboarding. After launch I do a structured review at 30 and 90 days, comparing results against the baseline we set, and I share learnings openly with the team regardless of outcome.

Describe how you work with engineering and design teams.

I see my role as creating the conditions for engineers and designers to do their best work, not directing them. I involve both disciplines as early as possible, ideally in the problem definition phase, not just solution review. With designers I focus on shared understanding of the user problem before we discuss solutions. With engineers I prioritise transparency about the "why" behind each initiative, and I actively seek their input on scope trade-offs. I hold a weekly sync to remove blockers and a fortnightly retrospective to improve our process. I also make a point of giving engineers visibility into user feedback and metrics so they feel connected to outcomes. Trust is built over time through consistency and follow-through.

Tell me about a time you had to make a difficult product decision with incomplete data.

At my previous company we were deciding whether to rebuild our onboarding flow. Quantitative data showed high drop-off at step three, but we did not know why. We had a two-week window before an engineering freeze. I ran five rapid user interviews and a quick unmoderated usability test to get directional insight. The interviews revealed that users were confused by a permission request we had not explained. Rather than doing a full rebuild, I proposed a targeted fix: adding a single explanatory screen before the permission prompt. We shipped it in three days. Drop-off at step three fell by 22% within two weeks. The lesson I took was that "incomplete data" rarely means "no data": small, fast research beats waiting for perfect information.

Describe a situation where you had to push back on a senior stakeholder.

Our CEO wanted to add a social sharing feature to our core workflow, based on feedback from two high-profile customers. I reviewed our broader data and found that fewer than 4% of users had ever used our existing sharing function. I prepared a short brief showing the usage data, the estimated engineering cost, and three alternative uses of that capacity that mapped more directly to our retention goal. I presented it as a prioritisation question, not a disagreement, and offered to run a lightweight experiment to validate demand before committing resources. The CEO agreed to defer the feature and approved a two-week spike to test a simpler sharing mechanic. It did not reach our threshold, which validated the decision and strengthened trust for future conversations.

Give an example of a product that failed. What did you learn?

I led a B2B reporting module that we built over three months. It launched to low adoption: under 10% of the target segment used it in the first 60 days. In the post-mortem we identified two root causes. First, we had validated the problem with buyers but not with end users, and the two groups had very different workflows. Second, we underestimated the switching cost from the spreadsheet tools users already had. I learned to separate buyer validation from user validation and to always map the incumbent behaviour before designing a replacement. I also introduced a "jobs to be done" framing into our discovery process as a result, which has improved adoption rates on subsequent launches.

How do you work with data to inform product decisions?

I treat data as one input alongside qualitative research, not as the only input. My standard toolkit includes event-level analytics (I have worked with Mixpanel and Amplitude), SQL for ad hoc queries, and A/B testing via our experimentation platform. Before any experiment I write a hypothesis in the format "If we do X, we expect Y because Z", define the primary metric and minimum detectable effect, and calculate the required sample size. After the experiment I read the full results including secondary metrics and segment breakdowns before drawing conclusions. I am careful to distinguish between statistical significance and practical significance: a 2% lift that does not justify the maintenance cost is not a win. I also hold regular data reviews with the team to build shared fluency.

How do you approach building a product roadmap?

I build roadmaps around outcomes, not features. I start with the company strategy and OKRs for the quarter, then identify the two or three user or business problems whose solution would most directly move those metrics. Each item on the roadmap maps to a problem statement, a hypothesis, and a success metric, not just a feature description. I use a "now, next, later" structure to keep the team focused on the near term while maintaining visibility of the direction. I share a version of the roadmap with key stakeholders monthly and update it whenever strategic priorities shift. I am deliberate about what I leave off: an overloaded roadmap signals a lack of prioritisation, which erodes team confidence.

Walk me through how you would write a product requirements document.

I start with the problem, not the solution. The first section of any PRD I write covers the user problem, the evidence for it, and the business case. Then I define the goals and explicit non-goals: the non-goals section is often the most valuable because it prevents scope creep mid-build. I include user stories in the format "as a [user], I want [action] so that [outcome]" and acceptance criteria that the team can test against. I add a section on open questions and decisions that need to be made, with owners and deadlines. Finally I include a risk section covering technical, UX, and business risks. I review the PRD with engineering and design before it is finalised: a PRD that surprises the team in sprint planning has already failed.

Product Manager

Product Manager interviews test your ability to balance user needs, business goals, and technical constraints. Interviewers want to see structured thinking, clear prioritisation frameworks, and real examples of how you have shipped products that deliver measurable value. This guide covers the questions asked most often and the answers that land offers.

For general interview preparation tips, read our guide to common interview questions.

Common Product Manager Interview Questions

Behavioral Interview Questions for Product Manager Roles

Technical Questions for Product Manager Candidates

What Hiring Managers Look for in Product Manager Interviews

What hiring managers really look for in Product Manager candidates:

Structured thinking under pressure. Use STAR or similar frameworks: vague answers cost you the offer.
Evidence of cross-functional influence without authority. Show how you moved engineers, designers, and stakeholders toward a shared goal.
Honest reflection on failure. Every strong PM has shipped something that did not work. How you talk about it matters more than the failure itself.
Data fluency, not data obsession. You should be able to query and interpret data, but also know when qualitative insight is more valuable.
Customer proximity. Reference real user conversations, not just analytics dashboards.

Questions to Ask Your Interviewer

→What does success look like for this role in the first 90 days?
→How does the product team collaborate with engineering: are PMs embedded in squads or organised separately?
→What is the current biggest challenge the product team is working through?
→How are product decisions made when engineering and business priorities conflict?
→What does the product discovery process look like here?

Practice These Questions Before Your Interview

The mock interview tool builds a practice session around a specific job posting and your background, so you rehearse the questions most likely to come up.

Start Practising

Free during beta. No commitment.

Related Roles