It allows content creators to be very creative with cool diagrams, infographics, and stories about potential and theoretical use cases. However, this makes our craft always more confusing for our audience and creates false and damaging expectations about the reality of the work.

That's why I want to share more real-world data and insights. I'm currently engaged in 3 product transformations with large-scale, multinational organizations—the kind of complex structures you may work in and for which none of the magical recipes from LinkedIn and consulting firms proved effective.

Adopting Marty Cagan / Silicon Valley Product Group's product operating model is hard. But not impossible. It's not theoretical or idealistic, and only people with no experience with the model can claim such things.

To kickstart some changes, pilot teams are an incredibly powerful tool to create momentum. Creating "islands of empowerment" is absolutely possible, and I've been doing it for years now. Here is how we do it:

👉 We create exceptions with a couple of pilot teams. We overinvest in coaching for these teams so they can quickly adopt most of the principles behind the product operating model.

👉 We overcommunicate success and achievements from these pilot teams to generate interest from the other teams (Pull effect) and allow the model to spread.

👉 We push the product model to an entire product / product line / business unit to ensure it no longer competes with old habits. Even when you want to change, old habits are incredibly sticky. Just think about going to the gym!

Here is some real-world data of deploying pilot teams.

The numbers represent the perception from team members of how well the behaviors and practices of the product operating model are applied. The key insight here is the confirmation by all the product team members, including product managers, designers and developers that they feel much more product-centric.

Especially, you can see big jump with Strategy and OKRs - This is where there are often a lot of quick wins. Just giving clear success criteria to a product team, a problem to solve instead of a solution to implement, can completely change the dynamic of the team.

But be careful - Surveying the teams is great to gather insights, and ensuring the teams really feel the difference is crucial. But it can’t be trusted. Which is why we also still perform a team assessment and are training product leaders to make them so they can be really autonomous in coaching the product model.

The pilot teams now project to have a combined impact of tens of millions of dollars just in 2025. And if you like these “Coaching In Public” posts, I’ll be happy to dig more into the numbers for you, let me know!

This doesn't mean the situation is better for organizations implementing the product operating model! Most product leaders—those managing product managers, designers, and developers—misunderstand their roles in the product operating model. Their traditional approach of relying on a "roadmap of high-level features" for the upcoming year is often mistaken for strategy. Such roadmaps are usually ineffective and can be a significant waste of time.

A proper product strategy has nothing to do with features. It involves deeply understanding customer needs, market dynamics, and a clear vision of the product's evolution. It relies on validated insights and paves the way toward product success. Product strategy identifies the problems to solve and the sequence to achieve the product vision. Consequently, a fascinating benefit of a well-crafted product strategy is its ability to make prioritization issues... disappear! When a company has a solid strategic foundation, team decisions are no longer about which ideas, initiatives, and features to pursue but about the best way to solve the problem identified and prioritized by the product strategy owned by the product leader.

If you struggle with prioritization as a product manager or leader, it's likely not a problem with your framework, bandwidth, or stakeholders. Instead, it signifies a deeper issue: a weak product strategy. Poor strategy leads to short-term thinking and focus on output instead of outcomes. The root cause of these prioritization challenges is an insufficient understanding of the sequence of problems to solve to achieve the product vision.

To address this, product leaders must shift their focus from creating roadmaps to developing robust product strategies. This involves deep knowledge about your customers, product, and organization. It also consists in combining key insights to highlight a path toward the product vision. By doing so, product leaders can ensure that their teams truly focus on figuring out the best product and features to put in customers' hands instead of juggling with an infinite number of "top priority" tasks to implement.

In conclusion, adopting the product operating model requires more from management than Agile transformations. It demands a leadership shift that includes significant contributions from managers and leaders. By developing a solid product strategy, tech companies can overcome prioritization challenges and create innovative products that customers will love.

Because there are some "hard skills" in design and engineering, it's harder to fake them and easier to spot weaknesses (which is a good thing for improving). Deploying prototypes and code is a natural filter to ensure minimal competence and initiate discussions on how to improve.

It's different for product management and leadership. Everyone feels like they can write a roadmap or user stories. The lack of experience and references for many professionals on what is high-level product management has a terrible consequence:

