Raw notes – to be formatted

Review

Initially, I was skeptical about this one, as it’s been plagued with delays and it seems the author changed midway through the process, with Marty stepping up to rescue the book.

The book addresses the criticisms of Marty’s previous works, which were seen as idealistic, theoretical, and not applicable beyond Silicon Valley. INSPIRED shared the best practices from top product teams, while EMPOWERED shared the techniques from product leaders to foster an environment for their teams to excel in the product model. TRANSFORMED provides some practical advice on how to close the gap. Given the scarcity of resources on Product Operating Models, some will be disappointed that Marty focused only on principles and stopped short of recommending a particular process.

Key Takeaways

The 20% that gave me 80% of the value.

Introduction

• The product operating model is for companies that need to power their business with technology. It’s not a single process, but a conceptual model based on principles that strong product companies believe in.
• It focuses on consistently creating technology-powered solutions that customers love and that work for the business, while getting the most out of the investment.
• There is no single right way to build products. The authors identified things that are true at great product companies.
• Reflect on your current model – IT model (business & IT separate), project model (project-based staffing & funding), or sales/marketing-driven.
• The motive to transform usually comes from a competitive threat, compelling prize, or frustrated leaders. Many companies fail at the first attempt.
• The CEO needs to be the chief evangelist for the product model. Transformation requires changes from everyone, starting with the product org raising its game.
• Product leaders need to take responsibility for up-skilling their people and fixing hiring mistakes. Your ownership equals your credibility.

Transformation Defined

• Don’t just focus on labels like “product-led” or “agile.” Look at what’s really changing across 3 spectrums:
  1. How you build – small releases, analytics, monitoring
  2. How you solve problems – assign problems to teams, let them find solutions
  3. How you decide which problems to solve – product leaders need a vision and insight-based strategy
• Shift from projects to continuous improvement of products. Use analytics, A/B testing, monitoring.
• Don’t serve stakeholders with feature teams. Solve customer problems that create business value. Hold teams accountable for outcomes, not output.
• Give teams problems to solve and desired outcomes. Find solutions that are valuable, usable, feasible and viable.
• Do product discovery to determine what will work before building. Test ideas 10-100x faster than building.
• Collaborate with stakeholders to find solutions. Expect some resistance to the change in control.
• The model requires high-performing teams with excellent people. This is why transformation is hard.
• Create a compelling, customer-centric product vision. Drive necessary org changes as a product leader.
• Do product strategy to identify the most important problems to solve. Create focus by turning insights into actions.

Product Model Competencies

• Product teams solve hard problems in ways customers love that work for the business.
• In exchange for autonomy, the team is accountable for finding the best solution.
• Strong teams need competencies in:
  1. Product Management – understand the customer and business
  2. Product Design – craft the holistic customer experience
  3. Tech Leadership – innovation depends on empowered engineers
• Expect product leaders to spend 80% of time on staffing and coaching. Lead with context, not control.
• Create product vision, team topology, product strategy, and team objectives. Evangelize relentlessly.

Product Model Concepts

• Empower cross-functional product teams with problems to solve. Focus on outcomes over output.
• Give teams meaningful ownership and expect collaboration, even when disagreeing.
• Do product strategy – focus on a few goals powered by insights. Be transparent about decisions.
• Do product discovery to minimize waste. Assess risks, run rapid experiments, test responsibly.
• Do continuous product delivery via small, instrumented releases with monitoring and infrastructure.
• Foster a product culture of principles over process, trust over control, innovation over predictability, and learning over failure.

The Product Model in Action

• Partner with customers for direct input. Make few commitments and fulfill them. Test extensively.
• Build trust between Product and Sales to create happy, reference-able customers together.
• Collaborate with Product Marketing on market insights, go-to-market, messaging, pricing, sales enablement.
• Partner with Finance to fund teams vs projects. Judge teams on outcomes, not feature delivery.
• Reset stakeholder relationships to collaborative partnership. Build trust via transparency.
• Interact frequently with execs for context sharing and decision-making. Make limited, high-integrity commitments.

Transformation Techniques

• Do a swift assessment on how you build, solve problems, and decide what to solve. Evaluate competencies and concepts.
• Update job definitions, fix ratios, engage engineers, revamp recruiting, provide coaching and onboarding.
• Optimize team chemistry, durability, and topology. Improve architecture, discovery, strategy, vision, funding, and culture.
• Use pilot teams, stakeholder coaching, quick wins, and relentless evangelism to drive adoption.

