A large amount of what a Product Manager does centers around the elements needed to tell a good story. I break up the tools I use in telling a story into three parts.

Gathering Data - everything about how I get and gather data around products and the problems products either solves or exacerbates.

Using Data - Employing and evangelizing data in KPIs, Product Experimentation and Pivotal strategy conversations.

Communication - Doing the upfront work to create and establish a practice of communication.

Gathering Data

Data! It feels ubiquitous to any conversation about technology. Customers never want you to just provide technology solutions, they want proof that you proof that it truly solved a problem. Leadership needs data at their fingertips, and they are often asking slightly different questions that correspond to using slightly different sets of data and analysis. The quest for data, like technology, is an ongoing pursuit to be better and tell better stories.

General Data Guidelines

• A product is only as good as its data - protecting the sanctity of data is paramount to any product at any stage.
• Quantitative data is not a substitute for good product instinct or qualitative data - the three must be balanced together to create quality products.
• Data is the words you use to tell a story - it is not the story itself. It lies with the product manager to combine how data relates to the Purpose.

Quantitative Data

If the technology is architected well, this is likely the easiest data to obtain about the most number of users. If the technology is not architected well, it should be a defining purpose to have clear data.

• Get access to a tool that provides flexibility in pulling and joining a variety of tables and/or sources of data on demand. This could be a database with Read-Only SQL access or a tool like Looker/Tableau.
• Have a small set of metrics that are monitored weekly or monthly that tell the story on each product. The balance is between having flexibility in the story told without being inundated with too much information.
• Be ruthless about what should be a monitored metric vs. a monitored alert. If the purpose of a chart is to monitor for potential errors, this should be an alert, not a metric. As a product manager, this should be delegated to those that perform a support function at the company.
  • If YOU, the PM, are the support function, it should still be separated as a support function for your support hat. So when the product is large enough, it can be transferred.

Qualitative Data

Qualitative Data can get a bad rap because it is seemingly not as reliable and does not capture as many users as quantitative data. However, the knowledge gained can be more impactful, creating a clear picture of how the product solves a user's problem or creates more problems for a user.

User Interviews