Why Product Operating Model needs empowered engineers
Today, we once again draw from the well of knowledge that is TRANSFORMED, focusing on the essential requirements of capabilities and ownership attribution. These concepts form an elegant and necessary - though not entirely sufficient - toolset for transitioning an organisation to the Product Operating Model (POM).
The Three Roles
TRANSFORMED introduces three roles with familiar names but insists on a nuanced understanding of their responsibilities. These roles function as a unified, core team with distinct ownership areas, yet all are deeply aligned with the product vision. The triad consists of the product manager, product designer, and tech lead. While there is typically one product manager and one designer, the tech lead represents a team of engineers. Ideally, the entire team is invested in the POM, but at least having the tech lead on board is crucial.
The Four Pillars of Ownership
Value: How likely is the proposed solution to outperform existing alternatives? Will customers prefer it, or will internal teams advocate for it over third-party options?
Viability: Can the solution meet privacy and compliance requirements? For AI-driven initiatives, can a suitable dataset be created, or a model trained within budget constraints?
Feasibility: Does the team possess the technical expertise to build the solution?
Usability: Is the product intuitive and user-friendly? Does it solve problems efficiently?
Product managers are responsible for value and viability. Product designers handle usability, and tech leads oversee feasibility. So far, this division seems straightforward and uncontroversial.
The Twist
However, this structure does not imply a waterfall process where product management defines features, engineering implements them, and design team adds a visual layer. Instead, the triad collaborates to discover the product together. For more on fostering a collaborative environment, refer to my previous post, “Yes and …” your solution.
Building Blocks of the Product Operating Model
Effortless Push to Production
The tech lead must foster a culture where deploying to production is routine. Robust CI/CD pipelines ensure that pushing to production happens daily. The absolute lowest acceptable frequency is to push at the end of a two-week sprint cycle, and even then the strong expectation is that integration and deployment run automatically and frictionless.
Access to User Data and Feedback
Understanding the impact of changes requires both quantitative metrics and qualitative user feedback. While product designers often focus on optimising usability, engineers also need to have access to data on how their solutions are performing in the real world. This visibility is key to building products that resonate with users. Seeing the product being “held the wrong way” is a source of many engineering epiphanies.
Design is More Than a Pretty Interface
Steve Jobs once said, “Design is not just what it looks like and feels like; design is how it works.” This ethos is central to the POM. The entire triad must focus on building something that works seamlessly. With easy deployment in place, Product designers can create prototypes at minimal cost (around 1% of the final product) and iterate based on user feedback.
The Empowered Engineer
Two quotes from TRANSFORMED underscore the importance of empowering engineers:
“Of all the principles in the product model, the single most important is the realisation that innovation absolutely depends on empowered engineers.”
“Most tech leads will tell you that spending a few minutes discussing a product idea early on can save weeks or months of damage control later.”
Building an innovative, resilient company requires moving beyond a top-down, waterfall approach where product managers dictate features. While such a model may function in highly regulated industries with substantial moats, companies that treat engineers and designers as mere “implementers” rather than core contributors will inevitably be out-innovated by startups with agile, customer-centric cultures. In the end, product-market fit is what truly matters.
Conclusion
These are just broad brushstrokes. Throughout the book, we see case studies from real companies and go into much greater detail on the behavioural expectations and competencies of each role within the product triad. There's even a dedicated section on how to preempt or resolve objections from those resistant to change. TRANSFORMED offers an inspiring framework for creating teams with clear ownership, shared purpose, and a sense of meaning.
#forces
Next week, we’ll shift gears to discuss data ontologies, exploring how they shape the landscape of modern data science.
