The Product Manager’s survival kit Part 1: Dispelling some myths

What if your strongest convictions were your biggest traps?

This series unveils the clarification of the Product Manager role within the French Scale-up ManoMano. It has been supported by Product and Business teams from all levels of the hierarchy up to the CEOs. You’re reading the 1st article out of 3.

I always found the Product Manager role unclear, and it weighed on me. I have worked in Product for more than eight years alongside amazing mentors in companies renowned for their Product practices. And yet, up until recently, I couldn’t explain my role in a few simple words. It was driving me nuts — how could I become great at Product Management if I didn’t fully understand the game’s rules?

Product Management has existed for a long time, but the way to do it significantly changed with the digital era. Tech companies shaped this role with a new view of the organization’s structure, leadership, and methods. This is because of specificities at the heart of the digital industry and the paralleled emergence of new schools of thought:

• Unprecedented scalability: economies of scale are tremendous in digital, and the boundaries to conquer the world are lower. In this context, many tech companies first aimed for user growth and, backed by Venture Capitals, could deal with monetization only once they had obtained a massive chunk of the market.
• Unprecedented iteration speed: As Remi Guyot phrases it, “digital allows for an extremely short loop between the design of a product, its distribution, and the measurement of its adoption. So quickly that it’s often better to launch something imperfect — and then correct it if necessary — than to try to anticipate what will happen.” This is the foundation on which are built Lean and Agile.
• Unprecedented tracking: every action leaves a trace, which enables tech companies to understand users’ behavior like never before, fine-tune the experience at a precise level, rationalize decision-making, and drive teams with measurable objectives.
• And in parallel, emerged new schools of thought: Like Design Thinking to get better at innovation and collaboration or decentralized organization models to improve the efficiency and motivation of the teams.

As a product manager, I felt responsible for applying and educating on its resulting principles. These changes were so massive that they created a break in the way of working. The product community was the most conscious of them and what they implied, which is why I guess it was called the “Product Culture” rather than the “Digital culture.” So I felt I had to educate stakeholders around me that were unfamiliar with them. Among these principles was to place users first, not commit to deadlines — as we would learn and adjust on the way — or try to back any decision with internal data.

But these principles often conflicted with the companies’ real-life situations. We know there is no straightforward recipe for success, and we must adapt to each context. This means that these principles eventually come in contradiction with the needs of the company. In my previous experience, we provided a SaaS to big companies’ employees. The administrators were opposed to our way of doing small iterations and adjusting because they had to update their training programs and documentation each time. It was hard to know when to adapt or insist. By being too loose, I would miss out on new and more efficient ways of doing things, but by being too rigid, I could make erroneous decisions considering the company’s context.

I needed an undisputable mission to guide my efforts. The trap with feeling responsible for implementing these best practices was to consider them as the end goal. To give more importance to the application of these principles than to the achievement of the expected impact - while they were just a toolbox to help me achieve this impact. There were famous definitions of the Product Manager’s mission, like “Discover a product that is valuable, usable, and feasible” (Marty Cagan), or in other words, be “the intersection between business, technology, and user experience” (Martin Eriksson). But I found them too vague to help me make trade-offs in real-life situations.

And a thorough understanding of the key principles to make the right trade-offs. As I dug into the product literature, I felt a little bit overwhelmed by all the principles to follow. I guessed that a perfect Product Manager could make perfect sense of them all, but if I were to focus on a few principles, what should they be? I had to understand these principles to the core to convince others or, on the contrary, drop them in front of a greater need. Once all these fundamental principles were completely mastered, I could focus on learning fancier ones.

All in all, this meant applying to myself the methodology I was defending for Product topics. I spent my time saying I didn’t want injunctions on what to do but objectives to reach so we could find the best solutions. That would be the same: clarifying my mission so I could find the best approach to reach it, helped by a set of best practices.

In February 2021, I joined ManoMano, a European unicorn with a strong history of Product culture, to strengthen my skills. ManoMano has been among the first in France to take the Product role so seriously and is still regularly quoted as one of the top companies to do Product in France. Over time, it has given rise to a significant Product community with some of the leading profiles in France.

In September 2021, I realized that the issues I had were occurring here too. After years with a strong Product voice, the business teams complained that we had become too rigid, not listening enough to their needs. Clinging to principles they felt were unjustified. As the company was going through a reorganization to scale after massive fundraising, it benefited from it to rebalance the power relations. It was now the time for Product managers to feel that they were not able to apply “by-the-book” Product best practices.

This was the ideal environment to achieve this clarification. On one side, there were Product people I admired, finding we were moving from best practices. And on the other side, a pragmatic company that had implemented these practices for years, and yet was partly withdrawing from them. I wanted to understand what we were doing that, according to Product leaders, concretely harmed ManoMano’s best interest. Or if there was something, we Product People misunderstood about our role.

I started my investigation with the same methodology as working on a product issue. I interviewed the leaders I knew and deeply respected to forge my own convictions. I also reached out to key influential members of the Product community like Remi Guyot (BlaBlaCar), Amandine Durr (Back Market), Pierre Fournier (Will), Martin Boutges (Doctolib), and Michel Ferry (Payfit) to get a broader opinion and crash test my ongoing reasonings.

