Last time I talked about Part 2 of Inspired, the part that focused on different roles that work together for successful product management. I mentioned a few points that stuck out to me about misunderstandings of some of the roles, some rules of thumb for each, and some of the trade offs different roles might have to account for when trying to create great products.

This time, I'll give some notes about stuff that stuck out to me from part 3, which is about what it means to describe the right product, and how to evaluate how we're doing when getting to product-market fit. Please keep in mind these are my observations of the book, it won't be comprehensive.

The Right Product

Product Roadmaps

Product roadmaps are not good for business results. Two reasons for this are

1. At least half of our product ideas aren't going to work out
2. No matter how many disclaimers you put on a roadmap, it's going to be misunderstood as a commitment

Sometimes we do need to commit to a delivery by a certain date. We try to minimize those instances and make that a high-integrity commitment.

The Alternative to Roadmaps

Two reasons management wanted roadmaps:

1. They want to make sure teams are working on the highest business value items first
2. Sometimes there's a need for date

Business Context can help address those two desires. Business Context can be given by the product vision and strategy, and by the business objectives. Management provide teams with those business objectives - problems they need to address. Ironically it can be difficult to get management to focus on business objectives as opposed to products.

High-integrity commitments are distinguished by their timeliness and their rarity. Normal 'commitments' are made too early, when we can't know how long something is going to take, or even whether it's going to be viable. There's a give-and-take via product discovery work. Product discovery helps mitigate some of the the various risks, demonstrating business value, viability, and engineering feasibility. With this information, a PM can partner with a delivery manager to come up with the rare high integrity commitment.

Product Vision and Product Strategy

The product vision is meant to inspire the organization (or business unit, in a large organization) toward something. This something will likely be on a 2-5 year time horizon, or 5-10 in hardware.

Product vision is not a mission statement like "organize the world's information". It can take the form of a storyboard or a visiontype. Visions can't be tested

Strategy is 'how to get there'. Strategy may be broken out by geographical area, or by milestones that give more data for subsequent steps. They could also be broken broken out by user persona in a B2C, or by vertical (ie financial services, automotive etc.) in B2B.

When you're prioritizing markets, use TAM (total addressable market). You can aim for a smaller TAM if TTM (time to market) is lower. Also consider GTM (go to market - ie sales channels available)¹.

Principles of Product Vision

1. Start with why - use vision to articulate purpose
2. Fall in love with the problem, not the solution
3. Don't be afraid to think big with vision ( > 6 months)
4. Don't be afraid to disrupt yourselves, because if you don't someone else will
5. The product vision needs to inspire
6. Determine and embrace relevant and meaningful trends
7. Skate to where the puck is heading, not where it was
8. Be stubborn on vision but flexible on details
9. Realize that any product vision is a leap of faith
10. Evangelize continuously and relentlessly. There's no such thing as overcommunicating when selling a vision

Principles of Product Strategy

1. Focus on one target market or persona at a time
2. Product strategy needs to be aligned with business strategy
3. Product strategy needs to be aligned with sales and go-to-market strategy
4. Obsess over customers not competitors
5. Communicate strategy across the organization - especially sales, marketing, finance, and service

Product Principles

An example product principle from ebay: "In cases where needs of buyers and sellers conflict, we will prioritize the needs of the buyer, because that's actually the most important thing we can do for sellers."

Product principles are not associated to a specific feature, release, or iteration.

The OKR Technique

Here are some critical points for doing OKRs (objectives and key results):

1. Objectives should be qualitative. Key results should be quantitative.
2. Key results should be a measure of business results, not outputs or tasks.
3. For product management, design, and tech, focus on the org's objectives and objectives for each product team, which are designed to roll up and achieve the org's objectives. Don't let personal objectives or functional objectives dilute or confuse.
4. Find a good cadence (e.g. anually for the organization, quarterly for a team).
5. Keep the number of Os (objectives) and KRs (key results) for each team small. 1-3 of each.
6. Every product team ought to track active progress against their objectives. Typically weekly.
7. Objectives need not capture every little thing, but what the team needs to accomplish.
8. If the team fails substantially, it's worth having a retrospective with some peers or management.
9. Agree as an organization how you will be evaluating or scoring your KRs.
   • It's common to use a scale of 0-1.0, with 0 for no progress, 0.7 for "meets" and 1.0 for "exceeds"
10. Establish a way to indicate when a KR is a high-integrity commitment vs a normal objective. This type of KR is pass/fail.
11. Be transparent across the product org on what Os each product team is working on, and their progress.
12. It's normal to have a give and take amongst these.

    Role	OKR Responsibility
    CEO and executives	Org OKRs
    Heads of Product and Tech	Product Team Os
    Product Team	Product Team KRs

Product Team Objectives

Sometimes there are incentives for OKRs at the functional level. For example, the head of UX wants to push for responsive design. Members of product teams may find product and business OKRs in conflict. The solution is to set up OKRs at the level of the product team, and then incorporate and negotiate functional OKRs. Sort of next them in product OKRs. There will be a cascading of OKRs from the product team level to the company or business-unit level. Same goes for individual development goals.

Product Objectives At Scale

Early startups get a long way without vision and strategy, just focusing on customers.

Some techniques for OKRs at scale:

1. First a clear understanding of the org-level Os is needed. Leadership sets them and which teams focus on what.
2. There are many platform teams. Leadership needs to help coordinate Os for these teams and coordinate dependencies among them.
3. After Os are set, there's a reconciliation process with leadership around the viability of KRs. There may be a need for modification or reprioritization.
4. Collaboration tools help visibility of OKRs, but lean on leadership to connect the dots.
5. Delivery managers help track dependencies among large numbers of high-integrity commitments.
6. There will be business-unit level OKRs, and whole-org-level BUs. Product team objectives 'roll-up' or cascade these.

Product Evangelism

Product evangelism is focused on the product team for an individual PM, more broadly at the Head of Product level. Remembering 'missionaries, not mercenaries', some techniques for evangelizing follow.

1. Use a prototype to help show the forest for the trees.
2. Share the pain. E.g., bring engineers to customer visits.
3. Share the vision.
4. Share learnings (especially from customers).
5. Share credit generously, and admit fault.
6. Learn how to give a great demo.
7. Do the homework - be the undisputed expert on users and customers.
8. Be genuinely excited. If not, try to change roles or what you're working on.
9. Learn to show enthusiasm.
10. Spend time with the team, including in one-on-ones. For remote work, try to do this every couple of months in person.

In big organizations, marketing and sales will take a bigger role in evangelizing to customers than the PM.

Reflections on Part 3

1. Sometimes, Cagan said, there will be a demand for a roadmap. How could you offer alternatives to meet the underlying desires contained in a request for a roadmap?
2. What would you do if the Product team tries to set their own Objectives? How about if executives try to set Key Results?
3. Here's a bit more about the visiontype. When is it appropriate to use it? When is it not?

¹See also this interesting presentation by Benedict Evans predicting future industry trends. Evans makes a distinction that a lot of what we think of as new markets or industries are actually just new channels in existing markets. Or to quote him "Is this a tech company? Or is it a mattress company with a website?"