TBM 291: Why Your Product Transformation Will Fail

Your product transformation will fail if:

You treat a transformation as a project. The track record for big projects is not good. The track record for formal transformation efforts is also not good. Is this because the companies that opt for this approach are less likely to succeed, or is it because the vehicle of a large project is somehow less likely to succeed? We can debate this later, but ultimately, if you view this as something with a beginning, middle, and end, you will likely be sorely disappointed. One way I like to think of this is that your company is transforming as we speak. It has been in a state of perpetual transformation. If you can nudge that energy in the right direction, you will continue on the journey that you are on.

You devalue the present. If the team feels like they aren't good enough, not smart enough, not skilled enough, and that progress is essentially becoming as good as other people who have, in theory, figured everything out, then you will lose the hearts and minds of your team. The messaging around these efforts can be downright toxic and gaslighting at times. Nothing is good enough, and everyone needs to be better except for senior leaders. Think of it this way: you're lucky your company exists. You're lucky if your company has customers. You likely wouldn't have gotten to where you've gotten without doing something right and attracting passionate people. Leaders often convey passive-aggressive dissatisfaction with the present state, coupled with difficult-to-believe enthusiasm and celebration, which can feel fake and disingenuous.

You don't let your team lead the change. Yes, you may need to inject some new skills into the mix, but if all you do is hire outside people to tell your team how to behave and what to do, you'll fail. I've always found the saying "people don't mind change, they mind being changed" to hold in these situations. The message you're sending is that your team is broken and that only outsiders can fix them. You'll be amazed at what they can do if you release the constraints dragging them down to date. There's a good chance that some pocket of people have been advocating these improvements this whole time, and you need to figure out how to harness that energy.

You put "the best" on a pedestal. You can learn a lot from studying how other teams work, but you need to do so with a curious mind and a good dose of systems thinking. What may seem like a fairly straightforward skill on the surface is likely the net result of many experiences driving conviction over long periods. People are often very surprised to learn what is happening in many companies singled out as great product companies. Reality doesn't match the myth.

Encourage your team to be students of the craft and students of different approaches, but mindlessly copying and pasting how other people operate will not get you where you need to get to. Final note: there's a good chance you have people already on your team with the requisite skills.

You ignore the continuous improvement muscle. Here's an uncomfortable truth: many of the companies noted for being the best aren't necessarily places that are friendly to continuous improvement, changing course, or adapting. They grew up "doing product" and can be fairly set in their ways. Change in these companies often involves disruptive reorgs and layoffs.

You don't have that luxury. You have to build the continuous improvement muscle. You'll have to figure out how to shift how you operate meaningfully. This is no small feat.

The critical implication here is that you'll need to shift into company improvement mode, and this is a unique motion that involves certain leadership skills, relaxing certain constraints, rewards, and incentives, and celebrating the journey. Continuous improvement requires top-down air cover and an unmistakable message from leadership that experimentation and trying new things are acceptable—creating conditions where people can explore new ways of working locally. Top-down change fails. Bottom-up only change fails. Middle-out change fails. You need the top-down air cover along with the bottom-up empowerment. Simply put, you will need to get good at changing and adapting, which is hard and uncommon, but you'll need to do it.

You don't let go. You will need to let go of certain processes, certain reports, and certain rituals. So many organizations change what teams do on the frontline and effectively translate those practices into what is happening on the upper management and leadership levels. There are only so many hours in the day. If your team is spending time tracking time, doing status checks on projects, responding to reactive issues and requests, or navigating complex processes just to talk to a single customer, they will not have time in the day to try new things. Change starts with subtractive change. What will you stop doing? What behaviors will you stop doing immediately to make room for the new behaviors that need to emerge?

You lose sight of customers. Why are you doing all this? Why does it matter? No one goes home to their significant other or friends and brags about being part of an agile transformation so that velocity increases. No one brags about the big promotion that the senior VP got because they were able to celebrate the big launch of an app! There's not some glorified point on the horizon that you get to and suddenly raise the flag and say, "We're a product company," because there will always be new problems to solve. If you are successful, you will have new problems to solve and new areas of improvement.

You must find a true north that connects and inspires your team and makes the trouble worthwhile. What are you hoping to achieve on behalf of your customers? How will you help them achieve their goals? What is a win-win approach that allows you as a business and helps your customers as businesses or individuals?

You copy/paste frameworks. Many teams make the mistake of picking specific frameworks as training wheels for their team. They feel that copying and pasting what has worked elsewhere is some kind of shortcut to get their team started. But instead of treating these as almost throwaway experiments with the expectation that you will move past these ideas, the teams languish and linger on these frameworks for years because that became the goal (instead of frameworks as a tool we use and then stop using). Think of frameworks as a good starting point, but you better move quickly on improving and customizing. Otherwise, you will become a captive to the framework. This also shows a fundamental misunderstanding of cause and effect. If a company had the DNA to evolve a way of working over time and reinforce that way of working with rituals and habits, that is what you need to copy, not the output of that activity (the framework).

You ignore architecture. You cannot have teams working independently if they have to collaborate with 30 other teams to get anything done. In observing companies, I would say that the biggest blocker to adopting more product-focused ways has nothing to do with the product. It's the architecture. It's the dependency. Given the current constraints, the teams can discover problems, run experiments, and measure impact, but there's no way to make that happen. I wince, thinking about all the companies that have subjected their teams to multiple rounds of so-called transformation as a basic avoidance mechanism for taking care of core architectural issues.

You don't use "working examples" to inspire change. Imagine being engaged in some multi-year effort with no end in sight, being told that your teams aren't good enough, perhaps even amid layoffs, and somehow the improvements never materialize. Or having a single example of a single greenfield team doing something fairly trivial and that being hung over everyone's head as an example of how things can work, with no real appreciation for the real-world difficulties of getting anything done in the company. This is what teams encounter very often. It can deflate and take the wind out of the sails of any effort to improve.

Therefore, it's critical to focus on fostering conditions where real-world examples can emerge that other teams can learn from and then making sure that avenues exist for those stories to be told and shared in the organization. How are things improving? How is it benefiting customers? How did the team locally adapt the general principles to make progress? What can the team learn? The stories you tell and amplify are so important.

(Final tip, for chrissakes stop calling it a Transformation. Your odds of anything succeeding go down automatically when you use that word.)