Thread by @mar15sa

"It doesn't matter how good your engineering team is if they are not given something worthwhile to build."

- Inspired by @cagan

10 Root Causes of Failed Products:

1. Source of ideas
2. Early business cases defining info impossible to know yet
3. Planning product roadmaps without dealing with the 2 inconvenient truths about product
4. Acting as project management instead of product management

5. Looping in the design to late
6. Inviting engineering in too late
7. Using Agile only for delivery
8. Being project-centric ("projects are output and product is all about outcome")
9. Customer validation happens too late
10. Missed opportunity cost

- Inspired by @cagan

3 Principles the Best Product Teams Follow:

1. "Risks are tackled up front, rather than at the end"
2. "Products are defined and designed collaboratively, rather than sequentially"
3. "It's all about solving problems, not implementing features"

- Inspired by @cagan

Value risk - whether customers will buy it
Usability risk - whether users can figure out how to use it
Feasibility risk - whether our engineers can build [it]
Business viability risk - whether this solution also works for the various aspects of our business

- Inspired by @cagan

"Mercenaries build whatever they're told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers."

"When a product succeeds, it's because everyone on the team did what they needed to do. But when a product fails, it's the product manager's fault."

4 critical contributions of a strong product manager are deep knowledge of your:

1. Customer
2. Data
3. Business and its stakeholders
4. Market and industry

Successful product managers are persistent: "pushing companies beyond their comfort zone with compelling evidence, constant communication, and building bridges across functions in the face of stubborn resistance."

"The morale of the engineers is very much a function of you as the product manager. It is your job to make sure they feel like missionaries and not mercenaries. You do this by involving them deeply in the customer pain you are trying to solve and in the business problems you face

Don't try to shelter them from this - instead, share these problems and challenges very openly with them. They will respect you more for it, and, in most cases, the developers will rise to the challenge."

^ this has been a key component to my team's success.

On @jinpa1345 making Google AdWords happen:
"Jane sat down with each of these people to get a deeper understanding of their concerns. Some were just plain uncomfortable with advertising. Others were worried about cannibalization.

...Once Jane understood the constraints and concerns, she had the information she needed to advocate for a solution that she believed would address the issues, yet enable countless small businesses to get a much more effective advertising solution."

"A team should feel empowered, yet accountable for some significant part of the product offering. This is harder than it sounds because large systems don't always slice up so cleanly. Some level of interdependencies will always chip away at the sense of ownership."

On @leahickman transitioning @Adobe to a subscription-based model:
"[F]or all of these interrelated pieces to be able to move together in parallel, she needed to articulate clearly a compelling vision of the new whole as greater than the sum of the parts...

To Lea, there was no such thing as over-communication. A continuous stream of prototypes helped keep people excited about what this new future would bring."

"One of the key themes of this book is focusing on outcome and not output. Realize that typical product roadmaps are all about output. Yet, good teams are asked to deliver business results."

"It's worth pointing out that it isn't the list of ideas on the roadmap that's the problem... The issue is that anytime you put a list of ideas on a document entitled 'roadmap,' no matter how many disclaimers you put on it, people across the company will interpret the items...

as a commitment. And that's the crux of the problem, because now you're committed to building and delivering this thing, even when it doesn't solve the underlying problem... The key takeaway here is that we need to solve the underlying problem, not just deliver a feature."

"[T]he root cause of all this grief about commitments is when these commitments are made. They are made too early. They are made before we know whether we can deliver on this obligation, and even more important, whether what we deliver will solve the problem for the customer."

"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."

10 key principles for an effective product vision:
1. Start with why
2. Fall in love with the problem, not the solution
3. Don't be afraid to think big with vision
4. Don't be afraid to disrupt yourselves bc, 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 the details
9. Realize that any product vision is a leap of faith
10. Evangelize continuously and relentlessly

5 key principles of product strategy:
1. Focus on 1 target market or persona at a time
2. Needs to be aligned with business strategy
3. Needs to be aligned with sales & go-to-market strategy
4. Obsess over customers, not over competitors
5. Communicate the strategy across the org

"Product principles are not a list of features, and they are not tied to any one product release. The principles are aligned with the product vision for an entire product line."

"Where the product vision describes the future you want to create, and the product strategy describes your path to achieving that vision, the product principles speak to the nature of the products you want to create."

"Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity."
- George Patton

"The Objectives and Key Results (OKR) technique is a tool for management, focus, and alignment"

10 tips for product managers to sell the dream:
1. Use a prototype
2. Share the pain
3. Share the vision
4. Share learnings generously
5. Share credit generously

6. Learn how to give a great demo
7. Do your homework
8. Be genuinely excited
9. Learn to show some enthusiasm
10. Spend time with your team

**These tips are key to being a product evangelist. If you take nothing else from the current notes, I suggest you look deeply at this

