Inspired

Table of contents

1. three stages of company
2. root causes of failed product efforts
   1. two inconvenient truths about product
3. three overarching principles of product
4. key concepts
   1. product discovery
   2. prototypes
   3. product delivery
   4. product/market fit
   5. product vision
      1. principles of product vision
   6. product strategy
      1. principles of product strategy
   7. product evangelism
5. product discovery
   1. principles
   2. discovery techniques
      1. discovery framing
      2. discovery planning
      3. discovery ideation
      4. discovery prototyping
      5. discovery testing
   3. transformation techniques
6. stakeholders
7. good culture
   1. top reasons for loss of innovation
   2. top reasons for loss of velocity
   3. innovation vs execution culture

three stages of company

• startup - a company that has yet to achieve market fit
• growth-stage - companies that are concerned with how to effectively grow and scale
• enterprise - companies that want to create a lasting business, through both value capture (tweaking and optimizing current products) and developing products to reach their full potential

root causes of failed product efforts

• many companies operate like above, leading to lack of innovation and very long turn times to get into customer hands
• the engineering teams might be agile, but everything else is waterfall
• this leads to 10 big problems:
  1. source of ideas - sales or stakeholder driven rather than engineers, who are often best source of ideas but just become mercenaries
  2. business cases - while often a good thing for big projects, expecting to know how much a product will make and how long it will take to implement is impossible at this stage
  3. product roadmaps - just a list of features and ignores the two inconvenient truths of product
  4. role of product management - in this model, it is just requirements gathering and documenting for engineers
  5. design too late - lipstick on a pig for design to be brought in so late
  6. engineering brought in too late
  7. agile too late
  8. project-centered work - projects are about output, and product is about outcomes
  9. customer validation happens too late
  10. opportunity cost - what could we have been working on instead?

two inconvenient truths about product

1. at least half our ideas are just not going to work
2. for the ideas that have potential, it will take several iterations to deliver value (time to money)

three overarching principles of product

1. risks are tackled up front rather than at the end
2. products are defined and designed collaboratively rather than sequentially
3. it’s about solving problems, not implementing features

key concepts

• holistic product - a products functionality, technology, user experience design, how we monetize it, how we acquire and attract users and customers, and it’s offline experiences
• continuous discovery and delivery - need to discover product to be built and deliver it to market

product discovery

• output of product discovery is a validated product backlog
• answers the questions:
  1. will the user buy this?
  2. can the user figure out how to use this?
  3. can our engineers build this?
  4. can our stakeholders support this

prototypes

• a series of quick and inexpensive experiments to prove product viability, feasibility
• strong teams test many product ideas per week, typically 10-20

product delivery

• bringing a product to market, including necessary scale, performance, reliability, fault tolerance, security, privacy, internationalization, etc.

product/market fit

• smallest possible actual product that meets the specific needs of a specific market of customers
• MVP is not a product, MVP is a prototype!

product vision

• long-term objective of a product, typically 2-10 years out

principles of product vision

1. start with why
2. fall in love with the problem, not the solution
3. don’t be afraid to think big with vision
4. don’t be afraid to disrupt yourself because, if you don’t, someone else will
5. the product vision needs to inspire
6. determine and embrace relevant and meaningful trends
7. skate to where the puck is heading, not to where it was
8. be stubborn on vision, flexible on the details
9. realize that any product vision is a leap of faith
10. evangelize continuously and relentlessly

product strategy

• the sequence of products or releases we plan to deliver on the path to realizing the product vision
• should be focused, whereas product vision should be inspiring

principles of product strategy

1. focus on one target market or persona at a time
2. product strategy needs to be aligned with business strategy
3. product strategy needs to be aligned with sales and go-to-market strategy
4. obsess over customers, not over competitors
5. communicate the strategy across the organization

product evangelism

1. use a prototype
2. share the pain
3. share the vision
4. share learnings generously
5. share credit generously
6. learn how to give a great demo
7. do your homework
8. be genuinely excited
9. learn to show some enthusiasm
10. spend time with your team

product discovery

• the purpose of discovery is to address these risks:
  1. value risk - will the customer buy this, or choose to use it
  2. usability risk - can the user figure out how to use it
  3. feasibility risk - can we build it
  4. business viability risk - does this solution work for our business

principles

1. we know we can’t count on customers to tell us what to build
2. the most important thing is to establish compelling value
3. as hard and important as engineering is, coming up with a good user experience is usually even harder, and more critical to success
4. functionality, design, and technology are inherently intertwined
5. we expect that many of our ideas won’t work out, and the ones that do require several iterations
6. we must validate our ideas on real users and customers
7. our goal in discovery is to validate our ideas the fastest, cheapest way possible
8. we need to validate the feasibility of our ideas during discovery, not after
9. we need to validate the business viability of our ideas during discovery, not after
10. it’s about shared learning

