Inspired – my reading notes

These are my notes from the book: Inspired – How to Create Tech Products Customers Love by Marty Cagan

I read this at the beginning of 2026. I was not planning to become a product manager. But was a tech lead in a product company. So I assumed it could only help me to learn basics and understand better peripheral areas. Especially nowadays, when with the rise of Gen AI prototyping is even easier, and the boundaries between engineers and product managers blur.

0. Intro

Examples: https://www.svpg.com/examples/

Engineers think in implementation model. Users think in conceptual models.

1. Key roles and responsibilities

2. Product management vs product marketing

Three common scenarios:

• marketing-driven product
  • the rest of the product team views this person as a marketing resource e.g. defining pricing, naming etc
• two people, one role
  • e.g. business owner + product owner. One for defining “high-level” requirements, the other “low-level”. No one feels responsible for the product
• two roles, one person
  • even if the person has the skills, does not have capacity. The product requirements coming from big customers are just passed to the engineering team.

Product manager is responsible for defining the product and validating it with customers.

Product marketing is responsible for telling the world about that product, including positioning, messaging, pricing, managing the product launch, providing tools for the sales channel to market and sell the product

3. Product management vs project management

Combining these roles made sense in shipped software products because the product equals the project (release).

Skills that characterise good project manager:

• sense of urgency
• framers – concisely identify and frame problems and run constructive meetings
• clear thinking – isolate separate issues, emotions, politics
• data driven
• decisiveness – must drive decisions yet the team members do not report to them
• judgement – instinct when to push, escalate, take someone aside, get information
• attitude – looking for ways to solve the problem, not obstacles and excuses that block the project

4. Product management vs design

It’s fine to outsource ui design, qa, user testing, but interaction designer should be in-house.
It takes time to develop understanding of the users, during development a lot of questions pop up, and ux is core to the company.

5. Product management vs engineering

Building the right product vs building the product right.

Engineering and product management are peers.

Makes sense to invite engieers to user testing so that they can see struggles first hand.

Also involve engineers or at least a tech lead from the very beginning of product discovery to get early cost assessment.

Making “headroom”, so that you don’t hit the ceiling, to prepare for user growth. Around 20% should be left for engineering to improve the platform.

6. Recruiting product managers

• personal traits and attitude
  • product passion
    • what are your favorite products? How would you improve them? What are bad products, why?
  • customer empathy
    • how they see the target market
  • intelligence
    • solving problems you don’t know answer for
  • work ethic
  • integrity
    • product manager doesn’t manage people directly so most of it happen via influence.
    • also doesn’t have the skills so must respect and trust other team members
    • the product team will watch how the PM is dealing with pressure e.g. to deliver faster or add a special feature for a special customer
  • confidence
    • because you have to convince people that whey they invest their effort in it’s worth it
  • attitude
• skills
  • applying technology
    • you need to understand how it can solve problems
  • focus
    • “the main thing is to keep the main thing the main thing”
  • time management
  • communication skills
    • speaking, writing, presentation
    • reference: presenting to win by Jerry Weissman
  • business skills

Domain knowledge is usually not a requirement. It can be learned within a few months. Sometimes too much expertise can be a trap either because you may think you understand customers very well without challenging your assumptions.

7. Managing product managers

If you empower people who aren’t capable, you are abdicating your responsibility as a manager. And if you micromanage people who are not capable, you are essentially doing their job for them.

Each product manager optimizes their product’s roadmap. Head of product is managing the portfolio roadmap, so must resolve cross-team conflicts.

NPS (Net Promoter Score) is a nice metric to measure the product success.

There is good and bad revenue. The bad one: it can bring short-term revenue but hurt overall experience. E.g. doing special work just for one customer.

Where should product managers live?

• sometimes they belong to the marketing organization
  • in this case the product manager often is mixed with the product marketing
  • it’s based on the misconception that you get good products only from talking to customers
