Inspired, by Marty Cagan
My detailed summary of Cagan's book, which sets the stage for product management done well. Essential foundational reading for any product team.
Inspired is a succinct overview of Product Management as a discipline, directly from the founder of the Silicon Valley Product Group. This book serves almost as a “glossary” or reference guide for anyone wanting to know the underlying context for terminology like “Discovery” and “Opportunity Assessment” and “Story Map Technique.” Cagan provides a lot of great context around what good versus bad product management looks like.
If you enjoy the summary below, I highly recommend buying and reading the full book either via Bookshop or Amazon.
PART I: LESSONS FROM TOP TECH COMPANIES
“It doesn’t matter how good your engineering team is if they are not given something worthwhile to build.” Also, “there is a tremendous difference between how the best companies produce products and how most companies produce them. The state of the art is [usually] very different from the state of the practice.”
Chapter 1: Behind Every Great Product
… is a product manager who leads the team (usually 2-10 engineers, and a product designer) to combine technology and design to solve real customer problems in a way that meets the needs of the business.
Chapter 2: Technology-Powered Products & Services
… are the focus of this book, and are different from consumer packaged goods (and other non-tech products).
Chapter 3: Startups: Getting to Product/Marketing Fit
… is the main focus of a startup (before they run out of money). “Nothing else much matters until you can come up with a strong product that meets the needs of an initial market.” The few that accomplish this are either lucky or - more likely - good at product discovery.
Chapter 4: Growth-Stage Companies: Scaling to Success
… is a good problem to have (often due to some initial product/marketing fit and resulting growth). Growth-stage companies tend to struggle with leadership styles ill-suited for their growing size, opaque “big picture” product visions, inappropriate go-to-market strategies for their stature, and technical debt from that initial MVP platform.
Chapter 5: Enterprise Companies: Consistent Product Innovation
… is really challenging once you’ve achieved scale. Most large companies are in a slow death spiral, in part due to the tremendous pressure from numerous stakeholders to protect what the company has created (which may well print money for a while yet).
Chapter 6: The Root Causes of Failed Product Efforts
… lie in the waterfall process “disguised” as agile development. Keep an eye out for the 10 serious issues:
Sales-driven or stakeholder-driven products (source of ideas)
Business cases for everything, based on information (how much money we’ll make, how much it’ll cost) we don’t have at this stage.
Product roadmaps that are essentially prioritized lists of features and projects, 50% of which won’t work, and most of which will need several iterations to be successful.
Product management that’s really project management (gathering requirements and documenting them for engineers).
Design involved way too late, putting lipstick on a pig.
Engineering involved way too late, even though they’re the best single source of innovation.
Agile is only used for delivery (if at all), within a project and an organization that is not at all agile.
Project-centric (focused on output) rather than product-centric (focused on outcome).
Customer validation only at the end (waterfall is the most expensive, slowest way to try out ideas).
Huge opportunity cost for the organization compared with what they could have been working on.
Chapter 7: Lean and Agile
… are meaningful innovations in how we work, specifically when a) risks are tackled up front, rather than at the end (value, usability, feasibility, business viability risks); b) products are defined and designed collaboratively, rather than sequentially; and c) the focus is on solving problems, not implementing features (… ultimately accomplishing business results).
Chapter 8: Key Concepts
Holistic product: encompasses the functionality, technology, user experience design, how we monetize, how we acquire users and customers, and the offline experiences.
Continuous Discovery and Delivery: "we need to discover the product to be built and we need to deliver that product to market."
Product Discovery: way to create a validated product backlog where the four major risks are addressed upfront: 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: experiments to quickly and inexpensively drive product discovery. Make sure they cost an order of magnitude less than building a product. Aim for 10-20 experiments/tests per week.
Product Delivery: everything you do to deliver a high quality product from the validated product backlog (security, performance, scale, reliability, fault tolerance, privacy, internationalization, localization)
Product/Market Fit: the smallest possible product that meets the needs of a specific market of customers.
Product Vision: long-term objective for a product, 2-10 years out.
MVP: we should see this as the minimum viable prototype since a product needs to be polished.
PART II: THE RIGHT PEOPLE
Getting the right product team is the most important thing.
Chapter 9: Principles of Strong Teams
Strong teams are made up of missionaries (true believers in the vision and committed to solving problems for customers), not mercenaries (who build whatever they’re told). They’re empowered to solve hard problems, accountable for results, co-located, and responsible for all aspects of their (part of the) product. Strong teams are stable (not just together for the duration of a project), collaborative, and autonomous. Distribute leadership: collaboration is built on relationships, innovation is built on expertise, and motivation is built on ownership and responsibility for the outcome.
Chapter 10: The Product Manager
… needs to be among the strongest talent in the company to combine technology sophistication, business savvy, credibility with key execs, deep customer knowledge, passion for the product, and respect for the product team. They must have deep knowledge of a) the customer (to drive daily decisions); b) the data (to inform decisions); c) your business (including your stakeholders and the constraints they operate under); d) your market and industry (so you can be substantially better than the competition). Good product managers must be smart (intellectually curious, quick learners of new technologies), creative, and persistent (pushing way beyond their comfort zone in the face of stubborn resistance). They must not be afraid to lead. (Consider taking an intro to computer programming course, and an intro to business accounting/finance course).
Chapter 11: The Product Designer
… is responsible for product discovery (measured by the success of the product), the holistic user experience design, prototyping, user testing (to assess the value of their ideas), and interaction and visual design. Working without a designer rarely gives the holistic design a good product relies on. Design is needed “not just as a service to make our product beautiful, but to discover the right product.”
Chapter 12: The Engineers
… are the most important relationships a product manager has, so do your homework and earn their respect. Give them latitude to come up with the best solution.
Chapter 13: Product Marketing Managers
… play an essential role in discovery, delivery, and go-to-market. They are deeply engaged with the sales channel, and so can represent the market to the product team.
Chapter 14: The Supporting Roles
… include: User Researchers (for either generative learning, to understand the problems, or evaluative learning, to understand whether we’ve solved the problems). Data Analysts (to drive data-driven insights). Test Automation Engineers (to ensure products can be released with confidence … product managers should not be responsible for this full-time job).
Chapter 15: Profile: Jane Manning of Google
… was responsible for launching AdWords, which released the sales-driven channel with a self-serve channel. She developed a solution that a) could live side-by-side with the sales-driven channel, and b) had internal mechanics to reward higher performing ads to prevent the worse ads from displaying even if they paid more.
Chapter 16: The Role of Leadership
… is to recruit, develop, and retain strong talent, and to cultivate a holistic view of product (connecting dots between teams). This is true for the (IC) principal product manager, principal product designer, and engineering leaders. These roles cannot be replaced by documentation. It’s easy to see if companies lack this holistic leadership.
Chapter 17: The Head of Product Role
… typically manages the PMs, product designers, sometimes the data analysts, and reports to the CEO. Importantly this person is a peer to the CTO and VP of Marketing. Core competencies include 1) Team Development (proven ability in recruiting, training, and ongoing coaching); 2) Product Vision & Strategy (to complement the CEO); 3) Execution (especially in stakeholder management and internal evangelism); 4) Product Culture (understanding the importance of continuous and rapid testing and learning). Group Product Manager is an excellent hybrid of an IC and first-level people manager role.
Chapter 18: The Head of Technology Role
… is responsible for continually making technology as a strategic enabler for the business. Core responsibilities include a) Organization (developing employee skills and managing retention); b) Leadership (informing overall strategic direction and build/buy/partner decisions); c) Delivery (making sure the org can rapidly, reliably and repeatedly delivery quality products to market); d) Architecture (for the business to scale and thrive); e) Discovery (making sure the members of senior engineering staff are involved); f) Evangelism (representing the engineering team as a spokesperson).
Chapter 19: The Delivery Manager Role
… is a special project management role responsible for removing impediments for the team. They can be helpful when your organization is larger than 5-10 product teams.
Chapter 20: Principles of Structuring Product Teams
Alignment with investment strategy
Minimize dependencies (between teams, so they can operate autonomously)
Ownership and autonomy (so they can be missionaries in their own ways). Interdependencies will always exist to chip away at this.
Maximize leverage (through shared services, though this creates dependencies)
Product vision and strategy (should be reflected in your team structure)
Team size (1pm to 2 engineers minimum, 1pm to 10-12 engineers is the max.
Alignment with architecture (which should also be consistent with the vision)
Alignment with the User or Customer
Alignment with Business (especially if there are multiple lines of business).
… And despite all of this, structure is a moving target.
When teams complain about not being autonomous, try to get specific details on what the team is not able to decide or where they feel constrained. Often it’s either from a) lack of trust from management; or b) the team wants to change something leaders assume is part of the foundation. Make sure the team skill level is appropriate, we err toward whatever will provide us with speed, we support integration, whether the sources of innovation are at the foundational level or within the application level, the tech is mature enough to be leveraged, and that the teams are accountable for their results.
Chapter 21: Profile - Lea Hickman of Adobe
She led their shift from the old desktop-centric, annual-upgrade model to a subscription-based model supporting all devices (including tablets and mobile). She found a true partner in their CTO, and led a "sustained and exhausting campaign to communicate continuously with leaders and stakeholders over the entire company … with a continuous stream of prototypes to keep people excited about what the new future would bring.”
PART III: THE RIGHT PRODUCT
… are typically focused on output (and are often stakeholder-driven). We want to be focused on outcomes.
Chapter 22: The Problems with Product Roadmaps
… are that half of our ideas (if we’re doing them right) are not going to work, and the ideas that do work are going to take iterations to get right. “The issue is that anytime you put a list of ideas on a document entitled ‘roadmap,’ no matter how many disclaimers you put on it, people across the company will interpret the items as a commitment.” Weak teams are the ones who plod through their roadmap of tasks they’ve been assigned, month after month.
Chapter 23: The Alternative to Roadmaps
… involve setting and documenting a clear product vision and strategy, and a set of clear business objectives for each product team. We may also have a set of date-driven high-integrity commitments which are only set with this high integrity after we’ve had a chance to investigate the full scope of work involved. Outcome-based roadmaps enable teams to be more motivated (since they are free to solve the problem in the best way they see fit), and must continue seeking solutions until they actually solve the problem.
Chapter 24: Product Vision and Product Strategy
The Product Vision is the future we are trying to create in the next 2-5 years. This is mainly a persuasive piece, and can take the form of a storyboard, a white paper narrative, or a visiontype (special type of prototype). Its primary purpose is to inspire.
The Product Strategy is the "sequence of products or releases we plan to deliver on the path to realizing the product vision.” Generally try to focus on a single target market at a time.
As a corollary, leadership (vision) inspires and sets the direction while management (strategy) helps get us there. When prioritizing your markets, consider the balance of a) total addressable market; b) distribution/go-to-market; and c) time to market.
Chapter 25: Principles of Product Vision
… highlights include a) start with why; b) fall in love with the problem, not the solution; c) don’t be afraid to disrupt yourselves; d) determine and embrace relevant and meaningful trends; e) skate to where the puck is heading, not to where it was; f) be stubborn on vision but flexible on details, etc.
Chapter 26: Principles of Product Strategy
… highlights include a) focus on one target market or persona at a time; b) obsess over customers, not over competitors, etc.
Chapter 27: Product Principles
… are really important to set so that you have a sense of the "nature of the products you want to create.” E.g. with eBay, “in cases where the needs of the buyers and sellers conflict, we will prioritize the needs of the buyer because that’s actually the most important thing we can do for sellers.”
Management by Objectives (MBO) and Objectives and Key Results (OKRs) are built on the same two fundamental principles:
Empower and motivate your team by telling them (in broad terms) what to do, not how to do it. “Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.” (George Patton)
Measure performance by results.
Chapter 28: The OKR Technique
Objectives are qualitative, and each product team should have no more than 1-3, covering what the team needs to accomplish, with accountability to achieve them.
Key Results are quantitative measures of business results, tracked on a weekly basis, with a pre-defined scoring method. Most may be on a scale of 0 - 1, with 0.7 being what you hoped to achieve, though high-integrity commitments are binary.
Chapter 29: Product Team Objectives
… are your opportunity to focus on the OKRs, since these are the cross-functional teams responsible for driving results within a tech product company. Don’t let functional team or personal OKRs conflict with the product team OKRs (and beware of conflicts between teams!).
PRODUCT @ SCALE
Chapter 30: Product Objectives @ Scale
… “When using OKRs at scale, there’s a larger burden on leadership and management to ensure that the organization is truly aligned, that each and every product team understands how they fit into the mix, [that there are no gaps in what needs to be delivered], and that they are there to contribute.”
Chapter 31: Product Evangelism
… is a main responsibility of the product manager, particularly within larger companies where the importance of your initiative may fall out of focus. Use prototypes, share the pain, share the vision, share your learnings, share credit for successes, learn how to give a great demo, do your homework, be genuinely excited, show your enthusiasm, and spend time with your team.
Chapter 32: Profile - Alex Pressland of the BBC
She (as an individual contributor) led the BBC to shift from broadcast content to content distribution (via syndication), developing a series of experiments and ultimately pitching the hugely successful “BBC Out of Home” product vision and strategy.
PART IV: THE RIGHT PROCESS
There are two main challenges: 1) discovering in detail what the customer needs (the single solution that works for many customers); and 2) deliver robust and scalable implementations that customers can rely on. We need to learn fast and release with confidence. To do good discovery, you need to “get your ideas in front of real users and customers early and often.” To do good delivery, you need to “use best practices for engineering and try not to override the engineers’ concerns.”
Chapter 33: Principles of Product Discovery
The purpose is to address upfront: a) value risk (will the customer buy this?); b) usability risk (can they figure out how to use it?); c) feasibility risk (can we build it?); and d) business viability risk (does this solution work for our business?). We do this through these principles:
Customers don’t know what’s possible, and with technology products, none of us know what we really want until we actually see it.
Creating compelling value is most important (so customers choose to buy.)
Coming up with good UX is harder - and more critical - than engineering.
Functionality, design, and technology are inherently intertwined.
“The most important thing is to know what you can’t know,” so expect some ideas to fail and most products to require several iterations.
We can only validate ideas on real users and customers.
The goal of discovery is to validate ideas in the fastest, cheapest way possible.
We validate feasibility during discovery, not after.
We validate business viability during discovery, not after.
Make sure you drive shared learning.
Chapter 34: Discovery Techniques Overview
Use a) framing techniques to identify the underlying issues that must be tackled during discovery; b) testing techniques to separate good ideas from bad; and c) transformation techniques to help your organization adopt these processes, as well as planning, ideation, and prototyping techniques that will be discussed.
DISCOVERY FRAMING TECHNIQUES
… have two main goals: 1) ensure alignment and clarity of purpose; 2) identify the biggest risks that need to be tackled (of the normal categories, including financial risk, business development risk, legal risk, ethical risk, etc.). Make sure you focus on understanding the problems before beginning to evaluate solutions.
Chapter 35: Opportunity Assessment Technique
… focuses on answering four questions:
What business objective is this work intended to address?
How will you know if you’ve succeeded?
What problem will this solve for our customers?
What type of customer are we focused on?
Chapter 36: Customer Letter Technique
… is useful for larger efforts, when there are “multiple reasons, several customer problems to be solved, or business objectives to be tackled.” An alternative to the (entirely imagined and somewhat dated) Amazon-style press release which describes the actual benefits to the customers, try writing a letter from a customer to the CEO in which they describe the impact it has had on their life.
Chapter 37: Startup Canvas Technique
… is useful for early-stage startups that require a more comprehensive framing technique to focus on inventing an entirely new product. This helps you stay focused on the biggest risks to the business under your current assumptions. “It’s human nature for people to focus more on those areas they feel they can control and are more knowledgeable about,” so make sure you tackle primary risks, not secondary ones. The major risk is value risk, particularly in creating something demonstrably and substantially better than alternatives.
DISCOVERY PLANNING TECHNIQUES
Chapter 38: Story Map Technique
… is used when you have a two dimensional map of user stories, with the horizontal dimension representing the user journey and the vertical dimension representing the progressive levels of detail needed to be covered within each step (with the more critical pieces at the top). "Many teams consider a high-fidelity prototype and a detailed story map as their go-to technique.” For more information, see Jeff Patton’s 2014 book, User Story Mapping.
Chapter 39: Customer Discovery Program Technique
… is when you find 6 reference customers (if working with businesses, otherwise 15-50 customers if you’re a B2C product) who partner with you to figure out product market fit. This is a real customer, using your product on production, paying real money for it, and who is willing to tell others they’re using it. If you can’t find reference customers, the problem is simply not compelling enough (a.k.a. it fails demand validation). It takes substantial effort to do this well (you’ll need a new set of reference customers for each target market you tackle), but it’s a powerful technique and will support you in the real market as you scale your sales/marketing effort. Remember: you’re building a general product … the single solution that solves all of their challenges.
Chapter 40: Profile - Martina Lauchengco of Microsoft
She led Microsoft Word’s development team for the Mac, focusing on solving performance issues specific to the Mac during the 90s. They went against the grain (the strategic goal of the time was to converge the codebase across the different Word products), and succeeded in creating value for their users.
DISCOVERY IDEATION TECHNIQUES
… are to answer the question: “How do we generate the types of ideas that are likely to truly help us solve the hard business problems that our leaders have asked us to focus on right now?” Surprisingly, most product teams are stuck working on the ideas of their management teams and are not doing their own ideation. Remember: all ideas must be subject to testing.
Chapter 41: Customer Interviews
… are critical methods of enabling shared learning, and come in many styles (formal/informal, etc.). Try to understand: a) are your customers who you think they are? b) do they really have the problems you think they have? c) How does the customer solve the problem today? And d) what would be required to make them switch? Some tips: 1) establish a regular cadence of interviews; 2) make sure your purpose is to learn quickly and understand your users (no ulterior motives) 3) establish a pipeline of recruitment within your target market; 4) if possible, go to them, but not at the expense of actually doing interviews; 5) bring the PM, product designer, and a rotating engineer. Also, make sure you prepare, ask good questions, and debrief afterward.
Chapter 42: The Concierge Test Technique
… is when you, manually and personally, complete the job the customer needs done. This requires “going out to the actual users and customers and asking them to show you how they work so that you can learn how to do their job, and so that you can work on providing them with a much better solution.”
Chapter 43: The Power of Customer Misbehavior
… is when we “allow, and even encourage, our customers to use our products to solve problems other than what we’ve planned for and officially support.” For more, see Mike Fisher’s book, The Power of Customer Misbehavior. This is also why it’s helpful to have public APIs … to see how others use your services.
Chapter 44: Hack Days
… are powerful ways to turn teams of mercenaries into missionaries. They can be undirected - where teams can work on anything peripherally related to the platform; or directed - when you guide the hack day projects toward a particular customer problem (like retention, relationships). This is a good way to include engineers in ideation.
DISCOVERY PROTOTYPING TECHNIQUES
Chapter 45: Principles of Prototypes
The purpose is to learn at an order of magnitude lower cost (time + effort) than building out the product.
They force you to think through the problem at a much deeper level than just writing it down. Just creating a prototype uncovers issues!
Prototypes are powerful tools for team collaboration / shared understanding.
They have many different levels of fidelity (trick is finding the right level for what you need to learn).
While they are primarily used to tackle one of the product risks, they can also communicate the broader spec to the engineering team. This is called “prototype as spec.”
Chapter 46: Feasibility Prototype Technique
… are technical spikes, intended as throwaway work, to assess and potentially address feasibility risk in any of the main technical aspects. Write just enough code to mitigate the feasibility risk. This usually should require no more than a few days of work, though that depends on the scope. When teams find they’ve grossly underestimated the amount of work a product takes, it’s usually because they didn’t address feasibility risk upfront.
Chapter 47: User Prototyping Technique
… “is key to several types of validation and is also one of our most important communication tools.” They have a wide range of fidelity, with the high-fidelity ones working as a pretty good simulation of the end user experience. Remember: this is not good for proving something. It’s mainly used to learn. We validate value in different ways, so be prepared to throw away your prototype here.
Chapter 48: Live-Data Prototype Technique
… is a very limited implementation of the product, without “the full set of use cases, automated tests, analytics instrumentation, internationalization and localization, performance and scalability, etc.” This is not ready for primetime, so make sure to set appropriate expectations with your stakeholders who may get really excited. “The key is to be able to send some limited amount of traffic, and to collect analytics on how this live-data prototype is being used.” Particularly relevant when you have a product that has game dynamics, search result relevance, social features, etc.
Chapter 49: Hybrid Prototype Technique
… include the “Wizard of Oz” prototype where you give someone a front-end that looks like the real product yet everything is happening with people behind the scenes. The key is making something that is definitely not scalable for the purpose of quickly learning if it solves compelling problems for users.
DISCOVERY TESTING TECHNIQUES
Remember, we test to assess the quality of our ideas within the context of the four main questions (value, usability, feasibility, and business viability). Most teams address things in roughly that order, but all are “trying to quickly separate the good ideas from the bad as we work to solve the business problems assigned to us.”
Chapter 50: Testing Usability
… is a well known challenge with many dedicated resources explaining how to do it well. Recruit users well (from your target market!), prepare the test well (the more realistic the prototype the better, define the tasks upfront, etc.), and test your prototype thoughtfully. Some points on testing: a) make sure you get their sense of your starting point (whether they understand at a glance what your product does); b) keep the user in use mode instead of critique mode; c) get comfy with silence; d) act like a parrot (and acknowledge verbally what they’re doing or parrot back to them questions they have … this help you to not lead them); e) pay attention to their body language. Remember, we’re looking for inconsistencies with how they use the product, and especially moments where they’d get frustrated enough to leave the product and go to a competitor.
MAIN POINT: Absolutely fix glaring issues with your prototype in between tests. We’re not out to prove anything, just to learn. And keep your summary learnings to an email.
Chapter 51: Testing Value
… is critical, since just because someone can use the product doesn’t mean they will choose to use it. Feature parity isn’t enough; your product must be substantially better.
Chapter 52: Demand Testing Techniques
… can be used for entire products (e.g. with landing page tests to see if someone will indicate enough interest) or for individual features (e.g. with fake door tests to see if someone will become a reference user for that new feature you’re testing). When they click through, just be upfront that you’re “exploring the possibility of adding this new feature and are looking for people to talk with about it.”
Within established companies, don’t create special innovation teams (it’s demeaning to the other teams). But while testing, remember to a) protect the revenue and brand; and b) protect the customers and employees.
Chapter 53: Qualitative Value Testing Techniques
… with real users and customers is the single most important discovery activity you can do, so aim to run at least 2-3 tests each week. Usability tests with high-fidelity prototypes are good. Also test value through: money (are they willing to buy?), reputation (are they willing to recommend?). access (are they willing to provide their log-in to the competitor service to “transition”?), time (are they willing to spend significant time helping you refine the product?). Remember: any test that “fails” is a future, expensive failure you’ve prevented for your company. Do not delegate this work.
Chapter 54: Quantitative Value Testing Techniques
… can be used to generate evidence or, in cases where we absolutely need to prove something, statistically significant results. Discovery A/B testing is generally done with a live data prototype with a minority of your users to gather evidence (as opposed to Optimization A/B testing which is done with a 50/50 split to hit stat/sig quickly). Invite-only testing and Customer Discovery Program testing are also valuable, though less randomized.
Note that any team that doesn’t take the time to implement basic analytics is flying blind. Make sure you cover the basics: user behavior analytics, business analytics, financial analytics, performance, operational costs, go-to-market costs, sentiment. Analytics is generally useful for:
Understanding user and customer behavior (this is table-stakes, otherwise how do we know if something is working or not?)
Measuring product progress (with our KPIs so we can stay focused on outcomes).
Proving whether product ideas work or not (particularly with ideas that will be expensive to fully deliver)
Informing product decisions (data beats opinions!)
Inspiring product work (you never know what unexpected insights may come from this analysis)
Chapter 55: Testing Feasibility
… is important to make sure we’re uncovering the best product ideas that are based on approaches to solving the problem that are only just possible, which means new technology and time to investigate/learn that technology. Asking “what’s the best way to do this and how long would it take?” is a great way to inspire creativity.
Chapter 56: Testing Business Viability
… is a critical, often overlooked, step in the whole flow. You need to make sure this works for the business by working closely with marketing, sales, customer success, finance, legal, business development, security, and the executive team. It’s your job to understand each of their relevant constraints and to work through them. Also, remember the difference between a) a user test (to learn); b) a product demo (to influence or persuade); and c) a walkthrough (to make sure a stakeholder understands the nuance of the product and to uncover any potential unforeseen risks).
Chapter 57: Profile - Kate Arnold of Netflix
… was the PM responsible for wrangling the stakeholders early on to create the queue, recommendations, and monthly subscription model so that they could solve their inventory/load balancing challenges and bring in the recurring revenue. Interesting note: they launched with the 30-day free trial when they had ~30 days of work left to set up the payments system.
Chapter 58: Discovery Sprint Technique
… is described in detail in the book Sprint by GSV team members. Yes, you can do a lot of this work within a single week to significantly inform your product strategy. If you’re introducing your company to the new process, consider hiring a discovery coach - a former product leader who can guide you through the whole process.
Chapter 59: Pilot Team Technique
… is also useful when introducing this new product process in a larger company. Have a single team (who is reasonably independent of others, and decidedly not an “innovation team”) pilot the new techniques to show everyone what results it can create.
Chapter 60: Weaning an Organization Off Roadmaps
… is important when you’re trying to get everyone to focus on delivering business outcomes instead of dates. They want roadmaps to: a) have visibility into what you’re working on and that you’re prioritizing the most important things; and b) to be able to plan the business and know when critical things will happen. You don’t need roadmaps to do this.
PROCESS @ SCALE
Often, when companies grow, the innovation grinds to a halt. This doesn’t need to happen.
Chapter 61: Managing Stakeholders
… is done best when you don’t collect requirements from them, but rather gather input on their needs, constraints, etc. on a regular basis. Consider a stakeholder as someone “has veto power or could otherwise prevent your product from launching.” Invest in your understanding of their needs, and bring that knowledge to the team. Meet with them on a regular basis (often weekly), and share high-fidelity prototypes to make sure they will support the actual product. No one should ever be surprised by a release. Don’t present your stuff to a group of stakeholders, if avoidable.
Chapter 62: Communicating Product Learnings
… is best done during a company all-hands, by the VP of Product, for about 15-30 min every other week. Share the big learnings on what worked, what didn’t work, and what is coming next. Be generous with what you’ve learned, but don’t get bogged down in details.
Chapter 63: Profile - Camille Hearst at Apple
She worked on the complex integration/partnership between iTunes and American Idol, which was a huge brand-building opportunity for both sides.
PART V: THE RIGHT CULTURE
Chapter 64: Good Product Team / Bad Product Team
… [is a riff on Ben Horowitz’s blog post, and essentially summarizes the main points of the book].
Chapter 65: Top Reasons for Loss in Innovation
… [also summarizes the book: be customer-centric, have a compelling product vision, have a focused product strategy, strong product managers, etc.]
Chapter 66: Top Reasons for Loss in Velocity
… include: Technical debt weighing down the team, lack of strong product managers, lack of delivery management, infrequent release cycles, etc. [Also summarizes the book]
Chapter 67: Establishing a Strong Product Culture
… requires balancing a strong innovation culture (experimentation, open minds, empowerment, willingness to use new technology, etc.) and a strong execution culture (urgency, high-integrity commitments, accountability, collaboration, results-orientation, recognition).
Thanks for reading Evan’s Notes! Subscribe for free to receive new posts and support my work.