👋🏻, I'm Julia.

Part 1: Lessons from the top companies

• 3 overarching principles of how to build product (pg 24)
  • Risks tackled up front, not at the end. Risks include value risk (will customers buy it), usability risk (will users figure out how to use it), feasibility risk (can the engineers build it with the available resources) and business viability risk (whether it works for the other various aspects of the business e.g. sales, marketing, finance etc.)
  • Products are defined and designed collaboratively, not sequentially.
  • It’s about solving problems, not implementing features. All about business results.
• There are 2 essential high-level activities in all product teams
  • To discover the product to be built; and (discovery)
  • To deliver that product to the market (delivery)
• Be aware of whether your team is actually Lean and Agile. Most product development processes are actually waterfall. This is because product needs to be defined holistically to include all aspects of interaction with the customer. (Pg 25)
• Product discovery purpose is to separate good ideas from bad. Need to get answers to 4 critical questions
  • Will the user buy this or choose to use it?
  • Can the user figure out how to use this?
  • Can our engineers build this?
  • Can our stakeholders support this?
• Product delivery - can we get to product-market fit?
  • What’s the smallest actual product that meets the needs of a specific market of customers?
  • This about MVP as Minimum Viable Prototype. If you’ve developed a product, you spent too much time on this. (Pg 29)

Part 2: Product team

• Cross-functional team of missionaries, not mercenaries.
• Typical comprises product manager, designer and 2-12 engineers.
• Given clear objectives, and are empowered to problem solve to meet those objectives (they must have autonomy). Accountable for the results.
• No hierarchy.
• Co-located where possible.
• Read about each of the individual roles from pg 41.
  • Product manager is like the CEO, but without the hierarchy.
  • Designers need to sit next to product manager to discover the right product.
  • Software engineers need to be involved in the process of discovery as well, not just delivery, otherwise you are not making the most of them.

Part 3: The right product

Product roadmaps

• Product roadmaps typically lead to poor business results because of 2 inconvenient truths about product.
  • At least half of our product ideas are not going to work, for reasons like...
    • A lack of value for customers, lack of usability, not feasible and no business viability.
  • Then even if ideas do prove the above, it typically takes several iterations to get to the point where it delivers the expected business value (time to money).
• Product roadmaps are essentially used to:
  1. Help management ensure teams are working on the highest business value items first; and
  2. Give management a sense of timelines so they can make date-based commitments, so any alternative would need to solve for these needs.
• Remember that we need to solve the underlying problem, not just deliver a feature. We need to make it about outcome rather than output.
• We want to get to autonomous product teams. For this, teams need to have necessary business context. The 2 main components of this are:
  • Product vision and strategy - big picture of what the organisation as a whole is trying to achieve (see next section below); and
  • Business objectives - prioritised, for each product team. (Pg 116)
• Business objectives need to come with measurable key results. It is management’s responsibility to provide product teams with business objectives, but instead of prioritising product ideas, we need to prioritise business results. This should help alleviate the need for point 1 of product roadmaps.
• To help with point 2, use the concept of high-integrity commitments, specifically for situations where we need to commit to a date of specific deliverable. (Pg 118)
  • Product team needs to be given some time to do product discovery so they can verify what needs to be delivered to solve the customer’s problems.
  • After discovery, they need to be willing to commit to dates and deliverables so that other parts of the business can operate effectively.
  • These commitments should be minimised as much as possible, but if committed, should be stuck to.
• Putting it together, modify product roadmaps so each item is stated as a business problem to solve rather than a feature (outcome-based roadmaps). Put deadlines only on items with a true date constraint.
• Benefits of this are:
  • Teams are more motivated as they are free to solve the problem in the best way they see fit. Missionary vs. mercenaries.
  • The feature must solve the business problem as measured by the key result. If the feature doesn’t do this, they need to try a different approach.
  • This model embraces likelihood of an initial idea / approach not working out.

Product vision and strategy

