The making of a product-centric organization: key takeaways from the French scale-up ManoMano

Published in

ManoMano Tech team

41 min readMay 25, 2020

This article gathers into a single place all our learnings about the set-up of a product-centric organization at MM (ManoMano). MM is a French scale-up specialized in e-commerce, leading online European DIY (Do It Yourself) space, see details at the end of the article.

The company grew from 2 product teams in 2017 to 25 in 2020 (others name them squads, feature teams…). The Product department is made of around 50 people, mainly Product Managers (~35), Designers (~10) and User Researchers (3). The team also included QA (Quality Assurance) until the end of 2019, this is why the topic will be addressed in this article. The whole tech department at ManoMano is about 250 people as of the beginning of 2020 (software engineers, data scientists and data engineers, architects…).

Product Management is still relatively new in France (even in Europe) and we wanted to share a tangible example through MM’s case with the tech community. Indeed, great books will tell you about Product Management theory (eg. Inspired or Product Leadership, my two favorites) but when it comes to real life examples, it becomes harder to find extensive resources (Spotify did a great job to share their story beginning of 2010’s). Everything is far from perfect and we will be very transparent about the mistakes we made. This post compiles, refers to and adds some perspective to all the blog posts published by the Product BU (Business Unit) between 2017 and 2020.

We hope that this article will help various profiles:

Young PMs (Product Manager) to better understand how to create impact
Start-up founders to build Product Centric Organizations
Senior Product Managers to scale their organization
Larger and more project-oriented organizations to make the transition towards this (still burgeoning) model…

Feel free to share your comments or your questions at the end of this article to make it a lively source of inspiration.

Like in Product Development, where we start with problem framing, please find the main issues we faced at ManoMano and will cover through this article:

Setting strong foundations for a product centric organization: how do you transition towards an organizational model based on cross-functional, autonomous and mission-oriented teams when it is not the company’s DNA? How to foster collaboration within these teams between heterogeneous stakeholders, coming from business or engineering backgrounds?
Scaling the product team: how to solve the complex recruiting equation in a growth context between “quantity” (especially in a dry market like the EU) and quality (without exploding HR costs)? How to know when to “buy” tools to speed up developments or take time to “make” tools to differentiate? Once fully decentralized, is a CPO (Chief Product Officer) still useful for the company?
Fostering user-centricity: in a limited resources context and in a seemingly design-mature industry like e-commerce, how to convince the company to strongly invest in UR (User Research) and design? How to conciliate the need for scale (design Ops) with the need for a human touch (DIY is a lot about advice between communities)?
Developing a reasoned data culture: how to make available clean product data to everyone in the team (and the company)? How to keep a balance between a strong data culture and the (necessary) business gut feeling? How to get the data science team and the product team collaborate while having quite different timeline?
Setting-up a decentralized QA culture: how to foster a strong QA culture in the whole tech department in parallel with a fast delivery culture? How to guarantee a bullet proof code as the number of features grows, while keeping the QA team staffing reasonable?
Growing your team members: how to coach a very distributed team whose main skills are soft skills? Which quality should you aim at developing within your teams to create real product outcomes? Which framework can you share with your overwhelmed team so that they can take a step back and make up their product strategy?
Being product-centric for real: How to really shift your company mindset from “shipping features” to “solving users’ problems”? Is a product centric organization compatible with the traditional BU approach (marketing, sales, ops…) ?
Conclusion: What should be the 4 key points to remember? How to move scale-ups from Next 40 (a French Label for most promising startups) to CAC 40 (equivalent of US Nasdaq) ? How to develop a long-term product vision in a VC-funded company? What is the future of the PM job?

We hope you enjoy this read as much as we enjoyed developing this Product BU!

Acknowledgements

This work is collective, I was in charge of the Product at ManoMano during almost 3 years but nothing would have been possible without:

The back-up of Philippe de Chanville (one of ManoMano’s two co-founders) who came to see me in 2017 at a time where Product Management was not so hype, and his continuous trust whatever we tried during the journey (and also the one of Christian Raisson, the other co-founder)
The seeds that Chloé Martinot (former CPO) planted before my arrival around Product centricity and the drive she demonstrated during my first 2 years to foster a user-centric approach
The invaluable help of Emmanuel Hosanski (Product Director) in running part of this product unit and the incredible maturity he displayed for such a young leader! And that of Nicolas Martin whose listening and communication skills proved to be so useful.
The resilience and determination that Oliver Dennemont pulled together to build a great QA spirit at ManoMano (QA was previously part of the Product team)
All the other members of the product department, especially Clément Caillol for his passion, Romain Mazuir for his commitment, Grégoire Ducroq for his drive, and all our junior Product Managers for their enthusiasm (Mathilde Dujon, Pierre Devaux, Etienne Desbrieres…). Also a big thank to Elise Berthet and Gary Delporte in the design team who have been standing still even during the long transition period where we had no design leader
A warm welcome to all the talents who joined us more recently (Amandine Durr, Sophie Muto, Denise Jones…) and who will keep developing the product within ManoMano
The support of Christophe Dargnies, the other ManoMano’s CPO (Chief People Officer), and the fresh eye he brought into our tech world which sometimes acts too much in a vacuum

A product BU offsite in the countryside (2018)

1/ Setting strong foundations for a product-centric organization

1.1 What is product-centricity and why is it important?

I would define a product-centric organization as one where users’ interests prevail over short-term business interests, and which mainly relies on autonomous, mission-oriented (vs. project-driven) and cross-functional teams to run.

To make clear what a user-centric mission means vs. a business-oriented one, I will give you the following example. A business-oriented mission would be to increase the conversion rate. A user-centric mission would be to improve the catalog’s accessibility (filters, bundles, relevance…). The good news is that it should also improve the Conversion Rate.

In the early days of MM and till 2017, Chloé Martinot (former CPO) planted important seeds towards this direction, which was challenging, because MM had built its success on two strong BUs in the company:

Sourcing: attracting Sellers to our platform
Marketing and especially acquisition: attracting Visitors to our platform