• sometimes they belong to the engineering organization
  • engineering focuses on building the product right. The product manager can be consumed in details and pressured to write detailed specs
• ideally they should have their own
  • with their seat at the executive table
  • design should belong to this organization
• if the company has business units and centralized engineering, it’s better that product managers sit with the business units

8. Patton’s advice for product managers

“Never tell people how to do things. Tell them what to do, and they will surprise your with their ingenuity” – general George S. Patton, Jr.

Customers and users may be telling to how the product should look like, but won’t tell you what problem they are solving.

Similarly product manager should focus on the problem, and not tell the designers how to design or give super specific details how to build to engineers .

9. Deputy product managers

Smart people with great product ideas may be hiding at all levels and organizations of the company. Not recognized because of ego, xenophobia, ageism.

• ask
• management by wandering around
• listen
• keep your door open
• share if you struggle with something
• hang out

10. Managing up

• measure and plan for churn
  • churn in a sense – plan changes
• communication style and frequency
  • adjust to your manager’s preference
• pre-meeting work
  • get all stakeholders onboard before the official meeting to make it quick and efficient
• recommendations, not issues
  • come with solution recommendation
• use your manager
  • they have more influence and access to people
• do your homework
  • think what questions may come up
• short e-emails
  • the more senior the manager, the more busy they are, the shorter the communication with them should be
• use data and facts, not opinions
  • netscape CEO: “if we’re going to make this decision based on opinions, we’re going to use my opinion”
• evangelize
  • make people in the other organizations excited about the product so that they are more likely to offer support
• low-maintenance employees
  • don’t make your manager handhold you

11. Assessing product opportunities

Product opportunities change e.g. because new technology arises, new people join the company, competitors come and go

Key questions to assess opportunity:

• exactly what problem will this solve? (Value proposition)
• for whom do we solve that problem? (Target market)
• how big is the opportunity (market size)
• how will we measure success (metrics/revenue strategy)
• what alternatives are out there now (competitive landscape)
• why are we best suited to pursue this (our differentiator)
• why now (market window)
• how will we get this product to market (go-to-market strategy)
• what factors are critical to success (solution requirements)
• given the above what’s the recommendation (go, no go)

Should you invest in new or existing products? The one that has bigger opportunity. E.g. if 9% of people who start the substitution process finishes it, if you go to 18% you doubled the revenue. And sometimes it can be very easy fix.

Do you understand the economics of your product? Do you know:

• exact revenue model?
• The total cost of your product?
• How much you pay for each new customer?
• Their lifetime value to the company?
• The return your product has generated for the company?

12. Product discovery

After discovery phase (what to build), you have to switch mindset into execution mode. Otherwise the quality drops and deadlines are missed. Instead, after the discovery phase, you start building v1, and in parallel do already a discovery for v2.

13. Product principles

Example:
For a movie site – the team believes that the user community’s reviews are more valuable than the ones made by professional reviewers.

Principles help decide what to build and align different teams.

Can’t be to generic (“must be reliable”), shouldn’t be confused with design principles (“user should know what to do next”).

Principles need to be prioritized. You need guidance to decide e.g. ease of use against safe and secure.

Resolving conflicts:

• what problem exactly are you trying to solve
• who exactly are you trying to solve this problem for (which persona)
• what are the goals you’re trying to satisfy with this product
• what is the relative priority of each goal

14. The product council

https://www.svpg.com/the-product-council/
It’s not to define business strategy. Rather, given business strategy help define product strategy. Also provide oversight of product efforts.

• milestone 1: Review proposed product strategies and product roadmaps, and initiate opportunity assessments for specific product releases. That is, select the product opportunities to be investigated
• milestone 2: Review opportunity assessments and recommendations, and issue go/no-go decisions to begin discovering a solution.
• milestone 3: Review product prototypes, user testing results and detailed cost estimates, and issue go/no-go decision to begin engineering
• milestone 4: Review final product, QA status, launch plans, and community impact assessments, and issue go/no-go decision to launch.

