The Product Operating Model
The response to my last article announcing my work on TRANSFORMED was very encouraging, and I want to thank everyone that shared their enthusiasm for the project or sent along their questions that they hope to see addressed in the book.
The feedback itself was not only a demand signal, but there were some really interesting perspectives that I had not encountered before. More about those in an upcoming article.
But one thing this new book is doing, is forcing me to come up with a term for what it is that companies are transforming to. I’ve written earlier about what it means to transform, but I have not named the destination.
Unfortunately the tech industry is not great when it comes to standardization of terms. We often have different terms for the same concept, or different definitions of the same term.
I am not anxious to introduce new nomenclature, but I do need to be clear on what I mean when I talk about important concepts in this book.
What I’m really referring to here is simply how the best tech-powered companies work.
There are a set of principles, practices and competencies that together represent this way of working.
Inside the strong companies themselves they usually simply refer to this “as their way of working” such as the Amazon way, the Apple Model, the Netflix way, the Stripe way, or the Spotify Model, but my work is all about teasing out the common principles and practices.
In my writing thus far, I’ve mostly tried to avoid naming this way of working, and you can see that when I refer to “the best vs. the rest” or simply refer to the types of product teams with “product vs feature teams”.
Some companies refer to this way of working as the “product operating model” and some refer to it as a “product-led company”.
I’m not crazy about “product-led company” or the related “product-driven company” because too many people think that means “product-management-led company” which of course it is not.
I’ve found in my early writing on TRANSFORMED that the most natural term seems to be simply: “product operating model” or “product model.”
I’m tentatively hoping to go with that term, although this article is a way of testing if that’s a good idea.
A tougher concept to name is what the other models are – the model you are transforming from.
In many companies, you’ll hear constant references to “the business” in terms of making requests, and they’re running what is commonly referred to as the “IT model” (as in, “IT is there to serve the business”).
A close cousin of the IT model is “the project model,” where the CFO plays an outsized role because funding and staffing is typically project-based.
If it’s general stakeholders, then it may be “the feature-team model” (because each stakeholder drives their roadmap of features).
If it’s sales driving, then you’ll hear “sales-driven product,” and if it’s marketing driving, you’ll hear “marketing-driven product.”
Every once in a while you’ll find a company claiming to be “engineering-driven” or “design-driven” but in these cases, it is much easier to transform the company to the product model as they already have so many of the key ingredients in place.
For the purposes of the book, I’m tentatively intending to refer to whatever model you are coming from as simply the “prior model,” and I’ll refer to the model you’re working to transform to as the “product operating model,” or “product model” for short.
There are quite a few other important product terms and concepts that I’ll be using in the book, but I’ll be defining those in the chapters and articles where I discuss them.