Overcoming Objections

• Address customer objections about capabilities, dates, roadmaps, releases, data, and pursued products.
• Handle Sales concerns over customer input, vision, special deals, competitors, and losing control.
• Manage other common objections from LOB, Success, Marketing, Finance about control, involvement, urgency, promotion, accountability.

Conclusion

1. The CEO must be the chief evangelist of the product model and can’t delegate the transformation.
2. Technology enables transformation but is secondary to having teams staffed with the right skills.
3. Strong product leaders who understand the product model can lead product management, design and engineering.
4. Empowered product managers are essential.
5. Product designers craft customer experiences that customers love. They elevate design from a supporting role to a central one.
6. Empowered engineers form the engine of consistent innovation by enabling and encouraging empowered engineers.
7. An effective product strategy based on quantitative and qualitative insights focuses on leveraging the talents of the teams to get the most out of the technology investments.
8. Redefining stakeholders relationships is one of the most difficult but essential aspects of successful transformation.
9. Continuous evangelism by product leaders is needed to land the product vision, strategy, and importance of moving the focus to outcomes and transformation.
10. Successful transformation requires corporate courage from executives and other senior leaders to acknowledge difficulties and make the leap to a fundamentally different model, even when the current one is not yet broken.

In-depth Summary

Part 1 Introduction

• The product operating model is for companies that need to power their business with technology.

• The Product Operating Model isn’t a process or a single way of working.
• The Product Operating Model is a conceptual model, based on principles that strong product companies believe to be true.
• It’s about consistently creating technology-powered solutions that your customers love, yet work for your business.
• It’s about getting the most out of your investment.
• There is no single right way to build products.
• Nothing you read in the book was invented by the authors; they’ve identified the things that are true at great product companies.
• Reflect on what your current model actually is:
  • IT Model: When ‘the business’ and ‘IT’ are separate.
  • Project Model: When staffing and funding are project-based.
  • Sales or Marketing-Driven: When those functions are driving.

• The motive to transform typically comes from a competitive threat, a compelling prize or frustrated leaders.

• Many companies fail at transformation and need to take a second or third shot at it.

• The CEO needs to be viewed as the chief evangelist for the product model

• Transformation requires changes from everyone, but it starts with the product organization raising its game.
• Product leaders need to take responsibility for raising the skill level of their people and correcting hiring mistakes.
• You have as much ownership as you have credibility.
• As a product leader, you need to be able to change hearts and minds.

Part 2: Transformation Defined

• Looking beyond labels (e.g. ‘product-led’, ‘agile’ and ‘empowered teams’) allows us to look at what’s actually changing in a transformation. When you adopt a Product Operating Model there are three dimensions that change, each of which is a spectrum:
  1. How you build – frequent small releases, product analytics, monitoring, phased rollouts
  2. How you solve problems – assign problems to teams and let them discover the best solution. Reset relationships with stakeholders so they’re collaborative, not subservient.
  3. How you decide which problems to solve – product leadership need a compelling vision, an insight-based product strategy to identify the most critical problems to solve.

Changing how you build…

• Technology investment should create value for your customers and your company
• You can create value from what you make and what you learn.
• Downsides of the project model:
  • Learning retention is challenging, leading to costly relearning or mistakes.
  • As teams transition to the next project, technical debt is often left unresolved.
• Shift your focus from projects to products. Practice continuous improvement through small frequent releases. Use product analytics and A/B testing to gather insight and monitoring for issue detection.

Changing how you solve problems…

• Increasing output is beneficial only if you’re building the right things.
• Just 10-30% of items on product roadmaps generate a positive return.
• Don’t set up feature teams that serve stakeholders. Instead, solve problems and serve your customers in ways that create value for your business.
• As feature teams are told what to build, they can’t be held accountable for business results. Ultimately, this creates a lack of trust between stakeholders and teams.
• Your product can become a graveyard of unused features and technical debt.
• If you can’t consistently deliver value to your customers in a way that returns value to the business, you’ll be outcompeted by a company that can.
• Give teams a set of problems to solve and a set of desired outcomes to achieve.
  • If necessary, work backward from stakeholder requests to find a solution that’s…
    • Valuable – your users want it
    • Usable – your users understand how to use it
    • Feasible – your team can build it
    • Viable – it creates value for your business
  • Empowered engineers are essential to innovation. The team that delivers the solution should help identify the right solution.