Estimates:

• at the opportunity assessment time the estimates should be preliminary: “small, medium, high”
• at the solution phase we are able to invite somone from engineering to help estimate more precisely.

15. Charter user programs

Also known as Customer Advisory board, Customer council, Voice of the customer.

Usually up to 10 customers. More it’s hard to manage.

Benefits for users that join:

• significant product input. They feel the pain and they want to make sure it’s solved
• early access to the product – getting relief earlier
• sometimes reduced costs
  Benefits for you:
• customers available for ongoing questions
• customers test and provide feedback early
• if they are happy they serve as a reference

It’s important that they do not pay before joining. You are not building a custom solution for them. It’s a different relationship. Explain this to them, that you’re building a general product.

If it’s hard to recruit customers, it may be the first reality check that you’re solving the wrong problem.

Make sure these customers are really your target market, and not “early adopters” who are usually more tolerant

You can get reports from sales, marketing or customer support but the most valuable source of information for product manager is talking and interacting directly with the customers

16. Market research

Tools:

• Customer surveys
  • you need to have good questions to avoid bias, and “garbage in, garbage out”
• Site analytics
• Data mining
• Site visits
• Personas
• Usability testing
• Competitive analysis
  • what your competition does right

They help you answer these questions:

• Do you understand who your users really are?
• How are users using your product?
• Can users figure out how to use your product? Where do they stumble?
• What do users like about your product?
• What do users want added to or changed in your product?

But good products are not created by market research. They come from deep understanding of the user’s needs combined with an equally deep understanding of what’s just now possible.

Focus groups do not provide good input.
Customers do not know what’s possible, and they their opinions are skewed by the most loud people in the group.

17. Personas for product management

Reference: “The inmates are running the Asylum” by Alan Cooper.

• They can help prioritize: we can do the work for “Sam” but if it’s only for “Bill” we will not do it
• They highlight different type of users e.g. admins, managers, end users

You need to prioritize the personas.
Also make sure you create them on actual users and not hypothetical stereotypes.

18. Reinventing the product spec

High-fidelity prototypes solve many of the issues with written spec.
It’s more tangible to give feedback on, so reduced time-to-market.
It captures the full user experience.

19. Design vs implementation

Requirements and design should be done at the same time. Same with development and testing. But UX design shouldn’t be mixed with engineering.

• once the development begins it’s difficult to make significant changes
  • partly it’s psychological – it’s hard to take a step back
  • partly it’s practical – the clock is ticking and rework just compound pressure for the team
• you can’t wait the whole sprint to get feedback. You need to test it out quickly
• you need prototypes. They need to be truly disposable.
• while it makes sense to break the releases into smaller pieces, you have to look at the ux holistically

It makes sense to use the “sprint zero” to work on design before implementation starts. The exception could be if there is a lot of infrastructure prep work that needs to happen.

20. Minimal product

Don’t define features as “must have”, “should have”, “nice to have”. Instead create high fidelity prototype that already contains minimal functional requirements. The engineering team can already estimate based on the prototype. If you then have to cut the features, you didn’t come with minimal requirements before.

The prototype must be tested with users as well. You don’t trust engineers to build the code right – you test it. The same you shouldn’t trust product managers they define the right product.

The most common reason product managers request changes to the spec is a consequence of not really thinking through the requirements in the first place.

21. Product validation

• Feasibility Testing
  • what is possible with the current technlogy
  • done by talking to engineers
• Usability testing
  • it will uncover missing product requirements but also which are not necessary
  • it checks if users can figure out how to do certain tasks
  • done with prototypes
• Value testing
  • it checks if the users actually care about these tasks
  • done with prototypes

22. Prototype testing

• finding test subjects
  • e.g. charter user program,
  • fare trades for business products,
  • family and friends for consumer products
  • advertising on website
