Projects End, Products Endure —

"Project to Product" is the latest hot phrase to come out of the digital transformation space, used in legacy industries and companies to describe the stickiest parts of the transformation.

Companies born of the digital/agile age (say, in the last 20 years) are more likely to either start or subtly shift into a product framework. This shift allows them to deliver high-value, customer-centered products and digital experiences in a more agile, iterative manner.

On the other hand, when legacy companies have built up significant culture and infrastructure around project-based thinking, it's harder to make the shift. It's like comparing steering a speedboat through Venice's canals with trying to dock a container ship at the Port of Los Angeles. 

Both require skill and deftness, but the speed boat captain has to maneuver differently than the container ship captain. Gravity plays a much more significant role in the container ship's navigation - too sharp a turn means the stacks of containers can shift and go overboard.

Why Is It So Hard For Legacy Organizations to Make the Shift? 

For legacy organizations, the "gravity" includes all the structures and cadences that have built up over many years and decades of honing the way your teams do their work: annual planning cycles, the way work is prioritized and staffed, the way finance/capital is allocated, the way technology is architected and scaled, and the way the product itself is articulated. You can't tackle one of these without impacting the others. Tearing these things apart and reorganizing them requires a major shift of mindset. Like the ship, making significant changes too quickly means a potential catastrophe.

Project-Based Organization Design Wastes Expertise, Time, and Money

I tend to sleep pretty soundly, but I'll admit to some tossing and turning when I think about companies stuck in the project mindset. The added infrastructure of a project-based approach creates so much lost knowledge and long delays. Under that model, you have to decide something is a priority, figure out how much to spend on it, assemble the team (which often means hiring or outsourcing), design a big plan, execute, and then, in the end, everyone on the team goes back to their "day jobs" or onto the next priority. Every time you switch projects, you lose the value of your team's collective abilities and skills. It's a decreased time to value and ensures that whatever value you extract will degrade the instant you pull the team to work on the next thing. It's as close to a lose-lose situation as I can imagine.

Many organizations balk at the idea of creating cross-functional teams to come together to make the experience of using the product better iteratively. They can't imagine teams are led through influence and not through reporting authority and believe they have to go all-in on a re-organization even to start shifting this mindset. I have spent HOURS explaining to people that a product team with a strong business owner and a strong tech owner can be successful if they don't report to the same leader and if their delivery team doesn't report to one of them. And, under this model, they can move faster without all the scaffolding of a waterfall project. 

I also see that some legacy companies believe that product ownership is something you can tack onto someone's "day job" and get the same results. When we start talking about the sprint cadence, planning cycles, daily stand-ups, and customer research, I inevitably hear, "That's crazy! They don't have time to do all of that!" Exactly. Dedicated, sticky teams are necessary, and they require a different way of approaching management and evaluation of product teams across business and technology organizations. 

Product-Based Architecture & Taxonomy Open the Door to Higher Productivity and Profit

Often, the way "in" to the product mindset for legacy organizations is through a new understanding of how they organize and think of their products. It's especially true when previous thinking about a product is limited to a box on a shelf in a retail store. As legacy companies start to expand their thinking to the platforms and capabilities that enable their customer and employee experiences, they often realize that they are spreading their dollars around according to a set of priorities that shift annually. When this happens, investments are focused on the latest and greatest, not on where they will get the best ROI. Everyone is muddling along with their slice of the annual pie, but the payoff to delivery is too long and convoluted to know if that investment is worth it.

Product taxonomy - the putting-in-buckets of all of the components a product-based structure is made of - can be done in many ways. How you choose to do this will likely be customized to your needs. To get started, I often recommend the Core, Platform, and Growth approach.  In this model, the Platform teams get some leeway to take a more measured/predictable approach, while Core and Growth teams are empowered to think and act according to customer needs and market changes. It is a particularly attractive model for enterprises with a significant underlying tech stack. Product ownership looks a little different for ERPs, financial platforms, data infrastructure, etc., and rightfully should be managed differently.

I recently wrote an article for Mind the Product that addressed this aspect of project-to-product-based thinking. Here's a real-life example of what it looks like: 

"We were trying to bring our executive team along on thinking about prioritizing resources against value, but they were stuck in the project-based, spread the capital around mindset.

We got them all together and used the 'Jedi Mind Trick' of relative prioritization. We made huge posters of all the PROJECTS that we had green-lit for the year, and unbeknown to them, we laid them out into what we were starting to think about as our PRODUCT taxonomy. We gave each executive a sheet of dots to use as votes – where did they think we needed to focus our attention? There were not enough dots to spread to every project, so they had to choose wisely.

In the end, we had a heat map of executive focus and priority. When we put up the capital allocation for projects, they started to see that they had too little money allocated to the things they all agreed were most important and too much on things that got few or no votes.

It snapped them out of their approach to funding, and we took that work and turned it into a priority review in our MBR and QBR meetings. That exercise marked the shift in our thinking from Project to Product."

Lisa, IT finance and planning executive

Is Your Leadership Team Ready to Reimagine?

A shift from Project to Product means that we have to mature our thinking about what the end looks like. As I've said before - projects end, products endure. Thinking about your product plan has to start with a vision: what will your company, your customer's experience with your company - look like once this product or capability is built? What will it look like when the sum of your products, working together seamlessly, are built?  

That's the topline vision - also known as a North Star - that leadership must articulate for and with their product teams. From that, product teams can evaluate the vast opportunities of what they COULD do with the time and resources they have and focus on what they MUST do to achieve their vision.

Leaders then need to stop asking "when will it be done?" and start asking, "what did we do this month/quarter/year to get closer to achieving our vision, and how do we know that?" Product management is a constraint-based model, after all. The planning and prioritization cycles that organizations work through have to help teams understand what's important and how value is measured. Then, they can know the work they can do within their current capacity to deliver on that value. 

The Journey Starts With a Single Step

As I said in a recent  Mind the Product article  - YOU are the MVP your company has been waiting for. While I don't believe you can do this shift in pieces (the only successful transformations I've seen have started with a commitment at the top), you can start small, iterate, and learn. 

However, you can't make this turn without careful planning and consideration. Identifying teams, customer needs, or growth opportunities that could carve out a new way of working is an excellent way to see how the project-to-product shift might work in your company. Applying the product mindset of discover, design, build, measure, and iterate can help you find your way into the value that's unlocked when you move to this way of thinking and working. 

If you're ready to start, let's connect. I can help you figure out how to take the first steps in your journey from project to product!