Applying the Product Operating Model for Non-Tech and Personal
Product Operating Model (POM) is a framework focused on continuous value delivery. POM is used in the context of companies that either sell tech products, or have engineers implementing tech solutions.
Companies in service industries like Finance, Hospitality, Travel, Healthcare, or Marketing, could also apply POM if there’s a team of engineers developing a solution under the hood – like the ticket reservation system for a railway operator, or a fitness companion app.
But what about the companies that don’t have a custom engineering solution behind their product or service? Could they draw valuable, actionable insights from the Product Operating Model? And, going even deeper, could the core principles of POM be applied at the individual level, in our professional or even personal lives?
I believe this is the case. In this article, we’ll explore how the key concepts of the Product Operating Model can be utilized by non-tech companies and by individuals.
photo by @karola-g on Pexels
I was inspired to write this article after reading the book “TRANSFORMED: Moving To The Product Operating Model” by Marty Cagan et al. It’s written for companies “powered by technology”. As the intro says, I’m going to look at POM from another angle, so the practical subjects related to the engineering teams are out of scope here.
However, there are a few takeaways from the book specifically related to the team structure and operation that I’d like to discuss, and will do it at the end.
I also won’t go into detail of how the product model is structured, and ways it’s implemented in the organization – there are sources that have this information in detail and with illustrations.
To set the scene, I’ll contrast the Product Operating Model to other approaches.
Product Operating Model vs. other models
So, when you move to the Product Operating Model, what do you move from?
Product vs. Project model
The biggest dichotomy is products vs. projects, outcomes vs. outputs.
In the traditional project model, development was done as a series of releases that took months, sometimes years. While project management has already greatly shifted to Agile approaches, with quick iterations and responsiveness to change, the nature of a project stays the same – it’s a temporary endeavor with an end date.
A product doesn’t have a “final” stage. After being presented to the market, it keeps being developed and improved to serve the customer better and to adapt to new trends – all the way until it’s discontinued.
A project is considered successful if its scope is completed on time and within budget. A product is successful if it achieves measurable business objectives.
Feature-team vs. POM: serving customers over stakeholders
Feature-team companies, as TRANSFORMED puts it, are focused on delivering features that various important stakeholders put into the backlog.
For companies applying POM, customer experience and needs are front and center, and it leads the product decisions. Even the key stakeholders that hold a lot of weight in the company can’t dictate the decisions.
Everyone who works on the product, particularly the developers, need to have a way to observe customers using the product, and otherwise getting feedback directly from the customers.
A product lives and dies by customer satisfaction.
Marketing-driven model vs. POM
The focus is on market research and marketing campaigns. Reactive to competition. POM focuses more on the product itself, on its improvement and innovation.
Sales-driven model vs. Product Operating Model
The sales-driven model is focusing on what sells the most right now; on developing new, flashy features. POM focuses on long-term customer value, improving the existing features.
Principles of the Product Operating Model that are universally applicable
- Have a clear vision and stay focused on it. It’s easy to get bogged in the details of implementation and maintenance as time goes by. Regularly check if there’s enough effort invested into bringing you towards the strategic objectives.
- Actively obtain and incorporate feedback.
- Optimize the internal processes, communication flows. Think how to improve information sharing, task management, and response time. Miscommunication is a source of many issues, so think of ways you could personally improve it.
- Proactive discovery and innovation process. Disrupt yourself, keep the edge, stay relevant. Those who grow complacent inevitably get sidelined.
- Constant incremental changes over big bang updates. Especially on the personal level – small steps will bring you a long way, don’t wait to start “on Monday”. Speed up time-to-value by testing ideas. Value could be measured in ways other than monetary, but you need to clearly define them for yourself.
The 3 key questions of the Product Operating Model
- Strategy level: Which problems are we solving?
- Discovery level: What is the right solution?
- Delivery level: How to build a solution?
This structure that starts with vision and comes down to the practicalities of delivery reminds of Simon Sinek’s “Why-How-What” Golden Circle model of product value proposition. However, there are notable differences.
Strategy: Which problems are we solving?
This is the level of vision, but vision from the point of view of the most impactful pain points. With so many problems to tackle, why do we prioritize those specific ones? And which ones do we acknowledge but consciously put to the side?
Framing aspirations as problems to solve rather than a general sense of purpose brings forward a practical mindset. It also helps to take stock of what is actually a problem, and if there’s an underlying issue behind that problem, and perhaps *that *is what we need to be solving.
Discovery: What is the right solution?
Now that we have identified a problem, what’s the most efficient way to tackle it? That’s where the brainstorming takes place. In the actual POM, this is the place for quick prototyping and fail-fast idea testing.
With services or at the individual level, the feedback is mostly not as explicit, and cause and effect relation is usually not quickly observable. So, how to find the “right” way to proceed? If there’s no clear winner based on the initial tryout results, go with the one that is the most sustainable in the long run. Don’t let burnout ruin your strategy.
Delivery: How to build a solution?
Once we identify a solution that looks promising, it needs to be developed.
Given that there are no actual tech teams in the service companies from the perspective of which I’m writing from, and definitely no tech teams on the personal level – how do we actually “build” a solution?
This is the roll-up-your-sleeves, practical level of the implementation. Outline the steps that need to be taken for the chosen solution, proceed with them, and measure the results. Using PM tools and AI assistance will usually help in implementing the solution.
Related: Workflow setup principles in any task management tool.
photo by @artempodrez on Pexels
Product Model for personal use: who is the customer?
When there’s a company, it’s clear that the customer is someone external. But how would it work on the personal level?
Are *you *the product serving your clients – people you have professional and personal relationships with? And you aim to make people around you happy, while maintaining healthy boundaries?
Or are you the customer, and the product is the life you build for yourself?
It could actually be both. Will these require solving different problems? I’d argue that the strategy could be integrated. But even if internal and external strategies focus on different problems to solve, the solutions shouldn’t contradict one another. If a solution to one aspect of your life comes at the expense of another important aspect, it’s a signal to review the strategy.
TRANSFORMED book and notes on teams in POM
In 2024, Marty Cagan and his partners at Silicon Valley Product Group (SVPG) published “TRANSFORMED: Moving To The Product Operating Model” – a book elaborating on the “Product @ Scale” section of “INSPIRED”, an acclaimed book on tech product management.
If you look through the articles on SVPG blog, you’ll piece together the information and ideas that TRANSFORMED presents, but in the book they’re more structured. (Also, repeated a few times throughout, to drive the point home).
I also recommend Marty Cagan’s talk about Common Transformation Pitfalls at ProductTank Oslo.
Related: Best Product Management books.
I’ll touch on a couple of aspects related to team organization that are stressed in the book.
Don’t be swayed by role names from the previous model
POM requires certain competences from key individuals that lead the product development. If there are already people with the titles like “product manager” or “product designer” in the organization, it’s necessary to review if what they do is actually aligned with what the product model expects.
Product Owner is not a job, it’s a role, and it’s usually played by a product manager.
Try the new model with one unit, then spread it across
Try POM with one team first, especially if moving to the Product Operating Model is a big shift for the organization. Try the POM with one team, see what works and what doesn’t, then scale – members from the original team could join and lead the other teams to guide their transformation.
Co-located vs. Remote teams in the Product Operating Model
According to the author, on-premises teams are better than remote. Because, while remote teams could be efficient in product delivery, product discovery takes more synergy and collaboration, which is harder to do when the team members aren’t in the same room.
I’d argue that product discovery and collaboration is quite possible on remote, though it does take more coordination and willingness to collaborate. But that goes for anything remote – being successful in this format depends on all parties involved being driven, autonomous and proactive.
Related: Overcoming challenges of remote work.
Agile POM by Scrum.org
Scrum.org has its own take on POM – Agile Product Operating Model. POM is already a framework inherently based on Agile principles, but apparently it could be made even more Agile. If you’re curious to learn more, see the whitepaper on APOM framework by Scrum.org.