However, creating a clear set of practices and aligning on how we know they are adopted is only one dimension of a transformation initiative. It faces more challenges as you go into its operationalization.

Fixing: No Measurement

It's fascinating how organizations sometimes don't know what's happening with their employees. Don't think I'm exaggerating: We've been watching agile transformations for 15 years, and while most leaders have opinions about their organizations' agile maturity, it's often very hard for them to indicate which departments or squads are more mature and why. And the leaders' opinions rarely align with the teams' feelings.

You all know the adage, "You can't manage what you don't measure, " which certainly holds true for coaching and transformation initiatives. Yet, most coaches, experts, and leaders of centers of excellence remain ill-equipped to assess the maturity levels of the teams and people they need to support.

How can you establish a successful assessment approach in the context of a human-first transformation and coaching initiative?

• Binary People need clarity: The main question is always "Am I there?" It's a yes/no question. Assessments must clearly state whether change is still needed to drive behavioural change.

• Continuous Just as in people management, yearly assessments are a waste of time and resources. In transformation initiatives, continuous measurement is critical. It enables short feedback loops, which are vital for driving behavioural change. This is why we firmly believe in creating dedicated technology to support complex transformation and improvement initiatives.

• Scalable Hiring one consultant to assess a few people or teams is easy. Hiring hundreds to evaluate thousands of people or teams is not viable. Some organizations are just too big to assess how they work efficiently, which is crazy. That is why technology is crucial to enabling successful transformations.

Homeric: Benchmarking & Monitoring

Measuring and assessing how people and teams work is at the heart of any coaching and improvement initiative. It's not about controlling and policing but more about developing people in a direction that will benefit both them and the company.

One of the core innovations of the Homeric platform is embedding assessments into playbooks by design. Each practice comes with success criteria that are used to evaluate whether a given practice is applied (Binary).

Using polls, surveys, or integrations with tools like Jira, Confluence, or Office, Homeric can also automate assessments by collecting and processing data and updating the practice status at any time (Continuous).

Because Homeric is a piece of technology, it can be used by one team or a thousand without needing more time or budget, unlike consultants. (Scalable).

drag embedded asset

published

For the first time, domain experts, coaches, and practice leaders can leverage data-driven scorecards to prioritize and adapt their work, prove and maximize their impact, and finally deliver successful transformations.

