Product manager

The Product manager (PM) is responsible for the direction and priorities of a digital product. They connect user needs with business objectives, then work with teams to choose which problems to solve. Their role is to set the product's direction and assess the value of the changes delivered.

This responsibility involves bringing together different types of information: user feedback, usage data, market knowledge and delivery constraints. The PM weighs these up to clarify product objectives and set priorities. The roadmap makes these choices understandable; it evolves when new information warrants revisiting them.

The scope depends on the organisation. In a team with specialists, the PM draws on their research, analysis and proposals. In a smaller organisation, they may take on more of the work of understanding and documenting needs themselves. When defining the role, specify the resources available and the decisions they will own.

Product manager, designer and developers: who does what?

• The Product manager sets out the product direction, organises priorities and brings together the perspectives of the stakeholders involved.
• The Product designer contributes to design and prototyping in collaboration with the PM.
• Developers handle technical delivery and provide the information needed to assess the constraints involved in building the product.

These contributions inform one another: choosing a problem, designing a response and assessing its feasibility require discussion. Recruitment should therefore clarify working relationships as well as individual tasks. Also specify whom the PM discusses objectives with and how disagreements are resolved. This profile covers digital products; the French title “chef de produit” alone does not establish an equivalent scope.

The first challenge is to focus the team's efforts on a problem worth solving. A request can be specific without revealing the need behind it. The Product manager brings together expressed expectations, available information and business objectives to inform the choice. For a business leader, what matters is being able to understand why one change takes priority over another.

Keep priorities easy to explain

A roadmap commits the team to work. If every request changes its order without a discussion of the consequences, the team risks losing sight of the reasoning behind earlier choices. The PM needs to compare expected value with effort, explain trade-offs and revisit assumptions. A clear direction allows room for learning without turning every new request into a priority.

Fictional example: a team receives a request for an additional feature while users are already encountering a problem in the existing journey. Before choosing, the PM gathers information about both problems and discusses the effort involved with the technical team. The decision can then focus on the value sought, rather than depending solely on one stakeholder's insistence.

Understand what the change achieved

Releasing a feature is not enough to assess its usefulness. Measuring outcomes helps the team examine what the product delivers and decide what to do next. Metrics therefore need to relate to the problem being addressed, and the data must be interpreted with its limitations in mind.

• Understand user needs through research, feedback and information about usage.
• Analyse the market and stakeholder expectations to inform product choices.
• Set out a product direction that connects the problems to be solved with business objectives.
• Compare the expected value and effort of changes to set priorities.
• Build a roadmap that can be revised and explain its choices to the teams involved.
• Collaborate with design and development to explore ways of addressing the prioritised needs.
• Work with teams to define metrics for assessing product outcomes.
• Analyse outcomes and revise decisions when the information gathered warrants it.

Backgrounds in engineering, design, management or marketing can prepare someone for Product management. They offer different starting points: technical understanding, design, economic analysis or knowledge of users. Readiness for the role also depends on what the person has learnt through practical experience with the product and other disciplines.

Connect the background with the skills gained

To assess education or training, look at the abilities developed: analysing a problem, using information, understanding an organisation's objectives and communicating a choice. A qualification title tells you less about the expected level of autonomy than practical work using those skills. A certification can inform this discussion without being sufficient evidence in itself.

Experience in a related discipline deserves the same approach. Someone with a design background may have worked on understanding needs; a technical background can facilitate discussions about delivery. Also examine what remains to be learnt, particularly prioritisation or connecting user value with business objectives.

Match autonomy to the role

For a first product role, consider a clearly defined scope and explicit support. The British framework describes an Associate Product manager role covering part of a product, with support from more experienced PMs. This is an example of how work can be organised, to be adapted to your team's resources.

For a role requiring autonomy, focus on the nature of the responsibilities already held: choosing priorities, collaborating on delivery and using outcomes. Clarify the resources the candidate had available to assess what they could apply in your context.

To assess a Product manager candidate, draw on their past decisions and an exercise that reflects the role you are hiring for.

1. Define the criteria for the role

Before interviews, agree on a common assessment framework: understanding needs, reasoning about priorities, use of data, cooperation and autonomy. Link each criterion to an actual responsibility of the role.

Specify the resources available in your team. A candidate who had support from researchers, analysts and designers will need to explain their personal contribution to the collective work. Avoid confusing the scale of their previous product with the scope of their responsibilities.

2. Reconstruct a past decision

Ask the candidate to choose a change they actually worked on. Have them explain the initial problem, the users concerned and the objective pursued. Then revisit the information they had when making the decision.

Ask concrete questions: “Which options did you rule out?” or “What information might have changed your choice?” If possible, ask for an anonymised document they are able to share: a roadmap, research summary or analysis.

Clear reasoning that acknowledges limitations is a positive sign. An account focused solely on features delivered deserves further exploration. Distinguish what the candidate decided, recommended or merely supported.

3. Observe a trade-off in practice

Prepare a short case based on the expected responsibilities. Give candidates the same information and let them ask questions to clarify what is missing.

Fictional example: present two requests for changes, incomplete user feedback and a capacity constraint. Ask the candidate to propose a priority, explain their assumptions and identify the information to seek next.

Assess how they compare expected value with effort. Also observe their response when new information contradicts their initial choice. A useful answer makes uncertainty visible; immediate certainty without examining the data calls for further questions.

4. Examine cooperation and outcomes

Ask them to describe a disagreement with design, development or a business stakeholder. Ask how the different views were collected, who made the decision and how it was explained.

Then revisit the outcomes of a change. Which metrics had been selected? What did the team learn after release? What change did the candidate recommend based on this information?

Value nuanced analysis. A collective result does not, on its own, prove the quality of all the candidate's decisions. Examine their ability to identify other contributions and the limits of interpretation.

5. Compare assessments

Involve a product colleague in analysing the reasoning and a technical representative in discussions about feasibility. If this expertise is unavailable internally, have an experienced product professional review the case and its criteria.

With the candidate's consent, use references to clarify their scope and how they work with others. Ask about situations already discussed, then compare the observations with the initial criteria. Record what has been established and what remains to be clarified before deciding.