How to create products customers love

I attended a webinar by Marty Cagan of the Silicon Valley Product Group, where he discussed some a "top ten" elements from his new book, Inspired: How to Create Products Customers Love.  The webinar will be archived at the FeaturePlan website.

He started out by reiterating the highlight of his webinar from March: The job of the product manager is to discover a product that is valuable, usable and feasible.  Thinking about this from my perspective of having been a product manager for three times as long as my tenure in March, it's interesting to see that the first elements of this role have to do with the customer.  It's only the last element that has to do the technology and the business.

Here are the ten elements he discussed with some of my recollections of his discussion.

1. Make sure you know what problem you are trying to solve - and that it's worth solving.  Don't start building something before you know what the problem is; who you're solving it for; and what success looks like.  I like that last element: define success, define "done."
2. Create a product strategy so you know what you're trying to achieve.  This is clearly linked to the first item, but Cagan also talked about the value of having this strategy or vision to guide and motivate the development of the product.
3. Create a prioritized set of product principles so you know the nature of the product you're trying to build.  Again, this builds upon the previous point.  What principles do you have?  Are you building for ease-of-use; for security; for a specific type of user?  What do you want the product to be?
4. You simply won't get great products by asking customers what they want.  This one is tricky - he's not saying to ignore customers completely.  But it is the product manager's responsibility to create a product that customers are willing to buy after you've built it.  He highlighted the particular need to lead customers to where they need to be, rather than following them.  (This is as opposed to project-base products, which are designed to a customer specification.)
5. Don't try to define/design by committee.  Instead, empower the three key people to help define the product.  Product manager defines the function / value.  User experience lead defines form / usability. And the engineering lead: technology / feasibility.  Note the connection back to Cagan's key elements of value, usable, feasible.
6. Realize that function (requirements) and form (design) are completely intertwined.  It's not possible to define function without thinking about design, and design always inspires new ways of thinking about the function.  There was a bit of discussion around the impossibility of the waterfall method of development, which starts with requirements and then designs around them, as if they are separate elements.  How many times have you seen a new design to a product inspire new ideas about how the product could be used - or new ideas about what the product should do?
7. If mostly what you do is race to add features, you're probably not helping.  Adding features is a following activity, not a leading activity.  Cagan claimed that most problems with products have little to do with whether they are missing features - it's just that the existing product does not deliver its features very well.
8. As important as the engineering is, the user experience design is even more important, and usually more difficult.  Just have a look at most business software, and you know the problem.  Cagan suggests, as he did in his previous webinar, that there should be about 2 user experience people per product manager for companies that sell user-facing software.  "Engineers are trained to think about how the computer solves the problem. User experience people are focused on how people solve the problem."
9. "Don't waste your time with PRD" - Use high-fidelity prototypes instead of words.  Cagan does allow for short documents that articulate what can't be shown in a prototype, such as the equations for internal calculations.  I am in deep agreement with this one.  I much prefer to see and play with prototypes over reading documents or even drawings.  It helps me understand everything that I missed in the written documents - even when I did the writing.  Prototypes also give you something realistic to test on users.  He made an interesting comment that prototypes help the product manager to "narrow down to the minimal product" rather than building a behemoth.  The other thing prototypes provide is a communication vehicle - requirements documents are hard enough to read for the people deeply involved in the project.  Just imagine giving those to the marketing or sales teams.
10. "Fail fast" - It's all about trying out your ideas on real users - before you build anything permanent.  In other words, get those tests going early and often.  And test with real customers.