Why do all tech companies converge towards the same product organization? ManoMano’s case
Building a valuable tech product is complex. First, because it requires a hard level of collaboration between stakeholders coming from heterogeneous backgrounds (designers, engineers, business, customers…). Then, when the company scales, building an ecosystem of tech products becomes even harder since the need of synchronization grows (architecture design, product portfolio management, code dependencies…). Finally, beyond the value of the tech products you build, your organization must ensure that everyone is deeply engaged and happy in their daily jobs.
Going through ManoMano’s product organization principles, you will see the same kind of organization that many tech companies adopted, a Spotify-like model (outcomes driven and cross-functional teams, groups, tribes…). Why? Because it works (pretty) well and we had no better solutions! Of course we adapted it to our own context. If you keep on reading, you will find specifics: business owners inclusion, data teams participation, QA ownership distribution, dependencies… Does it mean that the Spotify model will never be outperformed? More than our organizational model (macro-structurdes), future changes might rather come from processes and methodologies (micro-structures), especially in the way we apply lean methodologies and collaborate.
The product team is at the heart of the organization
We did not invent crazy new frameworks. Rather, we followed product leaders recommendations (first of all Marty Cagan) by organizing our tech department into small teams of cross-functional employees oriented towards user outcomes (eg. the browsing team will help users easily find their products). I know there are many debates on the naming. We don’t really care about the name, some will talk about feature team, others about product team or squad. What might be more interesting for other companies is to see our average ratios.
As you can see, the average ratio is something like (for the core team):
- 1 PM (Product Manager)
- 1 to 2 Front-end Engineers
- 2 to 3 Back-end Engineers
- 0,3 to 0,5 UX designer (we wish it could be more…)
- 0,3 to 0,5 QA engineer (we wish it could be more…)
You can see that the team is made of two entities: the core team and the extended team. The core team refers to the tech part of the team. They work together on a daily basis, all of them should participate in our agile rituals like stand-ups, planning… The extended team includes all Business Owners (BOs). They gather less frequently, every other week (even if they interact much more frequently with the PM), especially during the Demo ritual. More details later in the article about the Business Owner role. It is really important that they be part of the team.
Some resources are shared at an aggregated level
In a perfect world, shared resources that appear on the picture below wouldn’t be shared (UX, QA…). But let’s be honest: it would be too expensive. This is why some resources are shared at an aggregated level that we call Group. It usually gathers 2 to 3 product teams that share a common goal (eg. browsing, product page and relevance will constitute the Engage Group).
Shared resources at Group Level typically include QA, UX and Agile Coach. Groups allow sharing resources between teams in a clear and efficient way. It also allows senior PM to experience management (supervising one or even two teams beyond their own team).
Groups are also gathered at a higher level into Tribes but this time more for sync reasons. Again, ideally there would be no need to do that since teams are supposed to be independent and autonomous, but in reality, there is a strong need to align, organize and manage. Tribe resources will include User Researcher, Architect, Product Director. BOs will be very senior Business leaders.
The Tribe will collectively set goals that teams should achieve. Each team will then define its strategy to achieve these goals.
The whole team shares responsibility
Each team has a North Star Metric translating their mission into a long term KPI that helps the organization understand how it will impact business. Usually, each team has an additional shorter term KPI corresponding to its quarterly OKR. Let me give you an example: the AfterBuy team works on improving the customer experience following an order on ManoMano. Its NSM could be the average number of contact tickets opened per order. Since one of our main issues is about returns (marketplace nightmare), this team first chose to put its focus on offering a self-service solution to minimize return contacts with our Customer Service. The corresponding OKR was the percentage of orders covered by self-service return.
We sometimes had hard discussions whether to know if the PM should be held responsible for the whole team. Our answer is no. The whole team is responsible. Some will wonder: how can responsibility be distributed? Well, it can! At least as long the size of the team remains reasonable (which is the case by design). Think of a relay race: if the stick falls, who is responsible? The one who was holding it or the one about to receive it? Both. Holding the team responsible pushes the whole team to be successful. Otherwise, the team will harbour behind the PM and its engagement will lower.
In order to make the whole team responsible, the Product team sense of belonging should overcome the Business Unit team sense of belonging. For instance, all Product Team members should share the same OKR (the team OKR) and it should prevail over Business Unit OKR (especially for Business Owners). This is the only way to fight against silos as the company grows. It is hard and we know there is still room for that in ManoMano even if we made a lot of progress on this topic!
Business is included as much as possible
We try to involve as much as possible our business stakeholders. We created the Business Owner (BO) role to have a dedicated product stakeholder within each BU. We try to have the whole team sit together (aka the extended team in the first picture of the article). BOs are part of the team. BOs attend to every demo, potentially sprint planning, most importantly roadmap brainstorm through pitches mechanisms (this could constitute another article)… BOs are in charge of coordinating with their BU, both by spreading product release impacts and gathering needs from their BU. They usually have a product or tech mindset. BOs sometimes act as project managers on big projects, the Product Manager being one of the stakeholders of the global project (eg. in-house delivery project). We offer internal mobility allowing a BO to transition to a PM role (see this great interview from a BO who transitioned)
PM owns the strategy (requiring good discovery)
Getting the right things done is the PM’s main mission. Getting things done right is the engineers’ responsibility (see paragraph below). Doing the right thing means, according to Cagan, building a product that is both valuable, viable, usable and feasible. It means that the PM has to do the synthesis of many diverse stakeholders, from User Researchers (valuable) to Business Owners (viable), to Designers (usable) and Engineers (feasible). A PM is expected to make the synthesis of all these inputs into a product roadmap that will basically list the highest needs faced by our users. Every quarter they will detail their roadmap with the top features to deliver. This is what we call a product release (for more details see the book “Product Roadmap Relaunched” from Bruce Mc Carthy). If you want more details about the PM role, you can read our previous articles about what makes an impactful PM or about the 6 temptations he will have to resist…
We don’t have a PO role at ManoMano
I regularly get the question “Do you have PO (Product Owner) jobs at ManoMano to help the PM?”. The answer is no, we don’t. The PO job doesn’t exist at ManoMano. This is my personal opinion but the PO job is useless in a product centric organization: it is a PM job without the strategy part or an engineering job without the coding part… And it is different from a Project Management job that you definitely need on big projects.
So how do we do? Tasks generally considered as a PO duty are distributed to the members of the team:
- Ticket writing is made both by the PM (who write very functional macro User Stories with potentially the acceptance criteria) and by Engineers for the detailed technical strategy (subtasks of our tickets)
- Backlog grooming is of course a PM’s duty (otherwise how can you manage the product strategy?)
- Agile rituals animation and engineering team leadership are taken by the Scrum Master
UR is made easy for the team
We do have User Researchers but rather at a tribe level. They are facilitators and coaches. They set the tooling so that it is easy for PMs or designers to do their own UR if they want to (session replay, text analysis in huge text data sets, check of methodology or protocols when addressing surveys, coaches). PMs and designers will do the team day to day UR, focused on their scope, including user testing through platforms like Usertesting.com. If there is a need for a larger User Research study (at a tribe level for instance), UR will take care of it.
Product designers defines the solution
Once the problem is well framed, a Product Designer enters the game. Their role is to design a usable solution for our users. The solution is also challenged with the tech team to ensure it is feasible. It can lead to flows or component updates. Product designers also have the responsibility of setting up and maintaining the design system to make our product design scalable. Front-end developers can then be autonomous on designing regular flows as long as they resort to the Design System
Engineers are responsible for the delivery
Again, we try to commit engineers as much as possible in the product process. This means including the engineers at the very beginning of the product design. Giving access or inviting engineers into UR sessions is great (see the article talking about the PopCorn sessions). Engineers are responsible for the delivery. It goes beyond shipping the feature in quality and time (to which they committed to without being forced to by a PM or a BO). It is also about the code design and maintainability. If they consider that they need room for code cleaning, they will have it (be it by extra time on existing tickets to refactor or a dedicated ticket refactoring creation). We also allow transitioning from engineering roles to a PM role (see this interview).
Data team is there when needed, not all the time
Data people don’t spend their whole time in the team because their rhythm is usually different from agile teams. Their timeline is often longer, less tactical (the time unit of a Data Science team is a week rather than a day). At the beginning of a new project Data people should spend a few sprints fully integrated with the Team. It is critical that they make sure they understand each other well. The most important thing is to agree on a contract which states where and how the data will be exchanged, at which frequency, and in which format. When the algorithm is done and you need to integrate it in the production environment, it is more the Team that will make sure everything follows the software engineering standards. Meaning testing and deploying in a state-of-the art CI/CD pipeline, ensuring short response times, prod tech stack integration, versioning of code… See this great article from Etienne Desbrieres, our Relevance PM about Data and Product collaboration.
As regards to analytics, it is everyone’s job at ManoMano. Everyone is trained to perform basic analyses through our analytics tools (Tableaux, Amplitude) and quite advanced SQL queries (raw data is available through MetaBase). When some analyses require more advanced data skills (partial dependencies analyses for instance) there are dedicated data resources for each BU (thus Product BU).
Agile coaching is focused on the highest priority team
As you saw above, we do have agile coaches at Group level, meaning they will take care of up to 3 teams. They help teams organize better, improve their day-to-day routines (retro formats, processes, methodologies like Kaizen…). Rather than spending one third of their time on each team, they will focus on the team that most needs their help. How do they know where to focus? Besides agile KPIs, having a coach tied to a group enables them to feel the ambiance, be part of the coffee discussions and spot weak signals (either communication, mood, rumors…) to help them work on continuous improvement. We don’t want coaches to always have to push teams up, we want coaches to create conditions so that teams can grow without external help.
QA is everyone’s duty
Sorry that QA comes at the end of this article because it is not the case in reality! As with UR, we do have QA engineers (mostly, but also some more traditional QA profiles), but rather at a Group level. The QA role is not to do all the tests at the end of the delivery pipeline… They can do some tests, but their role is to bring methodologies and set up the right tools to empower the whole team to do testing on their own. They also educate teams to testing habits and benefits. Unit testing is done by the engineers. Functional testing can be done by the PM or the QA. Other kinds of tests by the QA (edge cases, negative tests…). QA people also keep a documented test plan and monitor the coverage of our tests especially on our most critical features (payments…).
Low customer facing teams can be addressed differently
Even if you want to be as product centric as possible, some teams are mostly about delivering a tech project (payment team, delivery team, adtech team). Of course there are some product issues, especially in terms of business prioritization and focus (should we favor delivery speed over delivery prices ? Should we add costly means of payment that users want ?). But usually business teams have a very strong knowledge on the topic, much more than any PMs not specialized on this particular topic. They can take these decisions and even drive the roadmap since it is more of project management than product management. I think that a PM is still very useful but perhaps one PM for two teams is enough.
We also see a growing need for Delivery Program Manager who would oversee the delivery of a big tech project (eg. delivery at ManoMano) impacting several teams. It would be more a tech resources than a product resource but would be very precious.
DevOps and Tech Core teams act as support teams
DevOps (going beyond the classical delivery pipelines management, also managing all the infrastructure) and Tech Core teams (managing core projects common to several teams, not to be confused with the core team inside a feature team described above) are support teams that fulfill three main missions:
- Developing shared tools or technologies (AB testing, delivery pipeline, speed…),
- Establishing standards common to all tech teams. For instance how to write proper code, how to write APIs protocols, Microservices design, CI/CD rules…
- Coaching teams in new challenges (eg. React or Cloud migration, continuous improvement of the CI/CD process…)
The Scrum Master of these teams is very important to ensure a good communication with every team. Weekly tech standups give time to dive into some of the most important issues within all tech people.
Dependencies remain hard to manage
This organization works really well… As long as you don’t have topics popping up with no clear team ownership (this is the case of every organizational model). You then have two solutions. First one would be that one team agrees to own the topic. But when a topic pops up, it is usually big and urgent… So teams won’t have room to take it. The other solution (that we need to experiment) is to create a dedicated Impact team staffed with one resource maximum from other teams. It minimizes the impact on the existing teams but still leaves room for unpredicted topics. I favor this option because Product Teams need time to deliver great results and shouldn’t be stopped in the middle of their journey.
Another dependency problem might arise on company big transversal projects (eg. when we launched the B2B at ManoMano. Every team was impacted!). The solution is to maximize the focus (meaning having all teams working on it at the same time) to minimize time spent to deliver the feature and enter in a run mode who can be handled by new teams or sub teams. The prerequisite to make it happen is to give as much visibility as possible to all the teams about when developments should start so that they can anticipate a lot in advance and make room in their roadmaps. A strong coordination upfront is of course mandatory.
Teams lifecycle is also hard to manage
Once the organization is up and running, new questions will arise after some quarters. First about team scope. Questions like: is this team still necessary? Should we create a new team to handle this new problem? Well, it depends first on your strategy. Is the team scope still a key lever of your company strategy? For instance we had a team dedicated to product qualification. At some point, they switched towards ratings which had become more of a priority. Then you can also wonder if the team reached the Pareto’s efficiency, the 20% of developments bringing the 80% of value… The team should be able to become aware of that. We turned off the recommendation team who had done a great job but whose latest iterations were not bringing as much value as before. What is hard is that the team members have usually become comfortable with their scope, they know each other well. So this is a change issue. Our advice is to prepare the team to this possibility from day 1.
Another question that will arise is: PM XXX gets bored in his team and would like to move in another team. Great idea! Which team would he like to move to ? But wait, all our teams are staffed… So he will have to wait for a new team. But what if the scope does not appeal to him? And will he have time to make the transition with the new PM? Not so easy! I recommend (but we were not able to formally set this process up at ManoMano yet) to organize it so that it becomes a smooth and regular process. You should favor PM mobilities, this is what will make them grow. Besides, it is necessary to favor horizontal mobility since vertical mobilities are less frequent in PM jobs. How to organize it? I would recommend to create teams mercato twice a year where PMs (and it can be extended to other functions) can indicate their will to move and their desires.
Interest-based communities need to have space despite cross-functional teams organization
We said that having cross functional teams mitigates the silo effect. Great! But it leaves each function a bit lonely. For instance, the PM is the only PM in the team. How can he interact with his peers? Progress? Coach? Challenge? Get the big picture to understand what’s going on in terms of product strategy? At ManoMano we created the Crafternoons, half a day per week where functional communities can gather and share knowledge. There will be an article to detail some of the workshops we organize, but in a nutshell we have trainings (eg. about our product analytics tool), we have a “product challenge” (one PM presenting his product strategy), we have a Glad Sad Mad ceremony (everyone sharing feelings of the moment), we have CPO talks (a CPO from another company comes to discuss with the whole product team). For the day to day, the community life essentially happens on slack.
What are the big improvement areas? Organizational? Methodological?
Like any organization, the Spotify model is not perfect. But it works really well and we don’t really have revolutionizing ideas to improve it. We keep trying to give more autonomy to each team, favor collaboration between all functions and especially Business functions.
On the other hand, we do feel like Scrum (most of the teams do Scrum, some do Kanban) is kind of killing us. It’s like a neverending flying wheel. 2 weeks sprints don’t add so much value when the company grows because everything is more complex and it takes more time to deliver significant value. Teams can get a bit demotivated because it can looks like a never-ending game. Time spent in ceremonies is big… Teams can get frustrated. So perhaps that the next big change will be about methodology. I really enjoyed reading the approach of Basecamp (shape-up) where they favor a 6 week cycle to deliver one big thing and 2 weeks of cool down that allows the whole team to work on what they want (code refactoring, new idea prototype) and re-energize them. We are also looking at new ways of handling meetings (eg. Liberating Structures) to re-energize our meetings and workshops.
Feel free to share your own “frustrations” and solutions in the comments. We hope this article was useful to you! I deeply think all ManoMano tech team for helping me write this article: Olivier Dennemont for QA, Yohan Grember and Romain Ayres for Data, Antoine Jacoutot for DevOps, Denise Jones and Pierre Devaux for Product, Aurélien Lajoie for Core , Nicolas Martin and Margot Rouzic for Agile, Grégoire Paris for Engineering.