MM’s value proposition relied mainly on price and choice, as many e-commerce companies. Philippe de Chanville (one of the 2 co-founders) was feeling at that time that the next growth stage would be fueled by a more differentiating Product, helping MM reach his vision to allow everyone to sustainably make its own kind of world (company’s mission). The goal was (and still is) to expand MM from an e-commerce platform to a DIY global services platform (inspiration, advice, buying, sharing…). The first step was to turn MM into a more product centric organization to be able to deliver along this new strategy. Why?

Break silos to bring multiple perspectives in our product shaping: a traditional organization limits collaboration between traditional BUs (sales, marketing, ops…) whereas this collaboration is mandatory to build complex products. If you think of relevance issues on our website, it includes several dimensions, from acquisition constraints (marketing) to product attributes issues (ops) to sellers visibility options (sourcing).
Put user experience at the heart of our product conception: traditional organizations tend to favor their business metrics (cost of acquisition for marketing, GMV -Gross Margin Volume- per seller for sourcing, response time for ops…) rather than user metrics, thus undermining the value creation in the long term. I will give you a clear example: when you searched for “Wireless drilling machine Makita 18V” (so a very precise product query!), you got more than 500 results! Why? Because sellers noticed that if they wanted to be listed in the results, an efficient way was to create artificial new “articles” (like a drilling machine + a battery). While maximizing their visibility (thus their sales), our users clearly suffered from this approach (500 results for a given product)…
Be driven by outcomes rather than features: when your product grows and becomes more complex, executives can’t just say “you have to develop this feature” anymore. Even if it worked in their previous company. Because each situation is different. For instance at ManoMano, delivery speed is not so important against reliability because our users usually order well ahead and need to have all their furniture to be able to start their construction work. Developing the right product starts with understanding deeply the need of your customers, the related problems, the expected outcomes if you were to solve it and finally shaping the right solution (feature). Not the contrary.

More than 500 results for quite a precise product query…

A good test to know if your company is product-centric or not is to look at the kind of metrics people push when pitching a new project. Do they talk about business metrics or users metrics ?

1.2 Becoming product-centric

We set our first actions in a reasonable time (6 months), mainly focused on Delivery (last part of the Product cycle, first one being Discovery and then Strategy according to Marty Cagan’s Inspired framework). They were quite successful. Employees are young at MM, many had read articles about product-centric organizations and were eager to experiment this model. On the business side, people were easily convinced by the promise of a better and faster delivery of the tech features. It was a major improvement as they just had come out from a big tech migration. You will find some recommendations below but keep in mind that they highly depend on your DNA (is your company driven by tech, sales, marketing…), your size (start-up, scale-up, mid-cap…) and your departure point (tech start-up vs. a big project-management style company). You will find more detail in the original article, how we turned ManoMano into a product-centric organization?:

Hire a seasoned leader who has experienced companies with a strong product centric organization. This will give him or her a strong legitimacy. France lacked (and still lacks) this kind of leader in 2017. I personally had some skills but not all. In the US, Philippe would have had more senior profile options on the table! Being appointed by the CEO gives a strong signal to the whole company that a new era is about to begin.
Align key stakeholders of the company on the meaning of a product-centric organization (you can have them read a book like “Inspired” by Marty Cagan, it will be a useful basis for discussion). You would be wrong to think that your vision is shared by others (see the last part of this article). Double your efforts when people come from many different product backgrounds. Have them envision how the company would be run once the model is fully deployed (what about strategic decision-making ? Decentralization? Resources sharing and allocation?).
Recruit User Researchers (at least one) to give more legitimacy to Product BU through User Knowledge (the only true asset and legitimacy of a Product BU). You will face pressure to postpone these UR recruitments (“it can wait, PM can play this role”…). Hold on tight on this recruitment!
Transform the company progressively (vs. a big bang) by introducing new behaviors one after the other. Aim at frequent small victories rather than a never coming big one. Start by setting up your first product team with the most engaged employees to demonstrate the value to other teams and on your most customer oriented features (eg. browsing team, relevance team). More technical teams (eg. payment team, ad/martech team…) can still be run the old way since it is more about shipping projects (eg. setting up a new Payment Service Provider for the payment team) . A PM in this team could even be counterproductive at the beginning.
Change your governance to favor autonomy and decentralization. Give your teams clear objectives but let them decide on the best way to reach these objectives. Don’t set a fake autonomy for your teams, especially when you hire great talents, or they will leave (because this new organization will raise high expectations of empowerment within employees)

Always remember that users’ knowledge will be the only true asset of any Product BU in a company

1.3 Fostering collaboration within extended product team is critical

The product team organization at ManoMano

Fostering collaboration within each product team should be your next focus once product-centricity is on its way. Shipping a great tech product is complex, requiring a high level of collaboration between multiple stakeholders from heterogeneous backgrounds (see figure above). Shipping several tech products is even harder because of the need for synchronization between all the teams. Here are some of the principles we follow at ManoMano, see the full article for concrete examples and (not too boring) diagrams (Why do all tech companies converge towards the same product organization? ManoMano’s case). Again, whatever name you give to your teams (product, squads, feature…), they will never make it without a strong collaborative spirit (vs. a Business Unit mindset) among team members.