It progressively became a large-scale project supported by my hierarchy. The magical thing about ManoMano is an environment that could turn this isolated initiative into a company-wide alignment. The VP Product encouraged me to push the process to the end. Get a company-wide picture, share the conclusions and seek a new alignment about our role. I was given full access. I interviewed +60 people, half from Product Teams and half from Business teams. The objective was to converge our visions in times of collaboration reinforcement. And to our surprise, our differences were superficial. Deep down, our positions were very aligned.

A 1-year-long project resulting in a 3-part clarification. I’m excited to reveal the conclusions that got adopted at ManoMano. They are threefold: the misconceptions of our role (part 1), the mission & key principles (Part 2), and an easy path to raising product practices within Feature Teams (Part 3).

A pragmatic vision. What follows is not a romantic vision of what should be Product according to Product. It’s a practical guide we aligned on at ManoMano to have the most significant impact where the company needs us. The conclusions presented below have been supported by Product and Business teams from all levels of the hierarchy up to the CEOs. It should be helpful to anyone trying to understand the Product Manager role better, either to get better at it or to have better relations with them.

Part 1: Top 5 myths pulling you back as a PM

“The hard part is not to climb up the mountain, it’s to climb down the one you are currently on” (Naval). In the search for a clarification of the role, I encountered wrong beliefs that were spread either as shortcuts or romantic visions of the job. Among them, there was confusion between what can feel most fulfilling as a PM — like innovating — and what the company actually needed. Or between our convictions — like focusing on users and expecting business metrics to follow — and the leadership’s strategy for running a business. These beliefs obscured our judgment of what was expected from us.

MYTH #1: “Product management means user-centricity”

It’s not our role. Designers represent user needs; Business partners represent business objectives. We represent the company’s best interests, which is to find a match between user needs and business objectives. To have a product that is used and serves the interests of the company. Whether we start with business objectives or user needs, in the end, we must address both dimensions. It can feel more fulfilling to start with users, make sense as it’s often the highest risk, and drive a more long-term approach. But it’s not a dogma. Neither of these dimensions is fundamentally more central than the other. The balance between the 2 is very personal to the company's leadership, and the real question may be whether you are comfortable with it.

Real-life example: We worked at ManoMano on cross-selling recommendations to help users purchase products they might not have thought of. The feature was helpful, particularly in the Do It Yourself industry where all users don’t have the technical knowledge. However, in this specific case, we jumped on it because it was the best opportunity to make our business profitable, not because it was the best opportunity to improve users’ life.

-> Instead: Product Management means balancing user needs and business objectives according to the company situation.

MYTH #2: “Product management means innovation”

Said who? Innovation is introducing something new, which is often long and uncertain. We must pick our battles and focus innovation efforts on the areas where we can make a real difference. The best strategy for other parts of the product might be to copy well and fast, not introducing anything new to the market.

Real-life example: Is it wiser at our stage to 1) spend time reinventing payment methods experience or 2) copy payment best practices and invest more time to find how to sell technical products online?

-> Instead: Product Management means knowing where to place innovation efforts.

MYTH #3: “Product management means long-term”

Always more exciting to work in the long term, right? Part of our role is to build a vision for the company and how to get there step by step. But we must have an impact where our company needs it. If achieving short-term expectations is a critical constraint for the company’s health — like getting profitable in a context where it’s hard to raise money — we must embrace it fully.

Real-life example: We all dream at ManoMano of an end-to-end experience where clients can hire an artisan with the materials and the tools for any work at home. But in a profitability context, working on highly profitable cross-selling is a bigger priority.

-> Instead: Product management means balancing short-term, mid-term, and long-term according to the company situation.

MYTH #4: “Product management means making all decisions”

That would be terrible! Ultimately, we are responsible for delivering the right product, but the PM is neither the one that should know everything nor make all decisions. Instead, our role is to ensure that the best decisions are made, by orchestrating a team of experts, each having a piece of the puzzle (design, tech, business, data).

Real-life example: Let’s say I’m aligned with the designer on the context and objectives of a feature, but we have different views on UI directions. If we didn’t reach a consensus, I would follow the designer’s judgment which is much more experienced than mine in this field.

-> Instead: Product management means ensuring that the best decisions are made.

MYTH #5: “Product management means no commitment”

It doesn’t have to be this strict. In a +1 000 people company, it’s inevitable that teams become interdependent and need timelines from others to anticipate. Product Discovery is indeed uncertain, but all topics don’t have the same level of uncertainty, and a significant part of this uncertainty can be addressed before the roadmap begins. At least, we should clarify our plan and try to break it down into small chunks to avoid the underwater effect and the total absence of visibility. It’s not even a loss of time, as it prevents future frictions.

Real-life example: A solution we’ve implemented at ManoMano is to have a 3-month advance discovery for our quarter planning, leave some room to iterate on risky topics, and when it’s not enough we can reshape the plan, provided we discuss it with the impacted teams.

-> Instead: Product management means giving as much visibility as possible.

The myths are not dead for all that. They are deeply ingrained. Now we have the alignment, we need to spread these reasonings within the company to get actual change, and this article is a way to do so!

In the following articles of this series, I will reveal the mission and key principles we adopted at ManoMano, and then share an easy path to implement better Product practices within your Feature Team.

These conclusions are the fruit of a collaboration involving +70 people. Thanks for your precious insights that nourished this project! If you have any remarks, please share. I’m interested to know if these conclusions apply to your context and what might differ.