About book Inspired: How To Create Products Customers Love (2008)
A decent guide to Product Management that contains some good food-for-thought for anyone involved in developing products, especially web-based ones. While I took much of the advice to heart, the book is too anecdotal for my taste. Many of the "arguments" for why you should follow the advice boils down to "trust me, I'm an expert." More studies and first-hand accounts would have driven home the points much more effectively. "Inspired" is a well-written, thorough, and down-to-earth work covering all aspects of product management at software companies.To paraphrase/summarize: the job of the product manager is to discover a product that is useful, feasible, and valuable. They do this through understanding users and potential users in detail and evaluating opportunities to solve problems for those users. Once an opportunity is identified, they create a prototype, validate the prototype with users, then work with engineering to build the product, product marketing to launch the product, and sales and support to follow up on the success (or failure) of the product.The book covers how product management fits in with other functions -- engineering, interaction design, visual design, project management, product marketing. The difference between product management and product marketing is often misunderstood, but Inspired explains it simply: product marketing is about understanding the marketplace (in aggregate), how your product fits into that, and how to explain it when it comes time to launch. Product management is about the content of the product -- understanding the users/customers (individually), how the product works, what it is for. Creating a product and explaining a product to the world require two very different skillsets that are rarely found in the same person.There's also a great chapter on how to "manage up," meaning how to work most effectively with your manager.Some excerpts and points:- "Engineers think in terms of implementation models, but users think in terms of conceptual models."- You need "one product manager for every 5 - 10 engineers," one interaction designer for every two product managers, and one visual designer for every four interaction designers.- "As a product manager, you are responsible for defining the right product, and your engineering counterpart is responsible for builidng the product right."- "Keep the focus on minimal product. Your job as product manager is not to defin the ultimate product, it's to defint he smallest possible product that will meet your goals."- While most work the engineering teams do comes from product, engineering teams should reserve some amount of time (the author used 20% when he worked at eBay) for refactorings, rearchitecting, and other internal technical changes that are unrelated to product.- Great product people may already exist in your organization if you look around. The author suggests that they often come from engineering.- Product managers should be passionate and evangelize internally. They "inspire the rest of the product team, and the passion for a product is contagious."- Empathize with your target market, but don't slip into the trap of thinking of yourself and your friends as being the target users, even if it's partially true. Related: "It can be dangerous for a product manager to have too much domain expertise, because they believe they can speak for the target customer, and that they are more like their target customer than they really are."- Engineering knows what's possible, so they are an important input to the product discovery process.- Product marketing knows of broad unaddressed needs in the marketplace, making them another important input to product opportunities.- Good revenue vs bad revenue: the former enhances your Net Promoter Score and expands your market, the latter does the opposite -- for example, adding customized features for one banner customer, what the author calls "specials."- Product management should be a top-level organization, not placed as a subset of engineering or marketing (two common org structures). The design team can be part of the product org.- "Conduct the real meetings before your official meeting." Get buy-in from key stakeholders beforehand. "The formal meeting still has an important purpose, which is for every at the table to see that everyone else is on board."- "Opportunities for new products exist all around us, in every market -- even mature markets. This is because what is possible is always changing."- Product should always be working well-ahead of engineering, to keep engineering teams fed with new work when they finish their current projects.- "Review the business performance of products that have launched, typically 3 - 6 months post-launch. This sort of accountability will help the council better understand which investments and decisions they made were good ones, and why."- The author strongly favors high-fidelity prototypes (e.g., they look like the real thing, not a rough paper mockup) as they are cheap to create nowadays and give better results when validating the prototype with users. High-fidelity prototypes are also great for engineering teams, because it's extremely clear what needs to be implemented.- On the importance of reference customers at launch time: "Potential customers need to know that this product really works for people like them."- Building a customer advisor board of charter around six customers will help in the feedback process for a new product, and also provides real customer references at launch time. Think of these charter users as development partners, and treat them as colleagues.- "Winning products come from the deep understanding of the user's needs combined with an equally deep understanding of what's just now possible."- Use "personas," archetypes of an imaginary but plausible user that describes a particular customer segment you're targeting.- If there are technical feasibility risks (e.g., something that might be hard or impossible for engineerings to implement), get with an engineer to address them early, during the prototype phase.- Do your own user testing, ideally in person.- Take care to avoid accidental "user abuse" -- surprising changes in your product, especially ones that create incompatibilities. Even releases too many changes in too short a time period ("change fatigue") can be a type of user abuse.- "As a general rule, users don't like change. Sure, they want the software to be great, and they clamor for new functionality, but most people aren't excited about taking the time to learn a new way to do something they can already do."- The author describes what he calls "gentle deployment," which is a way to cautiously and respectfully roll out changes to a large usercase. This includes techniques such as rolling out both the old and new versions alongside each other, with a link somewhere inviting users to try out the new version, long before the new version becomes the default.- Make sure to reserve product, engineering, and design resources to follow up on feedback in the week or so following a big product or feature launch.- Great ideas almost always come from the bottom up, not top-down product strategy. Use techniques like Google's 20% time or skunkworks teams to encourage this.- "Build relationships before you need them."- On working in large organizations: "Pick something worth fighting for, where the outcome truly matters. When you do fight, make sure you're fighting for your product and not against another person." And: "Triage your meetings ruthlessly." And: "Evangelize! Explain the vision and strategy, demo the prototype, and share customer feedback. Don't underestimate the importance of this internal sales function."- "Knowing how to get feedback on product ideas is probably the single most important skill for product managers."
Do You like book Inspired: How To Create Products Customers Love (2008)?
Definitely some good points in here. But I would recommend skipping around quite a lot.
—NAZERKE
great book on product management. attention product managers: read this
—nhill8
Great book. Give great information on details of Product Management.
—eastlake1
A must read for anyone even considering creating a product.
—sas