Most people:
1. Ignore the competence aspect of product management/leadership
2. Turn to frameworks and tools to compensate
3. Are trapped in an always-searching-for-the-next-framework mode as they can't solve their challenges induced by a lack of competence.

There is an obvious personal aspect: How do you feel when I mention a potential "lack of competence" on your side? Odds are you're feeling judged, attacked, and ready to justify you're great at what you're doing.

That's the power of taboos.

Devs are excited to go to YouTube to learn a new programming language or pattern. We feel insecure and threatened, so we completely ignore the deep human nature of our craft.

Let me illustrate this with a real-world example I’ve discussed in recent weeks:

An Insurance-tech startup had a challenge around copywriting. PMs were accountable for the legal viability of the product text content. They had to approve any piece of text going to the application. Consequently, designers were frustrated with the delays or not working with the real content.

The product leader made multiple attempts to find a process to free up PMs' time so they could validate the copywriting fast enough for the designers… without removing actual work. After a while, the leader reached out to the community to see if a product ops person was something he needed to find a solution.

As people started to discuss the possibility of creating specific expedited JIRA tickets and connecting Figma to the CMS to import real content, I was a complete UFO for everybody when I suggested training the designers so they can approve the content like the PMs.

Problem solved. There were no additional processes, steps, or tools. Happy, empowered designers. Happy product managers with less on their plates.

Investing in competence is your best bet for real results and impact. The product leader should always make investing in people the first choice, and tools and frameworks should only be considered a last resort.

I hope this will inspire you for your next opportunity to improve product practices in your organizations.

📍 Bonjour à vous. Bienvenue sur mon site web et dans ma vidéo d'introduction. Je m'appelle Vincent Pavao et je suis coach produit. L'objectif de cette vidéo, c'est de vous présenter en deux minutes qui je suis et quels sont mes services. Contrairement à la plupart de mes collègues du monde du coaching produit, je ne me concentre pas sur les startups et les skal ups, au contraire.

Transformation Produit

Je me concentre vraiment sur les plus grandes entreprises qui ont plus de monde, plus d'équipes, des structures plus complexes, des contraintes opérationnelles réglementaires qui sont plus importantes et souvent aussi beaucoup d'historiques, qui font que arriver à adopter le mode produit est un exercice qui est vraiment spécifique, pour lequel j'ai développé des des, des tactiques, des stratégies, des outils spéciaux, de façon à arriver à transformer les organisations à plus grande échelle pour cela.

Des techniques spécifiques aux plus grandes organisations

Mes différenciateur sont qu'on va toujours travailler sur un plan de transformation pour bien définir les objectifs et comment on va mesurer le succès. C'est vraiment fou. Je vais utiliser ce mot là, de voir que je peux parler à tellement d'entreprises qui ultimement, ne savent même pas comment définir le mode produit puis comment on peut s'assurer.

Voilà qu'on a atteint le niveau attendu, qu'on est suffisamment mature ou qu'au contraire on a encore besoin d'investir pour continuer à développer la pratique. La deuxième chose, ensuite, c'est que je bâtis des playbook uniques pour mes clients. Le contexte de chaque entreprise est différent, la façon d'implanter les pratiques, c'est différent également.

Et donc il est extrêmement important d'arriver à développer un référentiel documentaire qui va vraiment être unique à chaque entreprise pour pouvoir ensuite arriver à opérationnaliser le changement. pour les plus grandes entreprises, ce n'est pas la théorie. Le problème, c'est très facile pour tout le monde de comprendre.

C'est quoi le mode produit? Comment ça fonctionne? Le défi, c'est comment on pousse ce changement là au quotidien, à travers un grand nombre d'équipes avec des contraintes opérationnelles qui sont plus grandes pour que ce changement puisse se faire réellement et également s'inscrire dans la durée. Enfin, la troisième chose que je fais, c'est que j'opère les communautés de pratique dans les organisations de façon à s'assurer qu'en tout temps tous les employés, tous les leaders, peuvent continuer à échanger, à apprendre et à grandir tous ensemble, les grands sujets d'une transformation produit.

Adoption du Mode Produit

