The IT Leader's Complete Guide to Effective Product Management

Product Management

To begin, let’s start with an overview of product management. Generally, product management focuses on bringing the right features to market that make your product successful. And product management succeeds where other processes fail due to a targeted focus on value.

Features have to fulfill a business need. Product management keeps us from adding unnecessary features just because someone likes them. Because good product management has its metrics and key performance indicators (KPIs) tied to objectives, the data validates that we’re making the right product decisions.

Now many companies starting the product management journey think they already do this through solid project management. But are these the same? Simply put, no. Let’s look at some of the differences.

Product Management vs Project Management

Many of us coming into the product management space understand project management. However, we shouldn’t assume these are the same. To understand the distinction, let’s first look at the difference between a product and a project.

Project vs Product

Project — A project is a plan. It is a series of activities that must be completed within a timeline. The success of a project relies on completing those activities.

Product — On the other hand, a product is nothing without the value it provides to your market or users. In the IT world, this can be a software application, a service, or a physical product that requires technology or integration. And the success of a product relies on outcomes and KPIs. It’s not enough to reach the finish line. 

What else is different between the two?

Scope of Work

Next, let’s review scope differences between projects and products and how it applies to IT initiatives.

For projects, the scope typically involves a set of features or deliverables and a set delivery timeline. In fact, one application may have multiple projects over its lifecycle. And once you complete the project objectives, that project is done even if the product itself lives on.

In comparison, the product scope includes all the features and functions of the product. It covers the complete lifecycle of the product and defines how we can get features to customers using a continuous value stream.

So, an example of a software project could include adding a new feature, integrating with a new partner system, or upgrading libraries. But a product encompasses your whole application and how new features help our customers.

With the idea of value streams, we don’t tie ourselves to a predefined set of deliverables, judging our success on whether we met a timeline or not. Instead, we work to solve problems related to the vision of the product over time. And we drive additional features to our customers that add value.

And, eventually, the product scope involves the end of the product lifespan. With product management, we can decide when our product no longer provides the value it once did, and we either pivot or retire the product.

That difference in scope can also be seen when you consider the questions that product and project management attempt to answer.

Questions to Answer

In addition to the difference above, product management and project management answer different questions about your software product. Let’s review the questions that each practice helps answer.

First, when considering project management, we should review this set of questions.

• What are the requirements of this project?

• How do we execute the project?

• How do we mitigate risks and resolve conflicts in the project plan?

• What are the project timelines?

• How do we break down the tasks required into smaller pieces?

In turn, when looking at the scope of product management, we should consider the following questions.

• What’s our product vision?

• What do we build to drive towards that vision?

• How do we mitigate risks that we’re building the wrong product?

• What is the value of the product to either our customers or our company?

• How do we know if we’re headed in the right direction?

• When will we know it’s time to kill the project?

In looking at those questions, the distinction between product management and project management should be clear. In short, project management focuses on finishing a project, task, or feature. On the other hand, product management focuses on defining the product vision and building the right product to reach that vision.  So project management defines how, while product management shows us what and why.

Next, let’s take a more detailed look at what responsibilities go into Product Management.

Responsibilities of Product Management

To have an effective product management strategy, we must have clear responsibilities and expectations. We’re not going to go into specific roles involved in product management, such as product owners or product managers, as those roles can vary from company to company. Instead, we’re going to cover the responsibilities that someone in your product-driven organization should have. So what are the responsibilities of product management?

Own the Product Vision

The first responsibility of product management involves the product vision. This vision should define the scope of the product, the problem you’ve set out to solve, as well as identify a target market. Additionally, this vision clarifies the motivation behind developing the product.

As leaders, we should create a vision that’s compelling and easy to understand, while still being specific enough to help drive strategy. However, don’t make your vision too specific. Your vision shouldn’t focus on how we’ll achieve great things with our product. Instead, it should focus on the change we hope the product will produce. The actual implementation comes later through the roadmap and the specific implementation your application teams create.

And why is the product vision so important? Without a clear product vision, you won’t be able to get your product team moving in the same direction. Your product may be pulled into many directions, trying to fix all of the world’s problems instead of focusing on your specific niche. Instead of fulfilling the change that your vision identifies, you’ll find your team shipping features that don’t drive the product towards beneficial outcomes.

Likewise, if your product team doesn’t align behind the vision, your product will suffer. That’s why a shared vision is critical to the success of your product.

Overall, without a clear vision, you’ll find yourself back in project management territory. In that territory, the team completes the defined tasks but doesn’t question whether these tasks drive the product towards the vision. But with a clear vision, you’ll have an aligned team that knows what you’re building and why you’re building it. They’ll make decisions that drive the product forward without the need for excessive management. And that will help set your product apart and provide value for your customers.

Once we have a compelling product vision that’s been communicated well to the team, what’s next?

