How would you decide which feature to build next when you have five stakeholders with five different priorities?

Start from the product strategy and business objectives — not from stakeholder requests. Evaluate each option with objective criteria: what user problem does it solve? Which business metric does it move and by how much? What effort does it require? Communicate the reasoning behind the decision to all stakeholders transparently, including those whose priority was not selected. Stakeholders accept a 'no' with documented reasoning better than a 'no' based on the PM's judgment alone. If the prioritization conflict persists, it is a signal that the product strategy is not sufficiently clear or shared.

How would you distinguish between a genuine product opportunity and a problem from a single loud customer?

A genuine opportunity appears recurrently from multiple sources: interviews with different users, behavioral data, support tickets, and sales conversations. A single loud customer's problem appears with high intensity from a single source. The litmus test is prevalence: how many distinct users have expressed this problem spontaneously without being prompted? If the answer is one or two, it is a request; if it is twenty, it is an opportunity. Individual customer requests also have their place, but in a different prioritization process from the strategic roadmap.

What is a North Star Metric and how would you use it to align the team's decisions?

The North Star Metric is the single metric that best captures the value the product delivers to users and that predicts long-term business growth. Examples: weekly watch time at Netflix, daily messages sent at Slack. All team decisions are evaluated by their expected impact on the NSM. Input metrics are the factors the team can move directly that, combined, drive the NSM. Having an NSM does not mean ignoring other metrics; it means having a clear hierarchy that prevents the team from optimizing local metrics at the expense of the global objective.

What is the difference between outputs and outcomes in the context of product management?

An output is what the team builds and ships: a feature, an API endpoint, a design. An outcome is the behavior or metric change that output produces: users who previously abandoned the flow now complete it; time to activation dropped from 7 days to 3. Output roadmaps commit the team to building specific things regardless of whether they generate value. Outcome roadmaps commit the team to moving specific metrics with the freedom to discover the best way to do so. Managing by outcomes increases the probability that the team's work has real impact.

How would you prioritize between investing in new features for user acquisition versus improving retention of existing users?

The decision depends on the product's current state and the business model. If retention is low — users leave before finding the product's value — investing in acquisition is filling a leaky bucket: expensive and inefficient. Improving retention first raises LTV per user and makes the acquisition investment more profitable. If retention is healthy and growth is the primary objective, acquisition may be the highest-impact lever. Cohort retention data is the source of truth for this decision.

How would you manage the relationship with the engineering team so that collaboration is effective and not based on an order-taker model?

Involve the engineering team in discovery from the start — not only in delivery. Engineers have valuable perspectives on technical feasibility, solution opportunities, and risks the PM does not see. Share the problem context before sharing the solution: what the business objective is, what user problem is being solved, what constraints exist. Respect the team's technical estimates and collaborate on trade-offs when there is tension between scope and timeline. A PM who treats engineering as an execution team gets a team that delivers what is asked for — but not the best possible product.

How would you define the success criteria for a new feature before the team begins developing it?

Define before development: the primary metric expected to move (with the current baseline value and the target), the secondary metrics to monitor for unintended effects, the time horizon for evaluating impact (typically 4-8 weeks post-launch), and the success threshold that would justify additional investment or the failure criterion that would trigger a revert or iteration. Without these criteria defined before launch, success is defined retroactively using the best available data — which produces confirmation bias.

How would you communicate to an important stakeholder that their feature request will not make it into the roadmap in the next two quarters?

With transparency and documented reasoning: explain the product's current priorities and why they generate more value for the business or users than the request. Acknowledge the value of the request without committing to a date that cannot be met. Share what information would change the prioritization: evidence that more users have the same problem, additional business impact data. A 'not now' with reasoning maintains the relationship better than a 'yes' that never gets delivered or a 'no' without context.

How would you apply the opportunity solution tree framework by Marty Cagan / Teresa Torres to structure the team's discovery?

The opportunity solution tree connects the desired outcome (the metric the team wants to move) with the opportunities (user problems or needs that, if resolved, would move that metric), the possible solutions for each opportunity, and the experiments to validate each solution. The structure prevents the problem of falling in love with a solution before exploring all the opportunities. The team works in parallel exploring multiple branches of the tree rather than betting everything on one solution. User interviews continuously feed the tree by identifying new opportunities and validating the hypotheses of active branches.

How would you design an experiment to validate whether a product hypothesis has potential before investing in full development?

