In the last 10 years, whenever someone has asked me what my favourite book is, my response has been “The Lowland by Jhumpa Lahiri” (although “Home Fire by Kamila Shamsie” did come close.) I was engrossed when I read it for the first time as a teenager, and I don’t remember being interested in mundane activities like eating or sleeping for those few days. I recently read The Lean Product Playbook, as recommended (or rather, directed to) by my manager. It’s a book that attempts to be a guide for building products from scratch that have a higher likelihood of achieving product-market fit. I did struggle to get through some parts but it definitely captivated me, and had enough nuggets of wisdom to fill up several pages of my notebook. Now that I’ve finished it — I think it’s safe to say The Lean Product Playbook takes up the second spot in my list of favourite books right now.
So, without further ramblings about my favourite books, here are some of the learnings from this book, that I’m holding dearly:
- In any product-building process, there’s something called the “problem space” and another called the “solution space.” Here’s a story that illustrates what these spaces mean: NASA was trying to find a replacement for ballpoint pens when they were preparing to send astronauts into space, because these pens depend on gravity in order for the ink to flow. A company named Fisher Pen Company spent about a million dollars to come up with something called the Space Pen, a pen that would work in zero gravity. In contrast, the Russian space agency simply gave their astronauts pencils. Where did the Fisher Pen Company go wrong? They jumped into the solution space; they constrained their thinking to “a pen that works in zero gravity.” when really, the problem space is much broader than that. It’s “a way to record notes in zero gravity for later reference that is easy to use.” Essentially, the problem space is where you discover, pinpoint and learn about the problems you’re trying to address through your product. The solution space is where you actually get to solving these problems - brainstorming features, drawing wireframes, sprint planning and all of the other steps associated with a typical “product building process” should ideally only come here; after you’ve done a significant amount of market research. Since it’s so common, one of the easiest ways to tell that a product team is starting with the solution space is that instead of articulating customer benefits, they list product features. While benefits begin with a verb (like “reduce”) and usually speak to increasing something that’s desired or decreasing something that’s not desired, product features define exactly what your product is going to do. Here’s a diagram that explains exactly what each space consists of, in the product building process:
- Personas are useless if you don’t continuously revisit them through multiple “customer discovery” conversations
- A good way to decide what product ideas to pursue is through the importance-satisfaction matrix. Importance is a concept in the problem space i.e. how important is a customer need to them, and satisfaction is a concept in the solution space i.e. how satisfied is a customer with the solution Uber capitalised on the high importance-low satisfaction quadrant (see image below.) When Uber was founded, the only existing solution for an on-demand ride service was taxis and users of this often complained about rude drivers, dirty cars, uncertainty about the cost of trips, and the hassle of payment. Uber seized the opportunity and used technology to increase transparency, provide a feedback system and store payment methods
- The importance-satisfaction framework can also be used to quantify the opportunity you have, to innovate. For example, the gap analysis framework defines this opportunity as
importance - satisfactionand the jobs to be done framework defines this opportunity asimportance + maximum(importance - satisfaction, 0) - Early on, search engines differentiated themselves using performance features i.e. no. of search results, freshness of search results and relevance of search results. Google won — over time, most search engines were indexing a lot of pages so the number of results became less important, and they were also able to add new pages quickly so results were fresh Google was the only one able to achieve super high relevance. Plus, “autocomplete search” was a feature that added a touch of delight When a new search engine, Cuil tried to compete with Google, it tried to do so by differentiating by the no. of search results but this didn’t work. Why? Because in order to have a shot at beating a market leader, the value prop for your new product needs to at least match them on two important performance features, which Cuil didn’t bother doing
- Airbnb used a “concierge MVP” (where you manually do things and only later automate it) to grow their service. The founders, in the early days of the company, took photos of properties themselves and communicated directly with hosts and guests to facilitate the booking process, simulating the experience they envisioned for the platform, which gave them insights into needs and helped shape the development of the platform
- Similar to concierge MVP is the Wizard of Oz MVP - the only difference is that users don’t know you’re manually doing things. An example is early Amazon. Jeff Bezos used to manually purchase and deliver books to customers himself
- Delight often involves a dynamic response by the product based on a user action. An example is the “rubber band” effect that occurs in iOS when a user attempts to scroll past the end of a webpage or document
- When you are very close to your product, it is difficult (often impossible) to perceive it as a new customer does. As a result, you have product blindness and user testing is the antidote to this. This is why the first time you test with users often leads to the most surprising learning
- Teams can be easily prone to “shiny object syndrome”, which is when you drop what you’re building to chase each cool new idea you come up with
- How agile development should work — everyone is involved at all times, but there are leaders for each part of the process. Product managers write user stories, designers create artifacts, developers code and testers test
- Good conceptual design can be the key to success of a product. Uber’s map-centric design directly addresses one component of their value prop, which is transparency. Intuit Quicken’s checkbook conceptual design helped them become the leading personal finance software in a crowded market, simply because everyone at the time was familar with writing checks
- When doing user testing in waves (i.e. when you gather feedback from a set of users, address the feedback from them by making changes in the product, and then test the new and improved product with another set of users,) no user will tell you, “good job on fixing ______” You measure such progress by silence, the absence of complaints
- Steve Jobs once said, “When you first start off trying to solve a problem, the first solutions you come up with are very complex, and most people stop there. If you live with the problem, you often arrive at an elegant and simple solution. Most people don’t put the time or energy to get there.”
- Sean Ellis, the founder of GrowthHackers, came up with a simple way to determine if a product has achieved PMF. It was a survey question that asked, “How would you feel if you could no longer use [product X]?” and the possible responses were: Very dissapointed Somewhat dissapointed Not dissapointed N/A - I no longer use [product X] He found that products for which 40% or more users replied with “very dissapointed” had achieved product-market fit