Transformed FAQ
This page is here to hold questions and answers that come up once the TRANSFORMED book is published and we can no longer add them to the “Objections” section of the book.
ADDITIONAL OBJECTIONS AND QUESTIONS
“Our product managers are already so busy, how can we possibly add more responsibilities onto these people?”
This question is already covered in the book, but this comes up so often that we wanted to include here for people that do not buy or read the book.
When transforming from a feature-team product manager to an empowered product team product manager, the job is essentially completely different.
The feature-team product manager job is fundamentally about project management, and as such, as with virtually every project manager, their number of meetings simply expand to cover the amount of hours available. It is a very time and meeting-intensive job. A lot of communication and coordination, primarily to get work through the delivery process.
Yet in an empowered product team, the job is not about delivery or project management; it is about product discovery.
We have long advised product managers to offload the project management to one of the project managers (whatever title your company uses for this: delivery managers, project managers, or program managers).
We have also long advised that it takes most product managers on the order of four hours per day to cover their product discovery responsibilities (discussed in depth in INSPIRED). And then we encourage product managers to save an additional hour a day to answer questions from the engineers that come up during their delivery work.
But the real point is that when moving from feature teams to empowered product teams, you are not adding responsibilities, you are changing responsibilities. This is why true product management in the sense we’re describing here is considered a new competency.
“Many of the principles seem very similar to principles that are in the Agile Manifesto, or underlying Lean Startup. Is the product model trying to bring these back under a new name?”
We have long argued that the principles behind Agile and Lean are here to stay. Unfortunately it appears that in many parts of the world, people have abandoned these principles, and instead latched onto particular processes, which in many cases obscure the underlying principles which is where we think the real value is. So we do hope that the product model helps move the focus back to these underlying principles. But you will also find that the principles go beyond product discovery (lean startup) and product delivery (agile) to look more holistically at product development.
“You say in the book that the support of the CEO/GM is essential, yet you also emphasize how much the product leaders can do to drive the transformation, and even what an individual contributor product manager can do. Are you suggesting a transformation can only succeed with an already supportive CEO/GM?”
In our experience, this is not a binary thing – where the CEO is either supportive or she is not. In practice, it is about progressively earning the trust of the executives. I sometimes explain this as like a multi-level game, where you start at level 1, and once you’ve shown you have achieved a certain level of skill, you are able to enter level 2, and so on. It’s very much like this.
The product manager or the product leader demonstrates that they can contribute towards real outcomes at one level (e.g. a product manager with her own skills, or with her product team, and a product leader with a set of product teams), and the company leaders see this progress and give them more room to have larger impact, and this continues during the transformation, until a full business unit has transformed, or until the full enterprise has transformed.
We consider this not only reasonable, but prudent. The CEO may be very supportive in theory, but likely can’t know if the product teams and product leaders have the skills and the motivation to successfully deliver outcomes.
“Are you suggesting that an individual contributor can take on the responsibility of transforming a company?”
No, we have never said this. However, we have pointed out many times that an individual contributor has more ability to impact her work environment than most people realize. And if she does this – such as by up-leveling her skills from a product owner or feature-team product manager to an empowered team product manager – then it’s not unusual that she finds herself getting recognized and sometimes even promoted. And if she makes it to product leader, then she has much more ability to impact the broader company.
“What about Product Ops? I don’t see this described as one of the four critical competencies. Are you suggesting that the role is unnecessary?”
This is also in the book, but we’re expecting many of the people that are worried about this are not likely to read the book, so let us try to clarify here: There are several quite different definitions of Product Ops we have encountered in companies around the world. In this article we summarize the six major definitions we see. If you read the article you will see that some of these definitions we find very helpful, and others range from harmless to serious anti-patterns. So a crisp answer on this is difficult because of the ambiguity out there.
When the Product Ops people are helping the product teams to quickly answer questions qualitatively (primarily via user research) or quantitatively (primarily via data analysis), we find that to be very helpful. For more than two decades this has existed in strong product companies, and demonstrated real value, it was just not called “product ops.”
“How do you define which companies are considered the best?“
We have long used the heuristic that the company must have demonstrated that they are capable of consistent innovation.
We point to companies such as Amazon, Apple, Google, Netflix, Slack, Spotify, and Stripe, as well-known examples. We also note that it’s not just us that consider these companies consistently innovative. The stock market has recognized these companies as well.
Note that this doesn’t mean that every product effort is successful. In fact, failures come along with innovation. But it does mean that the company has shown they have the skills to have multiple significant successes, even as they scale.
This also means that an early stage startup that may have a truly innovative first product, but has not yet shown that they can continue to innovate as they scale, would not be included (no matter how much we may love that startup).
“Since every company is different, can you really leverage practices between companies?“
Yes, every company is different, just as every person is different. But fortunately the principles are remarkably consistent across the best companies.
It is true that one of the most common excuses is the classic “but we’re different,” so don’t be surprised if you encounter this argument.
In product, we look for “differences that make a difference.” And when it comes to the product principles underlying the product model, we find those principles in virtually every type of tech-powered product company we know, whether they are building hardware, software, for businesses or consumers, from regulated industries to entertainment. So just because every company is different in some way, does not mean that they would not benefit from learning from the best.
“I know someone that works at one of these companies considered among the best, and he says that not every team at this company is an empowered product team, and that some are feature teams.”
Even at the best companies we know, some teams are not truly empowered. There can be various reasons for this. In some cases, the people on the team have not yet demonstrated that they have the necessary skills. In other cases, their leader has reverted to micro-managing. In any large company, you will find a mix. The question really is what is the primary model at this company? Remember that no company is perfect.
“Is there ever a case where a feature team is good enough?”
First, it’s important to point out that an empowered product team can do everything a feature team can do, plus a good deal more. So you’re not losing anything by up-leveling to product teams. Second, be aware that there are real morale differences between the people working on feature teams vs product teams, especially if people on feature teams see how different things are for their colleagues on product teams. But to answer the question directly, yes, there are some cases where a feature team is enough. One example is a bug-fix team. There is rarely the need for any product discovery on a bug fix team. Another example is a team dedicated to addressing major technical debt issues, such as a re-platforming team, at least once the major technology decisions have been made, and now it’s a matter of plowing through the code base making all the necessary changes. These are both useful teams, that don’t require the extra capabilities of an empowered product team.
“I know someone that works at one of these companies considered among the best, and he says that their culture is terrible and nobody should try to emulate them.”
The cultures of the companies we highlight vary dramatically, and have usually been heavily influenced by their founders. They also change over time (especially after the founders leave). We focus instead on the underlying product first principles, and we find that these are remarkably consistent across innovative companies. Those are what we focus on, and what we encourage others to learn from.
But more generally, if you are looking for reasons to avoid the effort to try to make your company better, it is not hard to find them. In fact, we highlight the most common reasons for failure here.
“Is a bet at one level, just a feature at another level?“
A bet is an outcome you are seeking (a problem to be solved), and a feature is output (a particular approach to a solution someone wants you to build).
A bet is just one metaphor for expressing your product strategy, and your product strategy is what drives the areas your company wants to invest in. The key to empowerment is to be sure to give your product teams as much latitude in coming up with the most appropriate solution as possible.
“If we move to the product model, will we need to reorganize?“
In most cases, no. In general, the product model is orthogonal to your organizational design. This article explains why, and how the product model relates to the org structure.