• The case for Product Discovery: time to money is more important than time to market.
  • Product discovery is the art of quickly determining if an idea or approach will work.
  • We don’t have to build everything. We have many tools that can validate an idea or assumption 10x – 100x faster than building and deploying the product.
  • This effect is how small product teams can outmaneuver larger companies with bigger budgets.
  • Work backward from stakeholder requests if you need to, to find a solution that’s…
    • Valuable – your users want it
    • Usable – your users understand how to use it
    • Feasible – your team can build it
    • Viable – it creates value for your business
  • Empowered engineers are essential to innovation. The team that delivers the solution should help identify the right solution.
• Collaborate with stakeholders to find solutions that serve your customers in a way that works for your business. Stakeholders will often have to relinquish some control, which can be challenging without trust. They are likely to resist, which makes transformation challenging.
• The model requires high performing teams with high caliber people to work. These people would likely have been unhappy in a feature team setup. This is why organization transformation is difficult.

Changing how you decide which problems to solve

• It’s easy to swap a roadmap of features for a roadmap of problems or outcomes. Empowering product teams to solve problems with clear measures of success can generate significantly better solutions.
• However, you need to prioritize the right problems to solve during product planning.
• Disrupt yourself before you’re disrupted. Product leaders need to drive the necessary changes across the organization, as other stakeholders are likely to resist the change.
• You need a strong, customer-centric product vision to unite teams and inspire your organization. The vision should be compelling, inspiring, and customer-focused. It should describe the future you are trying to create for your customers, not just a reaction to a short-lived opportunity.
• Product strategy is the process of identifying the most important problems to solve now. It creates focus. You’re betting on insights (qualitative, quantitative, technologies, market trends) and getting the most out of your technology investment).
• Product leaders play the primary role in coaching and developing their people to have the skills to discover and deliver solutions effectively and successfully.

💡 There isn’t ‘one right way’ to build great products. Focus on the principles. Reflect on the context, and if the team is making the right choices.

Part 3: Product Model Competencies

• Product teams exist to solve hard problems in ways your customers love yet that work for the business.
• Responsibility for finding the best solution should sit with the product team, in exchange for autonomy they are held accountable for results.
• Strong product teams need these new competencies. If you don’t have them, you need people who are willing and capable of learning them.
• To discover an effective solution you have to tackle:
  • Value risk – will the customer choose to use it?
  • Usability risk – can users easily learn, use and perceive the value of the solution?
  • Feasibility risk – can you build and scale the solution with the constraints you have?
  • Viability risk – will the solution work for your business?
• Roles and responsibilities in a product team:
  • Product manager: value and viability risks and accountable for achieving outcomes.
  • Product designer: usability risk, and the product experience.
  • Tech lead: feasibility risks and accountable for delivery.

Product Managers:

• Product managers need to understand their customers and business:
  • Customer knowledge includes product usage, the market, competition, and trends.
  • Business knowledge includes the product’s funding, monetisation, manufacturing, marketing, sales, delivery, service, and legal
• It can take a product manager 2-3 months to get up to speed with active coaching.
• Product managers need to establish trust-based relationships with major customers and stakeholders.Incompetent product managers frequently require escalation.
• The product function will be judged by its weakest product manager. Every product manager should be good enough to lead the business within 5 years.
• Transformations often fail due to companies’ unwillingness to enforce product manager standards.
• Product managers should have direct access to: users and customers, product data, and business stakeholders.
• Domain knowledge isn’t strictly required and can be augmented by domain experts.

Product Designers:

• Designers are responsible for the holistic customer experience and how the user and customer experience the product’s value.
• Product designers need to be comfortable in service design, interaction design, visual design, and sometimes industrial design.
• You need product designers who can help discover an effective solution.
• Designers should be comfortable engaging directly with users, and extracting insight they can use to shape the product.
• Product designers should take the lead in the lead in the daily product discovery work and prototyping.

Tech Leads:

• Innovation absolutely depends on empowered engineers. They need to care just as much about what they built as how they build it.
• If your tech lead is unable or unwilling to engage in product discovery, it’s unlikely your product will achieve your goals. Add it to the job description.

Product Leaders

• Empowered product teams still need product leadership.
• Expect to spend 80% of your work week on staffing and coaching .
  • Coaching: helping everyone develop their craft
  • Staffing: sourcing, recruiting, interviewing, onboarding, evaluating, promoting and replacing the members of teams
