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

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

Published in

ManoMano Tech team

8 min readMar 4, 2021

This article is the first of a 2-part series, the second part (8 things I wish I knew when I became Product Manager (Part 2 of 2) is available here.

I joined ManoMano — the leading European e-commerce marketplace in the home-improvement sector — in April of 2018 as Product Manager, looking over the Search and Browsing experiences. It was my first job in Product Management, after five years working as a consultant on data and measurement strategies at Google. Nearly three years have passed and I find myself moving to a Lead Product Manager role, passing on the mantle to a Junior Product Manager.

In this article I tried to summarize what have been my main learnings from this experience, and what I wish to share with aspirant Product Managers.

1 — It’s a manager role, but you are only handling a carrot

I took my first PM role after five years of professional experience, right about the time some of my friends and fellow business school alumni were beginning to move to manager positions. For the longest time I did my best to defuse questions about the “manager” part of my job title. “ No, I explained, I’m not the actual manager of the development team, I’m not in charge of pushing for pay raises or validating expenses”.

I came to realize, however, that my statements were not totally accurate. True, as a PM you will normally not be in charge of performance reviews or green-lighting paid leaves. But you will be the functional manager of the team. I think of this image to qualify the subtle difference: if a manager can lead its team with a carrot (vision, reward) and a stick (evaluation), the product manager can only do so with the carrot.

You will not be in charge of setting or reviewing any one member of your team’s objectives. But you will still have to share your vision, and have them share your convictions, to remind them what role they have to play, why they are doing what they do — to appeal to their inner motivation to do the work with the standards of quality that you deem appropriate.

Takeaway #1
If you want your team to deliver on your vision, share your enthusiasm, soothe doubts and hesitations, take suggestions and challenges from your dev team with an open mind. In case the challenges formulated by your team conflicts with your vision, explain why you will discard them (ex: they are not solving an actual user problem, are too complex to implement or affect too few users). Reward best practices by publicly recognizing efforts and achievements. In a word: be a stick-less manager.

Practically speaking thats means: involve your team as early and often as you can in the discovery phase, explain your decision-making process to them, rely on their expertise and give them freedom to challenge decisions up until the last moment.

2 — It is not a technical role, but be curious

The most common question I get asked when I talk about my job as a PM is “ Did you study engineering?”. A lot of remarkable PMs have, I did not: I majored in Communications from a Political Science university. I am not a technical person but the vast majority of PM roles are not either.

I remember walking to a room full of software architects, developers and software-reliability-engineers during my first week at ManoMano and feeling like the odd one out. The topic of conversation was the optimization of processing time between two micro-services. In some cases it took too long for micro-service A to share data with micro-service B which resulted in delivery information not being displayed on the Product Details page.

You can call that a pretty technical conversation — needless to say I could not follow. After a while I asked the room: “ How often does this page fail?”. If it seems like I had a brilliant epiphany and the entire room turned to me in awe, rest assured that was not the case. I had just asked a silly question, because I was the silly person in the room. But sometimes all it takes is a silly question for a problem to be looked at from a different angle. Indeed, only a minority of users were affected by the failure and there were much simpler solutions the team could implement to solve this issue.

Takeaway #2
The lack of technical knowledge that you might think is holding you back is actually an asset that benefits simplification and understanding the big picture. That being said you need to be curious: there is a basis of concepts and processes on which you need to gain a good understanding in order to improve the quality of your recommendations and explanations to Business Owners.

Practically speaking that means: don’t be shy when asking questions to more technically savvy colleagues, help your team see the big picture and keep user interest at heart. However, after some time in a product management role you should be more than familiar with the following concepts and tools: object-oriented programming (javascript and/or python are useful starting points), placing API calls using Postman, caching, streaming vs batch data collection, micro-service architecture, querying databases using SQL, server-client interactions, DOM and HTML.

3 — It’s all about communication

Before becoming a PM I was a consultant for five years. Consultants traditionally have clients, so communication is a natural part of the job: you want to anticipate questions or challenges from your clients, you want them to perceive your work in a good light so that they are best inclined to listen to and ultimately follow your recommendations.

When I started working as a PM I remember telling friends and family: “It feels weird now, because I don’t have clients anymore”. At the time that realization came to me because I would stay entire weeks at the office and never have to leave for an outside meeting.

Well, it took me some time to measure how wrong I had been. True, I did not need to leave the office to meet clients… I would stumble upon them in the elevator, at the water-cooler or even play foosball with them — but I sure as hell still had clients!

If you think about corporate organisations for a minute, you will realize that they are first and foremost sophisticated decision-making machines. Historically, decisions were made at the top and trickled down below. Product Management’s tour de force has been convincing executives that they are better off letting 25 to 30 years-old college graduates make critical decisions while acknowledging that nothing is certain and failure is OK. Of course the Leadership team in your company is never going to sign-off on your decisions if they don’t believe in you. It is tempting to view it as unwarranted scrutiny and interference, but it’s only accountability — you need to earn your partners’ trust.

Takeaway #3
Think of Leadership and Stakeholders as your partners: you want them to feel confident about your methods, your hypotheses and decision-making process. You want to hoard as much confidence capital as possible and the key to this is communication: do not let them doubt you.

Practically speaking that means: invest time and effort in every event involving your team (bi-weekly demos, company wide presentations, steering committees) because they are as many opportunities to show how great a job your team is doing.

4 — Focus on building relationships

If you read Product Management books too literally you will come up with this notion that the only thing that matters is your users and how they react to your product. While this assessment is true in theory, it leaves out a big part of your organisation (see point #3: you have users and partners).

I realize now that at first I was not the PM I aspired to be exactly because I overlooked the importance of building relationships with my stakeholders. I would try to avoid giving lengthy explanations on what we were doing (I simply did not have time or they would not understand) or get into petty feuds about A/B tests interpretation (for some reason I would find the time for those). My relationship with Business Owners was not an asset.

It all changed with two simple actions: I took all of my Business Owners out for lunch individually and then collectively. While the one-on-one lunch said “I care about you and what you can bring to the table”, the group lunch said “but see, there are many voices to hear and my job is to prioritize the user’s”.

From then we could count on healthier relationships, sometimes leading to what I call quality disagreements with my stakeholders: arguments where the other person’s perspective is clear and understood, and a genuine effort is made by both parties to meet the other halfway.

Takeaway #4
While tech may be on the front-lines, you should acknowledge that what you are building is only possible thanks to a collective effort. Dismissing comments, ideas or challenges from your stakeholders is detrimental to both your product and your reputation. Even when they are misguided, you should always address challenges from your Business Owners in order to build stronger relationships.

Practically speaking that means: invest time in getting to know your stakeholders personally, understand their situation and motivations. Be respectful of their challenges as long as they are respectful of yours and always err on the side of understanding. Be patient as you may feel like you are only repeating the same information over and over — what you are in fact doing is building stronger relationships.

Dear Aspirant Product Manager

You are considering a very interesting career path, in one of the sexiest fields there are: Information Technology. As with any career decision, you need to assess your motivations and the reasons that are driving you towards this choice.

Product Manager is a role full of contradictions. The title suggests you are managing a product? But you will be managing people, at times entire parts of an organization. You think it’s a technical role? But you will be evaluated on your ability to transition in-and-out of the technical. You were told to focus solely on your users? Know that you will have to consider stakeholders as true partners and employ your soft skills into building strong relationships with them.

No doubt you can find a company to add PM to your resumé. But if you have what it takes, and share our mentality, challenge yourself to add “PM @ ManoMano” on your resumé by applying to our open positions.