Joe Ruekert

View Original

What I wish I knew when transitioning from a project to product organization

Some hard earned lessons on changing your organization

The project to product transformation is no different than any other change. It’s a multi-year journey, but one that is well worth the effort.

Making this shift helps companies become more customer-centric, drives innovation, and accelerates speed to market. This evolution is necessary to keep up with rapidly changing consumers and markets.

Traditional project management models make it hard to react quickly to changing customer, technology, and market forces. The project model is also risky. Investing months of time and significant capital before a project gets released to users can be a recipe for disaster if customers don’t like the product that was built.

What’s the solution?

The product management model starts with building software in smaller pieces, often within an Agile framework, and using short, focused efforts known as sprints to quickly deliver a product to the market. This reduces risk by testing concepts with customers before anything is built.

The real paradigm shift of a product model is the unification of all teams. Gone are the days of business teams writing vast lists of requirements, handing them over to IT and waiting for the final software to be built.

I’ve lived through several of these transformations as an employee and have helped coach several other organizations on their own project to product transformation. Here are 10 things I wish I would have known going in that would have made the transition easier and faster.

10 things I wish I knew before transitioning to a product organization

Making the transformation to a product (versus project) organization doesn’t just impact the IT team

Product management is a different management model altogether. Leaders have to drive a fundamental change in what they value, how they prioritize and fund the work, and evaluate employees. Leaders should set expectations early on that product management will directly impact all areas of operation.

Establish the why before defining how

The motivational speaker Simon Sinek wrote the book, Start With Why, based on his TED Talk, the third most listened to in TED history. According to Sinek, the world’s most influential leaders all think in the same way, and that people don’t truly buy into a product until they understand the why behind the design. To establish your why, set a clear vision and sound strategy upfront. This is critical, particularly for large, enterprise organizations to help employees understand why the company is making the transition, what it means for their careers and what success looks like. Leaders are sometimes so anxious to make the transition that they rush into the changes without fully understanding how it will affect their teams on a company culture level. The result is often confusion, lack of buy-in from the team and resistance to the changes that are being made.

After defining the why, define your products

There’s no perfect answer, but it’s best to pick a starting point and expect to be in transition for the next 6-12 months. Over the next few years, teams can expect to change their definition of what is a product, how big they should be, and what type of investment each gets.Most organizations don’t account for the time and effort it takes to change the culture. Starting with one team and using that successful transition as an example the rest of the company can help other teams more willingly adopt changes.

Culture is the key

Successfully changing company culture comes down to one thing: trust. Organizational change shifts roles and responsibilities. A great keynote speech that talks about building heist teams is this one. Building the right culture on the team –– which keeps everyone motivated and energized –– will accelerate progress, and making sure everyone understands their role and how they fit into the bigger picture is the role of the product team.

The transformation to Product Management is effectively merging the business and IT organizations

Rather than working in silos, in a product organization, the engineers sit with their product managers and UX resources. Breaking down the silos between technology and the business is the whole point of product management. It forces everyone to focus on solving customers’ problems together instead of having tunnel vision that focuses on one function. This fundamentally shifts how the organization views the IT team and their own roles in meeting the broader goal.

Developing critical skills is crucial

Product development –– i.e. building the software –– usually gets the lion’s share of attention in new product organizations. While agile, scrum and working with developers in sprints are the things many senior leaders will focus on to drive speed of delivery through the pipeline, it’s equally as important to focus on product strategy and discovery as it is delivery. Very few organizations truly understand what product strategy is. Even fewer think about product discovery: the art of getting data and truly understanding what you want before building anything to scale. Product management’s goal is to eliminate a product’s risk before it gets to market.

Project managers don’t always make good product managers

Talent roles may need to shift. Project managers often have little knowledge of the customer and can lack data-gathering and interpretation skills. They are only connected to the business and metrics of the organization through the scope, timing, and budget for their project. Product managers and leaders require very different skill sets to succeed. Mastering the politics of building relationships internally and getting work done is also vital. Product managers need to be strong leaders who use data to drive prioritization. They need to get good at telling leadership and the rest of the organization “no” in order to protect their teams from distractions and low-value functionality.

Learn to navigate funding with finance

In my experience, finance teams usually have a really hard time with this transition from funding a project to funding a product (in the form of funding teams). This isn’t how they are used to determining what gets done and what the results of those efforts will be. It often takes the C-suite really pushing to make this transition happen to get finance teams on board. The best strategy to approaching this potential obstacle is finding the maverick within Finance who is willing to be the internal champion of change and allow time to get everyone on board..

Start small to eliminate too much work in progress

Teams often struggle when they don’t have enough time to learn and evolve. A critical piece of the equation is making sure the workload is manageable when teams are also expected to be learning a new way of functioning within the broader picture.

Rip off the bandaid

In today’s rapidly changing environment, organizations don’t have the luxury of creating a perfect structure and model before moving to adapt to the new way business functions. Time and time again, leaders get so hung up on finding the perfect team structure, tools or just the right time to make a change that the transition stalls indefinitely. The most important thing is to establish why you are doing this, getting buy-in and investment from your teams, and get started, working out the kinks as you go. Help reduce roadblocks to building working software that solves customer and business problems. The best version for your company is the one that is customer-first, iterative, data-driven and is driven by motivated, trusting teams.