(Feel free to book a demo; we'll happily show you how transformative our platform is!)

The truth is that no one has ever read this document seriously. No one was involved, so no one cared. The document gathers dust in Sharepoint and Google Drive. The person who wrote it may have left, and no one even remembers where to find it. Consider the typical presentation, a jumble of 1,000 bullet points and overcrowded slides. It's a recipe for forgetfulness, ensuring that nothing sticks. And let's remember the lack of involvement from the people and teams expected to change their working methods. Is it any wonder that this uncontextualized content is met with resistance?

Step into the graveyard of Agile transformations, product model adoptions, centers of excellence, chapters, communities of practices, and other continuous improvement initiatives. Here, documentation lies dormant, a testament to its ineffectiveness in driving change. But here's the real truth: It's not the documents that transform organizations; it's the people. Armed with expertise, active engagement, and the correct bites of documentation to assimilate, leaders, coaches, consultants, and experts have the power to drive change, not the tools themselves.

How can documentation, tools, and technology in general finally enable successful transformations and thriving communities of practice and centers of excellence instead of dragging your continuous improvement efforts down?

Fixing: No Engagement

Whether you're using tools like Confluence, Notion, or PowerPoint, they are not designed to maximize engagement and content consumption. It's just not what they are meant to do. These tools are before all databases and information repositories, aiming at the editor's satisfaction, not the reader.

As a result, they are terrible tools in the context of coaching and training people. They encourage the creation of tedious, generic, and extensive documents, quickly obsolete and hard to maintain, that will fail to engage and convince people to adopt new behaviours and practices.

In intense company operations, when people and teams don't even get enough time to work on their improvement initiatives, the consequence is immediate: they will ignore, push back and intensely criticize the transformation initiative.

What are the keys to valuable and impactful documentation that can change how people and teams operate in your company?

• Atomic

  Content must be sliced into small, actionable, digestible, memorable and personalized (contextualized) nibbles to be accepted and generate engagement and learning.

• Measurable Many frameworks and operating model presentations have been doomed to fail since day 1. Suppose you can't explain what the new practice or behaviours will look like. How can you expect your entire organization to adopt it? Why would someone change if no one checks if it's done?

• Interactive & Personalized

  A transformation or improvement initiative should be tackled from the receiver's perspective, not the change agent's. Documentation should not be fun to create. It must be fun to consume.

You won't be surprised that these principles are at the core of the Hoemric platform and explain why we focus on creating playbooks: Each play is a new practice of behaviour that must be adopted and documented in an atomic, measurable, interactive, and personalized way.

The leader, coach, and consultant editing the playbook uses the power of Homeric's technology and AI not to create more documentation faster but to create an engaging experience for the readers, who will ask more!

Fixing No Distribution

With tools whose mission is to be the best possible databases and information repositories, it's fascinating to see how they take for granted that you need to go to them. Isn't this arrogant? It's as if, as a coach, I'd stay in my office all day and say, "I only coach from my desk; you have to walk to me, not the opposite." How successful would I be?!

This is another collective failure of all these documentation tools. While designed to store content, they are not intended to distribute it. This is the difference between success and failure in the context of a transformation or improvement initiative. Employees and teams are busy. There is no task or event in calendars to "change working habits", so they do not go to the documentation systems to read poor content proactively. They don't, and it's not related to the quality of the documentation. It's related to how efforts to learn and change fit within a working day.

Some organizations invest a lot of time and money to move information across various systems, thinking the documentation is not consumed because it was in the wrong place. So, they create integrations between Notion, Confluence, Asana, JIRA, Sharepoint, and more tools to flow information. Still, it has a negligible impact only. Whatever the tool is, if the employees and teams don't have some capacity to focus on the documentation, they will never go on the documentation system.

What should we be doing to spread best practices and behaviours successfully?

• Proactive

  Yes, we must stop going to the documentation system. The future belongs to proactive systems that come to us. Anything that helps you become a better professional should reach out when it's relevant and valuable.

• Nudges

  Improving best practices is not an operational task, so there is no allocated time for it. This is why coaching and training should be delivered through nudges - small touchpoints that will not distract you from your daily activities.

• Consistency

  The messaging must be consistent anytime, anywhere in the organization. It's especially hard when working at scale with potentially tens of different coaches or consultants delivering their own message variant. This can be incredibly disengaging for the teams and discrediting for the change agents.

These observations are also at the core of Homeric's product principles. This is why we created the first "vocal documentation system". Users don't need to come and allocate time to browse and learn the playbooks: The playbooks will go to them. Our AI generates observations, insights, recommendations, highlights, and other small nudges automatically distributed through typical communication channels like Slack, Teams, or email. And because Homeric is a piece of technology, influencing and nudging five users or 5,000 represents precisely the same effort.

Fixing: No Harmonization

When working in larger organizations and on a larger scale, improvement and transformation initiatives involve multiple experts, consultants, or coaches, depending on the nature of the initiative. Just think of the Agile transformation at Capital One, one of the biggest US banks. They had more than 1,200 agile coaches and scrum masters with the mission to deploy Agile methodologies across the organization.

How can you ensure these people promote and spread the same message and practices? Even in smaller organizations, once you have a few coaches, how can you ensure everybody contributes to the emergence of a company culture precisely defined by sharing the same behaviours? You can't, and this is why you need some reference documentation.

Some companies may have a PowerPoint document or a Confluence page used as shared material between the coaches and experts. However, they often miss the point as they describe processes or frameworks instead of the actual practices and behaviours to be adopted. Then, as it's open for interpretation, each coach and expert can advocate for their version of the transformation, creating a massive amount of frustration around them while setting the transformation for failure.

What are the key elements between harmonized coach and transformation at scale?

• A reference that cannot be copied

  It's always unbelievable how often people make their own variants of different documents. Obviously, people need to look at the same sources to promote the same message and practices.

• Clear success criteria

  Describing practices and behaviours is one thing; aligning on how to confirm they are applied is another. Most organizations have stakeholders and players with differing views on what change looks like and how to assess whether the expected change is achieved.

• Open dialogue

  It's impossible to "decide alignment". It's created through continuous discussions, feedback and adaptation. Without this constant dialogue, each coach, expert and team will stay in their lance, doing their own version of anything. Beyond the induced failure of any improvement or transformation initiative, companies are doomed to live in an environment with endless friction, arguments and the complete absence of a work culture fostering innovation and performance.

These principles are certainly at the core of Homeric design. The collaborative workspace allows coaches and experts to work on the same reference material and forces them to describe and use the same criteria while enabling communities of practices and centers of excellence to foster communication between the transformation agents and the teams and individuals who need to adopt new work methodologies.

In conclusion, I can't stress enough how crucial it is for organizations to move away from presentations and spreadsheets when managing change, improvements, and transformations. It simply does not work. While the objectives, techniques, and behaviours to adopt may remain the same as the organization scales, the context requires companies to equip appropriately. Engagement, distribution, and harmonization become the driving forces of impactful documentation. Do not stay stuck with tedious documents gathering dust on Confluence, Sharepoint, or Google Drive!

We certainly want Homeric to be the right solution for all of this. Feel free to reach out if you want to know more. We'll be happy to help you find better ways to make your improvement or transformation initiative the success it deserves to be!

We've been co-building Homeric with amazing customers (thank you all again for your support, collaboration, and feedback!), including world-class players like CGI, Roche, CBC, Alten and Michelin, who allowed us to deeply understand the reach and potential of our vision and technology.

Homeric has evolved from an AI assistant to a comprehensive operating system, empowering leaders, coaches, and experts to drive their transformation and improvement initiatives. Our technology enables the propagation of expertise across employees, teams, and departments in a scalable, measurable, and human-centred way.

Homeric is a powerful tool for organizations seeking to enhance their work culture. Whether it's about being more agile, transitioning from project to product, adopting new business models, or onboarding new employees, it enables professionals to create reference playbooks that are automatically distributed and evangelized at any scale. This feature facilitates harmonizing practices across multiple departments, sites, or coaches.

Attached to these playbooks, leaders, coaches, and experts can train our tool to assess whether a given practice from the playbook is genuinely adopted. Homeric will now continuously monitor how change spreads across organizations, generating real-time benchmarks and progress reports from the individual or team level to consolidated data at the company level.

We can't wait to show what Homeric can do to more people, and we'll be proud to be your trusted partner in any transformation or improvement efforts you may need to implement!

Following the success of INSPIRED, aimed at team members in product development, and EMPOWERED, intended for product managers and leaders, TRANSFORMED takes a step further. The goal now is to engage with company executives and business unit heads. TRANSFORMED aims to enable and catalyze the changes necessary for the successful application of the principles and practices shared in Cagan's earlier works, thereby fostering an environment of product transformation and sustainable innovation.

From this workshop, I took away three key insights:

Lesson 1: Product Success Isn’t Limited to Silicon Valley's Big Tech

The main critique of Marty Cagan's work is that his principles only apply to digital, internet-era companies. Critics argue they aren’t transferable to large organizations or those carrying a "legacy." TRANSFORMED disproves this view with detailed case studies from industries such as healthcare, transport, media, travel, and finance. These companies have not only successfully applied the principles of INSPIRED and EMPOWERED, but they've demonstrated such outstanding results that industry giants like Google, Amazon, and Apple are referring to them as examples to follow!

Lesson 2: A successful Product Transformation Requires Powerful External Enablers and Coaching

One surprising-but-not-so-surprising revelation from the workshops was the importance of external catalysts in a successful product transformation. I think it's a brutal conclusion because many smart people and organizations will train, learn, practice and try to transform by themselves. But the effectiveness of this approach is not confirmed by experience. Based on industry research and successful examples:

Either there was a complete reset of the product leadership team (CPO, CTO at a minimum) with the arrival of experienced leaders on the product model who massively coached their organization.

Or there were product coaches " who had been there done that" deeply integrated into the transformation effort, with an ability to act well beyond a benevolent presence and daily experience sharing.

No enabler, no transformation. Or at least, we are still looking for an example! Don't hesitate to comment or contact us if you have any"examples in mind!

Lesson 3: AI is Crucial for Large-Scale Transformation

Drawing from my experience at Homeric Technologies, it became clear that AI is pivotal in successfully propagating good practices and establishing a product-focused culture in an organization. Given the complexity of global companies with multiple independent business units, it's unrealistic to think transformation can be achieved without the aid of AI and related tools to augment the reach, influence and impact of the enablers who will make or break your transformation. I'm more convinced than ever that the technology we develop can make a huge difference. Let's do it!

Our "AI-Powered Playbooks" have now been successfully deployed in about fifteen countries. Regardless of the size of the organization, these playbooks allow the product culture to thrive every day, thereby facilitating empowerment and product innovation.

Are you ready for your own product transformation journey? What are the key challenges and blockers you face at an organizational level? Feel free to leave a comment or get in touch if you have any questions or insights to share.

Choosing Which Problems to Solve

Product teams are responsible for quickly and consistently solving difficult problems in ways that customers love and organizations can sustain. Choosing which problems to solve is critical because there are always hundreds of problems or ideas but only a limited amount of resources to implement a couple of solutions.

Strong product companies establish an effective strategic context by having a compelling vision and an effective product strategy to identify the most important problems to solve to achieve the product and company vision.

Solving Problems

Setting up the right strategic context is essential in order to focus and decide which problems to solve. It also provides teams with the information they need to make better decisions, enabling them to solve problems in truly empowered ways.

Instead of stakeholders prioritizing their projects and providing them with a roadmap to build, strong product teams are assigned problems to solve, and the cross-functional team is empowered to discover a solution that is valuable, usable, feasible, and viable.

Building and Deploying

Despite Agile being around for many years, many organizations still rely on infrequent big-bang releases. The rise of "Fake Agile," focusing on processes and one-size-fits-all frameworks, puts companies in situations where they supposedly reinvented themselves but actually never changed how they build and deploy software.

Not being able to generate data and insights in a matter of days is an innovation killer and will hinder the organization's ability to compete with more informed, agile, and innovative players.

As we conclude our discussion on the patterns of the best product teams, it's clear that setting the right strategic context, solving problems in empowered ways, and adopting agile practices for building and deploying software are crucial elements for success. By prioritizing the most important problems, embracing innovation, and leveraging data-driven insights, product teams can position themselves for competitive advantage in today's dynamic marketplace. Stay tuned for more insights and strategies to enhance your product team's performance.

The Challenges encountered by product teams not using product OKRs

Product teams that don't use OKRs (Objectives and Key Results) often struggle with clarity and focus. Without clearly defined and measurable goals, it's difficult to ensure that everyone on the team is moving in the same direction. This can lead to inadequate alignment, wasted effort, and missed opportunities. Product teams may also struggle with prioritizing work, as it's harder to decide what to focus on without clear objectives and key results to guide decision-making.

Decoding the OKR Framework: A Game Changer for Your Product Team

The OKR framework is a powerful tool for setting and achieving goals. The "O" stands for Objectives - these are clear, actionable goals that align with the company's vision. The "KR" stands for Key Results - these are measurable outcomes that indicate progress towards the Objective. A well-defined OKR is aligned with the company's vision, specific, time-bound, measurable, and ambitious.

Power Up Your Productivity: Unleashing the Potential of OKRs

OKRs provide a framework for setting ambitious goals and tracking progress towards them. They ensure alignment across teams and individuals, promote focus and coordination, and facilitate communication about what's important. They help to create a results-oriented culture where success is defined by the achievement of measurable outcomes.

OKRs in Action: 5 Inspiring Real-World Examples for Your Product Team

I found a few great examples of product OKRs:

1. Objective: Implement a weekly newsletter successfully. Key Results include achieving a 45% open rate and growing the email subscriber base by 10% each week.

2. Objective: Optimize our marketing funnel. Key Results include running 35 user interviews with the target audience and increasing the visitor-to-trial conversion rate from 6% to 12%.

3. Objective: Improve customer satisfaction by 45% by the third quarter. Key Results include increasing the Net Promoter score from 7.0 to 8.5 and reducing the number of requests to support from 3.5 to 1.0 per user per month.

4. Objective: Improve customer engagement by 50% by the third quarter. Key Results include increasing monthly customer retention rates from 40% to 60% and increasing the average time spent on our app from 10 mins to 20 mins.

5. Objective: Improve product team learning by 45% by the end of the year. Key Results include holding bi-annual meetings for old and new staff members to educate them on company culture and history, and conducting weekly knowledge sharing sessions held by product team members​.

Each of these OKRs is a great example because they are specific, measurable, achievable, relevant, and time-bound. They can help to drive engagement and commitment from the team by providing clear goals and measurable outcomes.

Mastering Product OKRs: Top 3 Pro Tips for Success

Embarking on your product OKRs journey? These best practices will help ensure your success.

1. Alignment is Essential

Your product OKRs must be closely aligned with your organization's broader objectives. When your product team's efforts are synced with the company's mission, it creates a powerful synergy that accelerates progress. Make sure your product OKRs aren't isolated goals but contribute meaningfully to the overarching business strategy.

2. Set Measurable and Ambitious Goals

OKRs thrive on ambition. Don’t shy away from setting lofty objectives. However, make sure these goals are measurable. Quantifiable key results allow you to gauge your progress and success accurately. This balance between ambition and measurability ensures you aim high, but also have tangible markers to track your journey.

3. Regularly Review and Adjust

OKRs aren't set-and-forget goals. Regular check-ins to review progress are crucial. These touchpoints allow for necessary course corrections and adaptations. Remember, it's about progress, not perfection. If circumstances change or if a key result isn't driving the expected impact, don't hesitate to adjust. This continuous learning and adaptation keep your OKRs relevant and effective.

The core differences between project and product management

Before diving into the intricacies of the transition, it's essential to understand the fundamental differences between project management and product management.

Project management focuses on the planning, execution, and closing of projects. It involves coordinating resources, setting and meeting deadlines, and ensuring that the project's goals are met within the given constraints. Project managers often work with a variety of stakeholders, including team members, clients, and upper management, to ensure that the project stays on track and delivers the desired results.

Product management, on the other hand, is centered around the creation, development, and continuous improvement of a product or product line. Product managers are responsible for guiding the product's vision, strategy, and roadmap, while also working closely with cross-functional teams such as design, engineering, and marketing to bring the product to market. They are constantly iterating and refining the product based on customer feedback, data analysis, and market trends, to ensure it meets the needs of its target audience and achieves business objectives.

Some key differences between project and product management include:

• Scope: Project management is generally focused on a single project with a defined start and end date, while product management is an ongoing, continuous process that evolves as the product and market change.

• Goals: Project managers are primarily concerned with delivering a project on time and within budget, whereas product managers aim to create and maintain a successful product that drives customer satisfaction and meets business objectives.

• Methodologies: Project management often follows more traditional, structured methodologies such as Waterfall, while product management typically embraces more flexible, iterative approaches like Agile and Lean.

• Team Structure: In project management, teams are often assembled for the duration of a specific project and then disbanded once it's completed. In product management, teams tend to be more stable and long-lasting, fostering deeper collaboration, shared ownership, and a stronger understanding of the product and its users.

The challenges of transitioning

We won’t lie: transitioning from project management to product management is challenging. You should be ready to:

• Embrace uncertainty and learn from failure: Product management involves more ambiguity than project management, necessitating comfort with making decisions based on incomplete information, taking calculated risks, and learning from both successes and failures.

• Navigate different team dynamics: Product management teams are more stable and long-lasting, requiring strong relationships with cross-functional team members and a deep understanding of the product and its users.

• Adopt a new mindset: Product management is about outcomes and business impact. It requires frequent changes through continuous experimentation, customer interactions and data analysis. Meeting deadlines or staying within budget are not driving the show.

The benefits of embracing product management for your business

Companies that adopt product management principles and practices can reap significant benefits that contribute to their long-term success. Some of the most notable advantages for businesses include:

• Sustained innovation: Product management promotes a culture of innovation by encouraging teams to experiment, learn from failures, and iterate on their ideas. This approach allows companies to stay ahead of the competition, adapt to changing market conditions, and create cutting-edge products that drive growth.

• Customer-centricity: By embracing product management, companies prioritize understanding and meeting the needs of their customers. This customer-focused approach leads to the development of products that solve real problems, ensuring greater customer satisfaction and loyalty.

• Increased agility and adaptability: Product management methodologies, such as Agile and Lean, emphasize flexibility and responsiveness. By adopting these practices, companies can react more quickly to changes in the market, customer preferences, and emerging technologies, enabling them to remain competitive and seize new opportunities.

• Better alignment with business objectives: Product managers are responsible for aligning product strategies with overall business goals, ensuring that resources are effectively allocated and invested in projects that drive the most significant value. This strategic focus helps companies optimize their efforts, maximize ROI, and achieve long-term success.

• Improved cross-functional collaboration: Product management fosters collaboration between different departments within an organization, breaking down silos and promoting shared ownership of the product. This collaborative approach leads to more effective communication, a deeper understanding of the product and its users, and ultimately, better outcomes for the business.

Many stories can be found online about companies that have successfully (or not) embraced the shift.

A case study by the Boston Consulting Group (BCG) explored how Schneider Electric transitioned from a project-based approach to a product-oriented organization. As a result of this shift, SE experienced increased innovation, faster time-to-market, and improved employee satisfaction. The company credits this success to adopting product management practices and customer-centricity.

💡 Read the Schneider Electric case study on BCG's blog

Marty Cagan, author of "Inspired: How to Create Tech Products Customers Love," has worked with numerous successful companies that have shifted from project management to product management. He emphasizes that a customer-centric approach, empowered product teams, and a focus on outcomes over output contribute to increased innovation and employee satisfaction.

💡 Read these articles on SVPG's blog:

• Product vs. Project Teams

• Empowered Product Teams

How to navigate the shift from project to product?

A critical aspect of successful product management is fostering cross-functional collaboration. Encouraging collaboration between different departments within the organization leads to the creation of cross-functional teams focused on the product. This approach breaks down silos, promotes shared ownership of the product, and leads to more effective communication and decision-making.

Adopting an Agile mindset and culture across the organization is a key component of transitioning to product management. It means fostering an environment where teams work iteratively, learn from mistakes, and continuously adapt their processes and products based on feedback and changing circumstances. This approach enables companies to respond more quickly to market changes, customer preferences, and emerging technologies, ensuring they remain competitive and capable of delivering value to their customers.

Establishing a customer-centric culture is vital for the success of product management initiatives. Prioritizing the understanding and meeting of customer needs emphasizes the importance of customer insights, feedback, and data-driven decision-making. Product discovery techniques like customer interviews, surveys, and usability testing can be utilized to gather insights and inform product decisions.

💡 Find out why it's critical to involve your developers in product discovery activities.

Aligning product strategies with business objectives ensures that product managers work closely with business leaders. This strategic focus helps the company optimize its efforts, maximize ROI, and achieve long-term success. Finally, seeking external expertise and support can prove invaluable during the transition process. Engaging experienced product management consultants or coaches can provide valuable insights, share best practices, and help tailor product management methodologies to the specific business context. Additionally, utilizing a SaaS solution like Homeric Technologies, which is designed specifically to support companies in assessing their product management maturity and adopting best-in-class product management principles, can greatly facilitate their shift from project to product. 🚀 Find out how Homeric Technologies can help you build a world-class product culture.

In conclusion

The transition from project management to product management is challenging but highly rewarding for businesses. The companies who manage to efficiently navigate this shift will be able to reap the benefits of increased innovation and more engaged, happier employees. They will also increase their chances to thrive in today's competitive market landscape.

Coaching is the manager’s #1 responsibility

As a product leader, especially a Director of Product Management, it is essential to not only manage your team but also coach them. By developing their skills and allowing them to succeed, you are not only benefitting the individuals but also the organization as a whole. By providing support, guidance, and a clear vision, you can help your team members grow and achieve their full potential, ultimately leading to a more successful product and a more cohesive team. Being a manager and a coach is not an easy task, but it is necessary for those in leadership positions to take on both roles in order to foster a culture of growth and success within their teams.

Questions are a great way to develop people

Asking key questions can help product leaders foster success and growth for their product managers. By understanding the strengths of their team members, product leaders can better utilize those strengths and develop a culture of growth and development. Similarly, understanding how the team creates value and the rules they have set for themselves can help leaders identify areas for improvement and growth. Additionally, regularly discussing user feedback with the team and addressing any issues or complaints can help ensure that the team is working effectively and efficiently toward the success of the product, the team and the organization.

A sneak peek just for you!

Here are a few questions that are especially valuable for product leaders to drive 1:1 discussions with product managers. They are even useful to PMs, as you can use them yourself! The Homeric Platform hosts hundreds of other insights to help you grow the best agile product teams.

• What strengths and unique advantages does your team possess?

• How does your team's work create value?

• What rules have you established for working effectively with the team?

• What issues or challenges does your team have legitimate complaints about?

• When was the last time you discussed user feedback with the rest of the team?

• What are your teammate’s opinions of you?

Tell us how it went!

Have you ever used such questions to coach and manage product managers? We would love to know, so don’t hesitate to share your insights. If you want to know more about coaching PMs and creating outstanding agile product teams, please contact us!

• How does one transition from an academic background in engineering (Polytechnique Paris) and Political Sciences to a career in product?

• What is it like to work on product development in a century-old, giant corporation?

• How does the "L'Oréal spirit" make things easier for him?

• In his opinion, what are the main challenges faced by product organizations/teams?

• And finally, his mission to share knowledge and some recommended resources and tips.

Thanks again, Victor, for sharing these insights with our team. It was truly a pleasure!

If you had to introduce yourself simply to someone who is not in the industry, what would you say?

I would say that I work in the digital world. I build applications and digital tools that help people to easily accomplish certain tasks and make positive changes in their daily lives.

Furthermore, I enjoy sharing knowledge about this work. I like to explain how we build these digital products, how we ensure their quality, and how we ensure they meet identified needs. I believe it's important to simplify complex topics and help people understand what they are working on.

This is a relatively new field, so building discussions around it can help people make better decisions, reduce anxiety, and help people move forward in the right direction.

You have an interesting academic background (Polytechnique and Sciences Po). How did you transition to product management?

In essence, a product manager navigates between three worlds: business, tech, and UX. If I had to position myself, I come primarily from the technical side. I am an engineer with an academic background that included mathematics and physics. I enjoyed solving complex problems, which is what I still feel like I am doing today - solving complex problems using theoretical tools, science, and empirical laws.

I am also influenced by the business side, particularly through my education at Sciences Po. I learned how to explain things well and highlight what's important.

I began my career in consulting and quickly became interested in topics related to software development and digital technology. It was through agility that I naturally gravitated toward product management.

I love that it allows me to continue to touch on a wide range of expertises. I think it would have eventually frustrated me if I had been limited only to the technical aspect of software development.

When we talk about product culture, we often think of big tech companies or the startup world. You work at L'Oréal, one of the largest international groups. What is it like to do product management in a very large enterprise?

Interesting question! There are some things that work well, and others that don't.

To start with the positives:

• Historically, L'Oréal has been very marketing-driven. There are important parallels with agility, in the sense that the focus is on the user. There is a strong desire to create products that suit them well, all supported by research. In the company culture, there is a willingness to do things that really serve the customer and sell them in a smart way.

• L'Oréal has grown a lot through acquisitions. The organization is quite decentralized, with entities working in parallel. In terms of IT, the decentralization phenomenon is also present. There is a strong culture of autonomy and "empowered" teams that is conveyed. Although it is a large, century-old group, these are values that are deeply rooted in the company culture. Internally, we refer to the "L'Oréal Spirit," which is a sort of organized chaos that aims to liberate energies and direct them in the right direction, while avoiding constraining people. Once again, we are very close to agility and values found in product management.

When you read Empowered fron Marty Cagan, he explains that it takes a very clear vision, with teams inspired by this vision and the company's mission. This is very true in a company like L'Oréal. From my experience, this is quite rare in large companies that are often very centralized with an all-powerful IT department.

• On the other hand, a more challenging aspect is that we are extremely perfectionist. There is a very French and marketing-driven aspect to it. When you launch a product, you cannot take it back. This means that they are ultra-vigilant. In IT, we have the chance to release a product and have it evolve over time, but even though there has been progress in this area, it still goes somehow against L'Oréal's culture to admit that it is by failing that we learn.

And your role in all of this?

I work on developing "business" applications for L'Oréal employees to support the value chain that allows for the creation of a cosmetic product: research, operations, sales, marketing, finance, etc. There are several digital teams working on a multitude of products. These teams have different structures, levels of maturity, etc. I work around these teams to support them, help them strengthen their practices and operations, and be with them on the field.

You work with many product teams. Do you disrupt their ways of doing things? How is it perceived by the teams and management?

The good part is that product management is on the rise, so people are familiar with it and find it interesting. They generally want to learn how to do it. The problem, however, is that when they start applying product management principles, they obviously don’t do things very well at first, yet they have with very high expectations. So inevitably, if it doesn't work the first time, which is inevitable, it can generate big disappointments. So overall, the environment is enthusiastic, but things need to be rationalized and expectations must be managed.

You are well connected in the industry. Based on what you hear from your peers, what do you think are the main challenges faced by product organizations/teams?

There are three major challenges that I encounter most frequently:

• Company culture: It's often hard to implement a "test & learn" approach, to disseminate information effectively across different departments, and to ensure that all parts of the organization work together efficiently. It varies a lot from one company to another, but it's a common issue.

• Technical excellence and product design quality: This aspect is often underestimated, especially in France from my experience. The job of software developer is not valued enough here. They are typically not seen as crucial individuals in the company. In other parts of the world, it’s actually the opposite, especially in the United States. It's rare for a software developer to be paid a high salary in France. The tech players are often perceived as consumables, and I see this as a problem because technical conception is neglected, and at some point, agility is lost due to the accumulation of technical debts. All the great thinkers in product management state that 50% of your innovation ideas come from your developers. It's a real problem.

• The third point is the lack of emphasis on the user experience. I'm not talking about having beautiful interfaces, but really focusing on the problem we want to solve, rather than the solution we want to build. And also, doing this throughout the product life cycle. It's challenging because the product design profession is not yet well-known or developed.

Are there any practices that are close to your heart? Any small things that you recommend that can make a difference?

• Learning from failures. Failing is important, as it pushes us to ask the right questions, and allows to deliver value iteratively and progressively.

• On the technical side, anything related to what we may call software craftsmanship, such as TDD (Test Driven Development), Domain Driven Design, and all DevOps practices. We may not always be able to implement them everywhere, but we should try to be inspired by them as much as possible.

• In terms of UX, many invest in user research. Spending time observing your user, to have unbiased information and clearly identify the right problem to solve.

You invest a lot of time on LinkedIn to demystify and popularize a wide range of concepts related to product and teams. Do you have a specific mission or objective with this?

We have access to an incredible amount of knowledge thanks to the internet. I want to participate and contribute to it. I have personally learned a lot, so I also want to share. Firstly because I believe it can help people. But also because it allows me to build a network, improve my writing skills, reflect on substantive topics, and be challenged. But the goal is mainly to have an impact by sharing important things for people.

To finish, could you share with us a top 3 of the books that inspired you and that you recommend to everyone?

With pleasure!

• For a somewhat general book on product management, I would recommend "The Product Book: How to Become a Great Product Manager" by Josh Anon and Carlos González de Villaumbrosia, which is very good (available for free here via The Product School).

• Next, "The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations" by Gene Kim, Jez Humble, Patrick Debois, and John Willis, on the topic of DevOps, but not at all technical, very accessible and really enjoyable.

• And finally, "Accelerate: Building and Scaling High Performing Technology Organizations" by Nicole Forsgren, Jez Humble, and Gene Kim. It's a bit of an outlier in this list, but I think it will mark the history of tech.

Thank you again Victor for agreeing to share your experience with us! 🙏😃

• What to prioritize in an ocean of possibilities?

• How to experiment efficiently?

• How to move quickly and be "action-oriented", in a constantly changing context.

• Etc.

Thank you, Albin, for sharing these insights with us!

Tell us more about yourself. What is your background?

I started working in the software industry about 10 years ago, after studying computer science. My early career was more on the technical side, then gradually, I became more interested in the strategic aspect of things: Why am I developing this feature? Who will be using it? How will it create value for my users? Quite naturally, I was dragged into product management.

For a few years, my job was to establish certain work approaches in different companies. I quickly realized that I was doing the same thing again and again, and that it started to look like a framework. Realizing this, I thought that instead of serving a single employer, it would be interesting to serve several customers, several product leaders who would need what I do. This is how I started Linky Product 2 years ago.

Tell us more about Linky Product. What’s your mission, and what does your day-to-day look like?

Linky Product's mission is to make product strategy simple.

We see a lot of product leaders who seem to be lost in the complexity of their work. As they grow their teams, they are continuously exposed to thousands of ideas from everywhere. Succeeding in prioritizing all of this, and creating a product strategy that aligns everyone, is a never ending challenge.

At Linky Product, we experienced these challenges within many companies. We managed to realign stakeholders or development teams that were highly misaligned.

All over the world, the largest technological ecosystems have the reflex to be Product oriented, to find the right compromise between business objectives and users to achieve success. Our mission now is to bring this to as many teams as possible. To meet entrepreneurs, product leaders who are a little lost managing their priorities, and to give them tools to make their lives easier.

Can you tell me a little more about Linky Product's interventions?

We intervene with a subtle mix between consultation and coaching. We want to give our client companies the tools that will help them to evolve in the long term.

Our target customers are essentially product leaders, even if it varies a lot from one company to another. We mostly work with people who have development teams around them and whose efforts will have to be prioritized.

Our typical mandate is very strategy-oriented and lasts between 1 and 3 months. We then help leaders to structure their strategy and decision-making process. We give them a framework that allows them to collaborate more effectively as a team. Our approach is human centered, adapted to the context, the challenges and the major next steps to be achieved by our clients.

We are very action oriented, so our clients car reach their market/users as quickly as possible. It allows them to collect data and to learn from it as quickly as possible, so it can feed their strategy.

You have accompanied numerous companies. What are the most recurring issues?

• What do we do in the ocean of possibilities?

• How to structure thoughts and experiments?

• How to have a common and shared framework on the directions/priorities to take?

• How to project oneself in the long term and make decisions?

These are major topics that come up very frequently.

How do you assess the product maturity of an organization? Do you sometimes feel like it won’t be so easy to improve the situation?

We conduct workshops with our clients and their teams. We have in-depth discussions about their identified (or unidentified) objectives, what is already in place, and what they would like to implement. We also try to identify the blocking points and various challenges.

I often observe what we could call vertical maturities, meaning that there is an axis on which they are very good, but they have forgotten all the others. Just because you conduct user interviews every day doesn't mean you have a good product strategy. You just have a lot of data. Similarly, you can have good delivery practices and a beautiful Scrum, but customers who don't use your product.

The discussions are quite natural. We try to perceive what the real problem is and where it lies. Are the teams misaligned? Is the business strategy unclear? Is the understanding of the market not good? Once the problem is identified, we can focus on resolving it within the next few months or the next year.

Indeed, it happens that we think changing thins won’t be easy. But we only accept mandates when we are convinced that we can help. Occasionally, we feel that it's not the right time and that there are other priorities to address first. We also have people who are simply not in the "product mindset," and they are not interested. In that case, the dialogue doesn't really happen, and that's okay. We often see this in larger companies that have been functioning well for many years. It's difficult to just come up and tell them how they could improve things.

In your opinion, what makes the difference between the best product organizations and the others?

I see two main aspects:

• The first is the "expected results." Are they present, and are they clear?

• And the second is how often do they talk to customers/users.

For me, these two aspects are the first signals of a product that will succeed. Everything else, in general, stems from these two things.

Is the delivery good? If it doesn't serve any outcomes, we don't care. It won't be a success.

These two things are the pillars of a functioning product organization. And usually, that's where product leaders spend most of their time.

One last word?

Simplicity is the key to success!

It's central, and it sums up pretty well what we do at Linky Product!

Thank you, Maël, for meeting us!

Could you tell us more about yourself and your journey? Who are you, and what do you do?

I have more than twenty years of experience in IT, with a Bachelor's degree in computer science from UQAM. I started my career as a programmer, then began a transition to agility in 2008 with the role of Scrum Master. Since then, I have supported teams of different sizes, in different business areas and at different management levels.

I remember my first experience with an agile transformation, back in 2008. We were lucky to have an experienced coach, Alain Chaput, who was able to guide us successfully in this adventure. He showed me the benefits of this way of thinking. Everything resonated a lot with me. I thought it was “common sense”. Above all, this is what got me hooked on agility.

I then carried the dual role of Developer/Scrum Master, but quickly realized that I had to choose between the 2, because the levels of interaction and areas of interest are different. I was known to have a good human contact, in addition to being good at simplifying complex issues. I was also recognized for my ability to facilitate communication between business people and technical teams. This led me to choose agility for the next phase of my career. I self trained a lot and ended up finding the Agile Community of Montreal. I started by attending their events, then got involved as a member of the Board of Directors in 2014, and now as President since 2021.

Tell us more about Agile Montreal and your mission?

Agile Montreal is an NPO that has exists since 2011 and whose mission is to promote agility in the greater Montreal area. We offer networking events, several conferences per month, a mentoring program for people looking for support, etc. We are well known for our signature events (Agile Tour, Devops Day, Agile Open, Spark the Change, etc.). Another important component, Agile Montreal supports the development of communities of practice in relation to agility. If a new community needs a structure, tools, visibility, etc., they can approach us, and we will support them the best we can in their implementation and development.

You got into agility in 2008. Things were different back then. Can you tell us about the differences between now and then?

The biggest difference is that today, everyone is talking about agility, but without necessarily understanding what it is really about. Many companies are trying to follow ready-made recipes and bring them to scale. It almost became a management and/or delivery method, without really understanding the why and the values ​​behind it.

Personally, I like to begin the relationship with the people I coach with a discussion around values ​​and the “why”. I ask them, “Why do you want to be agile? What are you trying to fix? Because agility might not be the right solution for you, in your current context. And it’s fine!”.

I also try to be pragmatic, even within the community. There are diehard agilists who consider everything else as the devil or as outdated. But it’s wrong. Each context is unique. Hence the need to be well advised and accompanied.

You have coached many teams throughout your career. What issues do you see most frequently?

I have found that the most important problems are rarely present at the team level. We can quickly deploy a simple and effective collaboration mechanism within teams. The most important thing there is to put in place a good continuous improvement process, to ensure the teams improve efficently over time.

On the other hand, during agile transformations, I observed a lot of resistance coming from other spheres of organizations. For example, on the sales side (Editor's note: in a software service sales context). If sales teams don't understand agile properly, they will struggle to efficiently communicate the benefits of this approach. Salespeople will sign deals that aren't aligned with how teams operate. This means that from day 1, there will be misalignment with the client, which creates dissatisfaction and frustration on both sides.

Another example: Budget planning. A company that plans budgets over 2 years, over 5 years, while teams are asked to continuously inspect their work to potentially switch directions. We cannot function efficiently and comfortably in such environment.

When organizations are not agile in their fundamentals, but still want their teams to work in an agile way, it creates a clash. To work efficiently at the team level, agility must be understood and accepted beyond the teams.

You’re saying that several companies are implementing agile practices, but without being agile. Can you elaborate?

I can find out quickly, by paying attention to how they communicate. I see if there are concepts that are not mastered. For example, adapting to change, delivering value, etc. You take the 4 values ​​of the agile manifesto, or the 12 underlying principles, and you realize quickly that they are far from it. Typical case, they take a BRD (Business Requirement Document) and they try to split it, so it fits into tickets. And, "that's it, we're agile because we do Daily Scrums, and we have Jira tickets”.

For me, agility means having the customer at the center of all your thoughts and all your decisions. You make sure that each of your activities creates value for the customer. It shouldn’t be to make your bosses happy, or for profitability. Obviously, profitability will remain an overarching goal, but it should be the result, not the starting point. First, take care of your teams, who will take care of your customers, who will pay for your product/services and generate your financial success. Not the other way around.

If companies want agility to generate results, they need to put in place a corporate culture based on trust. But it's not always easy to create or to maintain over time.

The context is also a strong factor. Agile methodologies, Scrum for example, are frameworks that apply well to product development, but not so much to project development. Without going into the debate of one vs. the other, it's true that it applies much better when you have a product, and the ability to experiment, get feedback and make it evolve with small increments. Agility is particularly adapted for complex domains, with many unknowns. You have to approach it with a scientific method. Make a hypothesis, run an experiment, look at the result, validate or invalidate the hypotheses, adapt the product and start again. This is called empiricism.

To build the Champlain Bridge, the parameters are known. It’s a complicated project, for sure, but there aren’t many unknowns. We know the laws of gravity, the price of materials, engineering rules have been established, etc. A waterfall approach is perfect for that. But if you plan to send a rocket to Mars, there are lots of unknowns. It’s highly preferable to use more agile, more iterative approaches to avoid having an enormous problem in the end.

As an organization, how can you know that you have built an agile culture that works?

You must find out if the teams (and not just the development teams!) have implemented an effective continuous improvement process. Are they trying to improve? Are they learning from their mistakes? In my opinion, this is where real agility is. If there is no continuous improvement process, there is no agility. It is fundamental. We must constantly ask ourselves what can we do today to avoid repeating the mistakes made yesterday, and deliver even more value to our customers, for the same time or the same budget.

Obviously, teams need to improve on the right things. The continuous improvement process of teams must be aligned with agile principles. Delivery is one of the principles, but delivery without creating value for the customer or for the company does not make sense. Another principle, communication. Be honest, transparent, talk to each other about the real things and don't let things escalate. Even if it is not fun to admit that we are late or that we have made a mistake, if we are honest and quickly raise flags, we can react and manage accordingly. Another important principle: it’s critical to create an environment of motivated individuals, people who understand what you are trying to accomplish, so that they are able to make the best possible decisions in the context and based on the information available.

Any last word?

There is a significant correlation between the agile maturity of organizations and the well-being of teams. The company must create a psychologically safe working environment, which starts with management, and that offers the possibility to all team members to openly say that they made a mistake without being considered incompetent or altering their image in the organization. That doesn't mean you can do anything and everything, but it's okay to make mistakes if you put continuous improvement processes in place to improve. This is how an organization can maximize the benefits of agility.

Thank you again Maël for sharing your experience with us! See you soon! 🙏😃

Interested in the topic of building strong, empowered product teams in a climate of trust ?

• Check out this article on the importance of involving developers in product discovery initiatives.

Throughout our years of supporting product teams, we definitely saw a recurrent pattern: For various reasons (that we’ll try to address below), developers are often left out of the product discovery activities.

« Developers maximize their value when they focus on code »

How sure are we about this? Is your business model about writing code, or solving your client’s problems? When using developers only to code, you only get half of their value!

Developers need to work on the problem, not just the solution

If your team members don’t understand the « why » behind what they build, there’s a big chance they won’t be able to do a great job. You may think that developers can just rely on the product manager to understand the why but their engineering background will allow them to understand the pain point in a unique way and come up with the best ideas leveraging technology.

Speaking with clients is engaging and rewarding

Furthermore, when developers are directly exposed to clients and users, there’s a very strong sense of appropriation. It’s so much more engaging and rewarding than just working on a Jira ticket. Companies should never forget that purpose and meaning really do matter.

It helps mitigate the risk

Not leveraging feedback and experimenting put the delivery at risk. If developers are only expected to deliver requirements defined by others, they are entitled to feel like they did their job even when the results are not there after a release. At the end of the day, even though the company believed that they would be saving time by not involving the devs in discovery, they actually wasted a lot of time, on top of diminishing the value created for the clients and ultimately, for the company.

« So, how should they get involved? »

Start with customer interviews

It’s crucial to build customer empathy, and it’s very easy to do. They don’t need to run the interview, but having them present and making sure they can ask questions can go a long way. Developers generally don’t like to be considered mere « code generators».

By including them in customer interviews, they become actors. It significantly increases their sense of ownership. There is nothing more motivating for a developer than seeing a user struggling with their code!

By simply allowing them to talk to the customers, you managed to create a virtuous cycle!

In general, ensure developers are strongly involved in all discovery initiatives

Obviously, developers need to be part of the design cycle. They will look at the problem and the solution from the feasibility angle, and will help identify and validate solutions that are better aligned with the existing code base, more efficient, or easier to execute. It can only be good for your product (and your budget!).

Teresa Torres' "Product Trio" is a great concept to involve the whole team. The trio is composed of the product manager, the product designer and the tech lead (and ultimately the developers in general).

« What if developers don’t want to talk to customers? »

Create and promote successful initiatives.

You will be surprised to see how often they are actually looking for these moments! Some developers might push back, feeling more secure when focusing on code writing. Explaining that it’s a great opportunity to influence the upcoming features and requirements with their tech flair will motivate most developers… And of course, start simple, the objective is to create sustainable and long-lasting practices!

« Ok, but it will lower the team capacity »

Think outcomes, not output

Did you know that 80% of features in the average software product are rarely or never used?

Companies focus too often on maximizing output. But if the features are not valuable for the clients, it’s a waste of time, money and talent.

Companies need to focus more on business and customer outcomes, the real success criteria for any tech product.

To wrap things up

You have the opportunity to initiate a virtuous circle that will boost team’s morale and improve both employee retention and business results

By investing more time working on deciding what to build, you will deliver not more, but better features, your team will have a stronger impact both for the company and its customers.

By encouraging your developers to actively participate in product discovery, you will reduce the risk and cost associated with features development. Your team will reduce waste and deliver better products, enabling the right dynamic to delight customers!

--

Are you interested to learn more about product discovery?

Find out how DoorDash managed to get ALL their employees to be part of continuous discovery.

Continuous discovery is an essential set of practices in product management. It’s a well known fact: the most innovative companies in the world encourage all members of their multidisciplinary teams to meet with their users on a very regular basis.

The least we can say is that Doordash does not take this lightly. Through the "WeDash" program, the company requires all of its employees to make deliveries at least once a month, no matter their role within the company. The CEO himself complies with this rule. If the initiative may seem drastic, it obviously aims to expose employees to the reality of delivery people, who are in the field and in contact with customers. Employees are at the forefront of identifying potential flaws in the user experience, and thus strive to design better products.

This video shows the WeDash experience through the eyes of a DoorDash software developer. Seeing her in action as well as her testimony will show you how valuable the experience can be.

You may have heard of it, as the program isn’t new. DoorDash launched WeDash in its early days, back in 2013. The practice was paused during the pandemic, but recently picked up again. The company now counts more than 6,000 employees, and doesn’t seem to be planning to abandon the program. Discovery practices are firmly inscribed in the DoorDash DNA.

Obviously, and for several reasons, some employees may not be able to perform deliveries. Though, they are still encouraged to put themselves in the shoes of their users via the WeMerchant programs (a day in a partner restaurant) or WeSupport (time invested in the customer service department).

The DoorDash company is far from perfect, but we must admit that this program is inspiring!

Let’s start with a little ice breaker: One thing you like, and one thing you hate.

I like: Smash burgers (with cheese everywhere!) 🍔 I hate: When my daughter wakes me up in the middle of the night to change her diaper 🐥

Tell us a little more about you. Who are you, what do you do?

My name is Oscar and it's my birthday today! I have been working at Coveo for about a year. I am a product manager in the business services division (support center, etc.) and machine learning.

We offer a Search & Relevance SaaS product. Companies that deploy my product seek to optimize the management of their customers' support cases. They care about their clients' experience and know how important it is to help them find the right information or the right document at the right time. For the end user, our solution helps them find answers to their support questions or problems independently, thanks to machine learning.

My role is to properly identify the problems and address them with my team, but also to work with the platform, data and marketing teams who are involved in all of this. As a PM at Coveo, we are attached to a line of business, but we collaborate a lot with a set of teams to deliver our solutions.

How and why did you become a product manager?

I began my career on the advertising side, working for an advertising/creative agency. I did a lot of digital campaigns. I was a little frustrated to manage campaign after campaign, without necessarily having a real focus on results. My next job was also in digital, but in eCommerce, which was much more factual and data driven. I was a Product Owner. This is when I started being exposed more to the world of product management. On the other hand, my role was very delivery-oriented, with a lot of day-to-day operations. From there, I started reading a lot and began to learn about what actual product management and product culture was. I realized that strategic elements were somewhat neglected in my role. I then found a company in conversational AI, which allowed me to work in what I consider my first real role of product manager. I was closer to the executives and worked directly on building a strong link between what we develop and the business value created for the company.

Then I said to myself, I'm loving it, it's really the best job in the world.

Today, I continue to develop my skills and learn in a larger organization, Coveo.

In Quebec in general, product maturity is still at an early stage, it is very interesting to be part of this movement.

Did someone introduce you to the world of product management?

Not at first. It was really through personal research. Later, I had the chance to work with a product leader who had a lot of experience and really helped me make progress. She asked the right questions and helped me move forward. But above all, the simple fact of seeing someone with experience do the job in the day to day was a super addition to everything I could read.

When you read a lot on the same topic, you end up going around in circles. To learn, you have to actually do it, be in it. You must fall and rise again to learn and fully understand the intricacies of the job.

Learning the role of product manager, how did it go?

It was very humbling, because after a few years mastering a more operational role, you tend to reproduce patterns and ways of doing things. But it doesn't work. You are no longer asked to manage the backlog story by story or bug by bug. PM's job is about identifying the right questions and ensuring that the right people are involved so that they find the solution. This transition is intellectually easy to understand, but in the day to day, it is sometimes difficult to leave aside certain old reflexes. It is quite hard to self-coach to transition on your own. I believe it’s a huge plus to be coached & advised by an experienced product leader.

What’s your favorite part of the job?

Working with really smart people, exposing problems, and solving them together. I don't believe I’m the one with the answers to every problem I identify. But acting as the glue, having 360° visibility, speaking with anyone in the company, and to bring it all back to what's really important, it's trippy. Building a story to get everybody on board, the leadership and autonomy inherent to the role. There isn’t a single template for product management. It's a very proactive job. Once you understand where you could add value, share it with the organization, make them want to engage, convince and influence, it's really motivating and it fits with my personality.

What’s the most challenging part of your job?

It’s hard to say… Maybe contribute to developing and structuring the product culture within the organization. I find this to be somewhat missing from my PM role today. But really, there is not much that I don’t like. Even when I spend time in Jira. I learned what it's like to write a good user story, which will engage the team and get them to say "let's do this". Otherwise, some PMs sometimes find it challenging to have to present regularly to management, stakeholders or certain customers. Personally, I find it very rewarding to spread my message.

What does your typical day look like?

I often use the elevator metaphor. First floor, you have the dev teams. You must be able to talk to them effectively. Then, you have a meeting at level 7 with VPs who will have very little time and to whom you have to provide the "1 liner" that will interest them, and ask what I expect from them. The next hour, you’re at level 4 with a client and you’re going into the details of an analytics case. Through all these floors, you have to convey the same message, but in different ways to adapt to your audience and generate the right engagement.

My typical day consists of a lot of meetings to ensure alignment, follow up, ask questions, etc. It's a lot of informal discussions. It’s also important to keep space for efficient focus time, and to make time to write. It is necessary to have an almost-scientific method in our approach to problems. Establish hypotheses, identify the strongest ones, determine if we are able to test them, set validation criteria, etc.

In short, my typical day: discussing, writing, thinking!

What’s your recipe for success?

Move fast. Avoid large scopes. It's a bit of a cliché, but I would advise teams to do a lot of MVPs. For example, if we have to improve a machine learning model, we will look at a specific element, and we will make sure in a vacuum that it works before involving too many people. I think that in the industry, people tend to address big projects too quickly.

If you are not able to deliver value, or show concrete progress in 6 weeks, your scope is probably too big.

This way it’s also easier to create momentum. Work on small projects to create small successes. Several small wins create momentum behind your initiative. Whether it is the motivation of the team, or of the stakeholders. Everything gets easier when people see that things are progressing.

What advice would you give to a new/aspiring PM?

Find a boss, or senior PM, and watch them go. Of course, you have to document yourself, but finding someone who can inspire you and give you feedback is super important. Another piece of advice, be proactive and independent. Do not hesitate to push doors, discuss with people, present your analysis and ask for feedback.

Could you name your favorite communities or sources of content in relation to product management?

I have a long list of blogs, podcasts, etc.: Mind the Product, Product Tank, Lenny’s Newsletter, Bring the donuts, Department of Product, Product Coalition, Elezea, etc. But I got out of the “product only” newsletters a bit. I branched off into things that help me in a different way. For instance, we have competitors in the customer center industry who host podcasts. Being able to listen to your target user speak in a context that you did not set yourself is very useful. You can see if their speech changes, if it brings new approaches to the problem, etc.

I also recommend consuming more business-oriented content. Most of our clients are public companies, so being aware of their context, what could impact them etc. is very valuable. It's good to be open to a lot of things, as there is always information to take back and that allows you to improve continuously.

Any last words?

Product managers must encourage the multidisciplinary side of their work. Surround yourself with the right people, be it tech, user experience, marketing, etc. Be the catalyst of the problem, so that they can solve it in an optimal way.

I believe what you are also doing at Homeric is a good addition to all this product thinking & culture. Helping teams to have more visibility and collaborate better, in the end, I’m sure it will pay off!

Thanks Oscar, and happy birthday! 🙏 🎂

I can hear and read a lot about how it's difficult to compete with the "Big Tech" as they have plenty of money and attract all top talents. While the statement is true, many people miss that it's the consequence of something, not the cause. When they started, they had no money and top talent wanted to work in other companies. There is something else at play. It's critical for all to understand it if we want to level the game with those companies and be able to compete in a sustainable way in the tech industry.

We must ensure competition remains possible

As a citizen, I am both fascinated and terrified by those companies. On one hand, I am fascinated because they deeply changed how we all live with great products we all love. How could Apple V2 sustain this pace of innovation and right moves from the iPod in 2001 to the M1 Chips in 2021? 20 years of basically continuous customer delight, innovation, and market growth!

On the other hand, I'm also terrified by where the business landscape is going. For the first time in history, the biggest companies continuously try to disrupt themselves and capture new values in any field they can, enabling them to keep growing and maybe achieve what GE or Exxon couldn't: Become real global mega-corporations no one can compete with. Is it a good thing for the world and the tech industry to see a single company like Amazon being at the cutting edge of marketplaces, cloud services, consumer electronics, logistics and supply chain, automation, transport electrification, drones, AI, and virtual assistants, media production and distribution? They even started to step into healthcare. There are two important consequences with this new reality:

• New players can't scale and become real competitors to the big tech as they get acquired or copied by companies able to execute faster and stronger.

• It's only a matter of time for established players in any market before having to compete with the Big Tech and being at risk of major disruption, if not worse.

Work Culture is easy to understand, but incredibly hard to implement

This is why I think it's critical to understand what makes the big tech so effective and to also adopt their principles. On the paper it's pretty simple: they trust and empower their teams to do the right thing. In reality, it requires incredible discipline and consistency to make this a reality at the organization's cultural level, but this is the transformation journey we must all take.

This culture of empowerment is the root cause of innovation and business success. Not talent. Not money. Those are consequences of embedding such a culture in organizations. The Big Tech companies are very self-conscious of this and spend a significant part of their time to find the best way to foster, spread and scale such a culture in a very intentional way. Most organizations just don't and, as a result, get outperformed on 2 fundamental statistics:

• 75% of cross-functional teams are dysfunctional, leading to low employee retention.

• 88% of SaaS features do not get adopted by users. It's been above 70% for the whole IT world for the past 20 years.

Homeric is your partner in your Odyssey to high performance

Those are the problems we want to solve with Homeric. We want to assist teams in their journeys to become highly functional and significantly impact their customers. Homeric delivers tools and resources to show a path to a true culture of empowerment that will enable organizations to get better business results, high employee retention, and build a work culture that will, as a consequence, allow them to attract better talent and increase their bottom-line.

Want to know more or have questions about teams performance? Work culture to enhance it? We're always one click away, let's connect!

A lot of confusion about Product Management

The more we talk around Product Management and Product Leadership, the more we feel like a lot is not clear for many people and especially for the people directly involved in product teams: product managers (and the infamous product owners), designers and developers. A lot we can see and read is unnecessarily complex and we think we're more and more in an environment set for failure as some people found how to take advantage of the confusion to make money. We want to try to give another perspective.

Some silos need to be broken.

We also think the coverage of product management in Hi-Tech companies is very segmented, to not say it's just like silos. On one side we have the niche coverage from product professionals, not very open to our closest collaborators like designers and developers. On the other side, there is the whole agile community that talks a lot about "Product". Those 2 worlds are too far away from each other and we'd like to believe there are some constructive bridges to be built.

We, product professionals, actually depend a lot on digital transformation to maximize our potential. Digital transformation also desperately need better product management and leadership to achieve the best possible results.

Goal: To interact with you.

We'll cover many topics with articles and hopefully will be able to setup interactive moments with the audience like AMAs and Workshops. There is a lot to be done and we sincerely hope our experiences and insights will be able to help you a bit in enabling products teams to deliver their best value.

75% of teams are dysfunctional

The study behind the infamous HBR article is absolutely clear: Lack of clear objectives or objectives not aligned with the real organization's goals; poor team dynamics; missing out on scope, dates, or budget; These issues happen all the time and they often happen simultaneously: to be considered dysfunctional in the study you must fail on at least 3 of these success criteria. Teams are not only late. They are late while not delivering the right features and not respecting the company strategy.

You can see here one differentiator of high-performance teams. Successful tech companies actively take action to avoid these pitfalls. Most organizations do not. Who really looks back into the initial business cases that enabled budgets to look at the actual returns?

It's about Team Interactions...

The first dimension in which a team can be dysfunctional is team interactions. It's about how people behave and interact with each other and with the rest of the organization. This theme is often overlooked by management for 2 reasons:

• Almost 150 years of scientific management (Taylorism) domination makes us believe people are interchangeable resources. Only the output matters and it's independent of the person if the work is properly organized. While it's true for operational tasks, it's completely wrong for creative activities and product development.

• Managers and executives are poorly-equipped to monitor and influence team dynamics. The presence or absence of coaching on this by first-level managers is a very effective way to make the difference between high and low-performance teams.

Team interactions can be split into 3 axes:

• Vertically, how the team and upper management, sponsors, and executives interact with each other.

• Laterally - how the team interacts with other teams. Other technical teams for dependencies, customer success teams for user feedback, etc.

• Internally - How the team members interact with each other, especially cross-functionally with the relationships between product, design, and engineering for example.

If you haven't taken explicit actions to define and educate on how the team members and stakeholders should interact with each other, you're probably failing: it's basically impossible to have it right "spontaneously".

Maybe it's time for some improvements? Homeric can help ;-)

... And Team Practices

The other dimension in which a team can be dysfunctional is their team practices. It's about how the different team members are going to truly collaborate with each other to deliver the best possible outcomes for the teams and the organization. Organizations fail on this theme for 2 main reasons:

• Silos are not broken. Even in a supposedly agile cross-functional team, Designers are expected to spend their time creating mockups, developers are expected to code and product managers are supposed to write stories. With no focus on collaboration, the team is obviously unable to perform.

• Output is king. Lack of clear objectives, process compliance, absence of user feedback, etc. All those issues will make the team fall back on output because this is the only thing the team can actually do. As you may expect, the odds of solving real customer problems at the end are very, very low.

Team practices cover many topics we could group like this:

• Stakeholder management, objectives definitions, and evangelism - All the actions you need to take continuously to basically manage the organization. Let's not forget, great products solve real problems for our users and customers, in ways that our customers love, yet work for our business.

• Product vision, strategy, and discovery - All the actions team will take to ideate, test, validate, refine the destination, the path, and the milestone for the product.

• Product delivery and operations - All the actions to build, maintain and operate the product.

Practices here encompass frameworks, activities, processes, production and just like the team interactions, it's impossible to get it right by default. Do your engineers contribute to the product strategy? They do it all the time in high-performance teams.

What about the consequences?

Working in dysfunctional teams is frustrating, draining, and not really sustainable. It also creates a vicious circle: Those teams continuously fail on more than half of their success criteria, creating a team environment of constant failure. Trust from the management will quickly disappear, pushing the team to become even more dysfunctional.

The final outcome: your employees will leave. Dysfunctional teams have an employee turnover 2.5x higher than highly-functional ones. Each time your high-performance competitor loses 2 employees, you lose 5! The impact on team morale, HR costs, reputation, and attractiveness is absolutely huge in the long term, and organizations will need to tackle this challenge if they want to stay in the innovation game.

Interested in breaking some bad patterns, increasing the quality of your products, and employee retention? Homeric can help, click here ;-)

The pandemic has changed how we work forever. Yet, embracing remote work doesn't come without challenges. Many organizations were already struggling with digital and agile transformations before the pandemic and the new work environment can actually negatively impact team performance and employee retention for product, software, and other cross-functional teams.

I've now been supporting and coaching tech teams for 6 years in addition to my regular product positions and it seems the need for organizations to understand how to truly empower their teams has never been so important.

This is why I'm super excited to announce that Alban and I are launching Homeric Technologies. We'll certainly keep offering coaching services for teams and we are also working to make the tools and resources I've been refining over the last 6 years available to everybody! With our upcoming application Odyssey, organizations will be able to benchmark teams and get access to a coaching plan with resources to maximize their team performance and employee satisfaction at the same time.

This is actually the wonderful thing about innovative product development: In order to get maximum business results, organizations need happy, fulfilled, and truly satisfied employees to invent the world of tomorrow. We'll be proud to be your partner in this journey.