8 things I wish I knew when I became Product Manager (Part 2 of 2)

Takeaways from 3 years of Product Management on the most exposed part of the user journey, at a hyper-growth company.

In the first half of this article (8 Things I Wish I Knew When I Became Product Manager — Part 1 of 2) I shared some of the main learnings of my 3 years of Product Management on Search & Browsing at leading European home-improvement marketplace ManoMano:

1. It’s a manager role, but you are only handling a carrot
2. It’s not a technical role, but be curious
3. It’s all about communication
4. Focus on building relationships

In this second part I focus on what will allow you to have the biggest impact: your ability to make compromises (#5), the preparedness of your team (#6), your ability to document your product (#7) and your ability to increase the amount of tasks and topics you manage (#8).

5 — It matters more to be heard than to be right

I took this advice from my current manager and it was both the most difficult and most relevant I got so far. Let me share two stories to illustrate this point.

About two years ago, I was engaged in a project to redesign Product Cards (individual elements on Search Result Pages showcasing products) a key asset of our #1 page. In the exploration phase I realized that we had no empirical proof that one colorful label on the Card brought any value to the user. Worse, we had hints that users dismissed Cards with the label because they did not understand it. I had concluded that we needed an A/B test to root our conviction on solid evidence. I brought the case to a high-ranking Business Owner and got into some kind of public (this time un-qualitative) disagreement — to put it mildly.

I still think I was right. But our users and conversion rate could not care less. I had failed to be heard, meaning the approach I used was ineffective. What I had failed to understand was why that Business Owner was reacting that way — the reason being we had signed exclusive deals with an important third party to display this label: it could not disappear overnight, and my suggesting it might be removed was what triggered an emotional response.

Flash-forward to last month, and I am engaged in a project to redesign Product Cards (hey, I never said we got it right the first time!). User research strongly suggests our users do not understand yet another label on the product card. Same situation, similar conversation, different outcome: we managed to find a common ground where we would tone-down the label and communicate proactively with third parties to warn of potential upcoming changes.

Takeaway #5
Your goal is to make impactful business decisions. Sometimes “having a point” is not enough to get people to follow and trust you. You need to focus on the person in front of you, understand their situation and motivations (see #4, Focus on building relationships) and find a way to get them to hear you. That might mean you have to add steps between now and the solution you are offering: it is still better than the status quo.

Practically speaking that means: study your stakeholders as if they were your users. What situation are they in? What are their motivations? What are they not telling you that you can guess with their reactions? Show them you care about them and the situation they are in, that you are willing to make additional efforts to find a workable common ground.

6 — Invest time in building muscle-memory

Last week, a new developper joined my team. Before we could share any documentation with him, he asked about a Jira issue he had seen on our board: “Why are there 3 emojis in the title?”. Where he saw three emojis (⚽️👯‍♂️🧩), the rest of the team knew that this ticket was a front-end development (⚽️) that should be carried out in pair-programming (👯‍♂️) on a react-fragment project (🧩).

In sports, the best teams are the ones who come the best prepared. Teams that trained so often on the same set of plays that they have developed muscle-memory: they know exactly what to do in any situation.

To paraphrase my favorite psychological concept from Daniel Kahneman’s Thinking Fast, Thinking Slow, building muscle-memory is removing the need for any conscious psychological investment in executing an action. Actions that are carried out this way (using our fast System 1) are automatic, you do not need to think when you do them, so in effect you preserve your conscious psychological and mental capacities for more complex tasks that require your entire focus (System 2).

Delivery (actually building, testing and shipping the code change) is an inherent part of Product Management. It is what sets us appart from consultants who stick to recommendations. However, oftentimes we invest all our conscious mental capital on delivery and we loose sight of the real deal: improving user experience. By building muscle-memory for you and your team you are in effect lowering the mental cost of delivery to a minimum.

Takeaway #6
You need to move past delivery. It is easier said than done for sure, and sometimes does not entirely rest on you (infrastructure, enabler teams, etc). But as much as possible you and your team need to standardize everything you do so as to define a framework (or playbook): in every situation your players need to know the play.

Practically speaking that means: Scrum is a great way to start since it comes shipped with the concept of Continuous Improvement. Invest time in your team’s retrospectives, share ideas, build on teammates ideas. Depending on organisations you will be able to rely on Scrum masters, Agile coaches, Lead Developers or even Engineering Managers, but in other cases it will fall upon you to keep track of actions, formalize team decisions, enforce best practices. It might not be exactly what you were hired to do but it will serve your objectives.

7 — It’s all about documentation

As a PM documentation should be your #1 priority, it is critical to the success of your product. Yet in my experience I find that our general approach to documentation is ineffective.

In fast growing start-ups time is scarce and there is a bias towards action at the expense of pretty much everything else (communicating, measuring impact, building for scale) — most start-ups motto is a variation of “move fast and break things” or “ask for forgiveness not permission”. Documentation (explaining how your product works) typically falls in a “non-action” category of tasks that are often overlooked. But as your company grows the accumulated documentation debt tends to slow it down. To repay this debt we often rely on ad-hoc efforts or resort to wishful thinking.

The issue is that documentation is always an after-thought: it is once a product is built and shipped that you then go back to documenting it, which feels like a chore. What does not feel like a chore though is the exploration phase of product building, when everything is possible and you get excited as you slowly see your ideas take off the ground. That is actually exactly the time you need to be working on documentation: at the same time as you are building your product.

Takeaway #7
As a PM you are solely responsible for the quality of your documentation. If you only had one responsibility it would be this: clearly stating how your product works, what underlying set of hypotheses and rules compose its architecture, how to debug it, to challenge or improve it. Instead of wasting time documenting after you built your product, consider everything you do during the exploration and implementation phase of your product as documentation and centralize it on a single document.

Practically speaking that means: every decision, meeting notes, Jira tickets, mock-ups, dependencies, hypothesis should be centralized on a single document. My teams and I use an in-house template we call Documented Product Exploration (DPE) which brings under one roof
i/ the exploration (problem space, user research, data points)
ii/ the implementation (solution space)
iii/ the underlying rules and caveat (the stuff that usually comes out late during the development phase).
By using this method we produce documentation at the same time that we build the product: thus not wasting time on documentation.

Want to know more about our documentation process? We have compiled our best practices in an article that will be published in the following weeks. Follow me (Clément Caillol) and ManoMano team to find out when it comes out.

8 — Become a productivity machine

Back in my high school senior year, I remember reading about the Solow Paradox, with this quote: “You can see the computer age everywhere but in productivity statistics”. American economist Robert Solow coined the phrase in 1987, as a way to qualify the sluggishness of productivity growth* he observed in the 80s and 90s, as Information Technologies (IT) were becoming ubiquitous (* if you’re interested in this topic Wikipedia tells me the debate is still pretty much raging on).

A friend of mine who worked as an IT consultant for some time used to tell a story that might explain why productivity statistics still do not reflect the computer age. Consulting for a Telecommunications company he was tasked with setting up an internal database of financial information. He was referred to a financial analyst whose role in enriching data was critical to the entire project. With immense surprise, as he was shadowing the analyst, my friend realized the part the accountant played in the process consisted in printing out hundreds of pages of excel tables and doing mathematical operations manually for each row, before typing the output back to excel manually…

I know that story seems too good to be true — but it is. Now think back to the tasks that you do on a daily basis: can you in full conscience claim that you are leveraging the near infinite ressources for automation and productivity gains that are at your disposal? Surely not, but in my experience being a great PM will require it of you.

Takeaway #8
Streamline everything you do, constantly. Never settle for one way of doing things but explore alternatives, remove friction in operational tasks. Become a productivity machine in any action you carry out, and you will start to see that the amount of things on which you can work and follow in parallel is almost infinite.

Want PM productivity tips? The Product Team at ManoMano has compiled all their best practices in an article that will be published in the following weeks. Follow me (Clément Caillol) and ManoMano team to find out when it comes out.

Dear Product Manager Old-timers

I’m hoping this series of article (see the first half, 8 Things I Wish I Knew When I Became Product Manager — Part 1 of 2) attracts as much interest from aspirant Product Managers as from industry old-timers (if there is such a thing).

There are as many ways to be a successful Product Manager as they are companies, even contexts — my comments exposed here are simply a relative insight. But I feel over all the differences we could list we find ourselves in similar situations: having embark our organization on our vision, working alongside stakeholders and partners that sometimes have very different interests, building the most efficient teams, being best versions of ourselves.

I’m interested to hear it from you: what advice would you give aspirant PMs as they embark on this exciting career?

Aspirant Product Manager, PM old-timer? If you have what it takes, share our mentality, and want to be part of a strong product culture: challenge yourself to add “PM @ ManoMano” on your resumé by applying to our open positions.

Acknowledgements
The publication of this article was made possible by the thorough proof-reading and constructive criticism of Mariana Lagneau, Yohan Grember, Rémi Hattinguais, Sergio Rodriguez, Luca de Battista, Amandine Durr, Edouard Winia, Fanny Lenglet, Margot Le Rouzic and Grégoire Paris.