Transformation happens all around us, every day.
Yet for many organizations, it feels like it’s nearly impossible to achieve. The project to product transformation is no different. It’s a multi-year journey, but one that is well worth the effort.
When describing companies or organizations that are trying to transform from a project to a product organization, what I am referring to are teams that are focused on 1) looking to change and accelerate how they deliver value to their customers and the business, and 2) are focused on building digital products in the form of software, websites, apps, wearables, etc.
Why would a company want to undertake this fundamental shift in how they create and build their products or services? Most are seeking to become more customer-centric, drive innovation and accelerate their speed to market. Ultimately, it often comes down to economics and rapidly changing consumers & markets. Many feel the product model will deliver more shareholder value and earn the company greater market share.
In today’s environment, the project management model feels monolithic, slow and cumbersome. It’s hard to react quickly to changing customer, technology and market forces when you are planning 12 months in the future. This puts the company at a competitive disadvantage compared to competitors who appear nimble.
The project model, it turns out, 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. At Fahren, seen companies waste millions of dollars and years on projects that ultimately didn’t meet market needs.
Enter product management
What’s the solution? Product Management. This methodology and management system has been around for several decades and has roots in the automotive industry, but became popular with software developers in the early 2000s.
Product management takes a different approach to deliver software, one built on speed, agility, data and being more customer-centric. The product model starts with building software in smaller pieces, often within an Agile framework, using short, focused efforts (sprints) to deliver working code to the market with high frequency. The model also strives to reduce risk by directly testing ideas and concepts with customers before those ideas are built.
The real paradigm shift of a product model is the unification of IT, business, design, analytics, and other teams to collectively deliver products. 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, often many months later. Business, IT and design all have the same goals and are working to solve the same problems, together.
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 turning the cruise ship easier and faster.
Ten things I wish I knew before transitioning to a product organization (actually 13)
- Being a product organization isn’t a system to build and deliver software. It doesn’t just impact the IT team, either. Product management is a different management model altogether. The CEO or organizational leader needs to lead, behave, and incentivize their teams differently than they have over the last 50 years. Organizations that don’t understand this truth will implement Agile or other frameworks without fundamentally changing what they value, how they prioritize and fund the work, and evaluate employees. Leaders should plan and set the expectation early on that product management will directly impact HR, finance, legal and compliance, and other areas of operation.
- Establish the Why before defining How. Set a clear vision and a sound strategy upfront. This is critical, particularly for large, enterprise organizations. Help your employees understand why we are making this move, what this means for their careers and what success looks like for them and the company before making any org changes. The challenge is that most leaders are so anxious to make the move and start operating differently that they rush into the changes without fully understanding the culture shock that is about to hit their teams. 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, the next step is defining your products. This process can be difficult for new product organizations because there are no perfect answers. It’s critical for organizations to pick a starting spot and be willing to adjust 6-12 months later. Many organizations will opt for an organization design centered around key pages, capabilities or customer flows. There’s no perfect answer. Usually, the place to start is what is simplest to align on and go from there. Over the next few years, teams can expect to change their definition of what is a product, how big they should be, what type of investment each gets, etc.\Most organizations don’t account for the time and effort it takes to change the culture.
- Culture is the key, and usually the missing ingredient, to the transformation from project to product management. Almost universally the culture change needed comes down to one thing, trust. How you set goals and evaluate individual and team performance changes. This organizational change will shift roles and responsibilities. Think Ocean’s 11, where everyone has a specialized skill and is working together with deep trust. While attending Mind the Product in San Francisco in 2016, one of the keynote speeches talked about building heist teams. You can watch the video here. Building the right culture on the team, with everyone motivated and energized, will accelerate your progress. Making sure everyone knows their role and how they fit is the role of the product team.
- The transformation to Product Management is effectively merging the business and IT organizations. This is a very difficult concept for many companies. In a product organization, the engineers sit with their product managers/owners and their UX resources. They all have the same goal. They all are working toward solving real customer problems. When the teams are siloed, managed and evaluated differently, it just doesn’t work well. This fundamentally shifts how the organization views the IT team and how they see themselves. Breaking down the silos between technology and the business is the whole point of product management. It forces everyone to focus on the customers and their problems instead of their functional area.
- The transformation will shift what is required from the VP and Directors. Leaders of product teams need to understand their value is not being the decision-maker on all things. The new leadership role is vastly different and becomes focused on being a team builder and enabler. As a leader, do all decisions and approvals need to go through you? Are there hours of meetings and red tape to align on roadmaps and make decisions? Are you giving your teams a roadmap to deliver or business problems to solve? Leaders in these new organizations become supportive and eliminate roadblocks for their teams. In my experience, the vast majority of directors and VPs struggle to lead the new organization, even with the best of intentions.
- Most organizations fail to develop their critical skills across all areas of Product Management. Product development, or the building of the software, usually gets 90% of the attention of new product organizations. Agile, scrum, working with developers in sprints – these are the things that senior leaders will focus on to drive speed of delivery through the pipeline. It is easy to fail to recognize that it’s actually as important to focus on product strategy and discovery than delivery. If you aren’t good at figuring what to build before building it, you might as well be in a traditional waterfall method of building software. You’ll get the same result, only faster. (That’s not a good thing). Very few organizations truly understand what product strategy is. Even fewer think about product discovery, the art of getting data and learning before building anything to scale. Product management’s goal is to de-risk what’s being built before it gets to market. These strategies typically come much later in the project to the product transformation maturity model.
- Project managers often do not make good product managers. You may need to shift people into roles that don’t suit them in the short term, but moving to a product model requires an entirely different talent strategy. Project managers often have little knowledge of the customer. They often lack data gathering and interpretation skills. They aren’t connected to the business and metrics of the organization, beyond that of 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.
- Finance will be slow to change their funding model of people and teams, not projects. Finance usually has a really hard time with this transition from project to product. This isn’t how they are used to determine what gets done and what are the results. This lack of comfort is usually a barrier to getting support. It takes the c-suite to really push and make this happen. The best thing we’ve seen is finding the maverick within Finance that is willing to be the internal champion of the model change and work from there. It will take time, so starting a new financial management model of funding a small number of teams can help guide the transformation.
- Start small and eliminate too much work in progress. Teams often struggle when they don’t have enough space and freedom to learn and evolve. A critical piece of the equation is ensuring that the amount of work moving through the teams is manageable. When Mike McNamara joined Target as CIO, he made the bold decision to eliminate swaths of technical projects. He knew that being able to say no to non-critical work is vital for teams to start operating in a new way.
- It’s time to rip the bandaid off and go. In today’s rapidly changing environment, organizations don’t have the luxury of creating a perfect structure and model before moving. We see it time and time again. Leaders get so hung up on finding the perfect team structure, the perfect tools or just the right time to make a change that they do nothing instead. Lots of meetings, lots of delays. The most important thing is to establish why you are doing this, getting buy-in and investment from your teams and to get started. 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.
- Lastly, it will be institutional inertia and internal politics that will sink the ship. When it comes to organizational transformation like this, people’s careers are on the line. Many people unknowingly struggle to support a change that may impact their ownership and autonomy. The result is an internal system that favors the status quo. Changing the way you think, work, and invest in more work than staying the course. Breaking that inertia is critical for the C-Suite, and requires direct support. If this isn’t a top-down led transformation, the leaders below them aren’t required to go all in.
It’s clear to me that making the move from project to product management, particularly if you are operating in the digital space, can dramatically improve growth, profitability and customer satisfaction. The hardest part seems to be creating a culture that truly supports that change. Know these thirteen things going in and you can avoid the mistakes of those who have gone down this path already.