• Lead with context not control. You need to give teams the strategic context necessary for them to make good decisions.
• Product vision: describes the future goal for the product organization, 3-10 years out.
  • The vision ensures alignment across product teams and stakeholders and is often referred to as the North Star.
  • The product vision keeps teams inspired and allows them to guide the product proactively rather than constantly reacting.
  • The product vision, which is more art than science, is meant to be emotional and persuasive, focusing on improving the lives of customers.
  • A compelling product vision influences the product’s architecture, team topology, and strategy, making it a powerful recruiting tool.
• Team topology: refers to the definition of responsibilities and ownership of different product teams.
  • The goal is to maximize empowerment by creating loosely coupled but highly aligned teams.
  • Formulating an effective team topology is challenging and crucial, requiring intense collaboration between heads of product, design, and engineering.
  • Decisions made impact team relationships, dependencies, and ownership.
  • Successful implementation leads to highly autonomous product teams that can tackle hard problems efficiently.
• Product Strategy: helps achieve the product vision while meeting business needs.
  • The strategy begins with focus, leverages insights, converts insights into actions, and manages work to completion.
  • The output of the product strategy is a set of business or customer problems to solve, which are assigned to specific product teams.
  • Strong product leaders distinguish themselves through the product strategy—they decide the focus, live and breathe the data and insights about the product, and constantly seek leverage points.
  • A strong product strategy requires time and effort to aggregate and assimilate data and insights.
• Team Objectives: Assign each product team 1-2 clear objectives derived from the product strategy.
  • The objectives represent significant problems that the team needs to solve.
  • Teams propose measures of success (key results) and discuss these with their leaders.
  • The litmus test for empowerment is if the team can decide the best way to solve their assigned problems.
  • Strong leaders empower their teams and let them take credit for their successes.
• Ongoing Evangelism:Product leaders need to constantly communicate the product model and strategic context.
  • Relentless evangelizing of the product vision, team topology, and product strategy is crucial across the entire company. It has to be an ongoing and percolate through recruiting, onboarding, coaching, and meetings at all levels.
• CEOs must ensure strong leadership across product management, product design, and engineering.

Part 4: Product Model Concepts

The critical concepts that will help you consistently create great products.

Product Teams: An empowered, cross-functional product team is the most important concept.

• Empowered with problems to solve: Teams are assigned problems to solve. A cross-functional team is needed to address the key risks (viability, value, usability and feasibility).
• Outcomes over output: Product teams exist to solve problems for the customer and for your business, not just build things.
• Sense of ownership: Each team needs to be responsible for something meaningful. The team should feel ownership of discovery, delivery, major innovation, optimization work, scaling and bug fixing.
• Collaboration: Collaboration is not about consensus, democracy, artifacts or compromise. Team members must be able to disagree and commit. Each discipline should contribute to decision making, everyone should work together to find the solution that works. There’s a natural decision-maker for most problems (e.g. certain disciplines own different risks). You can solve conflicts with tests or more discovery.

Product Strategy: You need an inspiring vision to work toward, and clarity on your path to get there.

• Focus: Review opportunities and threats before selecting just 1-3 goals to pursue. Chase too many goals, and you won’t be successful. Stakeholders want different things, focus is impossible in a stakeholder driven model.
• Powered by insights: It takes skill to identify the right insights that power your strategy. You’re looking to concentrate your effort on leverage points. Insights can come from anywhere, from data, customers, technology or industry developments. Product leaders are responsible for aggregating and analyzing them.
• Transparency: Being open and transparent about the data and reasoning used to make strategic product decisions helps product leaders align the organization and mitigates frustration and jealousy.
• Placing bets: Product strategy is not an exact science. Don’t expect to solve problems first time. Place multiple bets from different angles – maximize the likelihood you’ll meet the companies objectives.

Product Discovery: Figuring out the best solution to the problem they’ve been asked to solve.

• Minimize waste: Discovery plays a crucial role in minimizing wasted time and effort. Considering that 70-90% of features may not yield the expected results, it’s essential to gather reliable evidence that a solution will genuinely address the problem before committing to its development. We accomplish this by promptly testing ideas, accelerating time to money.
• Assess product risks: Address the key risks (value, usability, viability, feasibility) before you decide to build anything.
• Embrace rapid experimentation: Without creating a prototype or running experiments its difficult to know if customers want to use and can learn to use your product. Create experiments to quickly determine if your approach will work, test quickly and inexpensively. Teams need to be skilled in quantitative (how much, how many) and qualitative (why) discovery techniques.
• Test ideas responsibly: Protect your companies revenue, reputation, customers and colleagues.

