I own this book and took these notes to further my own learning. Taking notes, publishing them and re-reading them allow me to flatten my forgetting curve. If you enjoy these notes, I highly encourage you to do the same, buy this book here and take your own notes.
-
Good product teams
- Focus on, measure and celebrate outcomes (not output)
- solve customer problems in ways that work for business.
- missionary-like passion (not mercenaries)
- Look for product ideas in their objectives (e.g. OKR’s), observing customers struggle, analyzing data and seeking to apply new technology to solve real problems.
- Know all stakeholders and business constraints while testing something
- Know how to rapidly try out product ideas to determine which ones are truly worth building
- Love to have brainstorming discussions with smart thought-leaders from across the company.
- Are constantly trying out new ideas in order to innovate
- Know what interaction design is
- Implicates Engineers during the discovery step and show prototypes way before the sprint planning
- Engage directly with customers every week to understand their problems and test new ideas
- know that many of their favorite ideas won’t end up working for customers, and even the ones that could, will need several iterations to get to the point where they provide the desired outcome.
- Find the right techniques to improve speed and rapid innovation (quality of work > quantity)
- Monitor how the product is used and iterate
- Provide a constant stream of small releases
- Customer obsession > competitors obsession
-
Good PM (good to know for interview)
- Passion for product and solving customers problem
- Creative: think outside of the box to solve a business problem
- Persistent: pushing companies beyond the comfort zone, constant communication, building bridges across functions
- Expert of users and customers
- Strong relationships with stakeholders: understand their constraints and bring them solutions
- Become the undisputed expert of your product and industry
-
Product Risks
- Value risk (will people buy it, or choose to use it?)
- Usability risk (can users figure out how to use it?)
- Feasibility risk (can we build it with the time, skills, and technology we have?)
- Business Viability risk (will this solution work for the various dimensions of our business?)
-
Agile
- 1st Truth is that half of our ideas simply won't work or won't deliver what we hope, the best team assumes that at least 3/4 of their ideas won't perform
- 2nd truth is called time to money, it takes several iterations to bring real value to the business
- Most important is to know that we don't know, we can't predict how much revenue it will make
- Strong tech companies require consistent product innovation, that means constantly creating new values to their customers and for their business
- “Engineers are the best source of innovation, if you use them just for coding you are getting only half of the value”
- Projects are outputs and product is all about the outcome
- Objectives > Discovery »> Delivery
-
Outcome-based roadmap:
- Its all about outcome rather than output
- Product roadmap: each item is stated as a business problem to solve rather than the feature or project that may or may not solve it.
- You solve business problem rather than building features
- OKR system
-
Product vision vs strategy
- The product strategy is our sequence of products or releases we plan to deliver on the path to realizing the product vision.
- The difference between vision and strategy is analogous to the difference between good leadership and good management. Leadership inspires and sets the direction, and management helps get us there. Most important, the product vision should be inspiring, and the product strategy should be focused on.
- The product vision describes the future we are trying to create, typically somewhere between 2 and 5 years out.
- Jeff Bezos says, you want to be “stubborn on the vision, and flexible on the details.”
- PV is important for having a team of missionaries instead of mercenaries
- The product strategy is our sequence of products we plan to deliver on the path to realizing the vision.
- I encourage teams to construct a product strategy around a series of product-market fits. ==> “So, we use prototypes to conduct rapid experiments in product discovery, and then in delivery, we build and release products in hopes of achieving product/market fit, which is a key step on the way to delivering on the company's product vision”.
-
Product vision
- Start with why
- Fall in love with the problem and not the solution
- Think big and be ambitious
- Don't be afraid to disrupt yourself
- Inspire other: missionaries vs mercenaries
- Embrace the relevant and meaningful trend
- Identify the things that are changing, balance realism vs conservatism in the future change
- Be stubborn on vision but flexible on details ( J Bezos)
- Hire people that are passionate about this vision, advocate
- Evangelize continuously
-
Product strategy
- Focus on one target market or one persona at a time
- Aligned with the business objective
- Aligned with sales and go to market strategy
- Obsess over customers and not competitors
- Communicate the strategy over the company
-
Product objectives: OKR HP: MBO, “management by objectives”
- Objective = quali and KR = measurable
- KR = measure of business results and not output or task
- 1-3 objectives max
- Track the progress
- Make the team accountable for the results
- Be transparent
- Be ambitious, 70% rule of thumb
-
Sell the dream, evangelize
- Use prototype
- Show the customer pain
- Share the vision
- Share the learnings
- Share credit but take responsibility for the miss
- Learn how to give a great demo
- Be excited and show enthusiasm
- Be an undisputed expert in customers, industry, competitors, trend
- Spend time with your team
-
Product Discovery
- Input = prioritize good ideas –> Output: backlog
- The purpose of product discovery is to address these critical risks: Will the customer buy this, or choose to use it? (Value risk) Can the user figure out how to use it? (Usability risk) Can we build it? (Feasibility risk) Does this solution work for our business? (Business viability risk)
- Marc Andreessen, “The most important thing is to know what you can't know,” and we can't know in advance which of our ideas will work with customers and which won't.
- Our goal in discovery is to validate our ideas the fastest, cheapest way possible.
- If the first time your developers see an idea is at sprint planning, you have failed. We need to ensure the feasibility before we decide to build, not after.
- Validate the business viability of our ideas during discovery, not after.
-
Small feature: Opportunity assessment technique
- Business objective
- Key results (success assessment)
- Customer problem
- Target market
-
Big change: customer letter technique
- Letter of a customer super happy to a CEO + reply of the CEO
-
Product-market fit
- Product/market fit shows up in terms of happier customers, lower churn rates, shortened sales cycles, and rapid organic growth.
- Sean Ellis test - Hacking Growth - The choices are “very disappointed,” “somewhat disappointed,” “don't care,” and “no longer relevant because I no longer use.”. The general rule of thumb is that if more than 40 percent of the users would be “very disappointed,” then PMF
-
MVP:
- concierge test is a relatively new name to describe an old but effective technique. The idea is that we do the customer's job for them—manually and personally.
- Wizard of Oz prototype combines the front‐end user experience of a high‐fidelity user prototype but with an actual person behind the scenes performing manually what would ultimately be handled by automation.
- build things that don't scale philosophy of product discovery.
-
User interview:
- Customer interviews require some user research methodology
- There are three important cases you're looking for: (1) the user got through the task with no problem at all and no help; (2) the user struggled and moaned a bit, but he eventually got through it; or (3) he got so frustrated he gave up. Sometimes people will give up quickly,
- Act like a parrot. This helps in many ways. First, it helps avoid leading. “Will clicking on this make a new entry?” and you ask in return, “You're wondering if clicking on this will make a new entry?”
- Summarize the learning and send it to the team
-
Stakeholder:
- Share learnings With this as a foundation, the key technique is to spend one‐on‐one time with the key stakeholders. Sit down with them and listen. Explain that the better you understand their constraints, the better your solutions will be. Ask lots of questions. Be open and transparent.
- Stakeholder demand: always listen and show your interest, don't stop the person, try to understand the problem, then show him what you think and prioritize
-
Increase the ability to innovate
- Customer-centric that meet the needs of the business
- Compelling product vision
- Product strategy (product prioritization)
- Strong products managers
- Engineers in discovery
- Corporate courage
-
What decreases the velocity of a team
- Technical debt
- Lack of strong PM
- Lack of delivery management
- Infrequent release cycles
- Lack of product vision and strategy
- Not utilizing the product designer in discovery
- Changing priorities
- Consensus culture