Get product resources, conference updates, along with access to an exclusive Slack channel by subscribing below.
“In order to make data-informed decisions or quantitatively validate ideas, we must first have numbers to work with. Collecting data is no longer an issue – there’s no shortage of tools out there to grab every metric you want. The real issue is lack of focus.” Heather McCloskey shares some ideas on how to know what data to pay attention to and how to focus on the metrics that matter.
If you’re launching a new products or feature you may have difficulty selecting the right metrics because you don’t have a history of data. If you’ve just launched a product you might have a flood of data, but no structure or focus on the right metrics to use. Jim Semick provides several tips for incorporating metrics into your roadmap planning and practice data-driven product management.
“Metrics are a lens into your product’s health and performance. Defining your metrics, therefore, should be as intrinsic to your product development process as defining requirements.” Vince Law introduces the GAME framework – a four step process that you can use to define metrics for any product or feature.
Context is king. The metrics that are important to one product manager working on one type of product may be completely meaningless to a different product manager working on a different kind of product. Richard Holmes put together this list of metrics by product type which will help you pick the appropriate metrics for your product type.
In his keynote at Agile2018, Troy Magennis drove home the point that having the data isn’t enough. You have to tell the story about that data that leads to the right action. This is an important idea relevant for product managers as you look for ways to measure outcome rather than output and find ways to make that focus on outcome meaningful and actionable.
So far, we have concentrated solely on agile development. But there are other practices out there that emphasize many of the same techniques and ultimate benefits, including lean and design thinking. Jeff Gothelf believes that these different practices were productized by trainers and coaches eager to sell their services to company teams. And ironically, rather than ultimately deliver efficiency and collaboration, the bevy of practices to choose from has only made it harder for different teams in a company to work together. The answer is to identify the common components and find unique ways to use them together across your organization, including short development cycles and putting your customer at the center of everything.
Getting comfortable with the components of an agile program is crucial for a Product Manager. These are the jigsaw pieces that define what is being built when things will be delivered, how the team is performing and will also enforce discipline in estimations. This article from the folks at Atlassian gives a nice overview of each of the components.
Scrum is central to an agile process. In it, the role of a Product Owner is defined as a person who has “final authority representing the customer’s interest in backlog prioritization and requirements questions”. However, it’s important to note that the duties of a Product Owner are only a subset of the duties of a Product Manager. The Owner definition stems from a highly technical environment where that person is responsible for making development decisions based on customer feedback, priorities or other factors. Whereas the Manager role involves broader company activities including strategy, marketing, and sales.
This is a good question to start with. In his answer, Roman Pichler summarizes the differences between old school and agile product management. The agile product manager you’ll see is directly involved in development, is constantly refining requirements and regularly speaking with customers.
A big question, as a product person, is whether you are even allowed to participate in a Stand-up. Some argue, as you’ll see in this discussion, that Stand-ups are the domain of the engineers and a product person will not contribute positively to the group. But others argue that it’s essential that the product person participates. How much they should participate is another question — perhaps it’s enough to be a fly on the wall to learn how a project is progressing.