• preparing the test
  • define in advance the set of tasks you want to test
  • don’t waste the first-time visitor experience by directing the users straight to the prototype. See how they approach the problem from the very beginning
• the test environment
  • you can have a dedicated lab but the table at the cafe is as good.
  • going to the customer’s office can also bring valuable insight e.g. see their environment, gear
  • remotely you can’t easily see eyes movement or body language
  • it’s crucial that product manager attends the testing session to see the subtle signals
  • it’s useful to have someone to take the notes and to discuss with whether you saw the same thing
• testing your prototype
  • be clear that
    • this is just a prototype, it’s not real
    • they won’t hurt your feelings by giving their honest opinion
    • you’re testing the prototype, not them
  • you need to stay quiet and overcome the urge to help when you see users struggle
  • you can act like a parrot to prompt the users to talk. E.g. “I can see you look the list on the right” – and they may tell you what that are looking for
• updating the prototype
  • it’s fine to update the prototype during testing. You don’t need to wait the whole round
  • after for example 6 users in row didn’t struggle that could be a signal you’re done.

23. Improving existing products

It’s not only about adding new features. Analyze metrics and try to find where the pain points are.
E.g. you don’t need to ask for this information at this stage. Or maybe you don’t need it at all? If currently 7% of users who start the purchase flow finish it, moving it to 14% basically doubles the revenue.

24. Gentle deployment

User abuse. Users may not want new changes.

• They are not in a mood for a new version.
• They don’t want to learn how to solve the problem that they already knew how to do,
• they have processes and documentation around your software.
• The new change doesn’t work
• they are fatigued from the previous changes

You can let them know in advance e.g. newsletter, tutorials. But not everyone reads that.
It may make sense to run to versions in parallel. But this is technically more difficult.

25. Rapid response

The product launch is not a success yet. The first days have the biggest potential to fix issues. It makes sense to reserve the time a few days after project launch.
Monitor the metrics, define success criteria.

26. Succeeding with agile methods

The scrum method originated in a custom software world. Customer doesn’t know exactly what they want, so after the smaller iteration they can correct.
Product teams have different challenges because they want to satisfy multiple customers. Scalability issues may be the case, while for custom software it usually serves internal teams.

For product teams, the product manager and designers should be a sprint ahead of the engineers to validate the idea.

Don’t launch every sprint. Let the product manager assemble a defined release – to avoid too much change and upset users.

27. Succeeding with waterfall processes

• it’s not the best choice for product management
  • validation occurs late in the process
  • changes are costly and disruptive
  • responding to market is harder because the process takes longer

28. Startup product management

Usual approach is that someone with an idea gets funding, then the founder hires engineers and acts as a product manager and a designer. The team build something, the spec changes all the time. Then it’s presented to users and it’s underwhelming.

Instead the founder could hire product manager, a designer and build a prototype. Many of them actually. Startups are all about product discovery.

29. Innovating in large companies

Large companie are more risk-averse. They have more to lose.

• innovation via the 20% rule
  • people could spend 20% of their time doing projects they want.
  • great ideas often come from the bottom up
• innovation via skunk works
  • chasing ideas under the radar to avoid bureaucracy, as long as you meet requirements
• innovation via observation
  • observe how users struggle with the product
• innovation via user experience design
  • what is the idea solution? What is really essential and what is there just because it’s a side effect of the way the product was designed and built
• innovation via acquisition
  • letting startups understand the market and the acquiring one of the few that remained

Peter Drucker: “Every organization needs one core competence: Innovation”

30. Succeeding in large companies

1. Learn how decisions are really made in your organization
2. Build relationships before you need them
3. Long live skunk works
4. Just get it done
   1. Sometimes you may need to do work that’s not part of your job to move things forward
5. Pick your battles
   1. Make sure you’re fighting for your product and not against another person