Define the hypothesis precisely: 'We believe that [users with this profile] [have this problem] and that [this solution] will produce [this measurable result].' Identify the minimum experiment that can falsify the hypothesis: not the full MVP, but the fastest and cheapest test that produces evidence. Examples: a landing page that measures interest, a non-functional prototype in a user interview, a wizard-of-oz where the process is executed manually. Define the success criterion before running the experiment: what result would confirm the hypothesis and what would falsify it. The goal is to learn quickly and cheaply — not to validate what you already want to do.

How would you analyze a product's conversion funnel to identify the biggest improvement opportunities?

Map each step of the funnel with the conversion rate from one step to the next. Steps with the highest drop-off are the highest-potential-impact opportunities because small improvements produce large volume gains. For each high-drop-off step, diagnose the cause: is it a UX problem (users do not know what to do), a value proposition problem (users do not understand why to continue), a technical friction problem (errors or slow load times), or a fit problem (users who reached that step are not the right profile)? The cause determines the solution. Without the diagnosis, you optimize the symptom rather than the problem.

How would you structure the backlog prioritization process using the RICE framework?

RICE evaluates each backlog item with four factors: Reach (how many users it affects in a time period), Impact (how much it moves the key metric, on a scale from 0.25 to 3), Confidence (how certain we are of the above values, from 50% to 100%), and Effort (person-hours of team work). Score = (Reach × Impact × Confidence) / Effort. Items are sorted by descending score. The value of RICE is not in the precision of the numbers but in making the assumptions behind each estimate explicit so the team can challenge them and reach an informed consensus. Assumptions must be documented alongside the score.

How would you measure the adoption of a new feature and when would you decide it is not working and needs iteration?

Define adoption metrics before launch: percentage of target segment users who use the feature at least once, percentage who use it recurrently, and retention rate of users who adopt it versus those who do not. Set success and failure thresholds in advance. Evaluate after sufficient time (4-8 weeks) for users to have had the opportunity to discover and use the feature. If adoption is below the threshold, diagnose the cause before deciding on an action: do users not know it exists (discoverability problem), do they not understand its value (communication problem), or do they try it but not return (real value problem)?

How would you manage the product OKR definition process so that OKRs are aligned with company objectives and actionable for the team?

Product OKRs are the bridge between the company's strategic objectives and the team's work. The process: the company's strategic objectives define the context. The product team proposes the product OKRs that would contribute to those objectives from their area of impact. Key results are user or business behavior metrics — not deliverables (not 'launch X feature' but 'increase week-4 retention from 40% to 55%'). Each key result must be measurable with available data or data the team can instrument. Weekly OKR reviews with the team maintain focus and allow early detection if a bet is not working.

How would you evaluate whether a product is solving the right problem for its growth stage?

Verify retention in cohorts: if users who signed up six months ago are still using the product, the problem being solved is real and recurring. If retention drops to zero within the first few weeks, the product has not found the right problem or is not solving it well enough. Analyze the Net Promoter Score and open-text responses: do users recommend the product for a specific, concrete reason? Would they describe it as solving a real problem? The Sean Ellis question ('How disappointed would you be if you could no longer use this product?') with at least 40% answering 'very disappointed' is a signal of product-market fit on the right problem.

How would you structure a backlog prioritization session with the engineering team to make it collaborative rather than a PM imposition?

Share the full context before diving into individual items: what the quarter's objectives are, which metrics are being targeted and why. Present backlog items with the problem they solve and the impact hypothesis — not just the feature description. Invite the team to identify technical risks and uncertainties for each item before prioritizing. Use a visual prioritization framework (RICE in a shared spreadsheet, impact-effort matrix on a whiteboard) so the reasoning is visible and open to challenge. The goal is for the team to understand and be able to explain why they are building what they are building — not just to execute what the PM decided.

How would you define the strategy for a new product in a competitive market with established incumbents?

Start by identifying the user segment incumbents serve worst: do not compete in the center of the market but at the edges where the incumbent cannot or will not go. Define the differentiated value proposition in terms of the job the user needs to get done — not in terms of features. Establish the strategic bets: what must be true about the market, the users, and the product for this strategy to work. Validate the riskiest bets with the minimum viable experiment before committing significant resources. Strategy is not the roadmap; it is the reasoning that explains why this set of decisions will generate a defensible competitive position over time.

How would you balance stakeholder pressure for visible short-term features with the need to invest in platform and long-term user experience?