Product Delivery: Reliability is our most important feature.

• Small, frequent, uncoupled releases: These provide higher throughput and quality, as it’s easier to test new functionality and check for degradation of existing functionality.
• Instrumentation: Teams are held accountable for achieving outcomes. We need to understand how our products are used to measure success and provide valuable insights for product strategy formulation.
• Monitoring: System observability at all levels enables quick detection of issues.
• Deployment infrastructure: A/B testing and feature flagging enable careful release of functionality and isolation of the effectiveness of your latest release.

Product Culture:

• Principles over process:The process is not the thing. Do we own the process, or does the process own us? You can run your organization with process or people. Pushing decision-making down to teams, and leaning into coaching, teaching, and context sharing, is less fragile.
• Trust over control: Stepping away from command-and-control requires trust. Move away from stakeholders providing lists of features, to empowering the product teams by giving them problems to solve and allowing them to take responsibility for coming up with the best solutions to those problems. Leading with context not control, moving from hands-on micromanagement, to servant-based leadership with active coaching.
• Innovation over predictability: You can predictably ship software, but you can’t predictably solve problems. You have to let go of some predictability to allow innovation. Use occasional high-integrity commitments to help with balance.
• Learning over failure: Remove the fear of failure and risk aversion. Focus on tackling risks and learning quickly. Learn what works and what doesn’t as quickly as possible.

💡 High-integrity commitments can be used on occasion when it’s important to understand when new functionality will be delivered. Allow teams sufficient discovery time (let them do a feasibility prototype), then they can fully estimate the work and make a commitment to deliver the product by a given date. Dates should always come from those doing the work. The CTO should approve all high-integrity commitments. Used well they build trust.

The Product Model in Action

Partnering with Customers:

• Product teams need direct and frequent interactions with users and customers to understand customer problems, and learn what would make a successful solution.
• Reset relationships with customers who are used to dictating features and delivery dates.
• Only the product team should make high-integrity commitments to customers, and only after they’ve done the discovery work that gives them confidence the solution will solve a valuable problem for many customers.
• Customer involvement in product discovery process is essential (interviews & prototype testing).
• As a duty of care to your customers you must test your new functionality works as expected and hasn’t regressed functionality elsewhere. Correct any mistakes as fast as possible.
• Make your functionality easy to adopt and use.
• The product teams should be striving to create happy customers that become evangelists.

Partnering with Sales

• The relationship between product and sales is interdependent and crucial for a company’s success.
• Conflicts often arise when sales request features that product teams know won’t solve customers’ real problems.
• The product model emphasizes creating happy, reference-able customers, requiring collaboration between product teams and sales.
• Building trust between product and sales is the key to a great partnership, and doing that involves spending quality time together with current and prospective customers.
• In the product model, both the product and sales departments become customer-centred and outcome-based, forming a true partnership.

Partnering with Product Marketing (PMM = Product Marketing Manager)

• Market Understanding and Competitive Analysis: The PMM, with access to industry analysts and market insights, plays a key role in understanding markets and competition. They share information about new competitors and technologies with product teams. This collaboration often involves assessing competitive offerings and crafting responses for the sales team.
• Product Go-to-Market: Creating an effective product and ensuring it reaches customers. The PMM is an expert in go-to-market strategies and collaborates with product teams to establish and understand these strategies. They also consult on messaging and positioning considerations for product changes.
• Consult with PMM on key product decisions as their deep knowledge of target markets and GTM will be invaluable.
• PMMs can help you setup and run a customer discovery program, so you can work closely with a set of prospective customers form the same target market.
• PPMs can help with messaging and positioning to ensure new capabilities are noticed, understood and adopted.
• PMMs are likely to take the lead on pricing and packaging decisions in collaboration with product teams
• PMMs are responsible for the product’s sale collateral.

Partnering with Finance:

• Finance should fund teams, not projects. Replace projects and business cases by giving product teams accountability for business results.
• Judge product teams on business impact, not feature delivery. The cost of that accountability is giving the team autonomy to choose the best approach.
• Product teams should define success in business results when solving customer problems.
• Product teams should provide data and reasoning for resource requests, and conduct low-cost tests (discovery) for large funding requests.
• Finance aim to reduce the number of high-integrity commitments they require from product teams, recognizing they come at a cost.
• Support is needed for product teams to develop relevant competencies in a transformation.
• Collaborate with finance to test new product models and measure ROI.