On va parler bien sûr un de comment on met en place un contexte qui va permettre d'activer le succès. Donc on va parler de vision, produit, stratégie produit. mais également de la topologie des équipes, c'est à dire comment on va découper et organiser toutes les différentes personnes en équipe, en squad.

Et ensuite on va parler de l'exécution produit, donc comment on identifie, puis on valide les priorités. C'est ce qu'on appelle le l'exploration produit et bien sûr comment on bâtit les produits de la manière la plus agile possible pour avoir de l'impact mais également travailler d'une manière rapide et efficace.

si tout ce que je viens de vous dire ah vous semble pertinent et pourrait aider votre entreprise justement à pouvoir mieux performer, mais également mettre en place des équipes qui vont être plus satisfaites et qui vont pouvoir s'accomplir encore plus dans leur travail. N'hésitez pas à me contacter, ça me fera très plaisir, bien sûr de discuter de vos besoins.

Je vous remercie d'avoir pris le temps de m'écouter et je vous dis à très vite.

Introduction

Bonjour à tous, c'est Vincent. J'espère que vous allez bien. Aujourd'hui, je suis particulièrement enthousiaste de vous présenter un nouveau type de contenu que j'ai mûri depuis longtemps et que je souhaite lancer en 2024. Actuellement, je suis en phase de prototypage, expérimentant jusqu'à la fin de l'année pour évaluer ce qui fonctionne et ce qui nécessite des ajustements.

Je vous encourage vivement à partager vos impressions. Qu'en pensez-vous de cette approche ? Du format que nous envisageons ? Mon projet consiste à aborder ce que j'appelle la "question de produit", une démarche consistant à traiter des problématiques concrètes soulevées par les communautés et les organisations avec lesquelles je collabore. L'idée est de s'ancrer dans des problèmes réels, issus du terrain.

Mon objectif est de générer du contenu tangible et directement applicable, en m'éloignant des théories générales, souvent perçues comme éloignées de la pratique. Ces critiques reviennent fréquemment dans les discussions sur l'amélioration dans le domaine du produit. Je m'efforcerai donc de partager, en trois minutes, des pistes de réflexion, des conseils pratiques pour vous aider à progresser sur des thématiques spécifiques.

Je vous invite à interagir, poser des questions, ou demander des précisions en commentaire. Cela me ferait plaisir de développer davantage certains points.

SLAs qui varient entre les produits, un enjeu à régler?

Aujourd'hui, le sujet abordé concerne une question spécifique sur les SLAs (Service Level Agreements) que j'ai reçue, très représentative des défis rencontrés dans les grandes organisations et les équipes platformes.

Ces structures possèdent des portefeuilles de produits avec des niveaux de Service Level (SL) très variés. Les différences peuvent concerner des produits, des plateformes, des API, ou des microservices, chacun avec ses propres critères d'optimisation, performances, rapidités, et temps de réponse.

L'enjeu est de comprendre la variabilité des performances et de la qualité. Comment gérer cette diversité ? Comment s'assurer que, du point de vue de la gestion d'ensemble, nous avancions de la meilleure manière possible ?

1. Ne pas le régler, et développer la capacité de jugement de l’équipe

La première réflexion que je souhaite partager, c'est qu'il n'est peut-être pas nécessaire de tout uniformiser.

Il existe un biais, surtout chez les techniciens, à vouloir appliquer la même règle partout, sous prétexte de clarté ou de robustesse. Cependant, dans une approche produit, ce qui importe, c'est de répondre adéquatement aux besoins des clients et des utilisateurs. Il s'agit donc de maximiser le jugement et la capacité de décision de l'équipe produit. Si vous êtes un leader produit, comment pouvez-vous apporter contexte et informations à votre équipe pour qu'elle comprenne mieux son environnement et prenne les bonnes décisions ?

Si vous êtes membre d'une équipe, il est crucial d'interagir avec les parties prenantes pour comprendre l'environnement dans lequel vous opérez et ajuster vos stratégies en conséquence.

2. Le régler, si c’est un différentiateur stratégique

Le deuxième point que j'aimerais soulever est quelque peu opposé à ce que je viens juste d’écrire ;-)