The balance requires data, not just judgment. Quantify the cost of not investing in the platform: additional time added to each new feature because of accumulated technical debt, incidents caused by a degraded platform. Quantify the cost of not improving UX: abandonment rate in flows with known friction, support cost from usability issues. Propose an explicit investment model: a fixed percentage of the roadmap permanently dedicated to platform and UX, negotiated as policy rather than case by case. Stakeholders accept a 20% rule more readily than a constant negotiation where they always lose.

How would you manage the process of sunsetting a feature that has active users but is consuming disproportionate resources relative to the value it generates?

Quantify first: how many active users it has, how frequently they use it, what the technical maintenance cost is in team time, and whether those users have alternatives available. Communicate the sunset well in advance (minimum 90 days for active users) with a migration guide to the available alternative and a support channel during the transition. For users without an alternative, evaluate whether building one makes sense or whether the product should not serve that use case. Sunsetting is as valid a product decision as launching; postponing it indefinitely out of fear of user reaction accumulates technical and focus debt.

How would you build the case for the organization to invest in a full redesign of a critical flow that has high friction but also high historical conversion?

The 'if it ain't broke don't fix it' argument ignores opportunity cost. Quantify current friction: abandonment rate in the flow, average completion time, support contacts volume related to the flow. Estimate the potential impact of the improvement with industry benchmark data or partial experiments on sections of the flow. Propose a gradual rollout with an A/B test to compare the new flow against the current one before committing to the full change. The strongest argument is not 'the current flow is ugly'; it is 'the current flow is leaving X% of potential conversion on the table, according to this data'.

How would you evaluate whether the product team has the right discovery system or whether it is building features without sufficient validation?

Signals of a healthy discovery system: the team can articulate the user problem each feature solves with concrete evidence, features launched in the last six months moved the expected metrics more than 50% of the time, there is a pipeline of active experiments running in parallel with development, and the team rejects or reframes feature requests that lack a clear impact hypothesis. Signals of a weak discovery system: features are defined by analogy with competitors or by stakeholder requests without user validation, the rate of post-launch features that do not move metrics is high, and the team cannot explain why each backlog item exists.

How would you design the expansion strategy for a B2B product that has achieved product-market fit in one segment and wants to move into a new segment?

Expansion to a new segment is a new product-market fit challenge — not simply a sales question. Validate that the new segment has the same core problem as the current segment before assuming the existing product will serve them. Identify which parts of the product are sufficiently generic for the new segment and what requires customization. Evaluate whether the necessary customization compromises the value proposition for the original segment. Start with a pilot with two or three customers from the new segment to learn before committing the roadmap. The most common mistake is assuming that success in one segment guarantees success in another without validating the new segment's specific assumptions.

Describing the PM role as someone who collects stakeholder requests and prioritizes them in the backlog

A PM who operates as a stakeholder order-taker is not managing a product: they are managing a request backlog. Interviewers at companies with mature product teams specifically ask how the candidate discovered user problems and which solutions they rejected and why. The ability to say no with evidence is as important as the ability to say yes.

Not being able to articulate which metrics moved as a result of the features described in past projects

A PM who describes launched features but cannot say what happened to the metrics after launch demonstrates building without measuring. Interviewers specifically ask: what happened to retention, conversion, or engagement after launching that feature? If the answer is 'we did not measure it' or 'I do not remember,' it signals that the work was not oriented toward outcomes.

Conflating the feature roadmap with the product strategy

A feature roadmap says what will be built. A product strategy says why those specific bets will generate a sustainable competitive position. A PM who can only discuss the roadmap without articulating the strategy behind it — what hypothesis each initiative validates and what must be true for it to work — is operating tactically without strategic vision.

Not involving the engineering team in discovery and treating them as an execution team

The best product teams are shared-mission teams where engineering, design, and PM discover and deliver together. A PM who presents fully defined solutions to the engineering team for implementation misses the technical perspectives that frequently produce the best solutions. Interviewers at companies with a strong engineering culture explicitly ask about the collaboration model with the team.

Presenting past product success exclusively in terms of features launched or roadmap completion

Launching features is not product success. Product success is impact on users and on the business. A PM who describes their work in terms of how many features they launched, how many sprints they completed, or whether the roadmap was delivered according to plan demonstrates measuring outputs and not outcomes.

Not having a clear process for validating hypotheses before committing the development team