• The product vision describes the future we are trying to create, typically 2-5 years out. It should be inspiring. The 10 key principles are (pg 129):
  • Start with why.
  • Fall in love with the problem, not solution.
  • Don’t be afraid to think big.
  • Don’t be afraid to disrupt yourselves.
  • Needs to inspire.
  • Determine and embrace meaningful trends.
  • Skate to where the puck is headed.
  • Be stubborn on vision, but flexible on details.
  • Realise that it is a leap of faith (otherwise it’s not ambitious enough).
  • Evangelise continuously and relentlessly.
• The product strategy is the sequence of products / releases we plan to deliver on the path to realising product vision. The 5 key principles are (pg 133):
  • Focus on one target market or persona at a time.
  • Needs to be aligned with business strategy.
  • Needs to be aligned with sales and GTM strategy.
  • Obsess over customers, not competitors.
  • Communicate strategy across the organisation. Everyone needs to be aligned on which customers we’re focused on now vs later.
• To help figure out how to prioritise which target market to focus on, there are 3 critical inputs to your decision (pg 126):
  • Total addressable market (TAM) - big is better than small, all things being equal.
  • Go to market (GTM) - can we leverage existing sales channels?
  • Rough estimation of how long it will take (time to market - TTM).
• The product principles speak to the nature of the products you want to create.

OKRs

• Consider using OKRs as a management tool since:
  1. It doesn’t tell employees how to do something, just what to do; and
  2. It measures business results, not outputs.
• See pg 139 for critical points.
• For product team, focus on the organisation’s objectives and objectives for each product team. Don’t let personal or functional team objectives confuse the focus. If there are conflicts, they need to be prioritised at a leadership level, but generally, OKRs should be focused at the product team level since they are business objectives. (Pg 145)
• Product teams must track progress weekly.
• Differentiate between high-integrity commitments which are binary, vs normal objectives which are on a 0-1 scale.

##Part 4: The right process

Product discovery

• Remember that the purpose of product discovery is to address the critical risks of value, usability, feasibility and business viability. And ethics.
• Effective product discovery is getting access to customers without trying to push our quick experiments to production.
  • If you want to discover great products, you need to get your ideas in front of real users and customers early and often.
  • If you want to deliver great products, you need to use best practices for engineering and try not to override the engineers’ concerns.
• Principles of product discovery (pg 166)
  • Don’t count on customers to tell you what to build.
  • Most important thing is to establish compelling core value.
  • Good user experience is harder and more critical to success than engineering.
  • Functionality, design and technology are inherently intertwined.
  • Expect that many ideas won’t work and the ones that do will require several iterations.
  • We must validate ideas on real users and customers.
  • Our goal is to validate ideas in the fastest, cheapest way possible.
  • We need to validate feasibility of ideas during the discovery phase (i.e. involve engineers early). Similarly for business viability - financial considerations, marketing, sales, legal, business development etc.
  • It’s about shared learning. The team learns together and understands the context of why ideas fail or work.

Discovery techniques overview

• There are some key techniques in the discovery framework that may be useful (pg 171):
  • Discovery framing
  • Discovery planning
  • Discovery ideation
  • Discovery prototyping
  • Discovery testing

Discovery framing techniques

• The 2 goals of framing our discovery work are:
  • Ensure clarity of purpose and alignment of the team. Agree on business objective we are focusing on, the specific problem to be solved for customers and how we know we’ve succeeded. These need to align with the product team’s objectives and key results.
  • Identify the big risks that need to be tackled during discovery work.
• 3 techniques for framing:
  • Opportunity assessment - for the vast majority of projects, from simple to medium-sized projects.
  • Customer letter - for larger projects with multiple goals and complicated desired outcomes.
  • Startup canvas - when creating new product lines / business.
• The opportunity assessment has to answer 4 key questions about the discovery work:
  • What business objective is this work intended to address? (Objective)
  • How will you know if you’ve succeeded? (Key results)
  • What problem will this solve for your customers? (Customer problem)
  • What type of customer are we focused on? (Target market)
