Debunking Enterprise Illusions: Embracing True Transformation in Tech Companies
For the past decade, I have primarily worked with enterprise organizations as a consultant and sometimes in-house. Over these years, I have observed several common untruths that these companies propagate among their employees:
We practice agile.We practice SAFe.We are product-centric.We put our users first.We are innovating.
Let’s debunk these claims:
Our agile practice is superficial; we prioritize processes and talking about processes over genuinely delivering value.We claim to practice SAFe, yet our release cycle stretches to quarterly or even semi-annually — so much for SAFe.We act as a feature factory, delivering only what stakeholders demand without addressing the underlying problems.We assume we fully understand our users and seldom engage with them. When we do, we disregard their input, believing it irrelevant to our company’s needs.Our innovation is merely theoretical, confined to endless documentation and meetings without concrete action.
Although my words may sound harsh, they reflect the reality of many tech-enabled companies, which adhere to a traditional IT operating model rather than a genuine product operating model. For genuine transformation and innovation, companies must confront these harsh truths. Leaders in tech organizations should consider Marty Cagan’s latest book, Transformed: Moving to the Product Operating Model, released on March 12, 2024. Cagan, with contributions from his colleagues at the Silicon Valley Product Group (SVPG), offers insights into the practices and techniques that drive success in top product teams and leaders.
In the article below, I delve into the key points from Cagan’s book, supplemented by my own experiences. My 14 years of research and a decade in the UX field, with titles ranging from Product Designer to UX Research Lead to Co-Founder, have given me insights into the realities of the industry. Having worked with 20 companies, I assert that over 80% of them are caught in the same illusions mentioned above.
Themes and Article Breakdown
Transformed explores these key themes:
Companies must embrace a product operating model to stay competitive in the fast-evolving technological landscape.Developing core competencies in product management, design, and engineering is crucial, as is establishing a strong product culture and principles.The book outlines methods to evaluate an organization’s current situation, devise a transformation strategy, and address objections.It highlights the crucial role of product leadership in empowering teams through effective coaching, appropriate staffing, and providing strategic direction.The text prioritizes principles over processes to evade the constraints of inflexible methodologies.
This article is organized into the following sections:
Introduction to the Product ModelThree Dimensions of TransformationProduct StrategyEmpowerment and AccountabilityCommon Transformation PitfallsSignificance of Product LeadershipAchieving Meaningful Transformation
Introduction to the Product Model
The book champions the shift to a product operating model, urging companies to move away from traditional sales, IT, or engineering frameworks. This model encapsulates the best practices, principles, and competencies of leading companies.
A robust product company transitions from a subservient role to a partnership with stakeholders, with product leadership dictating the problem-solving agenda after engaging and gathering insights from stakeholders. These companies stand out through a compelling product vision and a strategy driven by insights.
The essence of a product vision is its purpose, designed to evoke emotion and motivate employees. For instance, at a staffing company, an effective product vision might be: “We work daily to match individuals with the right jobs, enabling them to support their families and achieve their potential.” Opting for a vision centered on profitability could be short-sighted, as motivation theories suggest that financial incentives only offer temporary motivation.
Gaining stakeholder trust emerges as the primary obstacle in adopting the product model. Real implementation of the product operating model is contingent on this trust, which is pivotal for moving beyond a feature factory approach where companies merely execute stakeholder directives without strategic autonomy.
Additionally, the CEO’s support is crucial for this model’s success. Transitioning to the product operating model poses a significant challenge for established enterprises concerned with safeguarding their brand and profits. These organizations often default to a defensive posture, focusing on preservation, which can lead to obsolescence. In contrast, embracing the product operating model can catalyze innovation, unlock new revenue streams, enhance profitability, and transform the organization into a disruptor rather than the disrupted.
Three Dimensions of Transformation
Transforming to the product operating model necessitates a shift in product development, problem-solving, and decision-making regarding problem prioritization. It involves embracing frequent, small, independent releases, focusing on continuous discovery to address customer issues, and formulating an insights-driven product strategy.
For many companies I’ve worked with, this transformation requires altering both their development and problem-solving approaches. The choice of problems to solve would heavily rely on effective product leadership. In this context, product leaders include:
Product Manager(s) (PM)Product Designer(s) (PD)Engineer(s)
These leaders are pivotal in devising solutions that are valuable, viable, usable, and feasible, making these attributes also represent potential risks:
Value risk: the customer’s likelihood to purchase or use the solutionViability risk: the solution’s compatibility with the company’s business modelUsability risk: the ease with which users can learn and utilize the solutionFeasibility risk: the company’s capability to develop and scale the solution
The PM tackles value and viability, focusing on the outcome. While the PD addresses usability, enhancing the user experience. The Engineer ensures the build’s feasibility. Solutions encompassing these four aspects accelerate the journey from development to profitability or as Cagan refers to it time to money. These product leaders are vital for successful transformation. Yet, many organizations merely retitle existing roles while claiming to adopt the product operating model, often mislabeling business analysts as product managers, graphic or visual designers as product designers, and standard developers as engineers.
Product designers should ideally emerge from the UX field. Regrettably, in many organizations, PDs are undervalued. Within the product operating model, PDs should stand on equal footing with PMs and engineers, responsible for designing the solution’s functionality. True PDs possess skills in service design, interaction design, information architecture, and research, leading prototype development and discovery processes. They deserve compensation on par with PMs and engineers. Additionally, charismatic UX researchers with strong stakeholder relationships might consider transitioning to a PM role, where they can leverage their skills and exert significant influence.
Product Strategy
The crux of transformation is zeroing in on the most vital problems, dictated by the product strategy. Product leaders must champion an insights-driven strategy, transcending mere fulfillment of stakeholder demands.
A robust product strategy hinges on continuous integration and deployment, with the team validating small changes to ensure they deliver value before proceeding to a full release, often through A/B testing. In contrast, many organizations I’ve encountered opt for bulky monthly or quarterly releases, which overwhelm customers with changes and breed sizable issues that are slow to resolve.
Successful product strategy necessitates active participation in product discovery, embracing both qualitative and quantitative research to foster insight-driven decisions, enhancing the likelihood of success. Neglecting product discovery equates to costly guesswork.
Effective product discovery accelerates the “time to money,” or the duration to achieve desired outcomes. If initial solutions fail to hit the mark, teams iterate on both the solution and the process, informed by prior discovery to ensure they address the correct problem.
However, many organizations falter at product discovery, often bypassing it for mere product definition, which typically involves basic designs and occasional usability testing. Teams should test numerous ideas, advancing only a fraction to development. Embracing product discovery allows for rapid, cost-effective prototyping, facilitating swift assessment of various risks and assumptions. Cagan asserts that the cost of any concept assessed during product discovery should be significantly lower than the cost of engineering implementation.
Cagan also highlights the necessity for engineers to invest in understanding the ‘what’ and ‘why’ behind the build, not just the ‘how.’ Innovation thrives when engineers are as invested in problem understanding as PMs and PDs. Despite efforts, engineers often prioritize development efficiency over user experience. Encouraging engineers to participate in discovery sessions, where they can directly observe the user impact of their solutions, may shift this mindset. However, this is challenging as their time is often guarded by agile team leaders (scrum master/team coach) prioritizing development tasks over engagement in interviews or usability testing.
A successful product strategy aligns with the business vision and needs, maximizing the value derived from product teams.
Empowerment and Accountability
The book underscores the critical role of empowered product teams, which are cross-functional, autonomous in decision-making, and accountable for their solutions. Such empowerment is essential for nurturing innovation and creativity.
In my experience, many organizations adhere to the IT operating model, also known as the feature team model, or less diplomatically, the feature factory. In this model, stakeholders and customers demand features rather than addressing underlying problems.
Trust deficits between stakeholders and feature teams are common. Features often suffer from delayed releases and perceived lack of value, resulting in abandonment. Industry analysis suggests that only 10 to 30% of features developed outside the product-oriented model are actually utilized, leading to significant technical debt. In this environment, engineers and designers act as mercenaries, focusing on fulfilling requests and aesthetics. When outsourcing, this mercenary role is even more pronounced. Conversely, in empowered teams, members collaborate to identify and implement optimal solutions, necessitating a reevaluation of the company’s perception of engineers, and recognizing their diverse capabilities.
Holding feature teams responsible for business outcomes is impractical as their role is limited to output production, not problem-solving. They lack empowerment.
Empowered product teams operate differently; they are not handed a roadmap of features but a set of problems to solve and outcomes to achieve. Such empowerment allows for total team and individual autonomy. I prefer managing my team using the Results Only Work Environment (ROWE) method, focusing on outcomes rather than the specifics of work execution. An empowered product team aims to develop solutions that benefit both the business and the customer.
Common Transformation Pitfalls
Cagan highlights several pitfalls that can derail transformations, including a top-down management approach, CEO disengagement, prioritizing sales in product development, and excessive technical debt, alongside challenges like subpar product managers and a predominant process culture.
In my consulting experience, transformation to the product operating model often meets resistance, especially from key stakeholders reluctant to cede control. I’ve observed instances where CEOs lacked genuine commitment, delegating the transformation process to someone in charge of engineering, diminishing the initiative’s visibility and support.
Additionally, despite initial enthusiasm for transformation, I’ve noticed that individuals within organizations frequently become disillusioned. This disillusion may stem from the increased responsibility of solving customer problems compared to the simpler task of feature development. In many teams, the collaboration among Product Managers (PMs), Product Designers (PDs), and Engineers is weak, with a hierarchical preference often ranking Engineers above PMs and PDs.
A major transformation challenge is the discrepancy between title adoption and actual role fulfillment, with individuals failing to embody their designated responsibilities fully. Another issue is treating PDs more like members of an internal design agency rather than integral, empowered team members.
Adopting outcome-based roadmaps can facilitate the transition from the IT operating model to the product operating model, helping teams pinpoint problem origins. Traditional models often feature roadmaps centered on capabilities dictated by stakeholders, whereas a product-operated model relies on an insight-driven product strategy. The transition involves evolving from feature-focused roadmaps to identifying the underlying problems each feature aims to address, granting product teams the autonomy to focus on outcomes. This shift, supported by product discovery, gradually educates stakeholders to move away from feature-centric discussions towards problem-oriented dialogues.
Significance of Product Leadership
Crafting a compelling product strategy and vision, designing team topology, and managing successful execution all hinge on strong product leadership.
The shift to a product operating model demands superior leadership and enhanced coaching. Leaders must provide guidance based on context rather than exerting control. They are tasked with creating and promoting a robust product vision aimed for realization within the next three to ten years. This vision serves as a source of inspiration and a potent tool for recruitment. Effective product leaders understand that developing this vision is an art form, intentionally crafting it to resonate emotionally.
These leaders prioritize optimizing team topology, which involves collaborative efforts with product leads to clarify responsibilities and grant extensive autonomy to the team.
Meaningful Transformation
The book concludes with the principle that meaningful transformation entails comprehending the role of technology, identifying strong product leaders, empowering them to form capable product teams, and reshaping how these teams interact with the business.
The success of a transformation should be gauged by the tangible benefits it brings to the company and its customers. Evaluating an organization’s progress in transformation can be done swiftly, within a week, by looking for tangible actions rather than just hearing the right words.
Monitoring the number of prototypes produced by teams provides insights. Reviewing the product vision and strategy is also critical. Process-wise, there should be a shift towards reduced dependencies and increased autonomy, leading to greater employee satisfaction.
If advocating for a shift to the product operating model in any organization I was collaborating with, I would suggest establishing a pilot team as a demonstration of how an empowered team can swiftly deliver impressive results. This team would include two product designers and two engineers, with myself acting as the product manager. The small size of this team allows for true agility and rapid experimentation. For organizations undergoing transformation, the key is to approach each day with a ‘day one’ mentality, constantly striving for improvement and innovation.
‘Transformed’: an enterprise UX expert’s take on Marty Cagan’s book was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.
