Highlights from my Product Management Course from Stanford University Continuing Studies

Intro

I recently finished the Fundamentals of Product Management Course from Stanford University's Continuing Studies for Winter 2020. The 10-week course is fully online but what distinguishes it from other platforms (Udemy, Coursera) is the emphasis on forming a team and collaborating right from the start. This experience taught me once again about the importance of team dynamics, managing personalities, leveraging strengths, in addition to product knowledge. The highlight of the course was conducting user interviews for potential users of our product. I believe I learnt quite a bit from this course and hence sharing my learning below:

Category-Defining Products

Having spent a majority of my career building multiple products that never reached market-fit (i.e. failed) I have to specially thank the course instructor for putting those failed product souls to finally rest in their graves. I thought we were aiming for the moon: Now I realize, we were aiming at empty space (No market). Building a product that doesn't have any competitors ("We will be the first") or no current products that are solving the exact same problem, you have what is called a Category-defining product.

In case of Category-defining Product it is more than likely that there is no market for this product, even for the MVP.

To tackle such a product (or rather understand the problem) I would suggest spending all the time on User Research and understand the reasons for no Products in this space. It could be Market Dynamics, Lack of a strong user need, and a roadblock in the form of regulation or even technology. It could also be that the alternate business model we selected, popularly marketed as 'differentiator', is completely contrary to the way value is generated within that particular Industry and has a feeble chance of success. Few exceptions though are Uber and AirBnb, which were essentially category-defining. It all depends on how far one is willing to go - In terms of money and time.

Problem vs Product

Lots of executives and sponsors show enthusiasm for an idea of a Product while hardly spend any time about the problem. To build the right product, it has to be the other way round. The course repeatedly emphasized about consciously turning our Product-obsessed minds into Problem-obsessed ones. The instructor quoted the below:

Fall in love with the Problem not the Product

I believe the challenge here is that very few teams posses the capability or even patience to structure, define a problem and research it in order to validate it at the user or market level, before proceeding to build an MVP. Define the problem, identify the users, conduct user research to understand their ways of dealing with the problem (those with the pain would have already found a hack to solve it), create a low fidelity MVP for User Validation, launch a paid campaign on appropriate channel for Market Validation, increase MVP fidelity, rinse and repeat.

Team Chemistry

Boy is this one tough! Having worked in teams as part of my regular job and working with a team as part of course it was at least a different experience. Even in a team full of Product hungry learners, all willing to get their hands dirty, it was still a challenge to manage opinions and reach agreements at each step. The difference here was that everyone expressed their views without fear, at least I made sure that each member spoke their mind. I clearly realized in this course that it takes quite a bit of time for team formation and the short-course span wasn't enough.

Team formation is a very gradual process

However, there was always a member who was pitching in more when everyone else was busy or were not ready for the task. Every time we were struck someone would take the lead to move the group forward. It was like no one on the team wanted us to fail!

Focusing on User Research

This could be a separate blog post of it's own. After collective brainstorming, building Empathy Maps and User Personas, all that my team could describe about the potential users for our product was that they used the Internet! We could not agree on anything else about the user characteristics or personas. This made the potential user segment very broad and subsequently most people we interviewed did not exhibit/express a real pain with the problem though they all expressed concerns about the problem. At least, it was a fun experience interviewing random people at Starbucks since every customer there was an internet user. The learning was

The problem has to be solved for a smaller defined segment that has the most need (popularly referred to as a 'beachhead') before trying to solve for a large population

By using tools like Design Thinking and Jobs-to-be-done framework we narrow down the segment of potential users that most likely have the pain and establish the collective characteristics and traits also referred as Psychographics, which greatly aids in identifying the right users to research.

Others (but still no less important)

1. No need to - "Get out of the building" as famously quoted by Steve Blank. Stay in the building and use online tools (lookback.io, usertesting.com) for User Research.
2. KPIs or Metrics, critical to defining success, have to be - Simple i.e. not arrived through complex calculations, Not influenced by external factors (a key point to remember), Representative of the Product, Should either increase or decrease.
3. There always a fire hose of ideas out there that have to be kept in check by using a right prioritization process that everyone collectively agrees.
4. Finding the Right Market is always the key to winning (market-fit) as mentioned by Andreessen Horowitz even with a mediocre team and and a so-so product. No matter the talent and chemistry of a team and the amazing product they can put together, it can easily get crushed by a mediocre market [1]
   

 

References

1. Pmarchive - The only thing that matters