Product Management Overview: Part 2 of 3

The articles on product management has three parts:

  • Part 1: Product Management (PM) role, Becoming a PM, Product life cycle, and understanding the company.
  • Part 2: Creating an opportunity hypothesis, validating a hypothesis, and taking an idea into action.
  • Part 3: Working with design, engineering, and marketing. Finally, completing the product lifecycle.

In the first part, we went through PM role, PM life cycle, and strategically understanding the company. In this part we will go through creating opportunity hypothesis, validating hypothesis, and taking an idea into action.

Creating an opportunity hypothesis:

There are ways like iterative progress or a big change step. Depending on the situation, a PM should decide if an incremental change is appropriate or if building a new product from scratch is appropriate.

  • Goals: It is important to establish the goal for the product. A product can be built in a iterative way or as a one big release, depending on the goal.
  • Quantitatively finding an opportunity hypothesis: Quantitative reasoning involves data analysis, to find the next approach. Qualitative reasoning involves understanding the vision of the product or the intuition based approach to determine the best step for the customers.
  • Metrics and analysis: metrics and analysis is important to determine the next steps for the product.
    • AAARR metrics: it is an acronym developed by McClure for the products. It stands for:
      • Acquisition: how users visit your product
      • Activation: a users’ first experience with your product
      • Retention: a user’s liking to use the product again
      • Referral: a user’s liking of the product to refer it to other person
      • Revenue: a user finds the product useful enough to pay for it
  • Surveys and customer interviews are helpful to assess the need and current situation of the product.
  • Intuition: intuitions are good but it is important to understand from personas’ point of view. Will this idea help a user? If yes, how?
  • Vision for the product is important and is developed by the team.
  • Team ideas: A PM should be a team player who listens to all the ideas and helps making the right decision for the product.
  • R&D: it is important to research an idea and plan to build it with the assessment of engineering and other feasibilities.
  • The competition: understanding the competition is important, to decide the approach for the product. For example, for a technical blog, there is competition with many companies and bloggers. Should a new technical blog be one of many of offer something different that others are not offering? Or should the quality be high? How will a new technical blog make the position in the market?
  • Business model and value proposition: Analyze how a product fits into the business and how the product provides the value to the customers. Here are key points about business model:
    • Key partners: outside the company, who are the key partners who make the business model work.
    • Key activities: what are the key activities. For example, a blog company’s key activity maybe content writing and website publishing.
    • Key resources: key resources could be human, physical (hardware), and intellectual properties.
    • Value propositions: what value a product provide to a persona, is the value proposition.
    • Customer relationships: this is about managing the relationships with the customers.
    • Channels: Channels are the ways a company reaches out to their customers. For example, for a blog company, Facebook, direct emailing, twitter, and other means could be channels to reach out to customers.
    • Customer segments: these are categories of the personas that the product will serve.
    • Costs structure: this is about finding the cost to maintain the product.
    • Revenue streams: this is about ways how the product will get the revenues. For example, technical books could be useful to generate revenues.
  • External affairs: sometimes, there are external affairs as well. For example, what if a client offers a multi-year maintenance contract, if certain features are added per a client’s needs?
  • Using Kano model to find opportunities: Per Kano model, a product needs three things, to be successful over time: 1. Value, 2. Quality, and 3. Innovation. As per this principle, there are three features:
    • Basic features: these are features expected from a product.
    • Performance features (satisfiers): these are features like how the app performs.
    • Excitement features (delighters): these are surprising, unexpected, wow features.

Over the period of time, each feature moves down. Excitement features becomes performance feature. Performance features become basic features.

Validating your hypothesis:

The next thing is to decide if it is the right thing to do. Every idea has an opportunity cost. Below are options s to validate a hypothesis:

  • Customer development: it is a process of reaching out to existing or new customers, to know their pain points, goals.
  • MVP or A/B testing: There maybe a decision to build an MVP. Or, maybe use an A/B testing. A/B testing is an approach to compare two sets of something. If idea is validated to be a good idea, next step is to plan for building it.
  • SWOT analysis: SWOT stands for Strength, Weakness, Opportunity, and Threats. It helps to identify what’s important to focus on. To do a SWOT analysis, identify goals and success criteria.
  • Internal validation: it is about asking key questions to understand if a product’s vision is aligned with the company’s vision.
  • External validation: it is helpful to perform external validation. It means seeking feedback from customers about the product.
  • Other ways: Interviews, Surveys, Analyzing data, Experiments, and A/B tests.

From idea to action:

Blow are key points to take a product from the idea to actions:

  • Why new ideas struggle: there may be chances that customers no longer need the new feature in the product that you planned for. It is very helpful to anticipate next steps and avoid assumptions, as much as possible. Suppose my product is a eBook on work skills for IT professionals. If it takes six months for me to write the book, what if there are better options available in the market in the next six months? In this example, I should list out assumptions and address those.
  • Working backwards for the future feature. Imagine your product is released and you are writing product reviews, product release, and product FAQ sections. These future preparation will help to assess the product. For example, if a writer is planning to write a book, what if he/she writes why and who should read the book, how this book is helpful to readers, and how it is different from other books.
  • Plan for an MVP: Minimum Viable Product (MVP) does not mean an incomplete product. It is a great exercise to prioritize what minimum features will help the customers. Then, over the period of time, iterating and adding more prioritized feature helps. For example, if I am writing a book, identify minimum required areas to address first in the book. I can create a second book later, with additional details.
  • MVPs and Plussing: MVP concept forces us to prioritize to the most important items. Plussing is a concept of adding a surprising element to it. This plussing concept has to be completely in-line with the core model. For example, if I am writing a book on technical product manager interviews, my MVP would be to cover the topics that the readers expect. The core idea of the book is to prepare candidates to clear an interviews. A plussing on it could be to share general tips on resume writing and networking.
  • Communicating via a Product Requirements Document (PRD): A PRD covers the features of the products to be built. This should be helpful to all stakeholders. A PRD should include what’s covered and not covered in it. It should include. In a waterfall approach, a PRD is a detailed document. In a lead development approach, it is a lighter weight document that will be iterated frequently. In any case, a PRD is a live document. For a project scope items, a PRD should be written. For bug fixes or an enhancement, a PRD may not be needed and such item can be covered via a ticket or a similar system. Some other points: we humans are wired to learn in stories. So, writing the requirements in the form of stories is helpful.

Next, we will go through part 3: Working with design, engineering, and marketing. Finally, completing the product lifecycle.


  • The Product Book: How to Become a Great Product Manager by Product School, Carlos Gonzalez de Villaumbrosia, et al.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s