Product Teams & Product People – notes on “How to Create Tech Products Customers Love” – #4/11

Product Teams & Product People - notes on "How to Create Tech Products Customers Love"

Product Teams & Product People

“We need a team of missionaries, not a team of mercenaries.”

John Doerr

Product Teams

The “2-pizza-box” rule indicates a good sizing for product teams: usually 2-10 developers, one product manager and one product designer. One product manager for two teams (or more) is okay as long as there are no more than 10 developers in total.

Spotify is a good example for an organizational setup – teams are named “squads”. Besides the product manager, the product designer and the technical lead other squad-roles are e.g. User Researcher, Delivery Manager, …

Some other companies use the term “triad” to emphasize the product manager / product design / technology lead roles within a team.

A product team is

  • Small
  • Durable (formed for many years) – achieve psychological safety; enables relationships – critical for real collaboration and trust
  • Cross-Functional – allows team access to engineers expertise necessary for innovation
  • Co-Located
  • Measured by Outcome – shift from “release and forget” (feature delivered) to outcome (business result delivered)
  • Empowered
  • Accountable
  • Understands Business context

Product Manager

“Intellectually curious, naturally collaborative, plus plenty of grit.”

Lea Hickman

The Product Manager (PM) is responsible and accountable for the results of the product team. The PM must think like an owner. PM’s should be seen as future CEO candidates for the company by the current CEO. If not, the PM is the wrong person.

PM-work should be around 4 hours per day (Spend your time wisely!). Get rid of the meetings! The Product Owner (PO) part is the administrative part of the role and accounts typically to 10% of the work of the PM.

Good onboarding tool for PM’s: Fill in the product canvas / lean canvas: https://leanstack.com/leancanvas by Ash Maurya, Alex Osterwalder

Productivity Hack by Marty: AIRPLANE MODE – put messengers and other instant communication features into airplane mode  if you want to get work done.

Misunderstanding the role of the PM is the most common reason for the failure of this product development model.

Insider-Tipp by Marty: Subscribe to Ben Thompson’s “stratechery” newsletter (see: https://stratechery.com/).

The PM contributes deep knowledge of … THE CUSTOMER

The PM is the first person in the company to talk to if anybody wants to know anything about customers. Marty’s introduction into his first product role: “talk to 15 customers in the US and 15 customers in Europe”. These visits created the base line for Marty’s knowledge about his customers. He furthermore continued to visit customers and talk to them. It’s important to memorize: “KNOW THE UNKNOWN”. Visiting customers is great for networking inside the company and outside as well.

The PM contributes deep knowledge of … THE DATA

The PM spends the first 30-60 minutes of a day to look into the available product data. The PM is the acknowledged expert on product data.

The PM contributes deep knowledge of … THE BUSINESS

The PM knows all aspects of the business model and the underlying business. The PM knows the dynamics, the various stakeholder. Marty intentionally doesn’t say “The PM acts like the CEO of the product” because the way people act is precisely not the analogy. The PM needs to understand the various dimensions of the business – as the CEO does.

The PM contributes deep knowledge of … THE INDUSTRY

The PM is a domain expert and knows about competitors, trends and does regular SWOT-analysis.

Skills for a Product Manager

The Product Manager should attend these academic classes:

  • intro to computer programming
    help to understand the developers
  • intro to business accounting / finance
    help to understand the business side of the product
  • intro to statistics / data analytics
    help to analyze data

Israel has great product teams: everybody has to do military service and in there people learn to solve hard problems under stress.

“Like me, trust me, listen to me.”

Adi Soesan

Adi used to be a fighter pilot in Israel and was kind to people, earned their trust and soon they started to listen / follow her. PM’s need to do the same: be sympathetic, gain trust from stakeholders and people will start to listen to the PM.

Product Designer

“I love creating solutions, and I am optimistic at heart. If you put those together, you get a tenacious-seeming, “there has got to be a way!” to solve any problem mindset, even if it’s a problem I don’t understand at first, or that keeps morphing.”

Audrey Crane

The Product Designer (PD) is responsible for how customers and users experience the value provided by the product. PD’s are typically specialists in interaction design. They’re also not limited to wireframes and do not focus only on online. The PD is doing ideation work and prototyping with the team, is busy with usability and value testing and designs assets for the delivery.

Tech Lead / Lead Developer

The Tech Lead (TL) is the PM’s key partner and overall responsible for delivery. The TL has to have business sense, coaches engineers on the team, is responsible for the holistic view on the technology solution, is an active contributor to product discovery. The TL typically is a senior engineer, an architect or a dev manager.

Other Roles

  • Delivery Manager: project manager to remove impediments
  • User Researcher: qualitative learning
  • Data Analyst: quantitative learning
  • Product Marketing: interface between sales and product, usually more closely to sales channels – pricing is typically at product marketing – usually provided through external specialists
  • Architect
  • Quality Assurance: manual QA no longer that important – test automation

Delivery Managers take over the project management tasks of the work. The role of a SCRUM Master is part of the Delivery Manager role.

The decision if there is an architect – or not is up to the CTO.

This blog post is part of a series. It summarizes my personal notes of the workshop held by Marty Cagan “How to Create Tech Products Customers Love” from 5th to 6th of June in 2019 in San Francisco.

2 thoughts on “Product Teams & Product People – notes on “How to Create Tech Products Customers Love” – #4/11

  1. Pingback: Product Vision & Objectives - notes on "How to Create Tech Products Customers Love" - #5/11

  2. Pingback: Foreword - personal notes on "How to Create Tech Products Customers Love"

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.