Product: "It is scalable and performant to the degree necessary. It has a strong suite of automated regression tests. It is instrumented to collect the necessary analytics. It has been internationalized and localized where appropriate...

It is maintainable. It is consistent with the brand promise. And, most important, it is something the team can release with confidence."

"If you want to discover great products, it really is essential that you get your ideas in front of real users and customers early and often.

If you want to deliver great products, you want to use best practices for engineering and try not to override the engineers' concerns."

"The purpose of product discovery is to address these critical risks:

1. Will the customer buy this, or choose to use it? (Value risk)

2. Can the user figure out how to use it? (Usability risk)...

3. Can we build it? (Feasibility risk)

4. Does this solution work for our business? (Business viability risk)"

"Customers don't know what's possible, and with technology products, none of us know what we really want until we actually see it.

It's not that customers... are necessarily wrong; it's just that it's our job to make sure the solution we deliver solves the underlying problem."

"If the first time your developers see an idea is at sprint planning, you have failed. We need to ensure the feasibility before we decide to build, not after. Not only does this end up saving a lot of wasted time, but... also tends to improve the solution itself"

"We must also consider value risk - do the customers want this particular problem solved and is our proposed solution good enough to get people to switch from what they have now?"

"It's just human nature for people to think and talk in terms of solutions rather than the underlying problems. This applies especially to users and customers but also applies to stakeholders in our business, other company execs, and if we're honest with ourselves... us as well."

Opportunity Assessment:

1. Objective: What business objective is this work intended to address?
2. Key Results: How will you know if you've succeeded?
3. Customer Problem: What problem will this solve for our customers?
4. Target Market: What type of customer are we focused on?

The working backward process is "where you start the effort with a pretend press release. The idea is that the product manager frames the work ahead of the team... How does it improve the life of our customers? What are the real benefits to them?...

It is describing a future state we want to create... It's a terrific evangelism technique - if people don't see the value after reading the press release, then the product manager has more work to do, or perhaps should reconsider the effort."

A 'reference customer' is a "real customer (not friends or family), who is running your product in production (not a trial or prototype)... has paid real money for the product... and is willing to tell others how much they love your product (voluntarily and sincerely)."

On @mavinmartina fixing Microsoft Word for Mac: "The team quickly learned that, while it may be a worthwhile objective to get to a common code base, it's an empty victory if the product that results isn't good. Moreover, users choose their devices and platforms because...

they value what's different, not what's the same. From the customer's point of view, they would rather wait a little longer and have a better platform-specific solution, than simultaneously ship generic product on all platforms...

This is a good example of how hard it can be to do the right thing for the customer, often in the face of massive pressure. But that's exactly what strong product managers figure out how to do."

"If the product team is given actual business problems to solve rather than solutions, and the product team does their job and interacts directly and frequently with actual users and customers, then getting a sufficient quantity and quality of product ideas is not... a problem"

What you should try to understand in every user or customer interaction:

1. Are your customers who you think they are?
2. Do they really have the problems you think they have?
3. How does the customer solve this problem today?
4. What would be required for them to switch?

Get the most out of user interactions by:
- Establishing frequency
- Aiming to understand, not to prove something
- Talking only to your intended target market
- Observing them in their environment
- Preparing
- Limiting who should attend...

- Learning what they're doing today (not what they wish they were doing)
- Asking open-ended questions
- Debriefing with colleagues to see if they had the same findings
- Keeping any promises made to the customer during the session

A concierge test is where "we do the customer's job for them - manually and personally." It is used "for quickly generating high-quality product ideas and... working on developing the customer understanding and empathy that's so important for... delivering strong solutions"

"Some product people can get upset when they find customers using their products for unintended use cases... [But] this is potentially very valuable information. Dig in a little and learn what problem they are trying to solve and why they believe...

your product might provide the right foundation. Do this enough and you'll soon see patterns and, potentially, some very big product opportunities."

Why public APIs are a great part of a company's product strategy: "I consider devs to be one of the consistently best sources of truly innovative product ideas. Devs are in the best position to see what's just now possible, and so many innovations are powered by these insights"

Types of Prototypes:
Feasibility - The dev writes just enough code to address whether technical idea is doable

User - Simulations of the idea (ex. wireframes)

Live-Data - Collect actual data to prove the idea will work

Hybrid - Combine aspects of the types above

5 Prototype Principles:
1. "Learn something at a much lower cost in... time and effort than building out a product"
2. "Force you to think through a problem at a substantially deeper level"
3. "Members... can all experience the prototype to develop shared understanding"...

4. "Create the right level of fidelity for its intended purpose"
5. Prototype as spec: "Communicate to the engineers and the broader organization what needs to be built"

We typically assess usability and value at the same time before evaluating feasibility. We'll address "business risks last because we don't want to stir up the organization unless we're confident it's worthwhile."

https://twitter.com/mar15sa/status/1283033570307723267?s=19

