Building Successful Products: The Role of the Product Manager.

Laura’s path to and in product management: 

• Originally wanted to be in software, but not as a programmer, so had to figure out how to change her profile to be able to do this. MS&E was the answer, graduated at the height of the dot.com boom in the late 90s.
• Has been in product for 25 years, mainly B2B and B2B2C.
• Recently focused on the high growth stage.

Why Product Management (PM) is important:

• CB insights on why startups fail - most reasons are product related, eg, no market need, mistimed, poor product.
• The PM has to build a feasible, viable and desirable product that people want and/or need and will use, that the engineers can build, and that will make money for the company.
• Best analogies:
  • PM is the orchestra conductor, making sure that cross functional teams are aligned, but without controlling/directly managing them.
  • PM is the janitor, fixing anything that goes wrong, or finding the right person to fix it.

Important concepts within PM:

• Product-market fit: 
  • Read: The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback by Dan Olsen 
  • Need to validate hypotheses. 
• Iteration and validated learning: 
  • Discover, by validating hypotheses.
  • Deliver, by measuring, learning and iterating - ideally on a quick cycle. This is easier with B-C than with B-B, where your product has to be embedded to be valuable.
• Reworking and pivoting:
  • If prove hypothesis wrong, need to pivot. This is why it’s so important to work on validation first.

Product lifecycle: you might be responsible for one part of the product (bigger company) or the whole thing (smaller company):

• Discovery phase:
  • Identify a problem. Figure that out before getting enamored with a product idea.
  • Evaluate the opportunity – not every problem needs to be or should be solved- people might not care that much.
    • Validate the need with the right customers. Lots of questions to ask here: what is the need? Who has this need? How will we reach them? Do customers think this is an important need? How big is the market and when? Are others trying to solve it? Why us?
    • Don’t ask customers what they want, ask what their problem is, or how are they doing their tasks already – what does that experience look like, to figure out where it could be streamlined or where the friction is. Observe people.
    • Avoid becoming a custom development shop for big, key clients.
  • Design the solution: this is where you move from the product space to the solution:
    • Figure out a minimum viable product – without oversolving! 
      • Very easy to spend too long setting requirements, or cramming too much in making it too complicated and too time consuming to actually create something.
      • Focus on minimum functionality that will provide enough value to the customer. You’ll start getting feedback and can keep iterating.
    • User experience:
      • User stories and profiles. 
      • Remember user and buyer might not be the same people.
      • Good product people think about all aspects of design: 
        • Visual design (what people will see). 
        • Interaction design, 
        • Information architecture, 
        • Conceptual design
    • Early validation: 
      • You’ve still not built anything at this point – you’re presenting sketches and wireframes and mockups. 
      • Get feedback on functionality and flow. 
      • Prototype. 
      • Do the validation with actual target customers. Your family and friends love you and will say your work is awesome.
• Delivery phase. 
  • PM’s don’t build the product.
  • The product is not “done” once the engineers are finished. The PM has to get the ‘whole product’ to market.
  • Delivery of the whole product – everything available for the customers/users:
    • Your generic problem by itself might not solve the problem. PM’s also need to think about and work on, for example:
      • Support, 
      • Distribution, 
      • 3rd party add ons, 
      • Installation, 
      • Configuration, 
      • Integration, 
      • Training
• Measuring and learning phase: 
  • Products will fail, or have multiple iterations, which brings you back to discovery phase again. 
  • Things to measure: ideally, you’ll have built in a way to do this:
    • Business success, 
    • Customer success, 
    • Product delivery, 
    • Product functionality 
    • Performance 
• Sunsetting phase:
  • Eventually a product has served a purpose, and has to be sunsetted. 
  • At a large company, you’ll need to know how to wind it down/end of life the product and that is a whole process too.

What are companies/hiring managers looking for with PM hires?

• Curiosity: always ask questions - are there more effective ways to do things?
• Enthusiasm: for the product, for the team. Someone who’ll be proactive.
• Humility/open mind: someone who’ll take in info, and not jump to conclusions right away.
• Good communicator:
  • Listening skills: listening to customers and stakeholders is critical.
  • Presentation skills: you need to get people who don’t report to you to follow you, so they need to understand the vision and business perspective. And you need to present the vision to many stakeholders.
• Ability to deal with unhappy people: you know you’re successful if everyone is equally unhappy with you, because you’ll never be able to please everyone, and you have to say “no” or “not yet” to people all the time.

Recommendations to get started in this career?

• This depends on where your passion lies, for whether a small or big company will work best for you.
• Some large companies have programs for people straight out of school, and will train them.  
• Associate PM roles, where you’re under someone else and will be doing something like data analysis first – these roles are easier to get into.
• Smaller companies can’t have these training programs or Associate roles, they’ll bring in people from other areas of the company who don’t need training about the company or product. Look for roles in teams like tech support, or implementation. You’ll learn the clients and product there, so you can later move into product. Find the angle where you can have the most value and distinguish yourself as a strong performer.
  • If you do this, be flexible so that you don’t inadvertently try to blend these roles when not appropriate - eg, when moving into PM from engineering, know that you’ll not be telling the engineers how to build the solution, even though you have that background. You’re telling them what needs to be built  and trusting them to figure out ‘how’ to build it from the technical perspective.
• V early startups don’t have a PM role: it’s what the co-founder or CEO does. As the company grows, and their attention is forced to move elsewhere, a PM role/team will need to be created. The co-founder/CEO will look for people within the company.