This week I finished reading Inspired: How To Create Products Customers Love. It’s by Marty Cagan, who was formerly a big deal at HP, eBay, and Netscape. I’ve read a ton of books over the past year, and this has easily been the most valuable business book I’ve come across recently. Doing a startup can be such a confusing and hazy process: “I don’t know what I’m doing!” “Am I doing the right things?” “Am I going down the wrong road?” “There’s no one to give me all the answers!”

True, critical thinking is a crucial skill. But this book has helped teach me how to think.

I really like this one: it’s staying in my library. If I ever hire a product manager, this book is going to be part of the training syllabus.

Let’s talk about the reasons it was so valuable:

• I strongly feel (and think) that I am going to be more organized in how I think about business. I feel more confident, and less like I’m in the middle of a chaotic whirlwind.
• Reading the book helped inspire what I think will be big improvements to my business strategy, but also real things I can implement today: A/B tests to try, concrete ways to improve my customer service/satisfaction, etc. I added about 16 lines to my long-term TODOLIST…
• It uses ideas that are popular in the “Lean Startup”/”Customer Development” movements and presents them in a cohesive and coherent framework. However, I have been thinking/reading/hearing about these ideas for a while, so the prior exposure (schema foundation) perhaps helped them finally fit into place. Then again, this is perhaps an example of the ATTRIBUTION ERROR: my circumstances have changed (I’m spending lots of time actually working on products rather than reading about other people doing it), and therefore have more personal-experience nodes in my semantic web, which is helping everything fit into place.

Two important caveats:

(+) This book is intended for people managing web software, but its principles can easily be extended to other kinds of business.
(+) I am not deeply experienced! These are all concepts that sound appealing on paper and have been very successful for certain people, but I don’t have any empirical knowledge that they’re successful, save from my own minor successes — my process in the past has applied similar ideas, but they haven’t been as well articulated/defined and conceptually separated!

Ok, onward…here are the nine big ideas (the concept of “Big Ideas” is borrowed from my friend Brian Johnson, author of the Philosopher’s Notes series as well as the new book A Philosopher’s Notes – On Optimal Living. A must-read…)

(1) Successful products are Valuable, Usable, and Feasible. It is the product manager’s job to discover a product that’s VUF: “the central responsibility of the product manager is to make sure that you deliver to engineering a product spec that describes a product that will be successful”.

(2) Engineers think in terms of implementation models. Users think in conceptual models. If you spot a product whose User Experience is built based on implementation rather than user conceptual models, there’s probably an opportunity to innovate.

(3) Charter User Programs: try to get 10 happy, live, reference-able customers from your target market by the time you launch. Not “Early adopters” — real customers who feel the problem pain hard and recognize that they want to solve it. You explain to them your goal is not to build a custom solution but instead a sustainable business; you are deeply committed to building a product that works for them. And they will pay for it: (once you deliver them a product they love — they don’t have to pay to participate in the program). You will be showing them prototypes, testing with their users, asking hundreds of detailed questions, testing release candidates in their environment. If you are having trouble recruiting reference users it means you’re chasing a problem that isn’t very important: this is a really, really important reality check. And when you launch, they’re happy with it, and happy to provide you a testimonial.

(4) There’s a difference between a UX (user experience) designer and a Visual Designer. The UX designer is an interaction designer, whose job is to determine tasks, navigation & a workflow that’s VUF. The product manager listens to problems; the UX designer designs solutions. The UX designer should be heavily involved in creating the prototype for customers to use.. they should have an active involvement before engineering gets involved. Once the prod mgr/UX designer have determined a VUF product, then it should get passed on to engineering. Step 1, UX design. Step 2, Engineering builds the product based on the high-fidelity prototype. This is to be done in serial, not parallel! In other words, the ultimate job of the UX designer is to make wireframes (which engineering uses to make a crude but high-fidelity prototype).