Partnering with stakeholders:

• Transition to the product model requires stakeholders to shift to a collaborative partnership with product teams.
• Product teams are designed to solve customer and business problems in ways that customers love and align with business needs.
• Building trust between stakeholders and product managers is crucial, facilitated by direct and unencumbered access to users, customers, and product data.
• It’s crucial for product managers to understand the constraints of the business and work with stakeholders to ensure solutions can be effectively implemented.
• Stakeholders are encouraged to participate in user testing, view prototypes, and access product data to foster transparency and collaboration.
• If a solution does not meet business needs or an error occurs, the product team promises to correct the situation promptly and prevent recurrence.
• This collaboration between product teams and stakeholders can lead to innovative solutions that exceed customer expectations.

Partnering with executives:

• Empowerment isn’t about leaving the product teams to it, the product model requires frequent, high-quality interaction between executives and product teams.
• Decisions: Decision-making is delegated to product leaders or teams who are closest to the technology and customers. However, good decisions require strategic context, which means executives must share business strategies, financial parameters, and industry trends. Similarly, product teams should transparently share their decision-making data and reasoning.
• Outcomes: Product teams expect to be accountable for outcomes rather than output. They need to be given problems to solve, and empowered to come up with a solution that works. They make best efforts to solve for the customers, solve for the business, and solve for the technology.
• Disagreements: Executives and product teams have differing perspectives, but both are vital. Teams should be coached to run quick, responsible tests for evidence collection. Executives need to encourage exploration of alternative approaches. If a risky approach is proposed, the team will responsibly test and share findings.
• Promises: Product teams acknowledge the importance of specific deliverables and the need for high-integrity commitments. They commit to making promises only when they know what’s involved and required to succeed, understanding that breaking these promises damages the organization. These high-integrity commitments are exceptions due to their significant time and effort. Once a promise is made, the team will take it seriously and do their utmost to deliver.
• Surprises are sometimes inevitable but strive to reduce them. Discuss sensitive matters with stakeholders before implementation to avoid wasted efforts on unaccepted solutions. Any possible risks are shared with executives prior to construction. If a built product is deemed problematic do a postmortem to prevent such waste in the future.
• Trust: Product teams know empowerment requires trust, which they aim to earn. Both parties acknowledge their mutual dependency and commit to support each other’s success.

Transformation Techniques

Transformation Assessment

• Start transformation with a swift evaluation of the present state. Focus on prevalent issues as no company is flawless. Engage at all organizational levels. Asking for prototypes, OKRs, vision, strategy, roadmaps in each team can be informative. Seek evidence of the principles in action, as processes offer mere surface insight. Be considerate, focus on the organization, not individuals.
• High-level assessment should focus on:
  • How products are built and deployed – e.g. release frequency, monitoring, instrumentation, dependencies, reliability, technical debt, levels of trust between disciplines.
  • How problems are solved – Outcomes or projects and features? Who determines the requirements? How much discovery happens? How involved are engineering? How often do teams talk to customers? Are prototypes used? Is success defined as shipping or meeting a business objective? Are outcomes measured?
  • How you decide which problems to solve – Annual or quarterly planning? How is funding allocated? Who proposes the initiatives? Is there a clear vision and strategy? Who decides the roadmap? Is it problems/outcomes or features? Is the organisation tracking their hit rate/product sense?
• A detailed assessment should assess the product model competencies and concepts, all mentioned earlier:
  • Competencies: product management, design, engineering and leadership
  • Concepts: product teams, strategy, discovery, delivery and culture.

Transformation Tactics – Competencies

• New Job Definitions → clearly define the job that’s required, evaluate which people are capable of succeeding with coaching from their manager, or another product coach (many can).
• Job Reset → if the organization has been using the titles but doing it wrong, then you need to be clear when the role has changed, and signal that to the rest of the company. It might be easier to relabel everyone as product analysts or product specialists, and then interview for new product management positions to keep standards high.
• Role balancing → you need the right ratios between the disciplines, after the transformation you’ll likely need fewer but stronger product managers, more flexible designers and a a strong set of tech leads.
• Outsourcing engineers → the product model requires internal engineers
• Raising the engagement of engineers → the tech lead needs to care about what you’re building, product discovery and spending time with customers needs to be in the job description
• If product managers have a business counterpart they need to have a strong relationship with them. If the product manager isn’t strong, it may make sense for the business counterpart to take the product role, and the product manager take a product owner role.
• Recruiting practices → stressing your product model makes you more attractive. The hiring manager is going to need to drive recruiting.
• Assessments and coaching plans → identify gaps in each person’s skills and create a coaching plan for each person
• Onboarding programs → create a product model onboarding program for product teams and stakeholders

