Transformation as a Project
In this article I’d like to highlight an anti-pattern that my partners and I have witnessed at several companies that are embarking on transformations to the product model.
It’s an understandable anti-pattern, but it’s also more than a little bit ironic.
As most know, moving to the product model means moving from a project orientation (building features and projects by specific dates) to a product orientation (solving problems and achieving business outcomes).
This change is of course referring to how we build our products.
Yet in many companies, they choose to manage their transformation effort as yet another big project.
They do all the same things they do for their big projects. They assign program managers and identify sponsors; they create a big project plan, with a company-wide rollout; they define RACI models and process flows for the new roles; they identify different work streams; then they proceed to divide up the anticipated work, assigning tasks, and tracking dependencies and status; and then they focus on reporting the progress in accomplishing the tasks.
How is success defined? Completing the project.
As with products, success starts with knowing what you can’t know, and admitting what you don’t know.
At the root of the issue is an organization that is well-intentioned, but has not yet come to terms with this reality. They believe they know what they need to do to transform, but the necessary learning is still in front of them.
This approach is the polar opposite of what we would do for a product, and what we advocate for in the book TRANSFORMED when it comes to your transformation.
Instead, the goal is to first learn and demonstrate to the organization what it looks like to have a product team that can successfully deliver outcomes, and then to scale those results with progressively more product teams.
The real point is to build the muscles to be able to successfully take advantage of new opportunities, and respond to the most serious threats.
We encourage organizations to consider the transformation effort as similar to a product. As such, we identify the major risks, and then create small prototypes (pilot teams) to tackle these risks.
These pilot teams are fast, inexpensive, and safe ways for the company to learn the product model, and especially to understand the implications for their organization, and for the rest of the company to observe and consider the impact on their areas.
It’s one thing to say “we need to upgrade our product owners to true product managers” but if the organization has never had true product managers, then this is a very profound change; one that goes far beyond a change in title.
It’s one thing to say “make engineers first class members of product teams” and quite another to see just how dramatically that changes the dynamics of the company, especially the source of the best product ideas.
It’s one thing to say that “our product leaders now have several new responsibilities that they did not have before,” and quite another to learn which leaders are capable of succeeding in this new role.
Running a transformation as a project is the same problem that happens with trying to create a product as a project. You don’t identify the important issues until the end, and you’ve spent significant time and money only to find out you’re not doing what you need to.
Once you have run a few pilot teams in the product model, the discussion moves from abstract to very tangible.
You may find you need some specific help with one or more of the key competencies.
You may find that a real product strategy has more implications on stakeholder collaboration than you realized.
Or you may find that certain discovery or delivery techniques are especially important for your types of products.
And these are just the direct consequences of what you learn. There are often second order effects that take more time to identify and address.
Just as with products, people sometimes fear that the prototyping/pilot team approach will take more time to complete the transformation, but as with products, if your goal is a successful outcome (aka “time to money”), it is in practice substantially faster.
So if you’re contemplating a transformation to the product model, I hope you consider the advantages of using the product model to transform to the product model in order to improve your chances of achieving the transformation outcome your company needs.