Est-il judicieux d'adopter une règle uniforme, par exemple en termes de disponibilité ou de temps de réponse pour les API ? Cela peut avoir du sens si c'est un élément stratégique, c'est-à-dire un aspect clé de votre stratégie produit et de votre proposition de valeur, qui définit l'identité de vos produits.

Prenons un exemple concret. Jira est réputé pour son interface lente, alors que des outils comme ClickUp ou Linear se sont distingués par des interfaces ultra-réactives. ClickUp s'engage à charger les pages en moins de trois cents millisecondes, et Linear, peut-être même en cent millisecondes. Ces critères de performance sont devenus des éléments distinctifs de leur proposition de valeur.

Il est donc important de réfléchir à ce qui, dans votre contexte, pourrait constituer un différenciateur stratégique et un élément clé de votre proposition de valeur.

3. Ce qui compte: être outillé pour attaquer le problème

Pour conclure, l'essentiel est de reconnaître que peu importe votre niveau de performance actuel, il représente votre point de départ. Ce qui est considéré comme excellent aujourd'hui pourrait devenir moyen demain. Comment vous assurer de mettre en place des processus d'amélioration continue ? Comment vous assurer de trouver des moyens, au fil du temps, pour continuer à progresser ? Le choix de la cadence vous appartient, que vous souhaitiez rattraper un retard ou simplement maintenir un bon niveau.

Ce qui est certain, c'est que toutes les équipes et toutes les entreprises doivent disposer de moyens pour s'améliorer constamment, car la barre des standards et des attentes ne cesse de monter. Voilà, c'était mon tour d'horizon en trois minutes. J'espère que vous avez trouvé cela intéressant.

Pour toute question ou pour plus de détails, n'hésitez pas à laisser un commentaire. Cela me ferait grand plaisir de continuer la discussion avec vous.

Merci beaucoup et à bientôt!

“Les questions produit” est un nouveau format que j'expérimente. Donc, s'il vous plaît, si vous avez des commentaires sur ce que vous allez regarder, n'hésitez pas à les partager avec moi.

En quelques minutes, je vais aborder une question très concrète du terrain, des équipes que je coache. Mon objectif est de fournir une analyse rapide avec des insights tangibles qui peuvent vous aider au quotidien. Je pense que dans le monde du produit, nous avons souvent du mal avec des théories de haut niveau difficiles à relier et à comprendre comment appliquer ces concepts de manière tangible pour une action immédiate.

Alors, plongeons dans un sujet : aujourd'hui, j'aimerais parler des parties prenantes commerciales et de l'établissement de bonnes relations entre les équipes commerciales et de produit. La question que j'ai reçue était de savoir comment gérer les parties prenantes commerciales lorsqu'il n'y a pas d'antécédent de collaboration. C'est très intéressant car nous pourrions être dans un contexte où le modèle de produit est nouveau, la personne en charge du produit est nouvelle, l'équipe de produit est nouvelle. Alors, quels changements pouvons-nous faire ? Il pourrait y avoir quelque chose de complètement nouveau à construire, ou peut-être certaines choses à changer ou à rattraper.