A PM who builds everything without prior experiments, or who cannot articulate how they validate product hypotheses before full development, is making investment decisions without managing the uncertainty risk. Interviewers at companies with mature product discovery practices specifically ask how the candidate validates before building.

Product Manager

Defines what to build and why so the product generates real value for users and for the business.

A Product Manager is responsible for discovering, defining, and prioritizing what the product team should build to solve the most important user problems while generating sustainable business value. They do not manage people or projects: they manage the product. Their work spans user research and market analysis through product strategy definition, backlog prioritization, and measuring the impact of every decision. They work at the intersection of business, technology, and user experience, collaborating with engineering, design, sales, marketing, and leadership to bring the product vision to reality.

Product DiscoveryRoadmappingOKRsProduct metricsPrioritizationProduct strategy

Recruit the best Product Manager here

Start now

Main Responsibilities

•Develop and communicate a clear product vision aligned with business objectives and user needs.
•Discover and validate the most important user problems through qualitative and quantitative research before committing development resources.
•Prioritize the product backlog with transparent criteria that maximize the value the team delivers in each cycle.
•Define the success metrics for each feature or initiative before development begins and measure its real impact after launch.
•Collaborate with engineering and design throughout the discovery and delivery process to ensure solutions are viable, usable, and valuable.
•Communicate product strategy and progress to stakeholders at different levels with the appropriate level of detail for each audience.

Key Skills

Technical Skills

Prioritization frameworks: RICE, ICE, MoSCoW, Kano, and opportunity solution tree for transparent, evidence-based decisions
Product metrics and data analysis: conversion funnels, retention, engagement, and tooling such as Mixpanel, Amplitude, or equivalent
Product discovery: user research techniques, experiment design, and hypothesis validation before implementation
Roadmapping and backlog management with tools such as JIRA, Productboard, Linear, or equivalent
Business analysis: monetization models, unit economics, competitive analysis, and market opportunity evaluation
Basic SQL for autonomous product data analysis without always depending on the data team

Soft Skills

Strategic thinking to connect product decisions with business objectives and market context
Influence without authority: aligning engineering, design, and business behind the product vision without direct hierarchical power
Decision-making under uncertainty: committing to a direction when information is incomplete and adjusting with data
Narrative communication: building compelling stories about the user problem and the product opportunity for different audiences
User empathy to distinguish their real needs from their surface-level requests
Judgment to say no: the ability to decline ideas respectfully and with data is as important as the ability to accept them

Real use cases

Context

The highest cost in product development is not building the wrong solution: it is building the right solution for the wrong problem. Systematic discovery reduces that risk.

Real examples

User interviews to identify the most frequent and most painful jobs-to-be-done
Demand experiments with prototypes or landing pages before committing the engineering team
Behavioral data analysis to identify where users are dropping off in current flows
Product hypothesis validation with the minimum viable experiment before building the complete solution

Context

A roadmap without strategy is a feature list. A strategic roadmap communicates the product's bets and the problem each initiative solves — not just what will be built and when.

Real examples

Defining a two-to-three-year product vision connected to business objectives
Outcomes-based roadmap instead of outputs-based: which metrics each initiative will move
Quarterly roadmap review process to incorporate learnings from the previous quarter
Communicating the roadmap to stakeholders with different levels of detail based on their audience

Context

Prioritization is the PM's most frequent and most difficult decision. Without clear criteria, it becomes the sum of the loudest stakeholder's pressures.

Real examples

Implementing a shared prioritization framework (RICE, opportunity solution tree) with the team
Facilitating prioritization sessions with stakeholders using objective criteria to reduce internal politics
Managing the technical debt backlog in the context of product priorities
Honest communication of why some ideas are not entering the roadmap, with documented reasoning

Context

Without clear metrics, the team builds features without knowing if they work. Product metrics connect the team's work with the impact on users and on the business.

Real examples

Defining the North Star Metric and the input metrics the team can move directly
Product instrumentation to capture the behavioral events needed to measure impact
Post-launch analysis of each feature to determine whether it moved the expected metrics
Product dashboards that give the team and stakeholders visibility into the product's health

Context

A well-built feature that launches poorly does not generate the expected impact. The PM coordinates the launch with marketing, sales, support, and communications to maximize adoption.

Real examples

Beta testing coordination with selected users to validate the feature before general release
Briefing the support team with new feature documentation before launch
Rollout strategy design: gradual release by user segment or cohort
Feature adoption measurement in the first weeks post-launch with predefined success criteria