The product team is at the heart of the organization and does include business stakeholders in its extended version
Some resources are shared at an aggregate level (UX, Agile coach and QA at a Group level gathering 2 to 3 teams, Product Director, Architect, User Research and Engineering Manager at a Tribe level gathering up to 10 teams)
The whole team shares responsibility, like in a relay-race where no specific individual can be blamed for if the stick falls (but everyone gets praised if the team wins). Product team (eg. browsing team) sense of belonging should prevail over Business Unit (Marketing, Sourcing, Ops…) sense of belonging for instance through shared Team OKRs for all the team members
Business Units are included as much as possible. For each product team, we created the Business Owner role in each related BU when relevant (Marketing, Sourcing, Operations… ). They are dedicated counterparts for the Product Manager bridging the gap between BU’s needs and Product Team resources. We even favor internal mobilities to allow Business persons to move into a Product Manager role, have a look at these fresh PMs interviews to see the perspective it brings.
PM owns the product strategy, which requires a great deal of discovery hand to hand with User Researcher (and potentially Business Owners) and Product Designer who designs the solution. We don’t have a PO (Product Owner) role at ManoMano. For me, it is a PM job without the strategy part or an engineering job without the coding part. PO’s role tasks are shared among the whole team (PM does the backlog grooming, Scrum Master does ceremonies animation, Engineers writes the detailed tickets…)
Engineers are responsible for the delivery. One could say the PM has to do the right things while Engineers have to do things right. But we try to integrate Engineers from the very beginning of the product development process, for instance by having them participate in some user research sessions. Data scientists are there when needed, not all the time because their timeline (weeks or even months) is different than agile timeline (sprints).
Agile coaching, QA (Quality Assurance), UR and even Design (through its Design Ops part) tries to spread their philosophy within each of the Teams and are in charge of educating (methodologies, techniques…) and setting the right tooling when needed

This organization works pretty well even if some challenges remain hard to tackle, mainly:

Dependencies management between several teams for big projects, both functional and technical (Program Managers can help)
Topics falling in the middle of several teams (we would like to try Impact teams, temporary teams made of different teams members with a well-defined topic to solve in a time-limited horizon)
Crazy rhythm dictated by scrum sprints. Experimentations like Shape-up from Basecamp could be worth trying to mitigate this effect.

At MM, we rely a lot on Cagan’s framework to divide Product Management activities into Discovery, Strategy and Delivery as described in Inspired. As you can see, we started to work first on the Delivery part. Some might disagree but for me, Delivery is the easiest part to address. Bring in some great agile coaches to help teams to organize (using lean methodologies) and you should see the first results quickly, both in terms of delivery pace and reliability. This will please Business people who will have a better visibility about the features to come. We provided them with quarterly Release Plans and organized demos, tech roadshows, tech releases… But it is only your first step: you don’t want to ship features, you want to ship outcomes. Changing the whole organization’s mindset from “shipping features” to “solving users’ problems” is really the hard part, we will talk about it in the last part.

Again, whatever the name of your teams, the processes you set, the only thing that matters is collaboration and team spirit

2/ Scaling the product team

There are some classic pitfalls in growing an organization that you can easily avoid when you know them ahead! As the company’s size grows, processes appear (even if we try to limit them to the maximum), decisions are more complex to be made because dependencies are higher. Inevitably, some former employees who don’t recognize themselves in the new organization will leave. Don’t take it personally, it’s just like that. They will be happier in a smaller organization and you won’t feel guilty anymore.

2.1 Setting the right environment for your team to scale without suffering

As the manager of the Product BU, your main mission is to set the right environment so that your BU members can work as smoothly as possibly. I see two areas of attention in a fast-growing context: support through senior leaders on the one hand, time protection on the other hand. You will find all our tips from our experience to smoothly scale in this article.

As regards to coaching and support, the main difficulty really lies in the senior leaders recruitment, because of the lack of seasoned tech leaders in France and even in Europe. Yet, the key to make the growth smooth is to hire first these profiles and let them staff their team. It is critical that you recruit your team’s leads first even if it is easier to hire junior profiles. They might start doing some Individual Contributor work at the beginning (and should be happy to) but they will help you hire their team as well as they will be able to choose their own team members. This is critical otherwise you might end up with too many junior people who won’t benefit from the appropriate coaching and will lose faith as well as undermine the Product BU legitimacy.

Protecting your team to allow it to work efficiently is critical when the company grows: projects surge exponentially and PMs can quickly get overwhelmed and interrupted continuously. Set clear company goals so that each team knows what matters. Defining a limited number of company goals (4) was one of the most impactful decisions I could make as a CPO (along with my peers in the C-suite). All of a sudden, PMs had a strong legitimacy to say no to projects who did not contribute to one of those goals. Reality was perhaps a bit more complex to handle than a simple “no” for PMs, but it truly helped. As a CPO, you can also set some routines in your organization for your teams to be able to focus more efficiently and without hurting the relationship with their stakeholders (for instance we created two no-meeting half-days so that PMs can deep-work).

To ensure a graceful growth, start by staffing the top of your pyramid, even if this pyramid is thin and that senior profiles are hard to recruit!

2.2 Recruiting with high standards in hyper-growth context

Recruitment is the key in sustaining your growth and staffing pressure can easily make you lower the bar in terms of quality. You have to resist the temptation of quick hires (prefer external resources by the time you staff internally the job). Here are some guidelines based on the mistakes we made and the solutions we figured out. Feel free to read the whole article:

Make your company attractive for Product Managers. In the short-term leverage your network, your company’s vision and values and the way you do Product Management (don’t underestimate how it can be attractive for employees suffering from their current company’s values and way of doing Product), the stocks opportunity. Hire recruitments agencies. In the same time, work on a longer-term strategy through your employer branding (blogging, conferences, talks: choose a differentiating angle based on your convictions to make your content stand out from the crowd). Hunt intensively while remaining personal: spend time qualifying and understanding candidates’ professional journeys. You better spend twice as much time qualifying profiles and send twice less messages
Provide candidates with the least painful and most appealing experience: competition is fierce about talents, you have to take risks and make up your decision with only 80% of confidence. We use a shared decision grid to pass the information from one round to the next: it allows us to reassess qualities where a candidate failed and to have a shorter interview cycle. Make intensive use of real Product Case study for your interviews (example here): case study based on real examples from your company enables you to give a good snapshot of your company products portfolio to the candidate. Fragmenting your case study into small questions assessing one quality at a time allows for modular interviews (no need to retest skills the candidate validated in a previous round) and give concrete material for brainstorming
Interview as if you were doing User Research to avoid mistakes: listen a lot, leave blanks to see if the candidate is comfortable with silence (he should be able to do great UR), be intentionally vague to see if the candidate asks for clarification (no user ever expressed clearly a need!) and check for self-awareness. The main mistakes we made were on fit (test Emotional Intelligence) or set-up (diversity mix, senior employees ratio…) rather than on candidates’ hard skills (except when going under too much recruiting pressure…)