Transformation Tactics – Concepts

• Team chemistry → assess the chemistry, coach or reshuffle until they work effectively
• Team durability → keep teams together where possible
• Team topology → Team topology, or the definition of responsibilities and ownership of product teams, needs to be based on the long-term product vision and strategy. It requires a balance between engineering needs and customer/business objectives. Changes should be made infrequently due to disruption but the start of a transformation effort is usually a good time for this. It can improve performance and morale by reducing dependencies and increasing end-to-end responsibility and ownership.
• Distributed teams and remote employees → product discovery is best done when colocated due to the close collaboration.
• Product delivery → Changes to architecture, tooling, infrastructure, test and release automation etc don’t all have to happen at once, but they are a prerequisite to the product operating model
• Product discovery:
  • Drive up customer interaction → commit to spending at least 3 1 hour sessions with customers each week (more when in discovery).
  • Discovery sprints → intense design sprints build trust within the team and can accelerate progress.
  • Hack days → are a great way to engage engineers in product discovery and prototyping
• Product Strategy → the input to a product strategy is the product vision and the company objectives. The result of a product strategy is a set of problems to solve, which are then assigned to product teams as team objectives and key results. The strategy should be transparent and easily sharable.
  • Create a product vision → Start by creating a product vision that can guide your company for three to ten years.
  • Create a product strategy → Product leaders undergoing a transformation often lack a product strategy and the mechanisms to make insight-driven decisions. They may need to enlist a product leadership coach to help build these skills.
  • Portfolio management → Do a portfolio review, put all systems into one of the following states: sustain, invest, sunset.
  • Funding teams → Move from funding projects to funding product teams, and delivering outcomes not projects.
  • Team objectives → Use OKRs to assign problems to teams.
  • Product vision / strategy sprints → Get the right people together for a week with the right information to speed up strategy and vision creation
• Product culture → cultural issues are the slowest to change, focus on showcasing cultural change and being evangelists for the transformation.
  • Hack days → get product teams involved in coming up with innovative solutions to the problems you’re trying to solve.
  • Customer engagement → measure customer engagement to hold yourself accountable, and make sure insights are gathered and shared.
  • Innovation accounting → How many ideas have been tested? What role has data played?
  • Culture retrospectives → Get a set of cross-functional leadership together one per quarter to assess how the transformation is going.

Transformation Tactics – Adoption

• Pilot teams → use teams that volunteer to kick-start change and try out new ways of working. Do whatever it takes to set these teams up for success. Make sure they have great people in place to cover each of the competencies.
• Get different groups or teams to start with a subset of the product model (how you build, solve problems, choose what problems to solve). Changing how you build is independent of the other two. Outcome-based roadmaps are a good transition tool.
• Coaching stakeholders → start with credible stakeholders who are happy to try out the product model, make them transformation sponsors. Use stakeholder briefings to go deeper on the transformation.

Transformation evangelism

• Transforming to the product model requires continuous evangelism. Remind everyone of the product model, the strategic context and the areas of progress.
• Celebrate quick wins and highlight progress.

Overcoming objections

Objections from customers:

• Customers want specific capabilities → Teams should understand and solve the root problem for multiple customers.
• Customers need specific delivery dates → Dates should be committed only if the feature aligns with the product strategy and feasibility.
• Customers want a detailed product roadmap → Sharing a compelling product vision gives clearer direction.
• Customers struggle with frequent new releases → Using continuous delivery of smaller changes reduces disruption.
• Customers worry about product usage data collection → Anonymous, aggregated usage data helps improve the product.
• Customers disappointed when a tested product isn’t pursued → Products must solve problems for a broad customer range to be viable.

Objections from sales:

