Part of ManoMano (MM)’s HR policy is based on internal mobilities. In this article, we are discussing with 3 employees who transitioned from a business or tech position to a Product Management (PM) role. Julien Lecarpentier was a backend developer at MM, Etienne Savey was in the Quality Team (in charge of integrating our seller’s catalog feed) and Clement Caillol was Analytical Lead at Google. They explain why they became PM, what they expected to do and what they really do and how it changed their perspective about the PM job now being on the other side. We hope this article will help anyone wondering if he could transition into a PM role or give a better view on the PM job to business and tech persons! Enjoy the read and feel free to share your own experience!
Julien (formerly in engineering): I wanted to discover something else than tech world. I also realized by working with the PM of my team (SuperMano, jobbers marketplace within ManoMano) that I was more interested in challenging problems and finding solutions on a user perspective rather than on a technical perspective. I now realized with more perspective that I am even still more attracted towards User Research and Product design than Product Management.
Etienne (formerly in business): When I started working at ManoMano I was probably the person using the most our back-office tools since the main part of my job was integrating new merchants’ catalog. At the beginning, I was nevertheless able to spend up to 50% of my time improving our internal tools. As ManoMano became bigger and bigger, I had no more time to allocate on tools improvement and I missed it. I also got staffed with management duties, up to 80% of my time, and realized I prefered creating things. That’s why I started considering to join the product team
Clement (formerly in data): Before joining ManoMano and the product world I pursued a career in data and analytics during 5 years before finding myself in some kind of a dead-end, unsatisfied with purely consulting roles. My frustration stemmed from relying on others to take actions on my recommendations. So my move to Product Management was greatly influenced by a desire to have tangible and measurable impacts on organisations and users. Additionally, I would also say that one of the key appeals I found (in analytics as much as) in product management is to be able to simplify and communicate tech possibilities and constraints to non-tech people.
Julien (formerly in engineering): I knew data was key in this role. I acted as a data guy for my PM, to me it should be necessary to have a dedicated role in each Team. I saw the PM as the one who participated actively to building the product roadmap of key features to develop, explaining why, prioritizing them, checking their impact, etc… I thought PM’s role was mainly about the discovery part: understanding user’s problems.
Etienne (formerly in business): For me, the role was a mix between intuition/data and communication (with the developers and all the stakeholders). I think that I was quite right, and it’s something that all PMs do at MM as far as I can see. However, I also noticed that there is a lot of diversity in each PM, because of their skills and background so that I feel they all have their own way of doing the job. I was also a bit concerned of my limited tech knowledge, but after speaking with other PMs at MM, they told me that it could be even an asset. I would bring the operational and business knowledge and the tech team would handle all the tech challenges. Communication would be key to create alignment.
Clément (formerly in data): At Google, in the sales department, Product Managers were a rare and revered sight and that’s how I initially came to learn about the job. Contrarily to a lot of folks whose job mainly relied on adapting sales content to local context, the PM and overall product organisation over there (Product Marketing Manager were our real point of contact) seem to be shaping Google’s strategy and empowering our end clients to make use of digital media. I didn’t get to work close to PMs before becoming one but I sure was intrigued!
Julien (formerly in engineering): Being PM at ManoMano has probably too much of diplomacy for me… I did not expect so much meetings with business, so much energy to put in to negotiate and get your features on the roadmap. Trust from business was very limited in our prioritization, you had to always go back to the reasons of your choices. It was really hard to have them understand that they were not our clients, that our users were and that their feedbacks were only a small part of the equation! We have this BO (Business Owner, kind of business ambassador along the Feature Team) role at MM and BOs were not collaborative enough. It was more of a “one shot” at the kick-off and let’s meet again in 4 months to check that project was delivered. They were changing a lot, it was hard to create a trusty relationship. This is for the cons. But there were also many pros! A lot of recognition and gratitude when things got done (much more than when I was a developer!). Working on users’ pains was really rewarding for me as I had expected. And data proved also to be key even if at some point you need a gut feeling. I really appreciated understanding our customer service pain points and helping them better do their jobs (I was in the After-buy team).
Etienne (formerly in business): I was staffed on the Import FT only 2 months ago so it’s still quite new for me. I am comfortable in my current scope because I have a good knowledge of the business aspect given my previous role! However, my feeling is that I still need to learn a lot, especially on the data part (I am getting better!). I work remotely with outsourced developers and directly with the stakeholders, and it works really well probably because EPAM, our contractor, is used to it. I was expecting to have a real impact on the legacy catalog projects (we are currently developing a revamped architecture) and this is clearly the case I am truly happy about what we did and what we are going to do. Reality of being a PM is being a builder on our scope.
Clement (formerly in data): When I became a PM, I remember telling friends that for the first time I would not have clients and would be able to self-organize and make my own choices, empowered by a strong organisation and strong vision. Little did I know that instead of external clients I would get the most challenging and demanding of clients: internal colleagues. I’m not saying that as PM I don’t get to make my own choices (I do) but I surely underestimated how much getting sponsorship and building on strong relationships with stakeholders would be crucial to my succeeding in the role. Today I tell my friends that as much as my background in tech, my masters in political science is a real asset as I feel that my job is similar to that of an elected official: producing a vision, adapting and engaging the organisation around it.
Julien (formerly in engineering): I wish I had had more time working on product strategy and more again about discovery (to improve user experience) but at that time we had big delivery issues for important projects. As I was a developer before, I sometimes had to play a kind of Lead Developer role within the team that took me time away. And I spent probably too much time writing tickets (a Scrum Master arrived and took on this task along with the developers).
Etienne (formerly in business): My main concern is about training to become a better PM, all PMs in ManoMano have now a huge background as PM which is good because they can help me, but in the same time I am the junior and with all the activity in ManoMano it’s not easy to ask a lot when there is nothing in place for this. I think this is for me the most important challenge in the next weeks and I’ll have to work with my manager on it, as I have a lot to learn.
Clement (formerly in data): Four letter: T.I.M.E. When I joined I took over the role of Chloe Martinot who was ManoMano’s first ever CPO and Product Manager on my current scope. I remember her telling me that Scrum would change my relation with time and back then that seemed like an overstatement. Now I realize that she was sugar-coating it for me. Where did time go?
Julien (formerly in engineering): I did not realize before transitioning that PMs spend so much time doing all kind of reportings. I became also aware of the importance of sharing a clear vision with the whole team which I think we could have done better when I was a developer. And I finally realized that what I really wanted to do was design, more than product management. I went back to the dev world because I wanted to move to Bordeaux’s MM new office. I then realized that we were really very far from user concerns! I work on MM’s back-office where no official PM exists. And I really appreciate being able to get the best of the two worlds: understanding our employees pain points through my fresh PM background and being able to develop quickly efficient solutions through my dev background! I was proud to reshuffle our customer service interface within 1 month and to improve their productivity by 30%!! And their wellness: I got so many messages thanking me to have improved their daily life!! This is also about care, one of our value!
Etienne (formerly in business): I realized the importance of the prioritization with the global picture. As a business stakeholder, it’s really frustrating when something you consider as a top priority can’t be included in one sprint, but when having the global picture this top priority task for your service can turn out to be a nice to have at a global level… Now that I am a PM, I really understand that frustration because I had it many times in the past. Because of this I do communicate a lot with the stakeholders when something isn’t taken into a sprint in order to explain why, and reduce the frustration. I think that because of my previous business stakeholder life, I am good at explaining the prioritization reasons we chose.
Clement (formerly in data): This doesn’t really apply to me, as contrarily to Julien and Etienne I directly joined ManoMano as a PM. To be sure, I’m now much more aware of the time and complexity involved in executing tech projects and probably all the more pragmatic in my recommendations.