Recruiting decision grid passed from one interviewer to the next

Recruiting is a long-term battle that will pay off a lot at some point, so do it very regularly and intensively from the beginning

2.3 Make or buy decisions grid

Make or buy decisions will be some of the most critical decisions you will have to make when your company grows. Buying solutions is very tempting to speed up your development but it can turn into a nightmare if your decisions criteria are not the right ones, with cost exploding or a never-ending dependency on a third-party provider below the competition… Making tools can still make sense if your volumes are high or if you can rely on low level off-the-shelf bricks that you can orchestrate (kind of a “make AND buy” approach). So take care of the following criteria:

Data ownership belongs to MM and is not mutualized with other clients to improve the tool (and your competitors!). Backward compatibility keeps us free to reconsider our choice in case new editors emerge (eg. if a breakthrough technology pops up)
Commoditization of the tool (all our competitors will probably use 80% of the features the same way as we will, eg. a chat) does not make it strategic for MM to build it in-house. Still, the tool must allow customization to some extent (through a clean and well documented API) to allow us to tweak the tool to MM’s specific needs on the 20% remaining features.
Viability of the editor allows for a long-term collaboration (because the editor is well established or just went through an important round of founding). It is important because integrating any solution comes with a cost, so you don’t want to change your editors every other year. Costs shouldn’t explode if our usage grows, which could become a deal breaker and have you reconsider a “make” option.

Algolia is a great example for ManoMano (I have no shares in this company!). It is our search engine. We decided to implement Algolia because semantic relevance is quite standardized across all the industries and it would have taken years to redevelop a good solution. But Algolia provides a great API to customize the behavioral part of search that is really specific to ManoMano. We can use our own data to improve our users’ experience without improving our competitors’ experience! It comes with a price but it has to be balanced with the cost of a Team (roughly 500K€ per year).

There is nothing bad at buying solutions even if you are a tech company, just be clear on requirements

2.4 Is a CPO still useful in a decentralized organization?

Once your organization is up and running, well decentralized, one can wonder if a CPO remains useful… My personal opinion is that there is still a need for a Product Leader, perhaps not necessarily in the C-suite, but this would depend on the DNA of other C-level members: be sure to have users’ interests well represented in your Executive Committee… It would also require in this case that the CTO be very business-savvy. The company Product Leader’s main missions would be as stated in the full article:

Product influence inside the company (eg. carrying out the user voice, evangelizing employees, especially new ones during the onboarding…) to strengthen user-centricity
Product influence outside the company (eg. nurturing employer branding) to attract talents
Product BU’s team management (eg. recruitment, product community animation, coaching,…) to create a strong and lively product community
Product playbook key principles (eg. key steps of product development framework, tooling, make/buy criteria…), to create a common DNA among all teams
Strategic portfolio management guidelines (eg. company goals setting, resources allocation principles) to have shared product strategy principles

Here is what an org chart could look like without a CPO. You would then have a VP Product reporting to a (business savvy) CTO.

A possible organizational chart of a Product-centric company where CTO would also wear the CPO hat

3/ Fostering user-centricity and giving voice to design

In many young companies I talk to (and ManoMano was no exception), Design is rarely a priority, and I’m not even talking about User Research. It can be measured in term of ratio in the product teams. Yet, since solving users’ problems is the ultimate goal of any product-centric company, figuring out the problems of your users should be the first step.

3.1 Developing User Research habits

PMs usually assume this role at the beginning of a company but it might be dangerous. UR is a real job and PMs will probably be the victim of several biases without even being aware of them (have a look at this interesting article from Chloé Martinot, the former CPO asking Should PMs do User Research?). Beyond biases, doing proper UR also requires:

Specific methodologies and skills to run qualitative or quantitative research
Time to recruit, qualify and animate a user base (PMs are generally overwhelmed)

As Chloé puts it, Research is not only about confirming what you know, it’s also a lot about discovering what you don’t. And too many times, PMs ask for confirmation.

We really started developing user centricity when Chloé officially took over the mission by becoming the first UR of the company. Thanks to her drive and leadership, she was able to reach significant results in a very short time. You can read her article on how to create an impactful user-research department within a month:

Start with tooling: Hotjar brought us us two important features, first one being session replay with its viral videos and also a CES score (Customer Effort Score) on our site through a form during user browsing popping according to some criteria
Create routines about User Research in the company with for instance the Pop-Corn session where everyone could come and watch session replays around a given topic, or the Customer Shoes given to all newcomers at ManoMano

ManoMano’s Product Managers talking to one of our users in Rouen

We finally split user research into strategic and tactical research and we finally agreed at ManoMano that:

Strategic research (more prospective and broad research like for instance understanding our users’ expectations for a mobile app) would be made by UR
Operational research (eg. checking features usability) would still be held by PMs or Product Designer, empowered by the UR team (tools and coaching on methodologies, biases…)

Don’t wait too long before hiring your first User Research, even if you may find several reasons to postpone it

3.2 Differentiating through design

Giving design a stronger voice and place in the company was the latest step of our journey, mainly through senior recruitments. I know that many will disagree with this opinion (that is purely personal, feel free to add your own in the comments) but even if the French Design scene has talents, there are clearly not enough. I often hear designers asking for a bigger share of voice in companies and better recognition, in the steps of companies like AirBnb. Yet reality shows a strong discrepancy between what some designers ask for and what they have to offer, especially a lack of perspective about business. Does it come from academics? Or because most of the greatest designers are freelancers? We (tech companies) also take our share of guilt since we don’t always put the resources that a good design department would require. Awareness within companies about what is design really about is also still burgeoning and too restrictive… And in our specific case at ManoMano, a DIY e-commerce marketplace might not be the dream job of a designer (even if it is, see below!). We interviewed several profiles and had to wait for almost 18 months before being lucky enough to find Sophie Muto, who was finally able to take design to a new dimension.

Making design at ManoMano might prove even more complicated but still necessary and possible:

