Inspired: How to Create Tech Products Customers Love – by Marty Cagan
Date read: 1/9/19. Recommendation: 7/10.
A valuable resource for technology teams that’s tailored to product management. Cagan discusses the principles of strong product teams and breaks down the individual roles–product managers, designers, engineers, product marketing, and other supporting positions. He also discusses the process of getting to the right product through discovery, ideation, prototyping, and testing. At times it can be a bit prescriptive and could use a few more stories to illustrate the concepts and techniques. But overall, worth the read for entrepreneurs operating in this space or those looking for an introduction to technology product management.
See my notes below or Amazon for details and reviews.
My Notes:
The best product teams share three main principles:
1. Risks tackled up front (value, usability, feasibility, business viability)
2. Products are defined and designed collaboratively
3. Focus is on solving problems, not implementing features
Product/market fit: smallest actual product that meets needs of a specific market of customers.
Product Manager key responsibilities (all focused on evaluating opportunities and determining what gets built):
1. Deep knowledge of customer (issues, pains, desires)
2. Deep knowledge of data and analytics
3. Deep knowledge of all aspects of your business (stakeholders, finance, marketing, sales, legal, technical capabilities, user experience)
4. Deep knowledge of your market and industry
Successful product people are a combination of smart, creative, and persistent.
VPs of Product should have these four key competencies:
1. Team development
2. Product vision
3. Execution
4. Product culture
How to organize teams:
1. Alignment with investment strategy
2. Minimize dependencies
3. Ownership and autonomy: build teams of missionaries (they’re force multipliers), not mercenaries
4. Maximize leverage: establish a balance with shared services
5. Product vision and strategy
6. Team size: 3-10
7. Alignment with architecture: otherwise dependencies, slow pace
8. Alignment with user or customer: team focused on buyers should be different than the team focused on sellers
9. Alignment with business
Management’s responsibility is to provide product teams with business problems, objectives, and vision (NOT solutions). Let the team figure out the best way to solve the problems.
Product Discovery:
Collaboration between product, UX, and engineers to tackle risk before writing production-quality software. Outcome is a validated product backlog.
Purpose is to address value, usability, feasibility, and business viability risks.
Goal is to gain deeper understanding of customers and validate product ideas (qualitatively and quantitatively).
Dedicating time to framing the problem and communicating this can make significant difference in results.
“But one of the most important lessons in our industry is to fall in love with the problem, not the solution.” MC
Opportunity Assessment Technique:
1. What business objective is this work intended to address?
2. How will you know if you succeeded?
3. What problem will this solve for customers?
4. What type of customer are we focused on?
Customer Letter Technique:
Product manager writes an imaginary press release or letter from hypothetical perspective of a customer talking about how it has improved their life.
Product Opportunities:
Assess the market and pick lucrative areas where pain exists. Or look at what technology enables and match that up with a pain point. Or encourage customers to use products to solve problems other than what you planned for.
One of biggest innovations at eBay was watching how customers used platform to sell things the team never would have imagined (concert tickets, fine art, cars). Built capabilities to facilitate these types of transactions after demand was established.
Customer Interviews:
Always be working to understand if your customers are who you think they are, if they really have the problems you think they have, how they solve the problem today, and what would be required from them to switch.
Prototypes:
Provide the ability to learn at much lower cost (time and effort) than building the full product.
Always ask, “what’s the fastest way to learn this?” MVP should be a prototype, never an actual product.
Benefits of prototyping: forces you to think through the problem at a deeper level, team collaboration, quickly assess one or more of the product risks.
A/B Testing:
Optimization A/B testing: Small changes, different calls to action, colors, fonts. 50/50 distribution. Conceptually similar.
Discovery A/B testing: Big differences, different concepts. Live-data prototype shown to 1% of users or less.
Necessity leading to invention:
In the early days of Netflix they had the same model (pay per rental) as Blockbuster. One of the many tests they ran was to assess customer interest in a subscription service (monthly fee for unlimited movies). They generated significant interest but created more problems in the process of bringing it to life. Most people wanted to rent the newest films which was prohibitively expensive. Netflix needed to get people to ask for a blend of old/new (inexpensive/expensive) titles. This was how the queue, rating system, and recommendation engine were born.