Once engineering has the finalized high-fi prototype [see idea #9 for a discussion of prototype] in their hands, THEN the visual designer can step in. They can take take the wireframes, and determine the look & feel. They can choose the layout, colors, and fonts — choosing how to communicate & evoking emotion in the product.

If you are in a startup and have antsy engineering resources, who are itching to work on something, once you have a vague notion of how the prototype is going to function, you can have them start preparing infrastructure for later: continuous integration; staging/dev/production environments; testing; SCM best practices. And give engineering 20% headroom in order to rewrite, rearchitect, refactor, etc. Think of this as a tax you must pay.

Still confused? Here’s a diagram I made to illustrate. I think in real life, especially in small start-up companies, one person will probably play the role of both product manager and the UX designer.

Diagram illustrating relationship between Users, UX, Product Manager, Engineering

(5) There’s a difference between product management and product marketing. Product marketing is responsible for generating awareness of a product and getting it into the hands of customers. Product management is responsible for building a great product that customers will love. It is rare that someone can be skilled at both roles – and at the very least, separating the roles conceptually enables more clear thinking.

(6) Important traits for a product manager to have: this is a long list, so feel free to skip to #7.

• sense of urgency
• identify and frame problems, & run constructive meetings
• solution-focused, data-driven thinking
• decisive
• judgment. when to push/escalate/get more info/take someone aside
• product passion
• customer empathy
  • understands their values, priorities, perceptions, tolerances, experiences
  • has empathy for their level of technical understanding
  • respects them
  • works closely with the customer during every stage: on campus interviews, present for usability testing, etc.
• intelligence
• work ethic
• integrity
  • mutual trust & respect (via integrity) will make him an effective persuader
  • understanding the job of, and respecting, team members
  • handling self under stress
• confidence – persuading others that the product can / should be built
• attitude
  • no excuses
  • give credit, take blame
  • knows team is realizing HIS product vision
• applying technology
  • knows what’s possible.
  • e.g., reading sites like Hacker News to make sure has knowledge of latest technical developments
  • many products emerge because they are just now possible to build, thx to technical innovations
• focus
• eliminating features. think MINIMUM VIABLE (== valuable, usable & feasible) PRODUCT
• time management
• communication skills: speaking, writing, presenting
  • recommended book on presenting: Weissman’s *Presenting To Win*
  • presentations have few slides – the presenter is knowledgeable — and they have Relevant data points
  • unambiguously states main points & what he needs from the audience
• business skills: finance/marketing technology, MBA-style
• domain expertise:
  • dangerous, because makes assumptions about domain/customer/market that go untested
  • should take 1-3 months of aggressive catching up to get up to speed in product domain: OK to hire smart & capable/skilled people otherwise unfamiliar
• use data & facts when presenting potential options — not opinion. the HiPP (highest paid person) gets to decide/ offer opinion
• low-maintenance: writes short emails
• when meeting about features/product decisions, determine consensus privately, before voting in a public forum
  • this may or may not be a wise general principle – for “politicking” –aka group social skills
    • corollary: “a fair fight is the result of poor planning” (see my discussion of Warfighting)
• knows the product principles ~ guiding values/ethics for product, and prioritization of them. knows goals and objective for product: can utilize this frame during difficult decisionmaking. Personal Development blogger Steve Pavlina has articles on values, and i found these (one and two) to be especially helpful.

(7) Net Promoter Score: ask your customers how likely they are to recommend the product, on a scale of 1-10?
- 9-10 are evangelists. 7-8 are neutral or lukewarm. 1-6 are detractors and may actively be campaigning against you
This frame helps you understand that doing custom client work may be worthless in that it is not an investment in NPS, and should be considered accordingly.

(8) Typical corporate paradigm. PM creates MRD (marketing requirements document), assessing opportunities. Then creates PRD (product requirements document), a solution /spec for engineering to build on. Better model is the Product Opportunity Assessment!

1. Exactly what problem will this solve? (value proposition)
2. For whom do we solve that problem? (target market)
3. How big is the opportunity? (market size)
4. How will we measure success? (metrics / revenue strategy)
5. What alternatives are out there now? (competitive landscape)
6. Why are we best suited to pursue this? (our differentiator)
7. Why now? (market window)
8. How will we get this product to market? (go-to-market strategy)
9. What factors are critical to success? (solution requirements)
10. Give the above, what’s the recommendation? (go or no-go)

(9) A typical “spec” document will have features listed in a P1/P2/P3 trichotomy: P1 = must have; P2 = high want; P3 = nice to have.
Instead, build a high-fidelity prototype before having engineering build the real product.
The prototype should only be shipping the minimal VUF feature set: “P1″ only. You can use dummy data / faked back-end processing, etc., but all the features that will be in the real, shipped product should be present in the prototype. This forces you to judiciously evaluate product requirements.
Though high-fidelity to feature requirements, the prototype is to be thrown away later — you should not build reusable code here; strictly “duct tape” code.
You can then put the prototype in front of actual users, and ask them if it’s valuable. You can also see if it’s usable.
It’s easy to make HTML&CSS prototypes, even for android/iphone thanks to cool CSS frameworks.

This is a book that I suspect I will coming back to time and time again… it’s convenient, too, because the book is organized into 41 discrete chapters. I have left the author, Marty Cagan, a 5 star review on Amazon. The book costs $29.35 on Amazon but only $9.99 on Kindle. I opted to read to get the hardcover, which is great because Kindles are difficult to flip through – and difficult to loan to people.

AwesomenessReminders: a great and hilarious way to show someone in your life that you care.
AwesomenessReminders is owned and operated by me, Zachary Burt.