Build a Product Strategy

After you have defined a product vision, it is time to build a strategy. This strategy involves both short-term and long-term objectives. It explains how you plan to reach the product vision and determine the priority of your deliverables. More importantly, your product strategy should be flexible enough to change over time. It has to work with changing market conditions and customer demands.

This strategy also requires clear communication with your product teams. You can do that communication with a product roadmap. You should understand that roadmaps are not the same as project plans. They do not list deliverables alone. They also tie deliverables to product and business goals.

Let’s take a look at some best practices for product roadmaps.

Roadmap Best Practices

In the roadmap example shown, you’ll notice some of these key points that make up a good roadmap.

1. Tie product features to goals and objectives. Without understanding how features tie into goals, we’re likely to fall into the pattern of just completing projects without considering how they affect the overall product.

2. Focus on business value. Every feature your product ships should provide value to either your customer or your company. This doesn’t mean that every feature needs to be visible by the customer. But it does mean that there should be tangible outcomes to everything the teams work on.

3. Define metrics and KPIs. Once we know what we’re building and why, we must make sure the outcomes of features and objectives are measurable. Without measuring how our features support the vision, we won’t know if we’re going in the right direction or if we were successful.

4. Keep the product roadmap up to date. It is a living document that should be reviewed and updated based on priorities and learnings. Revisit the roadmap often and question assumptions that you’ve made while developing the roadmap.

5. Share the document liberally. In order to align everyone on the product team, you’ll need to overcommunicate and answer questions when they come up. If your team repeatedly has to answer the same questions about the roadmap, then something isn’t working. Experiment with the format and try again.

OK, so now we know what our goals are and how we’re going to measure them. And we’ve got a plan and a roadmap to help share that plan with others. What’s next?

Manage the Release Process

Once we have a roadmap for what we need to deliver, we need to look at release management.

Whether you release to production automatically by using continuous delivery and automated testing, or you release manually after a set of manual or automated processes, release management provides visibility in the end-to-end value stream for your product. Using release management, you’ll be able to see if features are moving quickly into production, or if they’re stagnating somewhere in the delivery process. As with other parts of product management, the data you gain from a release management system will help you determine metrics for the life of your product.

Another benefit of having a robust release management process includes being able to coordinate and orchestrate releases between multiple applications. This is great in an enterprise environment where product launches rarely include just one or two teams. Often, it’s a coordinated effort between ten or more teams that must launch near the same time to bring the product to market. With a mature release management process, you’ll get the right features to the right customers at the right time

So now that you’ve got several responsibilities, tools, and processes for delivering your product to your customers, how do you provide leadership and guidance at a higher level?

Measure Results

After we’ve released our product to our customers, we need to measure results. Within product management, this could include business results and KPIs. But it can also include business analytics that identify how we can improve our processes.

When we talk about business analytics in this context, we’re talking about metrics around how we get our code to production. For example, we can take a look at the effectiveness of our release cycle. Do we have any bottlenecks in our release plans? Do the teams become blocked from releasing by common root causes? Or can we identify patterns to failed releases?

As you can see, with analytics we can measure many factors of our product lifecycle. Why is all of this important? If we don’t measure these outcomes of our products, then we won’t know whether we’re improving our release cycle or not. This is why we must also continuously monitor our results to ensure that we’re moving in the right direction.

Now that we’ve covered many of the product management responsibilities, let’s talk about one final piece of product management. And that’s product governance.

Product Governance

For higher-level guidance around the lifecycle of our product, we often turn to product governance.

Now, some of you may wonder what place governance has in our product-driven organizations. In fact, we often hear that product teams are autonomous entities that provide business value on their own. Why do we need an additional layer of leadership?

Well, product governance doesn’t require bureaucracy or command and control structures within your organization. Governance should help teams by providing clear rules and accountability. If you don’t lay out the vision for your product teams or provide a process for accountability, you won’t get the results you’re looking for.

As we mentioned a few sections above, product management focuses on creating products that meet the needs and objectives of our customers. Governance assists in this task by monitoring the outcomes and performance of products. And it ensures that we’re allocating resources appropriately to get the most value out of our product initiatives. This occurs as part of a regular review process that adds accountability to the product lifecycle.

Governance can also help drive the product roadmap, as the leadership present on the governance team often has visibility to market and product knowledge that the product teams might not have. And governance can also provide an additional check that the roadmap is on track to fulfill the product strategy and vision.

Conclusion

As leaders with a clear vision and proper metrics, we can ensure that our product management strategies are effective. We understand that product management isn’t just about delivering work, but about delivering the right work to the right people. And then we can use metrics and KPIs to make sure we continue to go in the right direction.

All this may seem like a lot to take on, which is why Plutora can help. Plutora’s value stream management platform can improve the speed and quality of application delivery, providing the data you need to manage the product and provide governance.