Design might not be seen as a game changer in e-commerce: Amazon is supposed to have set a standard that could turn dangerous to diverge from (even someone like Steve Krug, the author of Don’t make me think, recommends to be very cautious with not following the conventions). This does not make sense and several company demonstrated design could be a game changer in e-commerce, especially in China (WeChat, PinDuoDuo which introduced a brand new social e-commerce way) but also in the US (Poshmark for instance got rid of the reviews…)
Agility and speed, one of ManoMano’s vital forces, does not always match with design’s longer time frame in some cases (innovation, exploration…). A design system cannot be implemented within a few sprints, and it won’t show results before months.
ManoMano’s product ecosystem is more complex than one would imagine: B2C and B2B do not have the same needs, extra services like SuperMano (jobbing) target totally different users than MM’s regular ones, several communities interact (users, pros, mano advisors, super mano jobbers…). A systemic design approach would be the solution but again, it will take time.
Design is torn between the need to scale and the need to remain a creative and human discipline: as Tristan Charvillat from BlaBlaCar puts it, “Accepting to produce a creative work for the benefit of a higher ensemble requires designers to renounce to add their style and signature on it, it might turn out to be frustrating”. New jobs like Design Ops emerge to ease design scaling within companies and favor reuse, refactoring… It can be a chance for creative profiles who will experience more time to work on creative topics.

Designing a clear strategy relying both on short and long term actions is critical to get a buy-in from the whole company:

Short-term actions: strengthen recruitment both in numbers and seniority, gather every user feedback (customer service agents, operations through NPS analysis, product team through CES, marketing through studies…) into a single communication for all employees, keep on investing on the tooling (Chatermill for text analysis, AirTable for User Research…), dedicate at least one designer to a Group (2–3 product teams) allowing him to be present at the very beginning of the product development cycle
Long-term actions: build a robust design system hand to hand with Engineering, make user satisfaction the most important KPI in front of GMV, move towards a systemic design approach…

Make clear in the company that design takes time but that it is the key to maintaining coherence in your product portfolio as it grows

4/ Developing a reasoned data mindset

Amazingly, you hardly had data about our product analytics when I joined the company in 2017, despite a strong DNA in the company on data from the very beginning. You had many kinds of data available, but more about acquisition and sourcing, which made sense given the history of the company (remember that product centricity was still burgeoning in 2017). A product analytics tool existed (in fact it was more a UX analytics tool) but it was hard to use and a very limited number of people in the company were using it. There was no data layer on the website either…

4.1 Create a real product analytics culture (beyond the tooling)

Setting the right product analytics was our first action. Clément Caillol, a former Googler took the lead on this stream and successfully built a product analytics culture at ManoMano. As he explained in his article Great product analytics are not about the tools, it is about you, tools are necessary but won’t make it all. Our approach, that turns out to be successful (measured by the number of users of our product analytics within the company and easiness to access them) relied on the four following principles:

Agility: setting your tracking plan is painful. It defines all the properties and events you want to track (sessions, add-to-cart, price, page…). So keep the tracking to the minimum (many people are obsessed with collecting as much as data as possible) and make it easy to maintain (comprehensive taxonomy, progressive enrichment…)
Autonomy: we did not want a centralized team in charge of tracking, that would have created a bottleneck, dependencies and a disengagement from the product teams around the analytics ownership. So each product team is responsible for tracking its data. However when another team needs new data that lives outside its own domain, they will have to ask the product team in charge of that set of data. The global coherence of your tracking plan might also suffer from this decentralization, so a data governance committee (we call it product analytics council) might be needed at some point
Accessibility: everyone in the company has access to our analytics tool Amplitude, we offer regular trainings around this tool for different levels of expertise. The tracking plan is well documented and accessible to anyone. As the company grows, a need for a dedicated tool (we currently use a spreadsheet) might rise.
Agnosticity: through the use of a Tag Management System (we use GTM from Google), you can centralize your data before distributing it to the tools of your ecosystem (marketing, product analytics, bidding…) and switch tools (pretty) easily

4.2 Be data-informed rather than data-driven

Paradoxically, we almost had to constrain the use of data at some point, urging people to adopt a data-informed attitude rather than a data-driven approach as explained in this article (with tangible examples for each risk). Indeed, relying too heavily on data might turn out to be dangerous. Data should be one criterion of a business decision, not the only one (otherwise companies would be ruled by algorithms). Data is complicated and several risks might lead you to take wrong decisions, please be aware of them:

Your data might be wrong, more often than you think! Data quality is often the fifth wheel of the wagon. Wrong data is worse than opinions… Hire Data Engineers and set a data governance committee early on even if ROI might not seem very high at first sight
Your indicators might not be the right ones… Being obsessed with objectives can then be counterproductive. Even if indicators remain necessary, to clarify a vision (“this team’s job is to increase this KPI”), use them more as a feedback loop than an ultimate goal. Be comfortable with changing them frequently as they should measure to what extent you are solving the problem you are working on. Don’t waste your energy trying to explain the absolute value of some metrics (especially when you have more than one source), concentrate your efforts on understanding their variations
Your data results might often be biased, be it through a human bias (especially when people running the tests are the same as the one interpreting them), technical bias (are you really sure your AB test tool is well calibrated…) or methodological bias (have a read of Statistics done wrong and think how everyone now hides behind the magical p-value…). Rely on data scientists to educate teams and interpret results
Data often leads to over locally optimizing. Concentrating only on optimizing your current data won’t take your business to the next level. Don’t be ruled by the dictature of AB testing every single feature. Trust your guts. Don’t rely on your existing data set to find breaking patterns but rather on field research. Once a pattern is spotted on the field, measure it through data.

I will give you one tangible example (more in the article) about Conversion Rate (CVR). CVR is a vanity metric that depends on too many factors to be actionable (media mix, vertical, weather…). Making it an ultimate goal would be totally useless but investors look at it so you should aim at least at being able to explain its variations correctly… Take care to calculate it properly (robots…), check the variations of the metric (absolute value does not have any meaning) and use it (or better a submetric) as a feedback loop to see if your actions have impacts rather as a goal.