• The customer letter technique involves writing a letter from a hypothetical customer. The customer has sent this letter to our CEO explaining why they are so happy for the new product / developments, and how it has improved their lives. The letter also includes a congratulatory response from the CEO to the product team explaining how it has helped the business.
• Startup canvas technique. It’s great for highlighting the major risks. The idea is to tackle the biggest risks first. This is generally value risk (solution risk) - is your solution one your customers will choose to buy and use. The bar for this must be substantially better than existing solutions.

Discovery planning techniques

• 2 techniques:
  • Story maps - simple
  • Customer discovery program - complicated but recommended.
• Story maps are 2-D maps with major user activities on the horizontal dimension (loosely ordered by time from left to right). On the vertical dimension, we have a progressive level of detail as we flesh out each major activity into sets of user tasks and add stories to each of those tasks. Critical tasks are higher vertically than optional ones.
• Customer discovery program
  • Aim is to discover and develop a set of reference customers in parallel with discovering and developing the actual product.
  • Shoot for 6 reference customers in your first target market (it has to be focused) before moving on to the next vertical / target. This makes it easy for sales to go after those specific types of customers.
  • Recruit between 6-8 reference customers, preferably big names, who are in desperate need of the business value. Screen out those who are just interested in the tech. We need prospects who truly feel the pain and are willing to work with us, test prototypes etc.
  • The prospects should have agreed to buy the product and serve as a public reference IF the resulting product works for them. They should be informed however, that we are building a general product to serve them and other customers, not a custom solution (which they wouldn’t want anyway since it would be unsupported software).
  • Our job is to really figure out a single solution that works well for all 6 customers (not just include all their requests).
  • Think about NOT charging them in advance since it may distort the relationship. Or maybe put the money in escrow.
  • 4 main variations of this technique for different situations
    • Building products for businesses
    • Building platform products (e.g APIs)
    • Building customer-enabling tools used by employees for your company
    • Building products for consumers (work with 10-50 users)
  • If we can get to the point of 6 reference customers in a specific target market, we can typically declare product/market fit. So each reference customer is truly a significant milestone.

Discovery ideation techniques

• Customer interview
  • Always try to understand:
    • Are your customers who you think they are?
    • Do they really have the problems you think they have?
    • How does the customer solve this problem today?
    • What would be required for them to switch?
  • Tips:
    • Frequency - establish a regular cadence. At least 2-3 hours per week, every week.
    • Purpose - you are not trying to prove anything, just understand and learn.
    • Recruiting users and customers - talk primarily to people in your intended target market. About 1 hour of their time.
    • Location - observe them in their environment.
    • Preparation - be clear what you think their problem is and think about how you’ll confirm or contradict it.
    • Who should attend - product manager, designer and one engineer. Usually the designer drives, product manager takes notes and engineer observes.
    • Interview - natural and informal. Try to learn what they’re doing today.
    • Afterward - debrief with colleagues and check you all have the same understanding.
• Concierge test
  • Go out to actual users and ask them to show you how they work so you can learn how to do their job and work on providing them a much better solution.
• Customer misbehaviour
  • Allow and encourage customers to use our product to solve problems other than what we officially planned for / support.
  • This is one reason for the trend behind open APIs.
• Hack days
  • Try undirected or directed hack days. Undirected - people are free to explore so long as ideas are loosely related to the company mission. Directed - specific customer problem that self-organised product teams work on.

Discovery prototyping techniques

• Different forms of prototypes:
  • Feasibility prototypes - written by engineers to address technical feasibility risks during product discovery. Write just enough code to address the risk.
  • User prototypes - simulations. Range from low-fidelity to high-fidelity.
  • Live-data prototypes - collect actual evidence to prove something. Need a prototype and need to send live traffic to the prototype. Need to do this at a cost that is a small fraction of the commercially viable product.
  • Hybrid prototypes - combination of other types.
