A title you may find too technical or catchy, but it sums up Pearltrees' singular organization over the last few years, which has enabled several radical innovations in the educational digital sector.

But before I got to that title, I simply asked myself a few days ago why and how we were able to do all this with a part-time Product Manager? 🤔

Considering the organizations of comparable startups, this seemed very little and I thought I had found the subject of my first blog post! 💡

For those of you who don't work in startup Product or Technical teams, here's what ChatGPT tells us about the ratios usually found between these two teams:

"Hello my good man, the average ratio between the Product team and the Technical team in a startup is usually 1:5."

Yes, I enjoy my ChatGPT prompts.

Pearltrees from 2017 to 2023 is a half-time Product, also ensuring design, and 6 engineers 💕 on average, a ratio of :

1:12

How can such a difference be explained?

On reflection, there are essentially two reasons for this, both cultural:

• A strong, distributed product culture: it's this organizational specificity that I'm going to develop today.
• Operational excellence: this is not limited to the Product team, and will probably be the source of future articles.

Pearltrees' unique organization provides the Product team with considerable resources in terms of both "delivery" (producing lots of quality features on time) and "discovery" (choosing the right features). I have identified two key structuring elements that I will develop here:

• 💪 Developer project managers
• 👂 A Product AND Customer Success team

💪 Developer project managers

Rather than having shared responsibility between product, design, marketing and technical teams for the success of a feature (or user story, for Scrum fans), we prefer to have a single person in charge: the developer. Note that the Product Manager remains responsible for the success of the entire iteration (or Sprint), no kidding 😉.

The consequences of a developer taking total responsibility for his user story are manifold:

• Controlling deadlines: it brings all stakeholders together and creates its own deadlines and iterations within its user story.
• Quality control: it achieves a high level of quality for the main application and handles secondary situations with controlled investment.
• Autonomy over the product: it takes the initiative on functional details of its user story that have not been exhaustively identified beforehand.

The benefits for the Product Manager (PM) are obvious:

• An overall schedule that remains under control and predictable: the PM's attention can then be focused on where it has the most value, identifying the user stories to be removed or added.
• User stories delivered with a high level of quality: problems are identified earlier, often handled autonomously by the developer, and the PM is only called upon to find creative solutions to complex problems. Over and above the time saved on quality assurance, the PM is less interrupted on small problems requiring daily in-depth re-work on each user story.
• Specifications finalized and maintained by the developer: the PM leaves it up to the developer to finalize a spec that will never be 100% exhaustive by nature, and will evolve as the project progresses. In a way, the spec becomes the code. Depending on the nature of the user story and the developer's level of seniority, the upstream specification by the PM will be more or less detailed: a considerable time-saver.

There are, of course, conditions for nurturing this culture and making an unnatural organization work:

• A technical team with generalist and inquisitive profiles who are keen to develop skills that go beyond producing beautiful, robust code.
• Appropriate onboarding of young developers, who will need to develop project management skills quickly.
• Cross-functional management of the product team to enhance the technical team's skills in product, design and quality.
• A marginal loss of velocity on the part of the technical team, who find themselves making Product for a greater collective impact.
• Processes that frame iteration and user stories, and ensure that this "unnatural" organization holds up over time (a good source of articles for the future).

👂 A Product AND Customer Success team

From time to time, we see product and technical departments unified under the leadership of a Chief Product & Technology Officer (CPTO), for the benefit of better delivery, but rarely the union of Product and Customer Success, a combination that has proved formidable for "discovery". Haven't you ever wondered what the product resource does the other half of the time? Well, talking to users, but above all observing and listening.

To understand the impact of this organization on the PM, let's first take a look at some of the situations in which he will find himself as Customer Success Manager (CSM), illustrated by a few concrete examples:

• Crossing France to spend the morning with our users to understand their day-to-day problems. Issues that can't always be shared in writing, over the phone or by video (especially political issues).
• Interact with all user profiles without falling into the cliché of a persona.
• Spending hundreds of hours training users and experiencing product discovery with them: helping a user open a new tab in their browser and seeing them click on graphical elements that are not action buttons are valuable feedback that can only be captured in the field.
• Explore and learn about all the uses of the product, so that you can promote them to other customers. That's how asynchronous distance learning in sport-study skiing inspired Pearltrees Education's response to COVID 😍.
• Becoming a business expert to deepen our understanding of our customers' issues and maximize the product's impact: understanding the impact of Luxembourg's migration policy on its education system provided keys to understanding its educational digital needs 🤓

The benefits for the PM are also obvious:

• Build a backlog of functionalities based on deep-seated, high-impact customer needs.
• Make discussions with customer success and sales teams richer and more productive.
• Get live user feedback on new features.
• Solve complex bugs in minutes by calling a customer with whom we have a super relationship of trust (real darlings 🩷).

There are also conditions for setting up and maintaining such an organization:

• Be able to split your personality 🤪 so that the CSM doesn't influence the PM in his roadmap arbitrations: strategy, commercial interests and the needs of the technical team must not suffer.
• Managing your time 50/50 in a context where the seasonality of a CSM and a PM are not always aligned: my favorite moment? Launching a new iteration in the middle of a new school year 🎊.
• Don't forget to listen to your colleagues about their own customer feedback: even if 80% of feedback is already known, its frequency and source can be used to adjust the impact of stories on the backlog, and the remaining 20% is sometimes the most valuable feedback, because it brings a fresh perspective.
• Love customer relations, because the objective isn't to play CSM part-time to do Product Discovery: the objective is to reduce churn, upsell, obtain an outstanding usage rate, etc.

In conclusion

There's no such thing as good or bad situation organization. I'd say that this organization was particularly well suited to what we had to do: create radically innovative products.

Democratizing the organization of information on the web, digitizing teachers' pedagogical practices and granularizing school textbooks were made possible by good decisions, a lot of energy, but perhaps above all by teams who knew how to go beyond their initial function, like this technical team that made product and this product team that made customer success.

If you got to the end of this first article, you might want to read the next one? If so, feel free to follow me on LinkedIn to be notified 🔔. Do you have a comment? It's a pleasure, it's just below.