What I learnt through the years is that nothing is more important than qualitative research and that a quantitative approach is a strong complement (not a substitute) to quantify and validate field research.

4.3 Integrate data scientists in product teams when needed

Collaboration between product teams and data scientists requires some flexibility as their timeline is often weeks or months while teams work at sprints rhythm, usually two weeks. As Etienne Desbrieres (Relevance team PM) explains in his article, the relationship between a data scientist and a team is more a brother and sister one than a couple. They see each other from time to time but have their own life, which means data scientists should be highly integrated to the teams during critical periods like the kick off of a new data oriented project (like a new recommendation engine) but still be able to work at their own pace. The key to success is to be very clear about data transfer contracts (data type, formats, typologies…) between the team and the data scientist.

5/ Setting-up a decentralized QA culture

Again the same story as for User Research: everyone agrees on the importance of QA but when it comes to allocating resources in budget, QA is not at the top of the list. But when you run a tech company, code entropy and resulting technical debt can quickly become a huge bottleneck in your delivery pace, creating frustrations among businesses, undermining credibility of the tech team and worse, resulting in lost sales when bugs finally hit users. A first step was made by Yann Person before Olivier Dennemont joined us in 2019 to move things forward and to scale our QA department. Feel free to read his great article about his journey for more concrete details (for instance the tools stack, the bug reporting process…)

We faced several challenges in setting a QA culture. I can feel this pain is shared among most EU tech companies and is not specific to ManoMano (on the contrary the company could rely on a true concern within all the tech teams about the QA topic)

Lack of profiles, at least the kind of profiles we were looking for (not old-fashioned Quality Control profiles, doing manual tests at the very end of the product development process)
Increasing amount of code to test because of hyper-growth: we favored automation over manual testing (even if they remain mandatory) and kept the focus on most critical tests rather than focusing on code coverage. I noticed that too often QA analysts grant too much weight on the number of tests they perform rather than their criticality.
Lack of trust: our non regression tests (tests run after each new code release) were never 100% right so they lost credibility. Having a 100% test is now mandatory.
QA at the end: let’s be honest, QA often came at the end of the process. We are making efforts to bring a QA mindset at all stages in the whole team, from the PM or the Scrum Master writing tickets to the developers writing their code.

The QA team was split into two parts to ease scaling, one for tooling and the other to support functional teams. Its role is not to perform all tests in the company, even if they do some, but rather (like all support teams at ManoMano) setting the right tools and spreading the QA spirit among all teams. The two teams are:

QA tooling team (2 FTEs, software developers profiles): in charge of setting the right QA tools for all the other teams, and managing transversal QA tech issues (eg. data fixtures generation, not an easy one!!)
QA functional team (11 FTEs, QA engineers profiles): dedicated to a Group (2 to 3 teams), in charge of spreading QA tools, processes and methodologies in all the teams (and of course performing manual tests, and if needed automating them)

QA is a never ending process. Foundations are there but we still have a lot to do. Continuous improvement and decentralization are really key to make it work!

6/ Growing your Product Managers

Growing your PMs is not easy. Product Management is a recent discipline, its definition may vary from one company to another, there is no academic training, it relies mainly on soft skills that require time and experience to be learnt. Besides, PMs are distributed within the whole company making it hard to nurture a real team life apart from offsites or dedicated slots in the agenda (we now have half a day every Thursday called Crafternoon that allows all the PMs to spend time together).

6.1 Make clear the qualities to look after and the temptations to avoid

Highlighting the qualities that make impactful PMs is a first way to help them develop these qualities. Here are the qualities, you will find examples in the article:

Truly listen to your stakeholders to really understand what they mean, not to make your own case
(Re)Frame problems relentlessly and resist the temptation to jump into solutions. Solving the wrong problem won’t help!
Adopt a radical focus attitude and put all your efforts onto the problem that matters the most. Prioritizing a backlog is not enough, you have to cut it to focus all your resources only on the key topics
Spot and solve conflicts before they become an issue, don’t be dogmatic. You will save a great amount of time and energy. Non Violent Communication definitely helps.

Providing your team with your experience can also help them resist to the temptations that many young PMs will face, especially in front of senior leaders in the company:

Satisfying a maximum number of users. Making some people unhappy is sometimes necessary to keep your product strategy focused
(Always) following the product’s industry trends. Challenging common industry knowledge from your users’ perspective allows to avoid collective bias (remember DMPs and even Beacons hypes for tech veterans)
Avoiding conflicts with your feature teammates. Engaging intensely with your feature teammates allows great team dynamics to emerge and positive conflicts
Delaying product shipping not to be embarrassed by an ugly MVP. Accepting to be embarrassed with a non-perfect product makes you ship and learn faster
Being the company hero. Considering your product roadmap as a collective asset rather than your own corner increases your product’s buy-in

6.2 Provide your team with an efficient Product Toolbox

We also provide our PMs with useful product frameworks to help them shape their product strategy. PMs can easily be taken by their day-to-day operational duties and taking time for strategic thinking is hard. By scheduling “strategy meetings” and preparing them ahead with this toolbox, you can really help them take a step back. Here are some of our Product Management favorite tools:

Product Challenge is a meeting that we try to hold twice a year for every team. It always follows the same agenda (see article) and is very useful to align stakeholders on the product strategy (problem to solve, competition, key metrics, solution…)
USPs comparison chart provides an interesting support to assess your product USPs (Unique Selling Proposition) against the competition and make your strengths stand out. Invest on them, reduce your investment in USPs where you will never beat the competition. You can use “5 whys” to define your key USPs, especially when you are staffed on a new product area. Credit to Rémi Guyot from BlaBlaCar on this one.
Strategies/Tactics/Metrics is an efficient way to present a product strategy (that was shaped during a product challenge) to stakeholders (see full framework in Gibson Biddle’s article)
Opportunities Trees / Solutions are a great way to get challenged by your peers or your team stakeholders about a solution you chose to develop (why this solution and not another). This framework has been popularized by Teresa Tores.
Press Release forces the PM to shape a long term and user centered vision by making up a fake press release about his product (with a Q&A section, very important). This methodology is the starting point of new products at Amazon.