• We are the ones sitting down with customers every day, so why wouldn’t we tell the product team what to deliver? → Sales and product teams engage customers differently – sales for transactions, product for discovery. Strong solutions combine customer needs with what’s newly possible with technology.
• This great product vision is for the future – how will it help make our numbers now? → Share compelling customer references using the latest offering in the short-term, while explaining each effort’s intended business impact.
• We need to commit to some new capabilities to close deals sometimes. → “Specials” for one-off customer requests make products complex. Have requests go through sales leadership first to minimise, understand if in target market, and find solutions benefiting multiple customers.
• We lost a big deal because we’re missing key capabilities vs competitors. Why not prioritize that? → Customers often give simplistic excuses when choosing competitors. Focus on developing reference customers to truly understand differentiating needs.
• We keep losing against this key competitor – what can we do to better compete? → In this case, the sales team is explicitly asking product (and marketing) to help by devising an effective response, potentially involving major product work.

Objections from line of business:

• Why shouldn’t I control engineering resources? → Vision and strategy are collaborative efforts in the product model, similar to a startup.
• I’m not being kept informed. → The product model requires transparent sharing of strategic context and data.
• Teams repeat my problem discovery. → Include product personnel in customer interactions upfront. Teams still need time for solution discovery.
• Teams don’t feel the same urgency. → Product model emphasizes “time to money” by testing ideas before building.
• Teams resist showing early prototypes. → Encourage early sharing, focus on product direction, not surface-level issues.
• I prefer PMs reporting to me. → Avoid duplicate roles. Draw talent into a unified product org.
• I should create the product strategy. → Strategy should be a joint effort. The intent is maximizing value across business units.

Objections from customer success:

• Teams not caring about customer issues → Likely due to prioritization challenges. Suggest a top 10 list of customer pain points.
• Poor tools affecting customer support → Treat tools as products for improvement.
• Lack of awareness about product changes → Product marketing should communicate customer-impacting changes.
• Slow product org prompting adhoc customer solutions → Improve core product org’s delivery effectiveness to prevent unsupported solutions.

Objections from marketing:

• Sales can define products due to customer and competitor analysis → Innovation is often limited; hence the shift to product models which utilise product team expertise.
• Marketing’s insights and data are crucial for product creation → While valuable, integration by product managers and leaders is necessary for effective innovation.
• Different company teams want to contribute to product success → All teams, including marketing and sales, should collaborate closely with product teams for information sharing and product enhancement.
• Marketing wants to promote product features before completion → Premature promotion risks sales and adds pressure; such decisions need careful coordination and evidence-backed assurance.

Objections from finance:

• We need to flex technology investment based on business results → product teams are placing bets that succeed or fail each quarter/year. Team stability plays a big factor in productivity and morale.
• Outsourcing appears cheaper per engineer but more expensive per product → Look at the bigger picture – outsourcing is dramatically more expensive for achieving business outcomes. In-house product teams are better.
• Need to identify potential projects and understand costs for annual planning → It’s difficult to accurately predict costs and revenue for technology efforts ahead of time. Fund product teams, not projects.
• Need to be responsible with money, know what we’ll receive for each funded project → Business cases are unreliable for predicting returns. Know what you can’t know instead.
• How do we hold product teams accountable for results? → Assign key problems to solve and measures of success. Let teams take calculated risks aligned with product strategy.

Conclusion

1. The Role of the CEO: The CEO needs to be the chief evangelist of the product model and cannot just delegate digital transformation. They must be actively involved.
2. The Role of Technology: Technology enables transformation but is secondary to having teams staffed with the right skills.
3. Strong Product Leaders: Having experienced leaders who know how to work effectively in the product model is very important. They lead product management, design and engineering.
4. True Product Managers: Empowered product managers are essential. While companies often have “product managers”, their demands and responsibilities can vary widely.
5. Professional Product Designers: Product designers craft customer experiences that customers love. They elevate design from a supporting role to a central one.
6. Empowered Engineers: Empowered engineers form the engine of consistent innovation by enabling and encouraging empowered engineers.
7. Insights-Based Product Strategy: An effective product strategy based on quantitative and qualitative insights focuses on leveraging the talents of the teams to get the most out of the technology investments.
8. Stakeholder Collaboration: Redefining the relationship between the product organization and business stakeholders is one of the most difficult but essential aspects of successful transformation.
9. Continuous Evangelization of Outcomes: Continuous evangelism by product leaders is needed to evangelize the product vision, strategy, and importance of moving the focus to outcomes and transformation.
10. Corporate Courage: Successful transformation requires corporate courage from executives and other senior leaders to acknowledge difficulties and make the leap to a fundamentally different model, even when the current one is not yet broken.