Voici trois choses rapides que je peux partager pour vous aider : (Et encore, si vous avez des questions, n'hésitez pas à commenter. Je serai heureux de donner plus de détails.)

Le rôle des leaders produit est crucial.

Ils sont responsables du contexte stratégique, de la vision du produit, de la stratégie du produit et de la topologie de l'équipe, qui comprend la façon dont les équipes sont divisées et organisées, englobant le marketing, les ventes, les opérations et d'autres parties prenantes. Il est vital pour les leaders de produit de promouvoir activement, en expliquant la direction et les décisions de l'équipe de produit pour construire la confiance et la familiarité. Cette confiance fondamentale est essentielle pour que les équipes soient impactantes et fiables auprès des parties prenantes.

La proactivité au niveau de l'équipe est également clé.

Que vous soyez un chef de produit, un designer ou un leader d'équipe, ne soyez pas passif. Engagez-vous de manière proactive avec les parties prenantes. Cela pourrait impliquer d'avoir des déjeuners réguliers ou de chercher un mentorat auprès d'un VP des ventes, par exemple. Construire ces relations peut aider les parties prenantes à comprendre et à faire confiance à votre travail, vous permettant plus de liberté pour opérer efficacement.

Créer des artefacts visuels top niveau.

La présentation de vos documents est aussi importante que le contenu. Une vision du produit bien présentée, comme une vidéo convaincante, peut être plus impactante et partageable qu'un long document texte. Adaptez vos feuilles de route aux différents publics, comme les équipes de vente ou de marketing, pour les rendre pertinentes et engageantes. Il ne s'agit pas seulement d'utiliser des outils ; il s'agit de communication et de construction de relations.

En conclusion, ces étapes peuvent aider à construire des relations positives et constructives avec les parties prenantes, basées sur la confiance et la compréhension mutuelle. Cela peut finalement vous donner l'espace pour faire un excellent travail de produit.

Faites-moi savoir si vous avez des questions. J'espère que cela a été instructif, et j'ai hâte de vous revoir bientôt pour une nouvelle question produit!

Hey, everybody, this is Vincent and welcome to a new product question.

“Product Questions” is a new format I'm experimenting with. So please, if you have any feedback on what you're going to watch, please feel free to share it with me.

In just a few minutes, I'll tackle one very concrete question from the field, from the teams I'm coaching. I aim to provide a quick deep dive with tangible insights that can help you on a daily basis. I think in the product world, we often struggle with high-level theories that are hard for people to relate to and understand how to apply those concepts in tangible ways for immediate action.

So, let's dive into one topic: today, I'd like to talk about business stakeholders and setting up great relationships between business and product teams. The question I got was how to deal with business stakeholders when there is no history of collaboration. This is super interesting because we might be in a context where the product model is new, the product person is new, the product team is new. So, what changes can we make? There might be something completely new to build, or perhaps some things to change or catch up with.

Here are three quick things I can share to help you: (And again, if you have questions, feel free to comment. I'll be happy to give more details.)

Product Leaders need to share their strategic context

The role of the product leaders is crucial. They are responsible for the strategic context, product vision, product strategy, and a team's topology, which includes how teams are split and organized, encompassing marketing, sales, operations, and other stakeholders. It's vital for product leaders to proactively evangelize, explaining the direction and decisions of the product team to build trust and familiarity. This foundational trust is essential for teams to be impactful and trusted by stakeholders.

Product Team: Be proactive!

Team-level proactivity is also key. Don't be passive whether you're a product manager, designer, or team lead. Engage proactively with stakeholders. For example, this might involve having regular lunches or seeking mentorship from a VP of Sales. Building these relationships can help stakeholders understand and trust your work, allowing you more freedom to operate effectively.

Polish and adapt your visual artifacts

The presentation of your documents is as important as the content. A well-presented product vision, such as a compelling video, can be more impactful and shareable than a lengthy text document. Tailor your roadmaps to different audiences, like sales or marketing teams, to make them relevant and engaging. It's not just about using tools; it's about communication and relationship building.

In conclusion, these steps can help build positive, constructive relationships with stakeholders, based on trust and mutual understanding. This can eventually give you the space to do great product work.

Let me know if you have any questions. I hope this was insightful, and I look forward to seeing you soon for a new product question.

Thank you all, and see you soon for a new product question!

Introduction

Hello everyone, this is Vincent. I hope you're doing well. Today, I'm particularly excited to introduce you to a new type of content I've been developing for a long time and plan to launch in 2024. I'm in the prototyping phase, experimenting until the end of the year to evaluate what works and what needs adjustments.

I strongly encourage you to share your impressions. What do you think of this approach? Of the format we are considering? My project involves addressing what I call the "product question”, a process of dealing with concrete problems raised by the communities and organizations I work with. The idea is to focus on real, on-the-ground issues.

I aim to generate tangible and directly applicable content, moving away from general theories often perceived as detached from practice. These criticisms frequently arise in discussions about improvement in the product field. Therefore, in three minutes, I will strive to share lines of thought and practical advice to help you progress on specific topics.

I invite you to interact, ask questions, or request clarifications in the comments. I would be pleased to elaborate on specific points.

Are SLAs Varying Between Products an Issue to Address?

Today's topic concerns a specific question about SLAs (Service Level Agreements) I received, representing the challenges large organizations and platform teams face.

These structures have product portfolios with very varied Service Levels (SL). Differences may concern products, platforms, APIs, or microservices, each with its own optimization criteria, performance, speed, and response time.

The challenge is to understand the variability of performance and quality. How to manage this diversity? How to ensure that, from an overall management perspective, we move forward in the best possible way?

1. Not to Resolve It, and Develop the Team's Judgment Capacity

The first reflection I would like to share is that standardizing everything may not be necessary.

There's a bias, especially among technicians, to want to apply the same rule everywhere, under the pretext of clarity or robustness. However, in a product approach, what matters is to meet the needs of clients and users adequately. It's about maximizing the judgment and decision-making capacity of the product team. If you're a product leader, how can you provide context and information to your team so they better understand their environment and make the right decisions?

If you're a team member, it's crucial to interact with stakeholders to understand the environment you operate in and adjust your strategies accordingly.

2. To Resolve It, If It’s a Strategic Differentiator

The second point I'd like to raise is somewhat the opposite of what I just wrote ;-)

Is it wise to adopt a uniform rule, for example, regarding availability or response time for APIs? It makes sense if it's a strategic element, that is, a key aspect of your product strategy and value proposition, defining the identity of your products.

Let's take a concrete example. Jira is known for its slow interface, while tools like ClickUp or Linear have distinguished themselves with ultra-reactive interfaces. ClickUp commits to loading pages in less than three hundred milliseconds, and Linear, perhaps even in a hundred milliseconds. These performance criteria have become distinctive elements of their value proposition.

It's, therefore, important to consider what, in your context, might constitute a strategic differentiator and a key element of your value proposition.

What Matters: Being Equipped to Tackle the Problem

In conclusion, the essential thing is to recognize that no matter your current level of performance, it represents your starting point. What is considered excellent today might become average tomorrow. How can you ensure the implementation of continuous improvement processes? How can you ensure you find ways, over time, to continue progressing? The choice of pace is yours, whether you want to catch up or maintain a good level.

What is certain is that all teams and all companies must have means to improve constantly, as the bar of standards and expectations continues to rise. That was my overview in three minutes. I hope you found this interesting.

For any questions or more details, please feel free to leave a comment. I would be very pleased to continue the discussion with you.

Thank you very much, and see you soon!

Hi, I'm Vincent Pavero, and thank you for watching my introduction video. I'm a product coach, and I will present who I am in my services in two minutes. Unlike most of my peers, I don't focus on startups and scale-ups. Instead, I focus on product transformation with larger organizations, with more people, complex structures, and legacy.

Complex organizations need more than coaching

In those organizations, coaching is just not enough. We need to find innovative ways to operationalize the transformation. So whether you're moving from projects to products, you are building a product practice on the top of an agile transformation, or you just want to find the best ways to innovate for your organizations, I will help you with different strategies, tactics, and tools to make sure you can be successful in your product transformation.

The way I work is always to start with a transformation plan and assessment to make sure we have clear success criteria for your transformation initiatives. It's actually pretty crazy to see how many companies Do not know how to answer the question of how you measure success. So I will help you with that.

And then something also very unique I do is I will build with you a very unique playbook, combining all the best principles from the product operating model that is used in all. The most innovative and successful companies in the world, but we will combine those principles with your unique constraints and requirements to make sure you can find your own way to implement great product practices.

Once the playbook is in place, I will be present to help you run your product committee of practice and make sure everybody in many teams can learn, share and grow all together.

Adopting the Product Operating Model

In your playbook, in addition to the practices specific to your organization, we will cover typical topics like setting up the right environment to make your team succeed. So we'll talk about product vision, product strategy, and team topology. How you organize all the people in different squads to make sure you can deliver all the results that you need.

Then we'll talk about product execution, which combines product discovery, how you identify and validate the right solution to build, and then agile product delivery, which is about how you build your solution in the best possible way to have an impact and of course, go as fast as possible.

If you think it could be valuable for you, please feel free to connect with me and I will be very happy to discuss your needs. Thank you very much for your time. See you soon!