The best way you can help your team is being available to go through tangible problems when one of your team members face one. Spend time with him/her investigating the root cause and solving the problem.

I personally regret not having spent more time on the field (I spent a big amount of my time in meetings, I know most of the CPOs I talk to share the same impression).

The USP chart from MM Product Management’s toolbox. Credit to Rémi Guyot at BlaBlaCar

6.3 Reading is key to grow!

Readings is one of the most efficient ways to grow and I personally think that it would make a better investment for PMs to read a few great books than lots of average blog articles. Here are the books I would recommend the most by decreasing priority

Inspired by Marty Cagan: no need to talk about Product Management without having read this book.
The five dysfunctions of a team by Patrick Lencioni: driving a team is the PM’s key role, this book is all about this, putting a great emphasis on how to build trust.
Nonviolent Communication by Marshall Rosenberg: in a job where managing other stakeholders is so important, NVC appears to me as the best solution to solve potential conflicts
Liberating Structures by Lipmanowicz and McCandless: if you want to run participative, creative and varying yet effective meetings, this book is revolutionary
Statistics done wrong by Alex Reinhart: data can be dangerous, you better make your PMs aware of that!
The making of a manager by Julie Zhuo: a great book for those who transition to a manager position, many concepts are taken from High Output Management by Andy Grove, still very relevant even after more than 30 years (for more experienced managers). Thanks to Emmanuel Hosanski for sharing this one.
Méthodes de Design UX (French one) by Carine Lallemand: a very practical view over 30 UR methodologies (focus group, user recruitment, interview…). Thanks to Tiphaine Gamba for sharing this one!
Don’t make me think by Steve Krug: Even if it’s not groundbreaking, it states clear principles to go beyond personal opinions in UX Design
Product Leadership by Richard Banfield (required for Product Leaders). How to organize your team, hire talents, shape up and share your product strategy

Best way to grow in Product Management is experience. Favor horizontal moves in your company to experience as much as product as possible

7/ Being product-centric for real

After 18 months of great progress on our product centricity path, we experienced sort of a backlash once strategic issues piled on the table while tech resources remained limited. We started this article by explaining how we set strong foundations of a product centric organization. It mainly focused on Delivery issues. It brought great improvements in the company (visibility, reliability). We also talked about Discovery with User Centricity and design. Again people were pleased with these new insights coming from our customers. When Delivery is fine, Discovery on its way, the discussions moved towards Strategy. The way you define your strategy, mainly how you prioritize and allocate resources in a scarce world. This is when our fresh product-centricity was really crash-tested.

7.1 Why product-centricity became harder to spread at some point?

First, it turned out that part of the company was still relying on a feature driven approach rather than a users’ need approach. We were having debates like “we need to develop an app to increase loyalty”. Is being Loyal a need from our customers? Would an app “solve” their problem (I would rather say MM’s problem) about “not being loyal”… ? Sure 60% of our traffic is mobile, but is the absence of an app what really prevents customers from buying again on MM (vs. a deceptive quality of the product they bought, or a delay in their delivery that prevented them from moving on with their construction project) ?

We also had a talk about “We should increase our conversion rate. We should develop an app”. Again to what extent is there a problem among our users with our Conversion Rate? Do they really drop because of a mobile browsing issue or because of too expensive delivery fees? Or a lack of reassurance about the technical attributes of the product they were interested in (and which costs more than 1000€…)? I am not saying you should not follow the Conversion Rate metric but you should look at it from a user perspective, not your business perspective. It is fair to want to improve business metrics, but by understanding the users’ problems that limit them.

Then, a pure user-centric approach also eventually revealed a misalignment between the Sourcing BU and the Product BU about the weight to give to our sellers vs. our users. Here comes a clear example: we are revamping our Product Information Management structure. It is a good example of a project driven approach (our PIM had reached its technical limits). When adding some user perspective, it turned out that this big project had two main benefits:

(i) Improving our catalog’s accessibility for our final users by allowing a richer product information collection (more flexible for our sellers to fill in the product information data)
(ii) Easing the day-to-day operations of our sellers, especially those using our Fulfillment offer (unified toolbox, easier stock management…). Users would also be positively impacted at the end if the number of sellers using our Fulfillment offer grew because the delivery experience was better

As our resources are limited, we had to prioritize between these two benefits which raised a deeper question to know whether we wanted to ease our seller’s life or our final users experience. In a pure “user-centric” vision, the (i) option should be favored (but I am not saying it is a better option). This discussion highlighted a lack of alignment about users’ interests priority.

Finally, the new product centric organization created some (legitimate) frustrations within Business people, mainly about prioritization choices. For instance, some business people had been hired to deliver a specific project which depended (like 95% of our projects) on tech resources. By the time the new employee joined (it can take up to 6 months in France between the moment you publish the offer and the moment the employee really joins), the project had been deprioritized in our release plans. Even if prioritization is not made by thePM only, business people sometimes felt unheard. Product teams should probably have better explained the context and other competing priorities. Perhaps business people should limit their will to innovate (but this is one of our main reasons for success) or the company increase its focus…

In hindsight, I see three main reasons why it all happened at ManoMano, but also in many other companies according to what I can hear from my peers:

Misalignment on the “product-centric” vision: I failed in sharing and aligning my C-suite peers on a long term vision about what product-centricity really meant. I had my vision and I thought that it was obvious that the others had it too… I should have insisted way more on what it would change, especially that Product Teams should prevail over BUs. A good start would have been to have some workshops based on a common reading like Inspired.
Heterogeneous product cultures: MM recruited fast (from 100 to 500 employees in 3 years) and got on board experienced employees from companies (CDiscount, Zalando, Amazon, Privalia…) who had their own definition of product centricity, and sometimes it was not exactly the one we were trying to set . Not better or worse, but different. They came with some of their former colleagues which increased this heterogeneity. It makes the first point even more critical…
Lack of experience of the Product Managers: building a strong product-centric organization requires strong Product Managers. We definitely have a great team at ManoMano, but since this job is relatively new in France, most of them are quite young. And as smart as they may be, you also need experience to deal with some situations. Some say that the job of a Product Manager is to make everyone equally unhappy in the company. Making people unhappy is not an easy task…