• Principles of prototypes
  • Learn something at a much lower cost in terms of time and effort than building out a product.
  • Forces you to think through a problem at a substantially deeper level than just talking about it, thus exposing major issues.
  • Shared understanding and team collaboration/
  • Only do high-fidelity when we need to.
  • In many cases, a prototype provides a secondary benefit of communicating to the broader organisation what needs to be built.
• Feasibility prototypes
  • Write as little code as possible. Should just be 1-2 days of work. Most of the time, the code written should be throwaway code.
• User prototypes
  • Remember that these do not validate our product.
• Live-data prototypes
  • It needs to run well enough to collect data for specific use cases and that’s it. Actual users have to use the prototype for real work, so it generates real data.

Discovery testing techniques

• There is no prescribed order to answering the questions of risks we identified, but many teams follow a certain logic:
  1. Value - toughest and most important
  2. Usability - can customers even recognise the value?
  3. Feasibility - engineers can review this once we have designed a solution for users
  4. Business - don’t stir the pot under we’re confident it’s worthwhile.
• Testing usability (pg 243)
  • Recruiting users to test - customer discovery program, Google AdWords, user email list, solicit visitors from company website, go to where your users congregate, etc.
  • Usability testing is usually done with high-fidelity user prototypes.
  • Read this chapter for best practice and tips.
• Testing value (pg 251)
  • The customer must perceive your product to be substantially better to migrate from their old solution. There are several elements of value and ways of testing all of them: testing demand, testing value qualitatively, testing value quantitatively.
  • Demand testing: Fake door demand test (for specific feature), Landing page demand test (for a product).
  • Qualitative value testing: try to do 2-3 tests every week. It’s all about fast learning and big insights. Here’s how:
    • User interview to check that the user has the problems we think she has, how she solves the problems today and what it would take for her to switch (see pg 211 for Customer Interview Technique).
    • Run a Usability test. The user first has to understand your product and how it’s meant to be used.
    • Run specific value test. Use money to demonstrate value (credit card, letter of intent). Use reputation to demonstrate value (how likely would they recommend product on scale of 0-10, ask them to share on socials, or ask them for emails for their boss). Use time to demonstrate value (are they willing to schedule time to work with us on this?). Use access to demonstrate value (ask them for login details of whatever product they would be switching from).
  • Quantitative value testing: this is all about collecting evidence. There are a few ways of doing this - it depends on amount of traffic we have, amount of time and our risk tolerance.
    • A/B testing. Specifically “Discovery A/B testing” where we show current product to 99% of users, and the live-data prototype of 1%. Note, Optimisation A/B testing is 50/50 where we experiment with different surface level, low-risk changes.
    • Invite only testing. Opt-in testing where we identify a set of users whom we contact and invite to try the experimental version. Not as good as a truly blind A/B test as users that agree tend to be early adopters. Unfortunately, we can’t know why users don’t use a product, so we’ll have to follow up with a qualitative test if things don’t go as we hope.
    • Customer discovery program (see above).
  • 5 main uses of analytics:
    • Understand user and customer behaviour
    • Measure product progress
    • Prove whether product ideas work
    • Inform product decisions
    • Inspire product work
  • Types of analytics:
    • User behaviour analytics (click paths, engagement)
    • Business analytics (active users, conversion rate, lifetime value)
    • Financial analytics (Billings, time to close)
    • Performance (uptime, load-time)
    • Operational costs (storage, hosting)
    • Go to market costs (acquisition costs, cost of sales)
    • Sentiment (NPS, surveys)
• Testing feasibility (pg 273). Engineers are trying to answer several related questions:
  • 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 to build this?
  • Will the performance be acceptable?
  • Will it scale to what we need?
  • Do we have the infrastructure to test and run this?
  • Can we afford the cost to provision this?
• Testing business viability (pg 277)