discovery techniques

discovery framing

• allows us to quickly tackle the underlying issues that must be tackled during product discovery
• opportunity assessment - answer four key questions about discovery work – objective, key result, customer problem, and target market
• customer letter - originally like the amazon press release, but imagine you are a customer pleased with the solution, and write a letter to show that satisfaction
• startup canvas - useful for completely new products

discovery planning

• help identify the bigger challenges and planning how to attack this work
• story map - arrange user stories into mapping of functionality – useful for narrative of the work
• customer discovery program - getting reference customers (real customer, running product in production, paying real money, and willing to tell others) – often these reference customers are the single best indicator of future product success

discovery ideation

• designed to provide the product team with a wealth of promising solutions aimed at current problems
• customer interviews
• concierge test - do the customers job for them to get a feel for what it’s like
• customer misbehavior - monitor what the customer wants to do outside of typical behavior
• hack days - either directed or undirected, but useful for developer ideas

discovery prototyping

• many different forms of prototypes, different characteristics suited for different things
• feasibility - testing technical feasibility of a solution
• user - simulation of user interaction, with varying degrees of fidelity (closeness to reality) – useful to assess how a user interacts
• live-data - main use case is to collect actual data to prove something
• hybrid - some combination of the above

main principles

1. to learn something at a much lower cost in terms of time and effort than building a product
2. force you to think through a problem at a substantially deeper level tha nif we just about it or write it out
3. a powerful tool for team collaboration
4. many different possibilities for fidelity for a prototype
5. the primary purpose of a prototype is to tackle one or more product risks

discovery testing

1. testing usability
   • need to round up users
   • use a high-fidelity user prototype
   • need to keep users in use mode rather than critique mode
   • act like a parrot – repeat to users what you are hearing them say
2. testing value
   • can test demand, and can test value qualitatively or quantitatively
   • use a fake door demand test, where a button for some functionality exists but the functionality hasn’t been implemented
   • to test qualitatively, you can have users stake money, reputation (would they recommend it), time, or access (will they provide login creds to port current application to new one)
   • can test qualitatively through A/B testing (gold standard), invite only testing
3. testing feasibility
   • do we know how to build this?
   • do we have the skills on teams to build this?
   • do we have enough time to build this?
   • do we need architectural changes to build this?
   • do we have all the components?
   • do we understand dependencies?
   • will performance be acceptable?
   • will it scale?
   • do we have the infrastructure?
   • can we afford the cost?
4. testing business viability
   • need to go through all stakeholders to assess viability: marketing, sales, customer success, finance, legal, security, bus dev

transformation techniques

• discovery sprint: one week time box of product discovery designed to tackle a substantial problem or risk the product team is facing
• pilot team: allow the roll out of change to a limited part of the org before implementing more broadly
• moving off roadmaps - to wean an organization off of roadmaps, include the actual business outcome a feature is intended to help

Teams work on the prioritized business objectives determined by the leaders; we share key results transparently, and we commit to high-integrity commitments when critical delivery dates are needed.

stakeholders

• a stakeholder is a person who has veto power or can otherwise prevent the work from launching
• success for stakeholder management means they respect you and your contributions, they trust you understand their concerns, and will keep thme informed of important decisions or changes, and they will give you the room to come up with the best possible solutions

A group setting is not the forum for designing strong products. It results in design by committee, which yields mediocre results at best. Instead, meet privately with each stakeholder, show them the high-fidelity prototype, and five them the chance to raise any concerns.

good culture

top reasons for loss of innovation

organizations that lose the ability to innovate at scale are missing these attributes:

1. customer-centric culture
2. compelling product vision
3. focused product strategy
4. strong product managers
5. stable product teams
6. engineers in discovery
7. corporate courage
8. empowered product teams
9. product mindset
10. time to innovate

top reasons for loss of velocity

1. technical debt
2. lack of strong product managers
3. lack of delivery management
4. infrequent release cycles
5. lack of product vision and strategy
6. lack of co-located, durable product teams
7. not including engineers early enough in product discovery
8. not utilizing product design in discovery and instead having them try to do their work at the same time the engineers are trying to build
9. changing priorities
10. a consensus culture

innovation vs execution culture

• to be strong at innovation, you need a culture of experimentation, open minds, technology, business and customer-savvy teams, skill-set and staff diversity, and discovery techniques
• to be strong at execution, you need a culture of urgency, high-integrity commitments, empowerment, accountability, collaboration, results, and recognition
• innovation and execution are often at odds