7.2 Realigning and collaborating as a way to overcome difficulties

We overcame a majority of these frictions by aligning everyone on the meaning of a product centric organization. We shared a common starting point (Inspired) and we figured out what it means for us (coming from various backgrounds) and the way to achieve it. We finally recruited more senior leaders in the Product Team at a Director level (in 2 years the market already matured and our office in Barcelona gave access to a new international talent pool). PMs are well aware of their role on the product strategy part: aligning all their stakeholders (tech, business, legal…) on a common vision. Not defining the vision on their own. Four themes are refined or defined every 6 months to clarify the focus.

Please find below additional tips to make a product centric organization work more smoothly, from our experience.

Thinking always as Product Teams members (eg. Discovery Team, Delivery Team…), before BUs members (eg. Marketing BU, Ops BU…), is again the best way to overcome this tension. Think of internal mobilities to foster this team spirit, (check these interviews if you need to be convinced) and try to involve as many stakeholders as possible into strategy shaping. Managing many stakeholders can be hard, the good news is that new artefacts like Liberating Structures exist to help you cope with a large audience and still bring value.

Demonstrate empathy with your business stakeholders who don’t always know well your job as Jonathan Levitre explained (he was the first Product Manager to join ManoMano) in his article about how having healthy relationships with your business stakeholders:

Explain your job and demonstrate empathy. Involve them in the problem or solution discovery. Make them test, have them come to demos…
Adapt your communication according to the stakeholder, over communicate with your Business Owners in 1:1 meetings or regular lunches
Get respect for your time by setting rules to protect it
Demonstrate an entrepreneur mindset that will prove your stakeholders you care about their problems!

I would more than recommend to any Product Manager to read NVC (Non Violent Communication) from Marshall Rosenberg, it could definitely be a game changer in the relationship between your employees. Behind NVC, one of the key principles is that a “no” is never an attack against you.

Aligning his or her stakeholders is ultimately one of the key missions of a PM, like our Product Manager Pierre Devaux explained in his article. Done right, it should prevent many conflicts from even happening. The PM does not decide on the strategy on his own. He rather aligns all stakeholders on a common strategy. Align on:

The (user) problem
A (impactful) solution
A (non vanity) metric

Conclusion

Let’s first summarize the 4 key actions from this journey:

Key takeaway 1: align the company on a shared vision of a product-centric organization and its consequences in the everyday life of the employees, especially the need for collaboration and a product team mindset rather than a BU mindset, an approach based on problems rather than solutions (features)
Key takeaway 2: focus the company efforts on a very limited number of goals (problems to solve), so that the teams know what they have to achieve and don’t get lost in changing priorities. If you want big results, leave teams the time to make things out and don’t interrupt them every other day with “urgency”
Key takeaway 3: invest in long-term actions from the very beginning like UR, UX and QA: the more you wait and the bigger you will pay it in terms of debt (code, usability, design…).
Key takeaway 4: insist with your PMs that their personal growth is in their hands: distributed teams like Product BU are hard to coach. Your responsibility as a leader is to provide the right resources (books, trainings, time slots…) and be available when they need you to discuss a specific problem. I personally spent too much time with my peers from the C-suite to provide my own team with an extensive coaching…

As you could see in this article, one of our biggest pain points to scale was about recruiting. I hope that the growing tech scene in Europe will make experienced tech profiles more available in the coming years because this is what we need right now to bring our scale ups to the next level, from Next 40 to CAC 40 in France. To achieve this, tech companies also need to think bigger and longer term. How do you conciliate this with the short term perspective of most of the funds that fuel these companies? Even if they accept to lose money in the first years, at some point they will ask for profitability (and it is fair!). Which could lead to focus on tactical projects rather than longer term and more differentiating projects. So push these strategic projects from the very beginning!

We talked a lot about Product Management in this article, but a question deserves to be asked: will the PM job still exist within 10 years? I am not so sure, perhaps it is only a transition job that will move back to more classic business leaders once all companies will be “tech” companies. PM was a marketing job at the beginning (in CPG companies), it became a tech job when Hewlett Packard tried to apply this organizational model to its company. In a few years, tech will have become a mandatory “soft-skill” shared by everyone in the company. By that time, I would highly recommend to PMs to experience as much as possible horizontal mobilities, even to change jobs in order to get some new perspectives. Don’t be dogmatic with product theory, it will hurt more than it will create value. Always remember the principles of the methodology you use to understand what lies behind the processes (Agile Manifesto’s 5 principles remain so strong almost 20 years later).

Will product centric organizations in this future be the norm and classical BU organizations we currently know be deprecated to simple “skill” communities? Which gather once a week to share expert learnings? It might also be possible, favored by a need for decentralization, both to cope with the always faster pace of change (decentralized agility) and also by the need for empowerment from the employees (read Laloux’s book “Reinventing organizations” for a broader perspective about organizational models and autogovernance).

I personally greatly enjoyed that time at ManoMano building a product centric organization, we are experiencing a great time of change and it is exciting to be part of it! Think about that and enjoy.

About ManoMano

MM is the leading European online e-commerce platform in the DIY (Do It Yourself) space. It went from ~100M€ of GMV (Gross Margin Volumes) in 2016 to ~650M€ in 2019 (and a trend towards 1B€ for 2020). ManoMano currently has 550 employees located in three locations (Paris, Bordeaux and Barcelona). We are hiring!

About the author (Pierre Fournier)

I am a passionate tech entrepreneur. Now working on a new projet called WILL to help employees be fulfilled at work (French language at the moment).

If you enjoyed reading this article, feel free to subscribe to my Newsletter (every quarter). It talks about Product, Business, HR, Management… (mix of French and English articles). If you want to have a look at the kind of articles I write, feel free !