(notes on) ‘Inspired: How To Create Tech Products Customers Love’ by Marty Cagan
NB. These notes contribute towards my diyMBA, my attempt to learn lots without a formal MBA programme. Check out my full reading list, and why I’m doing it DIY.
In summary, this book is a must read for anyone taking their first steps into Product Management or working alongside software development for the first time. It outlines the skills needed to be a great PM, how to organise teams, and the tried and tested processes to follow. For those with more experience there’s a tonne of great context that explain why the practices used actually work, and why commonly believed alternatives don’t. A dense read with little waste means these notes barely skim the surface! Buy here.
Marty is also great on Twitter, follow him here.
TLDR
A Product Manager’s role is to assess product opportunities and define products to capture these opportunities. To be successful, they’ll need an awesome, empowered team around them with clearly defined roles. Involve this team early, working together to effectively assess opportunities and prioritise your choices. Be aware of how standard processes can lead to failure, and always focus on the outcome rather than the output.
My Notes
What makes a great Product Manager?
Great Product Managers solve customers problems, so must be empathetic to understand their perspectives and insightful enough to devise an original solution. They’re great communicators and are bilingual in business and technology. They have deep understanding of the customer, the data, the business, and the market / industry.
What makes a great Product Team?
A Squad is a cross-functional team of User Experience Designers, Engineers, a Project Manager, and Product Marketing.
The team must be:
- empowered and accountable
- autonomous (mostly). They’re able to try and solve the problem in the way they see fit
- supported with input from others in the company
The best teams:
- tackle risks first
- define & design collaboratively, not sequentially
- solve problems (not implement features) and focus on business results.
The Importance of User Experience Design
Design must be involved early with all processes complete before engineering begin building. Key roles are…
- An Interaction Designer, who understands users thinking and requirements and creates a wireframe.
- A Visual Designer, who builds the look and feel of the product on top of the wireframe.
- A Prototyper creates prototypes of the product.
- A Tester tests these products with perspective users.
Scoping Opportunities
A Product Opportunity Assessment (POA) evaluates opportunities through these series of questions.
- What problem does this solve?
- Who are we solving it for? How big is that market?
- What alternatives exist? Why are we the ones who’ll succeed?
- What factors are critical to our success?
- How will we define & measure success?
- Why is now the right time? What is our go-to-market (GTM) strategy?
- Therefore, is this a worthwhile opportunity to pursue now?
Product Principles and Personas help navigate choices
PMs are faced with many choices. Which feature to include first? What task is most important? Every stakeholder is likely to have a different opinion.
Once you have a product vision (the future you want to create) and product strategy (what path will help you achieve it), product principles will help guide you towards the nature of the actual products you want to create.
Eg at eBay: “In cases where the needs of the buyers and the sellers conflict, we will prioritize the needs of the buyer, because that’s actually the most important thing we can do for sellers.”
Personas, fictional user profiles, will also help guide you. Build to meet the needs of a specific persona, not all.
Principles of Product Discovery
- Value Risk : Will the customer buy this, or choose to use it?
- Usability Risk : Can the user figure out how to use it?
- Feasibility Risk : Can we build it?
- Business Viability Risk : Does this solution work for our business?
What Causes a Product Effort to Fail?
The standard process is Idea — Biz Case — Roadmap — Requirements — Design — Build — Test — Deploy
But why does this process fail?
- When the Idea comes from internal executives or existing external partners, there’s no team empowerment.
- The Biz Case asks 1) How much will it make? and 2) How much will it cost? Both are impossible to answer so the opportunity is misjudged
- Two inconvenient truths about Roadmaps 1) Half our ideas aren’t going to work, 2) It’ll take many iterations to work.
- When scoping Requirements, some individuals (PMs, Design, Engineering, Agile) aren’t involved early enough.
- When a product is too project focussed. Projects create outputs but Products create outcomes.
- When Testing and customer validation happens at the end of the process, its way too late.
Overcome these pitfalls by focussing on outcome rather than output. Each item should be a business problem to solve rather than a feature to build.
Key Concepts & Definitions
Holistic Product. The features, technology, user experience, monetisation functionality, method of acquiring users, and offline experiences all contribute to the holistic product.
Continuous Discovery & Delivery. Discover the product to be built, and deliver it to market.
Product Discovery. Tackle risk and separate good ideas from bad. Answer these questions. 1) Will they buy or use it? 2) Can they figure how to use it? 3) Can we build it? 4) Will our stakeholders support it?
Product/market fit. The smallest product that meets the specific market needs.
Product Vision. The long term objectives, and how it will deliver the company’s mission.
Minimum Viable Product (MVP). A prototype, not an actual product, that helps you learn directly from your users.
