So how do you shift from traditional project centric to modern outcome based development (projects to products)?

In part 1 and part 2 of this series we explored,

1. Why building products with a project centric mindset produces sub par results.
2. How digital leaders build products and why they can deliver better results.

In this article, we will explore how product teams can transform from a project to product mindset. Moving from the traditional approaches to leveraging modern product development best practices. And instead of blindly building features, these teams can now begin to deliver outcomes.

It goes without saying that this transformation is not easy. But it is also not as hard as most people think.

The key is to start both bottom up and top down.

As you will see, just training the team (bottoms up) or changing operating model (tops down) will not work.

A better approach is to do both,

1. Identify the gaps in your current product development capabilities and create a future state vision
2. Upskill your teams on the key gaps (both the core team and product leaders). You dont need to solve all the problems, just the most important ones.
3. Drive adoption of the new practices – first with a few lighthouse teams and one you see progress, scale rapidly. This is where you will start seeing real changes.
4. Codify the changes by updating the operating model and internal processes.

In Part 3 of this series, we will deep dive into each of the above steps.

(If you like what you are reading, and want to get more of these types of insights delivered to your inbox, consider subscribing to my free newsletter.)

Step 1: Identify gaps

Begin your transformation journey by first assessing your current capabilities.

Building an outcome centric mindset requires making lot of small and big changes. Knowing what to change now vs. later can literally make a difference between success and “just another failed transformation”.

To help avoid this fate, I usually recommend my clients to take a stock of where they are right now (warts and all). This will not only help you identify your biggest capability gaps but will also serve you as a guide throughout the journey.

If you are looking for something quick and directionally correct, consider using a product development capability map. For something more formal, use a maturity assessment (option 2 in the article).

Step 2: Build the right foundation

Once you have identified the key gaps in your capabilities, the next step is to to show the product team (and their leaders) what good looks.

It continues to surprise me how many teams may know the right words – “two pizza teams”, “continuous iteration”, “build & test” – but when asked to put it all together they are completely lost.

What they need is a prescriptive process, that takes them through every step of the product development cycle.

And the best way to do that is to have everyone in the core team go through a crash course on product development training.

By doing so, you incur three key benefits,

1. The product team knows what “good” looks like and what is expected of them (at the individual, team, and leadership level)
2. They are all on the same page and have a common understanding of the terminology, and
3. Begins to open their minds on what needs to change (priceless)

Three things to keep in mind, if you want the training to be effective.

First, don’t just train your product managers. It takes a village to build a product. So train the larger team – including UX and engineering managers – as well.

Second, stay away from generic cookie cutter training. To get the most bang for your buck, use the gap analysis (from above) to help create a customized training plan.

Third, the pedigree of your instructor matters. You want someone who understands both modern and traditional product development. You cant be an effective teacher if you cant empathize with your audience.

Step 3: Drive adoption

Too many product leaders forget this step. They think that once the troops have been trained, they should be ready to implement new ways of working.

But it rarely works that way. For the team (and it has to be at the team level) to behave differently you need to help them take the leap.

It’s a lot like teaching kids how to ride a bike. Yes, they might have a general idea about how the mechanics work. But in reality, to get over the fear of falling and learning to balance, they need a steady hand in the back to hold the bike up.

There is usually 2 parts to adoption.

Part 1: Start small with a handful of lighthouse teams

Changing from project centric to product centric can be daunting.

That is why, it is best to start with just a few teams.

In my experience 3 – 5 should be enough. And even within this pool of lighthouse teams, you want to start with just 1 team first. Once that team starts to show promise, then expand it to the rest of the lighthouse teams.

The philosophy in this stage is simple. Keep the risk low, while the team and you find your sea legs. And as the team grows in confidence, expand to additional teams.

Once the first team is selected,

1. Embed an experienced product manager into the team. Not to augment their work, but to help guide, advise, and coach the team on how to build products.
2. The product manager takes the team through all the necessary steps from strategy, discovery, and delivery. And trains them to be self sufficient.
3. The interim product manager then moves on to the next set of lighthouse teams.

One word of advice, be careful which teams you pick. Only pick team members who are naturally open to new ways of working. Changing the way we work is hard enough, you don’t want to have a “fuddy duddy” derail all transformation efforts.

This will greatly improve your chances of success and provide you with the momentum to go into part 2.

Part 2: Rapidly scale to other teams

If all you have are a hand full of teams, then you can skip this step. However, if you have a whole bunch of teams, then you need to figure out how to scale.

You could repeat what you did in part 1 and expand it to others. But frankly speaking it is slow. Once you hit upon a good thing, why wait.

A better option is to leverage the product members from the lighthouse team and have them do for the rest of the teams, what the interim product manager did for them.

You may have to provide them with some “train the trainer” training, but it is will worth it. For three reasons,

1. There is instant legitimacy. All the objections that you would have faced that it will never work here will simply melt away.
2. You can scale fast. 5 lighthouse product managers guide 5 more teams. These 5 teams produce 5 more coaches, which in turn can then guide 5 more. The cycle builds on itself.
3. It solidifies the new way of working. The old adage, if you “want to learn something really well, then teach it to others” works great in this scenario.

Now this adoption step always raises a lot of questions. So let me see if I can get ahead of them.

First, it is not necessary to train 100% of your product teams. 60% to 70% is good enough. By then, it starts to become ingrained in the organizations memory.

Second, this takes time. Don’t expect change in 1 – 2 months. Just Part 1 could take a better part of 4 – 6 months. But once you are through that you can progress quite rapidly to the rest of your teams.

Third, if you are wondering why invest in this type of “retail” change management. The answer is, this is the only way to make real change.

But once you make the change, you have to make it stick. Which bring us to…

Step 4: Update operating model

The last step is to codify the changes.

Organizations have a history of slipping back to bad habits. So to cut off access to the old way of working, now is the time to update the operating model, process, tools, promotion criteria etc.

There are several benefits of waiting to make operating model changes till the end,

1. You will know what to change. In the last phase, you will start to see certain trends on people, process, and organizations. Use that as the starting point and build your new organization around it.
2. You will have a better chance of the organization adopting the change. Since the teams have been part of the journey from the very beginning. They will understand the why and how this affects them personally. And so the resistance will be manageable (minimal if you are lucky).
3. It wont seem like a big risk. Most of the teams will already be operating in the new way. This just cements it.

If all of this sounds daunting. Consider getting an advisor, they should be able to guide you throughout the process.

Happy Building!!