On usability testing:
- When you first start the test, "make sure to tell the subject that this is just a prototype... Explain that she won't be hurting your feelings by giving her candid feedback, good or bad. You're testing the ideas in the prototype, you're not testing her"...

- "Before you jump into your tasks: See if they can tell from the landing page of your prototype what it is that you do, and especially what might be valuable or appealing to them."
- "Do everything you can to keep your users in use mode and out of critique mode...

If users knew what they really wanted, software would be a lot easier to create. So, watch what they do more than what they say."
- "Avoid giving any help or leading the witness in any way."
- Parroting helps "avoid leading leading value judgements"

"There's no law that says you have to keep the test identical for all of your test subjects. That kind of thinking stems from misunderstanding the role this type of qualitative testing plays. We're not trying to prove anything here; we're just trying to learn quickly."

Fake door demand test: Add a button to the current user experience. When clicked... "it instead takes the user to a special page that explains that you are studying the possibility of adding this new feature, and... seeking customers to talk to about this."

"One of the real advantages to startups from a product point of view is that there's no legacy of to drag along, no revenue to preserve, and no reputation to safeguard. This allows us to move very quickly and take significant risks without much downside. However...

once your product develops to the point that it can sustain a viable business (congratulations!), you now have something to lose, and it's not surprising that some of the dynamics of product discovery need to change."

"Quantitative testing tells us what's happening (or not), but it can't tell us why, and what to do to correct the situation. That's why we do qualitative testing."

"Qualitative is not about proving anything. That's what quantitative testing is for...

...Qualitative testing is about rapid learning and big insights." Methods to do it:
- Short user interview
- Usability test
- Specific value test (money, reputation, time, access)
- Iterating the prototype

Types of quantitative testing:
- A/B
- Invite-only
- Customer discovery program

5 uses of analytics in strong product teams:
1. Understand user and customer behavior
2. Measure product progress
3. Prove whether product ideas work
4. Inform product decisions
5. Inspire product work

"I strongly prefer to provide the product team with a set of business objectives - with measurable goals - and then the team makes the call as to what are the best ways to achieve those goals. It's part of the larger trend in product to focus on outcome and not output."

It's important to keep in mind "data will shine a light on what is happening, but it won't explain why"

PMs should understand analytics around:
- Use behavior (click paths, engagement)
- Business (active users, conversion rate, lifetime value, retention)
- Financial (ASP, billings, time to close)
-Performance (load time, uptime)
- Operational costs (storage, hosting)...

- Go-to-market costs (acquisition costs, cost of sales, programs)
- Sentiment (NPS, customer satisfaction, surveys)

Feasibility: "The question isn't, 'Can you do this?' Rather, you are asking them to look into it and answer the question, 'What's the best way to do this and how long would it take?"

3 Techniques for Showing the Prototype:
1. User test - test new product ideas on real users and customers
2. Product demo - sell your product to prospective users and customers, or evangelize your product across your company
3. Walkthrough - show your prototype to a stakeholder

"If you get too excited and roll out a significant change to everyone in the organization at once, then the laggards (those that hate change) may resist or even sabotage your efforts...

Pilot teams allow the roll out of change to a limited part of the organization before implementing it more broadly... If things go well, you'll likely end up with several other teams eager to adopt."

Weaning an org off roadmaps: "Plan to continue with your existing roadmap process for 6 to 12 months. However, starting immediately, every time you reference a product roadmap item... be sure to include a reminder of the actual business outcome that feature is intended to help."

Warning:
"If the stakeholder does not have this trust that you are going to solve for their concerns as well, then they will either escalate, or they will try to control."

In order to provide consistent innovation, a team must have a:
1. Customer-centric culture
2. Compelling product vision
3. Focused product strategy
4. Strong product managers
5. Stable product teams
...

6. Engineers in discovery
7. Corporate courage
8. Empowered product teams
9. Product mindset
10. Time to innovate

"Top reasons for loss of velocity":
1. Technical debt
2. Lack of strong product managers
3. Lack of delivery management
4. Infrequent release cycles
5. Lack of product vision and strategy
...

6. Lack of co-located, durable product teams (*Personal note: I strongly disagree with this but it's listed in the book)
7. Not including engineers early enough during product discovery
8. Not utilizing product design in discovery
9. Changing priorities
10. A consensus culture

"I think of product culture along two dimensions. The first dimension is whether the company can consistently innovate to come up with valuable solutions for their customers. This is what product discovery is about...

The second dimension is execution. It doesn't matter how great the ideas are if you can't get a productized, shippable version delivered to your customers. This is what product delivery is about."

Characteristics of a strong innovation culture:
- Experimentation
- Open minds
- Empowerment
- Technology
- Business- and customer-savvy teams
- Skill-set and staff diversity
- Discovery techniques

Characteristics of a strong execution culture:
- Urgency
- High-integrity commitments
- Empowerment
- Accountability
- Collaboration
- Results
- Recognition