Inspired
written by by Marty Cagan
1/16/20247 min read
Previously I read this book several times, and nowadays I wanted to go over it again. Here you can find my key takeaways from Inspired! Unlucky that we do not have the Turkish translation still!
Lets start!
About being a Product Manager (Smart, Creative, and Persistent )
The honest truth is that the product manager needs to be among the strongest talent in the company. If the product manager doesn’t have the technology sophistication, doesn’t have the business savvy, doesn’t have the credibility with the key executives, doesn’t have the deep customer knowledge, doesn’t have the passion for the product, or doesn’t have the respect of their product team, then it’s a sure recipe for failure.
To summarize, these are the four critical contributions you need to bring to your team: deep knowledge
of your customer, (To make this explicit, you need to become an acknowledged expert on the customer: their issues, pains, desires, how they think—and for business products, how they work, and how they decide to buy.)
of the data, (Most product managers start their day with half an hour or so in the analytics tools, understanding what’s been happening in the past 24 hours. They’re looking at sales analytics and usage analytics. They’re looking at the results of A/B tests.)
of your business and its stakeholders, (This means knowing who your various stakeholders are and especially learning the constraints they operate under.)
of your market and industry. (The normal case is that the product manager does need to have (or be able to learn) the necessary domain expertise.)
Three overarching product management principles :
1- It is all about solving problems, not implementing features. (Conventional product roadmaps are all about outputs. Strong product teams know that it is not about implementing a solution. They must ensure that solution solves an underlying problem. It's about business results. )
2-Products are defined and designed collaboratively, rather than sequentially. (Design, product and engineering should work side by side to come up with technology powered solutions that our customers love and that work for our business.
3- Risks are tackled up front, rather than at the end.
Risks:
Value risk ( whether customers will buy it)
Feasibility risk ( whether engineers can build what we need with the time, skills, and technology we have)
Usability risk ( whether users can figure out how to use it)
Business viability risk ( whether this solution also works for the various aspects of our business - sales, marketing, finance, legal etc.)
to take care of the risks --> Discovery
Discovery is very much about the intense collaboration of product management, user experience design, and engineering. In discovery, we are tackling the various risks before we write even one line of production software.
The purpose of product discovery is to quickly separate the good ideas from the bad. The output of product discovery is a validated product backlog. (answer to the 4 Risk Questions)
As product manager, you need to make sure you are at every single qualitative value test. Do not delegate this.
Your contribution to the team comes from experiencing as many users as possible, first hand, interacting with and responding to your team’s ideas. Marty Cagan says: '' If you worked for me, the continuation of your monthly salary would depend on this. '' :)
Customer Interviews to find out the following
Are your customers who you think they are?
Do they really have the problems you think they have?
How does the customer solve this problem today?
What would be required for them to switch?
Opportunity Assessment Technique (a Discovery Framing Technique)
An opportunity assessment is an extremely simple technique but can save you a lot of time and grief. The idea is to answer four key questions about the discovery work you are about to undertake:
What business objective is this work intended to address? (Objective)
How will you know if you’ve succeeded? (Key results)
What problem will this solve for our customers? (Customer problem)
What type of customer are we focused on? (Target market)
Customer Discovery Program (a Discovery Planning Technique)
For b2b For products and services aimed at businesses, the key number is six reference customers.
For consumer products, the same general concept applies. But, rather than focusing on six businesses to work closely with (where we have access to many different users at each customer), we instead focus on a somewhat larger number of consumers (on the order of 10–50) that we engage with to get them to the point that they are loving our product.
Product Evangelism
Product evangelism is, as Guy Kawasaki put it years ago, “selling the dream.” It’s helping people imagine the future and inspiring them to help create that future.
Top-10 pieces of advice for product managers to sell the dream:
Use a prototype.
Share the pain. Show the team the customer pain you are addressing. This is why I love to bring engineers along for customer visits and meetings.
Share the vision. Make sure you have a very clear understanding of your product vision, product strategy, and product principles.
Share learnings generously. After every user test or customer visit, share your learnings—not just the things that went well, but share the problems, too. Give your team the information they need to help come up with the solution.
Share credit generously.
Learn how to give a great demo. We’re trying to show them the value of what we’re building. A demo is not training, and it’s not a test. It’s a persuasive tool. Get really, really good at it.
Be the undisputed expert on your users and customers. And be the undisputed expert on your market, including your competitors and the relevant trends.
Be genuinely excited. If you’re not excited about your product, you should probably fix that—either by changing what you work on or by changing your role.
Learn to show some enthusiasm.
Spend time with your team.
Product Teams
We need teams of missionaries, not teams of mercenaries.
Mercenaries build whatever they're told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers.
MVP:
While this is partly a result of the way most people have learned this concept, I think the root of the issue is that while the P in MVP stands for product, an MVP should never be an actual product (where product is defined as something that your developers can release with confidence, that your customers can run their business on, and that you can sell and support). The MVP should be a prototype, not a product.
Building an actual product-quality deliverable to learn, even if that deliverable has minimal functionality, leads to substantial waste of time and money, which of course is the antithesis of Lean.
The product vision and strategy. This describes the big picture of what the organization as a whole is trying to accomplish and what the plan is for achieving that vision. Each of our product teams may have its own areas of focus (for example, buyer teams and seller teams), but it’s all supposed to come together to achieve the product vision.
The difference between vision and strategy is analogous to the difference between good leadership and good management.
Leadership inspires and sets the direction, and management helps get us there.
The business objectives. This describes the specific, prioritized business objectives for each product team
The idea behind business objectives is simple enough: tell the team what you need them to accomplish and how the results will be measured, and let the team figure out the best way to solve the problems.
The Objectives and Key Results (OKR) technique is a tool for management, focus, and alignment. As with any tool, there are many ways to use it. Here are the critical points for you to keep in mind when using the tool for product teams in product organizations.
Objectives should be qualitative; key results need to be quantitative/ measurable.
Key results should be a measure of business results, not output or tasks.
The rest of the company will use OKRs a bit differently, but for the product management, design, and technology organization, focus on the organization’s objectives and the objectives for each product team, which are designed to roll up and achieve the organization’s objectives. Don’t let personal objectives or functional team objectives dilute or confuse the focus.
Find a good cadence for your organization (typically, annually for an organization’s objectives and quarterly for a team’s objectives).
Keep the number of objectives and key results for the organization and for each team small (one to three objectives, with one to three key results each is typical).
It’s critical that every product team track their active progress against their objectives (which is typically weekly).
The objectives do not need to cover every little thing the team does, but they should cover what the team needs to accomplish.
It’s important that, one way or another, teams feel accountable to achieving their objectives. If they fail substantially, it’s worth having a post-mortem/retrospective with some of their peers or management.
Senior management (CEO and executive team) is responsible for the organization’s objectives and key results. The heads of product and technology are responsible for the product team objectives (and ensuring they deliver on the organization’s objectives). The individual product teams are responsible for proposing the key results for each objective they’ve been assigned. It is normal to have a give-and-take process each quarter as the OKRs are finalized for each team and for the organization.
Objective example: The product team has business-related objectives (for example, to reduce the customer acquisition cost, to increase the number of daily active users, or to reduce the time to onboard a new customer)
Product Market Fit
your users (those in your target market that have used the product recently, at least a couple times, and you know from the analytics that they’ve at least made it through to the core value of the product) and asking them how they’d feel if they could no longer use this product. (The choices are “very disappointed,” “somewhat disappointed,” “don’t care,” and “no longer relevant because I no longer use.”). The general rule of thumb is that if more than 40 percent of the users would be “very disappointed,” then there’s a good chance you’re at product/market fit.
There are two specific academic courses that every product manager should take
1- Introduction to Computer Programming
for this one I have : https://learning.edx.org/course/course-v1:HarvardX+CS50+X/home
2- Introduction to Business Accounting /Finance
for this one I have books in my hand