6. Build consensus before important meetings where decisions are required
   1. Once someone opposes your idea in public it will be harder for them to publicly switch opinion
7. Be smart about how you spend your time
   1. Attend the meetings you must, but get used to trust your colleagues to do their jobs
8. Share information
9. Put your manager to work
   1. Leverage their relationships
10. Evangelize
    1. You need to continuously spread the word, explain the vision and strategy, demo the prototype, share customer feedback

31. Lessons from apple

• hardware serves the software
• software serves the user experience
• user experience serves the emotion.

That’s why people want to pay 2x for a phone that may have similar specs like others.

32. Beware of specials

It’s easy to confuse customer requirements with product requirements.

It’s extremely difficult for the customer to know what he needs until he sees it; customers don’t know what’s possible; customers don’t often interact with each other to identify common themes.

Your product needs to adapt to market and that’s more difficult if you’re contractually obliged to support specific features.

33. The new old thing

You don’t have enter the new market to create the new big thing.
Apple came with iPod to a mature market full of mp3 players. Or Google with search engine.

Identify what current products fall short on, and do it better.

What is possible is always changing.

Todays applications are tomorrow’s foundation. E.g. browser was an application to view a web site, now it’s used to interact with applications inside it

34. Fear, feed and lust – the role of emotions in products.

People buy and use products largely for emotional reasons.
In the enterprise space the dominant emotions are generally fear or greed: my competitors will beat me to market, hackers will penetrate my firewalls etc
In the consumer space the emotions get more personal (e.g pride by showing my musical taste).
Different people may look for different emotions in the product too.

35. The emotional adoption curve

Reference to Crossing the Chasm by Geoffrey Moore. An interview with Jeff Bonforte.

Focus on anger. Find what people are frustrated with and solve the problem.

• The Lovers : Innovators
  • the are dangerous for product managers because they buy your product for completely different reasons than majority e.g. because of the technology used
• The Irrationals : Early Adopters
  • they feel the same emotions as the general population but with more intensity.
  • they often arrive at the same time as Lovers so can be easily confused.
• The Efficients : Early Majority
  • will adopt the product when it becomes practical
• The Laughers : Late Majority
• The Comfortable : Laggards

36. Usability vs aesthetics

Both are needed because visual aspects influence the emotional part of using a product.

37. Keys to consumer internet service products

• Usability – for consumer products it is far more important that they can figure out how to use it themselves
• Personas – with so many users you have to cluster them and their needs
• Scalability
• Availability – it has to be available all the time, not only during work hours
• Customer support – you really need to optimize the cost. But of course the main goal is to ensure great customer experience
• Privacy and data protection – you handle way more PII
• Viral marketing – users can recommend the product to each other if they love it
• Globalization – prepare for internationalization
• gentle deployment
• community management

38. Keys to enterprise products

• Usability – people often use these products for the whole day; it’s rarely the same person who uses the software and makes purchasing decision
• Product actually needs to work
• Specials – do not assume that the customer should dictate how the product should look like.
• Customers and Charter User Programs.
• Designing for the sales channel – e.g. if you sell through integrators – do not try to cut them out of equation
• The customer versus the user – inside the customer there may be multiple types of end users: admins, management, support agents etc
• Product installation – it needs to be easy
• Product configuration, customization and integration – your product probably won’t be used in isolation but needs to integrate with other software
• Product update – it needs to be easy. Customer doesn’t care about migrations
• The sales process – make your product easy to try out and buy

Solution product – solves a business-level problem, often food specific industry verticals; it may be based on an integration of one or more component-level products

39. Keys to platform products

Types

• operations systems (MacOS, Windows, Android)
• operating environments (Java, .net)
• Web services (Amazon APIs)
• application-level runtimes ( Facebook, Salesforce)
• the book is old but I guess cloud providers should be listed here as well

Parties and what they care about

• application providers – pricing, licensing, availability
• developers – ease of building
• end users – the end result