Inspired by Marty Cagan - Book Summary
This is my summary of ‘Inspired’ by Marty Cagan. My notes are informal and tailored to my own interests at the time of reading. They mostly contain quotes from the book as well as some of my own thoughts. I enjoyed this book and would recommend you read it yourself (check it out on Amazon).
Responsibilities of the product manager
At the individual contributor level:
Deep knowledge of the customer. 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.
Deep knowledge 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 AB tests.
Deep knowledge of your business. Know who your various stakeholders are and the constraints they operate under.
Deep knowledge of your market and industry. This includes competitors, key trends in technology, customer behaviors and expectations, following the relevant industry analysts. Your products will need to fit into a more general ecosystem of other products, and ideally your product is not only compatible with that ecosystem but adds significant value to it.
At the head of product level:
Team development. The single most important responsibility of any VP product is to develop a strong team of product managers and designers. Includes recruiting, training, and ongoing coaching.
Product vision and strategy.
Execution. Know how to get things done and absolutely prove your ability to do so. You should be expert on modern forms of product planning, customer discovery, product discovery, and the product development process. Know how to work effectively as part of an organization of your size. You need strong skills in stakeholder management and internal evangelism. Be able to inspire and motivate the company and get everyone moving in the same direction.
Product culture. A strong product culture means that the team understands the importance of continuous and rapid testing and learning.
—
Inconvenient truths about product
There is no escaping these inconvenient truths, no matter how smart you might be.
Half of our ideas are just not going to work.
The really good teams assume that at least three quarters of the ideas won’t perform like they hope.
With the ideas that do prove to have potential, it typically takes several iterations to get the implementation of this idea to the point where it delivers the necessary business value.
We call this time to money.
—
Continuous discovery and delivery
There are two high-level activities in all product teams. We need to discover the product to be built, and we need to deliver that product to market.
Discovery and delivery are our two main activities on a cross-functional product team, and they are both typically ongoing and in parallel.
—
Principles for effective product discovery
What’s the goal of product discovery?
The purpose of product discovery is to make sure we have some evidence that when we ask the engineers to build a production-quality product, it won’t be a wasted effort (increase the confidence in our ideas). We want to quickly separate the good ideas from the bad. Our goal in discovery is to validate our ideas the fastest, cheapest way possible.
The output of product discovery is a validated product backlog.
I view product discovery as the most important core competency of a product organization.
There are four types of risk when we build a product.
Value risk: Will the customer buy this, or choose to use it?
If it’s a new product, we need to ensure that customers will buy it at the price we need to charge, and that they’ll switch from whatever they’re using today.
If it’s an existing product, and we are improving that product (such as with a new feature or a new design), where the customer has already bought the product, we need to ensure the customers will choose to use the new feature or new design.
Usability risk: Can the user figure out how to use it?
Feasibility risk: Can our engineers build what we need with the time, skills, and technology we have?
Business viability risk: Does this solution also work for the various aspects of our business? This includes sales, marketing (both brand and go-to-market considerations), finance, legal, business development, and senior executives.
Tackle risks before you decide to build anything.
Don’t ship any production code during discovery (except maybe for an experiment which you should remove as soon as it’s concluded).
Don’t compromise your standards on releasing scalable, fault-tolerant, reliable, high-performance, secure software.
Most of the techniques don’t require the developer’s time.
It’s important because we appreciate how much time and effort needs to go into creating production-quality software in delivery.
We must validate our ideas on real users and customers.
Get your ideas in front of real users and customers early and often.
One of the most common traps in product is to believe that we can anticipate our customers’ actual response to our products.
We know we can’t count on our customers, executives, or stakeholders to tell us what to build.
It’s not that customers or our executives are necessarily wrong; it’s just that it’s our job to make sure the solution we deliver solves the underlying problem.
Customers don’t know what’s possible with technology.
The most important thing is to establish compelling value.
We can survive for a while with usability issues or performance issues, but without the core value, we really have nothing.
This is generally where we’ll need to spend most of our discovery time.
Functionality, design, and technology are inherently intertwined.
We push hard for the product manager, product designer, and tech lead to sit physically adjacent to each other.
We expect that many of our ideas won’t work out, and the ones that do will require several iterations.
Be open to solving the underlying problem in different ways if necessary.
We need to validate the feasibility of our ideas during discovery, not after.
Getting the engineer’s perspective earlier also tends to improve the solution itself, and it’s critical for shared learning.
We need to validate the business viability of our ideas during discovery, not after.
Few things destroy morale or confidence in the product manager more than finding out after a product has been built that the product manager did not understand some critical aspect of the business.
It’s about shared learning.
Protect revenue and brand.
Test and learn in a responsible way.
Protect employees.
If our customer service, professional services, or sales staff are blindsided by constant change, it makes it very hard for them to do their jobs and take good care of customers.
Protect customers.
Customers that feel like your product is a moving target that they have to constantly relearn won’t be happy customers for long.
—
Discovery techniques
There is no one perfect taxonomy for discovery techniques because several of these techniques are helpful for multiple different situations.
The techniques are not mutually exclusive.
Discovery framing techniques:
Goal of discovery framing techniques:
They help us quickly identify the underlying issues that must be tackled during product discovery.
For example, if we’re handed a potential solution we need to clarify the underlying problem to be solved.
Opportunity assessment
Designed for the vast majority of product work, which ranges from a simple optimization to a medium-sized project.
Answer four 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 letter
Designed for larger projects that often have multiple goals and a more complicated desired outcome. A typical example of an effort of this size would be a redesign.
At Amazon, they call it ‘working backwards’ and start the process with a pretend press release.
Rather than communicate the benefits in a press release format, you can describe them in the format of a customer letter written from the hypothetical perspective of one of your product’s well-defined user or customer personas. The letter is sent to the CEO from a very happy and impressed customer.
The letter explains why they are so happy and grateful for the new product or redesign. The customer describes how it has changed or improved their life.
The letter also includes an imagined congratulatory response from the CEO to the product team explaining how this has helped the business.
Startup canvas
For those times you’re creating an entirely new product line or a new business.
Check out business model canvas and the lean canvas.
Planning techniques
Story maps
Check out ‘User Story Mapping’ by Jeff Patton
Customer discovery program
You would not do this program for small efforts like features or minor projects. This is for larger efforts, like creating a new product or business, taking an existing product to a new market or new geography or a redesign of a product.
It’s my favorite leading indicator of future success. I attribute much of the success in my own career to this technique. It takes substantial effort, primarily on the part of the product manager.
The customer discovery program is designed to produce reference customers.
These are real customers (not friends or family) who are running your product in production (not a trial or prototype) who have paid real money for the product (it wasn’t given away to entice them to use it) and most importantly who are willing to tell others how much they love your product (voluntarily and sincerely).
We are discovering and developing a set of reference customers in parallel with discovering and developing the actual product.
For B2B, the key number is 6 reference customers. For B2C, the number is 10-50 people.
This technique is not designed to discover the necessary product - that comes next. It is designed to give you direct access to the target customers where you’ll find the product ideas necessary to generate future reference customers.
Go after reference customers from one single target market.
If you end up targeting two or three customers from two or three different markets, this program will not give you the focus you want and need.
We need reference customers to have the time and willingness to work closely with us.
They need to be willing to spend time with the product team, testing out early prototypes and helping the team ensure the product works well for them.
You will be interacting with them throughout the effort - you’ll be showing them prototypes and testing with their users, you’ll be asking many detailed questions, and you’ll be testing early versions in their environment.
Explain to each prospective member of the program that your job is to come up with a general product - something your company can successfully sell to a large number of customers.
You’re not trying to build a custom solution that only works for that customer.
You are, however, deeply committed to coming up with a product that works extremely well for them and just a handful of other customers.
I do my best to persuade teams to not launch a product in the marketplace until after they have six reference customers.
We don’t want to turn on the sales or marketing machine until we have evidence that we can help them be successful, and the reference customers are our best evidence.
Don’t take their money before you actually deliver them a real product they love.
I don’t like the customer to pay in advance to participate in this program. That makes it a different type of relationship.
You want a partner in coming up with the product. You don’t want to build a custom solution just for them, and you’re not a custom project shop.
If you find you are having real trouble recruiting even four or five prospective customers for this effort, it’s possible that you’re chasing a problem that isn’t that important.
Make sure you release the delivered product to these people before the general release, and make sure they are live and happy before the release. When you launch, they’ll be ready to stand up for you.
Ideation techniques
Goal of ideating techniques:
You want to generate the types of ideas that are likely to truly help you solve the hard business problems that your leaders have asked you to focus on right now.
Customer interviews
Concierge test technique
The idea is that we do the customer’s job for them - manually and personally.
Encourage customer ‘misbehavior’
You can allow, and even encourage, your customers to use your products to solve problems other than you planned for and officially support.
Example: From its earliest days, Ebay has always had an ‘everything else’ category. This is where people could buy and sell things that we at Ebay couldn’t anticipate people might want to trade. Some of the biggest innovations and biggest surprises came from monitoring what customers wanted to do.
Hack days.
The goal is for self-organizing groups to explore their ideas and create some form of prototype that can be evaluated, and if appropriate, tested on actual users.
Undirected hack days. People can explore whatever product ideas they like, so long as it’s at least loosely related to the mission of the company.
Directed hack days. There’s a customer problem (e.g. something is really hard to learn and use) or business objective (reduce the customer churn rate), and we ask people from the product teams to self-organize and work on any ideas they like that might address this objective.
Prototyping
Principles of effective prototypes:
A prototype should require at least an order of magnitude less time and effort as the eventual product.
The overarching purpose of any form of prototype is to learn something at a much lower cost in terms of time and effort than building out a product.
There is no such thing as one appropriate level of fidelity.
Fidelity primarily refers to how realistic the prototype looks:
Low-fidelity user prototypes: intentionally designed to look like wireframes sketched out on paper
High-fidelity user prototypes: look and feel like the real thing where it can be difficult to tell it’s just a simulation.
Create the right level of fidelity for the intended purpose, and acknowledge that lower fidelity is faster and cheaper than higher fidelity, so we only do higher fidelity when we need to.
Prototypes are simulations.
You can also collect real data with a prototype (‘live-data prototype’).
The main purpose of a live-data prototype is to collect actual data so we can prove something, or at least gather some evidence.
We need the prototype to access our live data sources. We need to be able to send live traffic in enough quantity to get useful data to the prototype.
The key is that we don’t have to build, test, and deploy a commercially viable product to do this. A live-data prototype costs a small fraction of what it would cost to build a commercially viable product.
What’s important is that actual users will use the live-data prototype for real work, and this will generate real data (analytics) that we can compare to our current product - or to our expectations - to see if the new approach performs better.
Value testing techniques
Smoke test.
Also called fake-door demand test.
The idea is that we put the button or menu item into the user experience exactly where we believe it should be. But, when the user clicks that button, rather than taking the user to the new feature, it instead takes the user to a special page that explains that you are studying the possibility of adding this new feature, and you are seeking customers to talk to about this. The page also provides a way for the user to volunteer (by providing their email address for example).
You can quickly collect some very helpful data that will allow you to compare the click-through rate on this button with your expectations or with other features. Then you can follow up with customers to get a better understanding of what they would expect.
You can show it to just a small percentage of users or within a specific geography.
Landing page demand test.
Rather than a button on the page, you set up a landing page for the new offering’s product funnel. You describe the new offering exactly as you would if you were really launching the service.
The difference is that if the user clicks the call to action, rather than signing up for the trial (or whatever the action might be), the user sees a page that explains that you are studying the possibility of adding this new offering, and you’d like to talk with them about that new offering if they’re willing.
In practice, the demand is usually not the problem. People do sign up for our trial. The problem is that they try out our product and they don’t get excited about it - at least not excited enough to switch from what they currently use.
Qualitative value testing: show people your prototype.
You won’t get your answer from any one user, but every user you test with is like another piece of the puzzle. Eventually, you see enough of the puzzle.
Interview people before showing your prototype to make sure they have the problem we think they have, how they solve this problem today, and what it would take for them to switch.
The main challenge in testing value when you’re sitting face-to-face with actual people is that people are generally nice - and not willing to tell you what they really think. So all of our tests for value are designed to make sure the person is not just being nice to you.
As product manager you need to make sure you are at every single qualitative value test. Don’t delegate this, and certainly don’t try to hire a firm to do this for you. Your contribution to the team comes from experiencing as many users as possible, first hand, interacting with and responding to your team’s ideas. If you worked for me, the continuation of your monthly salary would depend on this.
Use money to demonstrate value.
See if the user would be willing to pay for it, even if you have no intention of charging them for it.
We’re looking for the user to pull out their credit card right then and there and ask to buy the product.
If it’s an expensive product for businesses, you can ask people if they will sign a “non-binding letter of intent to buy”.
Using reputation to demonstrate value.
You can ask them to share on social media.
You can ask them to enter their email of their boss or their friends for a recommendation.
Using time to demonstrate value.
Especially with businesses, you can also ask the person if they’d be willing to schedule some significant time with you to work on this (even if we don’t need it).
Usability testing
Usability testing.
Moderated vs. unmoderated.
In-person vs. remote.
Can use sites like usertesting.com
Wizard of Oz.
A high-fidelity user prototype but with an actual person behind the scenes performing manually what would ultimately be handled by automation.
It’s absolutely not scalable, and we would never send any significant amount of traffic to this.
Can be helpful if you something that would be extremely hard to build out, and you want to see how it would work (e.g. machine learning features, analytics features with high database load)
Feasibility testing (spikes)
Also called ‘proof of concept’ or ‘feasibility prototype’.
Written by engineers to address technical feasibility risk. The idea is for the developer to write just enough code to be able to address the feasibility risk.
Most of the time the spike is intended to be throwaway code.
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?”
I have seen many teams process to delivery without adequately considering the feasibility risk. Whenever you hear stories of product teams that grossly underestimated the amount of work required to build and deliver something, this is usually the underlying reason.
Common examples include:
Algorithms concerns
Performance concerns
Scalability concerns
Fault tolerance concerns
Use of a technology the team has not used before
Use of a third-party component or service the team has not used before
—
Delivery
Delivering a product means to deliver the necessary:
Scale
Performance
Reliability
Fault tolerance
Security
Privacy
Internationalization
Localization
How to manage release risk:
AB testing.
Release gradually.
Early access (beta) releases
Invite-only testing
Identify a set of users or customers that you contact and invite them to try the new version. You tell them that it is an experimental version, so they are effectively opting in if they choose to run it.
Use best practices for engineering and try not to override the engineers’ concerns.
Top reasons for loss of velocity.
Technical debt. Often, the architecture does not facilitate or enable the rapid evolution of the product. This is not something that can be fixed overnight, but it needs to be attacked in an ongoing and concerted effort.
Lack of strong product managers. In those cases, the PM has not inspired or evangelized to the team, or the team has lost confidence in their PM.
Lack of delivery management. Most impediments won’t go away quickly without someone actively chasing them down.
Infrequent release cycles. Very good teams release multiple times per day. Correcting infrequent release cycles means getting serious about test automation and release automation so the team can move quickly and release with confidence.
Lack of product vision and strategy. It’s essential that the team have a clear vision of the big picture and how their immediate work contributes to the whole.
Not including engineers early enough during product discovery.
Not utilizing product design in discovery and instead having them try to do their work at the same time the engineers are trying to build.
Changing priorities. Realize that rapidly shifting priorities cause significant churn and substantially reduces the total throughput and morale.
A consensus culture. While this typically comes from good intentions, what it means in practice is decisions are very hard to make and everything slows to a crawl.
—
‘Inspired’ also covered many more insightful topics. You’ll find them below in alphabetical order.
Customer value
To get someone to switch to our new product, it’s not enough that it’s comparable (feature parity), it must be demonstrably and substantially better. They have to be motivated to wade through the pain and obstacles of migrating from their old solution.
Estimations
Holding a weekly planning meeting where you throw a bunch of ideas at the engineers - and demand they give you some sort of estimate in time or story points - is almost certain to go badly. If you put an engineer on the spot, without time to investigate and consider, you are very likely to get a conservative answer, partly designed to make you go away.
How great products are created
It is much more about creating the right product culture for success, and understanding the array of product discovery and delivery techniques so that you can use the right tool for the specific issue you are facing.
When a product succeeds, it’s because everyone on the team did what they needed to do. When a product fails, it’s the product manager’s fault.
KPIs
User behavior analytics (click paths, engagement)
Business analytics (active users, conversation rate, lifetime value, retention)
Financial analytics (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)
MVP
The MVP should be a prototype, not a product.
OKRs
If you deploy OKRs for your product organization, the key is to focus your OKRs at the product team level. Don’t let functional team or individual person OKRs confuse the issue.
Focus the attention of the individuals on their product team objectives. If different functional organizations (such as design, engineering, or quality assurance) have larger objectives (such as responsive design, technical debt, and test automation), they should be discussed and prioritized at the leadership team level along with other business objectives, and then incorporated into the relevant product team’s objectives.
Onboarding at a new company
It normally takes about two to three months of dedicated work for a new PM to get up to speed.
You need a manager who can give you the help and access you need to gain this expertise, including lots of access to customers, access to data (and when necessary, training in the tools to access that data), access to key stakeholders, and time to learn your product and industry inside and out.
Organizational change
One of the hardest assignments is to try to cause dramatic change in a large and financially successful company. It’s easier in many ways if the company is in serious trouble, and it is feeling big pain, because that pain can be used to motivate the change.
The technology adoption curve also applies to organizations, and how we make changes to how organizations work.
Some people in your organization love change, some want to see someone else use it successfully first, some need more time to digest changes, and a few hate change and will only change if they’re forced to do it.
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 team technique:
Roll out the change to a limited part of the organization before implementing it more broadly.
Look for a product team to volunteer to try out some new techniques. Let them run for a while (usually a quarter or two) with this new way of working and see how this goes.
Your specific success measures will depend on your goals, but ultimately, you’re looking to compare the team’s effectiveness in delivering business outcomes; that is, how well do pilot teams accomplish their objectives versus the others, or compared to how they did in the past?
PM advice
The successful product manager must be the very best versions of smart, creative, and persistent:
Smart. Not just raw IQ. Intellectually curious, quickly learning and applying.
Creative. Think outside the normal product box of features to solve business problems.
Persistent. Push companies way beyond their comfort zone with compelling evidence, constant communication, and building bridges across functions in the face of stubborn resistance.
The PM role in the team
For a product team to be empowered and act with any meaningful degree of autonomy, the team must have a deep understanding of the broader context. This starts with a clear and compelling product vision, and the path to achieving that vision is the product strategy.
Product design
Interaction design generally includes the underlying conceptual models (e.g. a photo management application may have photos, albums, projects), task flows, and control layouts to manipulate those concepts.
Visual design includes composition, typography, and how the visual brand is expressed.
Product evangelism
Product evangelism is “selling the dream” (Guy Kawasaki). It’s helping people imagine the future and inspiring them to help create that future.
Advice to sell the dream:
Use a prototype. For many people, it’s way too hard to see the forest through the trees. When all you have is a bunch of user stories, it can be difficult to see the bigger picture and how things hang together.
Share the customer pain. 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. Show how your work contributes to this vision and is true to the 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.
Share credit generously. Make sure the tem views it as their product, not just your product. When things don’t go well, step forward and take responsibility for the miss and show the team you’re learning from the mistakes as well.
Learn how to give a great demo. This is an especially important skill to use with customers and key execs. We’re not trying to teach them how to operate the product, and we’re not trying to do a user test on them. We’re trying to show them the value of what we’re building. It’s a persuasive tool. Get really, really good at it.
Do your homework. Your team and your stakeholders will all be much more likely to follow you if they believe you know what you’re talking about. 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. Absolutely be sincere, but let people see you’re genuinely excited. Enthusiasm really is contagious.
Spend time with your team. If you’re not spending significant face time with your designer and every engineer on your team, then they can’t see the enthusiasm in your eyes. Spending some personal time with every last person on the team pays off big in the level of motivation, and, as a result, in the velocity of the team. It’s worth your time.
Product marketing
A very large component of what is meant by “works for our business” is:
There is a real market there (large enough to sustain a business).
We can successfully differentiate from the many competitors out there.
We can cost-effectively acquire and engage new customers.
We have the go-to-market channels and capabilities required to get our product into the hands of our customers.
Product strategy
The product strategy is our sequence of products or releases we plan to deliver on the path to realizing the product vision. These might be different versions of the same product, a series of different or related products, or some other set of meaningful milestones.
The product strategy should be focused.
The product strategy gives you a tool to align your product work with your sales and marketing organizations.
The most important benefit is just that you decide to focus your product work on a single target market at a time. So, all teams know we’re tackling the manufacturing market now, and that’s the type of customers we’re obsessing on. Our goal is to come up with the smallest actual deliverable product that makes these manufacturing customers successful. Ideas that come up that pertain to other types of customers or markets are saved for future consideration.
There is no single approach to product strategy that is ideal for everyone.
For most businesses, I encourage teams to construct product strategy around a series of product/market fits:
For business-focused companies, you might have each product/market fit focus on a different vertical market (e.g. financial services, manufacturing, automotive).
For consumer-focused companies, we often structure each product/market fit around a different customer or user persona. For example, an education-related service might have a strategy that targets high-school students first, college students next, and then those already working but who want to learn new skills.
Sometimes, the product strategy is based on geography, where we tackle different regions of the world in an intentional sequence.
Sometimes, the product strategy is based on achieving a set of key milestones in some sort of logical and important order. For example, “First deliver critical rating and reviews functionality to developers building e-commerce applications; next, leverage the data generated from this use to create a database of consumer product sentiment; and then leverage these data for advanced product recommendation.”
Principles for coming up with an effective product strategy:
Focus on one target market or persona at a time. Don’t try to please everyone in a single release. Focus on one target market or one new target persona, for each release.
Product strategy needs to be aligned with business strategy.
Product strategy needs to be aligned with sales and go-to-market strategy. A new sales channel or go-to-market strategy can have far-reaching impact on a product.
Obsess over customers, not over competitors. Too many companies completely forget about their product strategy once they encounter a serious competitor. They panic and then find themselves chasing their competitor’s actions and no longer focusing on their customers. Customers rarely leave us for our competitors, They leave us because we stop taking care of them.
Communicate the strategy across the organization. It’s important that all key business partners in the company know the customers we’re focused on now and which are planned for later. Stay especially closely synced with sales, marketing, finance, and service.
Product vision
Refers to the long-term objective of this product, normally 2-5 years out. It is how we as a product organization intend to deliver on the company’s mission.
The product vision should be inspiring. Its primary purpose is to communicate this vision and inspire the teams (and stakeholders, investors, partners, prospective customers) to want to help make this vision a reality.
It’s a persuasive piece that might be in the form of a storyboard, a narrative such as a white paper, or a special type of prototype referred to as a visiontype.
It is not the same as the company’s mission statement. Mission statements are useful, but they don’t say anything about how we plan on accomplishing that. That’s what the product vision is for. Examples of mission statements:
“Organize the world’s information”
“Make the world more open and connected”
“Enable anyone anywhere to buy anything anytime”
Principles for coming up with an effective product vision:
Start with why. Use the product vision to articulate your purpose. Everything follows from that.
Fall in love with the problem, not the solution.
Don’t be afraid to think big with vision. Too often I see product visions that are not nearly ambitious enough, the kind of thing we can pull off in six months to a year or so, and not substantial enough to inspire anyone.
Don’t be afraid to disrupt yourselves, because if you don’t, someone else will. So many companies focus their efforts on protecting what they have rather than constantly creating new value for their customers.
The product vision needs to inspire. Create something you can get excited about. You can make any product vision meaningful if you focus on how you genuinely help your users and customers.
Determine and embrace relevant and meaningful trends. It is not very hard to identify the important trends. What’s hard is to help the organization understand how those trends can be leveraged by your products to solve customer problems in new and better ways.
Skate to where the puck is heading, not to where it was. An important element to product vision is identifying the things that are changing - as well as the things that likely won’t be changing - in the time frame of the product vision. Some product visions are wildly optimistic and unrealistic about how fast things will change, and others are far too conservative. This is usually the most difficult aspect of a good product vision.
Be stubborn on vision but flexible on the details. Don’t get attached to details. It is very possible that you may have to adjust course to reach your desired destination. That’s called a discovery pivot, and there’s nothing wrong with that.
Realize that any product vision is a leap of faith. If you could truly validate a vision, then your vision probably isn’t ambitious enough.
Evangelize continuously and relentlessly. There is no such thing as over-communicating when it comes to explaining and selling the vision.
Stakeholder management
Convince each key stakeholder that you understand their constraints and that you are committed to only delivering solutions consistent with those constraints.
Your solutions not only have to work for your customers, they also have to work for your stakeholders.
This must be sincere.
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. You will not have the latitude to come up with the best solutions.
You also need to bring this knowledge into the product team.
Keep stakeholders informed of important decisions or changes.
They want some visibility into what you are working on and assurance that you are working on the most important items.
They want to be able to plan the business and need to know when critical things will happen.
Spend one-on-one time with your key stakeholders.
Sit down with them and listen. Explain that the better you understand their constraints, the better your solutions will be. Ask a lot of questions. Be open and transparent.
Preview your solutions during discovery with the key stakeholders before you put this work on the product backlog.
Move discussions from opinions to data.
When situations boil down to the PM’s opinion vs. the stakeholder’s opinion, quickly run a test and collect evidence. Share what you’re learning openly.
It may be that neither of your opinions were right.
Don’t be ambiguous.
A lawyer needs to see the actual proposed screens, pages, and wording. A marketing leader needs to see the actual product design. A security leader needs to see exactly what the product is trying to do.
Presentations are terrible for this. Instead, meet privately with each stakeholder, show them the high-fidelity prototype, and give them the chance to raise any concerns.
You may need to spend some time explaining your role and how technology-enabled product companies operate and why.
In many companies, some of the stakeholders may not even understand what Product does, and some may even feel threatened by the role. Be sensitive to this.
Tips to work better with designers:
Do whatever you need to do to have your designer sit next to you.
Include your designer from the very inception of every idea.
Include your designer in as many customer and user interactions as possible. Learn about the users and customers together.
Fight your temptation to provide your designer with your own design ideas. Give your designer as much room as possible to solve the design challenges themself.
Encourage your designer to iterate early and often. Don’t get all nitpicky about design details with the very early iterations. Encourage your designer to feel free not just to iterate on the particular design approach but to explore alternative solutions to the problem.
Tips to work better with engineers:
There’s probably no more important relationship for a successful product manager than the one with your engineers. The morale of the engineers is very much a function of you as the PM. It is your job to make sure they feel like missionaries and not mercenaries.
If you don’t know something, it’s much better to fess up and say you’ll find out rather than try to bluster.
Have an actual appreciation for the demands and complexities of the engineering job.
Share very openly what you know about your customers - especially their pain - the data, and your business constraints.
Constantly demonstrate to your team that you’re open-minded, that you know how to listen, and you want and need their help in coming up with the right product.
Give your engineers as much latitude as possible in coming up with the best solution. Remember, they are the ones who will be called in the middle of the night to fix issues if they arise.
Not every engineer or even senior engineer wants to participate in discovery activities, and this is fine. What’s not okay is to have a team of engineers in which none of them wants to engage in discovery activities.
If you’re just using your engineers to code, you’re only getting about half their value. The little secret in product is that engineers are typically the best single source of innovation.
Tips for working better with product marketers:
There are typically fewer product marketers than product teams, as such, they get spread across different product teams.
In the best tech product companies, product marketing plays an essential role in discovery, delivery, and ultimately, go-to-market, which is why they are important members of the product team. They own positioning, messaging, and a winning go-to-market plan.
Make sure you have a product marketing manager to work with.
Make sure you understand the market - and your PMM colleague understands the product - well enough for each of you to be successful.
Team duration
Teams need to be durable. We try hard to keep teams together and fairly stable. Why?
Collaboration is built on relationships. Product teams are designed to nurture these relationships.
One of the prerequisites for consistent innovation is a team that has had a chance to learn the space, technologies, and customer pain. This doesn’t happen if the members of the team are constantly shifting.
Team performance
What makes a strong culture of execution:
Culture of urgency. People feel like they are in wartime, and that if they don’t find a way to move fast, then bad things could happen.
High-integrity commitments.
Culture of empowerment. Teams feel as though they have the tools, resources, and permission to do whatever is necessary to meet their commitments.
Culture of accountability. People and teams feel a deep responsibility to meet their commitments. Accountability also implies consequences - not necessarily being terminated, except in extreme and repeated situations, but more likely consequences to their reputation among their peers.
Culture of collaboration. Teams understand the need to work together to accomplish many of the biggest and most meaningful objectives.
Culture of results. The focus should be on outcomes/results, not output.
Culture of recognition. Teams often take their cues from what is rewarded and what is accepted. Is it just the team that comes up with the great idea that gets rewarded, or the team that delivered on a brutally tough commitment? And what is the message if missing a commitment is seen as easily excusable?
(Being) ‘technical enough’
The purpose of developing programming literacy is not so you start telling your engineers how to do their job but, rather, to significantly improve your ability to engage with and collaborate with your engineers. Less obviously, but at least as important, this knowledge will give you a much better appreciation for technology and the art of the possible.
Click here to browse more book summaries.