There's too many tiny chapters in this book to warrant me typing the names of them all.
- Strong tech-product companies don't just tweak and optimize existing products (value capture), but develop each product to reach its full potential
- source of ideas is important; dangerous to build sales-driven specials and stakeholder-driven products
- typical company has flow chart of ideas --> "biz case" --> roadmap --> requirements --> design -- build --> test --> deploy
- at idea stage, can't know how much money will make or how much it will cost. Depends entirely on how good solution turns out to be
- critical lesson in product is knowing we can't know
- Two inconvenient truths about products
- At least half of ideas are just not going to work out
- Even w/ ideas that do prove to have potential, typically takes several iterations to get implementation of idea to point where it delivers necessary business value (time to money)
- w/ sales and stakeholder-driven organizations, don't even have product managers; it's really a form of project management; it's about gathering requirements and documenting them for engineers
- similar for design; way too late in game to get real value of design
- engineering gets brought in way too late; engineers typically the best single source of innovation
- key benefits of Agile enter the picture far too late, meaning sacrificing most of the value of the process
- process is very project-centric; company funds projects, staffs projects, etc. Projects are output, but product is outcome
- biggest flaw is this approach delays all risk to end, means customer validation happens way too late (only after test stage)
- Strongly prefer teams that
- tackle risks up front
- Value risk = whether customers will buy it
- Usability risk = whether users can figure out how to use it
- Feasibility risk = whether engineers can build what we need w/ time, skills, and technology that we have
- Business viability risk = whether solution also works for various aspects of our business (sales, marketing, finance, legal, etc)
- products are defined collaboratively, rather than sequentially. Product, design, engineering work side by side, in give-and-take way
- focus is on solving problems, not implementing solutions
- tackle risks up front
- output of product discovery is a validated product backlog, that answers the 4 key questions (4 risks listed above)
- MVPs should be prototypes, not products. They're not something that ships to production
- Team composition
- A product team feels real ownership for a product or at least a substantial piece of a larger product
- Key to team composition is alignment btwn engineering and product management; heads of both normally get together to define size and scope of teams
- Never perfect way to carve up pie; always tradeoffs. Decide what's most important to you [dmr: Principles Stack for Org Structure]
- Aim to achieve team autonomy by minimizing dependencies btwn teams
- PM key responsibilities
- Deep knowledge of the customer
- Must be undisputed expert on the product [dmr: inside (what's possible/how works? or just outside?]
- Deep knowledge of the data
- Deep knowledge of the business. Need to know stakeholders, learn the constraints they operate under
- Deep knowledge of the market and industry
- To prepare for the role
- Become expert in users and customers. Share openly what you learn, becoming team and company's go-to person for understanding anything about your customer
- Build strong relationships w/ key stakeholders. Convince them you understand the constraints they operate under, and you will bring to them solutions you believe will work w/in those constraints
- Become an undisputed expert on the product and industry; again, share openly
- Need to engage directly w/ engineers every workday. Either soliciting ideas and input for items you're working on in discovery, and/or they're asking you clarifying questions on items they're working on delivering to production
- "If...product managers are constantly asking developers to look at the code to tell them how the system really works, then you're probably missing a principle product manager". Similar to CTO, more of a chief IC role than people lead. They regularly review work of various PMs and product teams, identifying and helping to resolve conflicts
- For head of product role, looking for 4 key competencies: team development, product vision, execution, product culture
- Why roadmaps exist (despite being terrible)
- Because management of company wants to make sure teams are working on highest-business-value items first
- Because management of company sometimes needs to make date-based commitments, and the roadmap is where they can see and track those
- Teams need to have necessary business context. To provide it, need
- Product vision [dmr: where going] and strategy [dmr: how to get there]. Each product team may have own area of focus, but supposed to come together to achieve product vision
- Business objectives [dmr: how we know we're making progress]
- OKRs: consider the KR to be a specific, measurable rephrasing of the O. E.g., given objective to "Dramatically reduce the time it takes for a new customer to go live", one KR could be "Average new customer onboarding time less than three hours"
- "It's management's responsibility to provide each product team w/ specific business objectives they need to tackle." Improvement over flow chart from top is this focuses on business outcomes, not product ideas
- To address occasional need for hard date, make high-integrity commitments
- Can still create roadmap from this approach, but items are stated as the business problem to solve, rather than feature/project. Called "outcome-based roadmaps"
- idea is not that every product team has its own product vision; organization should, product teams in org help to contribute to making that vision a reality [dmr: what does the supporting artifacts look like here? How to make that high-level org vision connect to each team, and make it clear to them the importance of what they're doing?]
- "Leadership inspires and sets the direction, and management helps us get there."
- 10 key principles for coming up w/ effective product vision
- Start w/ why. Articulate purpose
- Fall in love w/ the problem, not w/ solution
- Think big w/ vision [dmr: ~5 years out]
- Disrupt yourself if you need to
- Needs to inspire
- Determine & embrace relevant and meaningful trends (mobile, AI, etc)
- Skate to where puck is heading
- Be stubborn on vision, flexible on details
- Realize that any product vision is a leap of faith. Will take years to know if right
- Evangelize continuously and relentlessly
- Product vision = future you want to create; Product strategy = path to achieving vision; Product principles = speak to nature of the products you want to create
- [dmr: what we want to achieve = outcome; what to do = output; how we'll do it = input]
- "Much of the key to effective product discovery is getting access to our customers without trying to push our quick experiments into production."
- Purpose of product discovery is to address the 4 critical risks
- Value risk = Will the customer buy this, or choose to use it?
- Usability risk = Can the user figure out how to use it?
- Feasibility risk = Can we build it?
- Business viability risk = Does this solution work for our business?
- Easiest to tackle are usability and feasibility. Value risk is higher, and business risk is messier. Examples include:
- Financial risk - can we afford this solution?
- Business development risk - Does this solution work for our partners
- Marketing risk = Is this solution consistent with our brand?
- Sales risk = Is this solution something our sales staff is equipped to sell?
- Legal risk = Is this something we can do from a legal or compliance perspective?
- Ethical risk = Is this solution something we should do?
- Product discovery = Framing, Planning, Ideation, Prototyping, Testing,
- Customer Letter Technique
- Similar but different from Amazon-style press release [dmr: imo, superior b/c it cuts out the bullshit, focuses on the customer value]
- Idea is to describe benefits in format of a customer letter written from hypothetical perspective of one of your product's well-defined user or customer personas
- Letter, sent to CEO from a very happy and impressed customer, explains why they're happy & grateful for the product/redesign/feature. Describes how it changed/improved their life
- Letter, sent to CEO from a very happy and impressed customer, explains why they're happy & grateful for the product/redesign/feature. Describes how it changed/improved their life
- Reference customer = a real customer running your product in production, paying real money for it, who is willing to tell others how much they love your product voluntarily and sincerely
- Aim to discover & develop set of reference customers in parallel w/ discovering & developing the actual product
- Don't need them for feature / minor projects. These are for larger efforts, e.g. creating new product/business, taking n existing product to a new market or geo, or a redesign of a product
- Key number is 6 reference customers. Enough to instill confidence
- Must be similar customers. If targeting multiple markets or geos, need distinct groups of reference customers for each
- Looking for prospective customers that truly feel the pain and are near desperate for solution we want to build
- Important to screen out technologists (see: Crossing the Chasm); people who are interested in product b/c it's cool new tech, not b/c they desperately need business value
- Need them to be willing to spend time w/ product team, test early prototypes & help team ensure product works well for them
- Benefit to customer is they get real input
- Customer interviews
- Trying to understand if customers are who you think they are, if they really have problems you think they do, how they solve the problem today, and what it would take for them to switch?
- Bare minimum is spending 2-3 hours on customer interviews every week
- Not trying to prove anything. Just understand and learn quickly
- Be sure to talk primarily to people in intended target market
- Prep: beforehand, be clear what problem it is you think they have, how you'll confirm or contradict that
- Designer drives (usually have most training here), PM takes notes, developer(s) observe
- Ask open-ended questions, and try to learn what customer is doing today (not what they wish they were doing)
- Debrief w/ colleagues to see if heard same thing
- Principles of Prototypes
- All prototypes should require at least an order of magnitude less time and effort than eventual product
- key benefit is to force you to think through a problem at substantially deeper level than if just talk about or write something down
- powerful tool for team collaboration
- primary purpose of prototype is to tackle one or more product risks (value, usability, feasibility, viability)
- Feasibility prototype
- May want to address feasibility concerns, e.g. Algorithmic, Performance, Stability, Fault tolerance, Use of new tech, Use of third-party component/service not used before, use of legacy system not sued before, or dependency on new or related changes by other teams
- This type of prototype (as opposed to most others) should actually be code. Not commercially viable shippable product; just write enough code to determine feasibility
- Intended to be throw-away code. No UI, no error handling, etc
- Need to emphasize w/ engineers that this is discovery work, not delivery work
- Testing Feasibility
- Do we know how to build this?
- Do we have the skills on the team to build this?
- Do we have enough time to build this?
- Do we need any architectural changes to build this?
- Do we have on hand all the components we need to build this?
- Do we understand the dependencies involved in building this?
- Will the performance be acceptable?
- Will it scale to the levels we need?
- Do we have the infrastructure necessary to test and run this?
- Can we afford the cost to provision this?
- Consistent Innovation = the ability of a team to repeatedly add value to the business