It doesn't matter how good your engineering team is if they are not given something worthwhile to build. (Location 646)
In any case, one of the most critical lessons in product is knowing what we can't know, (Location 854)
So, I promise you that at least half the ideas on your roadmap are not going to deliver what you hope. (By the way, the really good teams assume that at least three quarters of the ideas won't perform like they hope.) If that's not bad enough, the second inconvenient truth is that even 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 that time to money. (Location 872)
In fact, we wouldn't call this role product management— it's really a form of project management. In this model, it's more about gathering requirements and documenting them for engineers. At this point, let me just say that this is 180 degrees away from the reality of modern tech product management. (Location 880)
Note: Avpid this model at all costs
We say 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; yet, they are not even invited to the party in this process. (Location 887)
Note: Engineers = innovation
projects are output and product is all about outcome. (Location 894)
Note: Outcomes > Output
Product > Project
Ask yourself, what is the actual end state we are looking for?
The point is to have a very inclusive and holistic definition of product. You are not just concerned with implementing features. (Location 963)
Note: Product includes things like operations, any touchpoints with the user, process, etc.
We need to discover the product to be built, and we need to deliver that product to market. (Location 969)
Note: Discovery and delivery happen in parallel. The product team is fully represented in both.
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. (Location 986)
To set your expectations, strong teams normally test many product ideas each week— on the order of 10 to 20 or more per week. (Location 999)
Note: Damn, really?
So, we use prototypes to conduct rapid experiments in product discovery, and then in delivery, we build and release products in hopes of achieving product/ market fit, which is a key step on the way to delivering on the company's product vision. (Location 1022)
It's also normal to be a little skeptical—“ How can I possibly run 15 of these experiments in a week?” I warned you that strong product teams work nothing like most teams, and this should give you your first taste of how different things can be. (Location 1026)
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. (Location 1042)
Note: Don't spend months building an MVP when you could get the same learning in months or hours.
More important than the absolute size of the team is the balance of skills needed to ensure we build the right things, and build those things right. (Location 1106)
To be absolutely clear, the product manager is not the boss of anyone on the product team. (Location 1115)
The nature of the relationship is more about true collaboration. I don't mean collaboration as a buzzword, either. I literally mean product, design, and engineering working out solutions together. Much more on that to come, but at this point, it's important for you to understand that this is not a hierarchy. (Location 1119)
Note: This is not a hierarchy
there is a special dynamic that occurs when the team sits together, eats lunch together, and builds personal relationships with one another. (Location 1129)
This is also one of the reasons why we greatly prefer members of a product team to be actual employees and not contractors or agencies. (Location 1135)
Note: Yikes
If we want teams to feel empowered and have missionary‐like passion for solving customer problems, we need to give them a significant degree of autonomy. Obviously, this doesn't mean they can go off and work on whatever looks fun, but it does mean that they are able to try to solve the problems they are assigned in the best way they see fit. (Location 1175)
There are essentially three ways for a product manager to work, and I argue only one of them leads to success: The product manager can escalate every issue and decision up to the CEO. In this model, the product manager is really a backlog administrator. Lots of CEOs tell me this is the model they find themselves in, and it's not scaling. If you think the product manager job is what's described in a Certified Scrum Product Owner class, you almost certainly fall into this category. The product manager can call a meeting with all the stakeholders in the room and then let them fight it out. This is design by committee, and it rarely yields anything beyond mediocrity. In this model, very common in large companies, the product manager is really a roadmap administrator. The product manager can do his or her job. (Location 1214)
Note: I have a tendency toward #2. I need to ensure i am not working this way
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. (Location 1273)
Note: Metrics are key for a product manager
This means knowing who your various stakeholders are and especially learning the constraints they operate under. (Location 1284)
companies understand the value in making products that are sticky, and this means that it can be difficult for prospective customers to move from your competitor to you. This is one of the big reasons why it is not enough to have feature parity with a competitor. Rather, you need to be substantially better to motivate a user or customer to switch. (Location 1294)
To summarize, these are the four critical contributions you need to bring to your team: deep knowledge (1) of your customer, (2) of the data, (3) of your business and its stakeholders, and (4) of your market and industry. (Location 1306)
Perhaps the most important thing I can tell you to help you succeed is that you simply must take very seriously your preparation for this role. (Location 1338)
To summarize, product owner responsibilities are a small subset of product management responsibilities, but it's critical that the product manager covers both. (Location 1393)
Just as you need to know the language of computing, you also need to know the language of business. If you have never done so, you need to take a course in the basics of business finance. (Location 1410)
Note: I need to read a book on this, perhaps something tailored to government. Knowing commercial finance would be helpful too.
If you are building user‐facing products, it's critically important that you get a trained product designer for your team. If you're doing products for consumers, I would argue that strong design today is table stakes. If you're doing products for businesses, then this is one of your best competitive differentiators. (Location 1493)
In strong teams today, the design informs the functionality at least as much as the functionality drives the design. This is a hugely important concept. For this to happen, we need to make design a first‐class member of the product team, sitting side by side with the product manager, and not a supporting service. (Location 1509)
There's probably no more important relationship for a successful product manager than the one with your engineers. If your relationship is strong, with mutual and sincere respect both ways, then the product manager job is great. If your relationship is not strong, your days as product manager will be brutal (and probably numbered). Therefore, this is a relationship worth taking very seriously and doing everything you can to nurture. (Location 1527)
Note: How can I build better relationships with the engineers on my team?
As a practical matter, you need to engage directly with your engineers every workday. (Location 1548)
Lea then began a sustained and exhausting campaign to communicate continuously with leaders and stakeholders across the entire company. 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. (Location 2191)
Note: No such thing as over-communication. Keep the product top-of-mind.
I coukd be doing better with this for NCAT. I need fo keep the execs more engaged, and should be sending mlre comms out to our high interest stakeholders
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. Don't misinterpret this. Sometimes, we do need to commit to a delivery on a date. We try to minimize those cases, but there are always some. But we need to make what is called a high‐integrity commitment. This will be discussed in detail later, but the key takeaway here is that we need to solve the underlying problem, not just deliver a feature. (Location 2272)
Note: High integrity commjtments help us to focus on the underlting problem, and not just delivering features
The product teams need to have the necessary business context. They need to have a solid understanding of where the company is heading, and they need to know how their particular team is supposed to contribute to the larger purpose. (Location 2293)
In the model I'm describing, it is management's responsibility to provide each product team with the specific business objectives they need to tackle. The difference is that they are now prioritizing business results, rather than product ideas. And, yes, it is more than a little ironic that we sometimes need to convince management to focus on business results. (Location 2314)
There is a tendency, however, with outcome‐based roadmaps to put a deadline date on every item, rather than only on the items with a true date constraint. This practice can have cultural and motivation implications to the team. (Location 2333)
The key is to understand that the root cause of all this grief about commitments is when these commitments are made. They are made too early. (Location 2353)
Note: It is okay to make commitments, but we often make them too early. We need to wait until we have had enough time to put together a high integrity commitment
So, the compromise is straightforward. The product team asks for a little time to do product discovery before commitments are made, and then after discovery, we are willing to commit to dates and deliverables so our colleagues can effectively do their jobs as well. (Location 2366)
Start with why. This is coincidentally the name of a great book on the value of product vision by Simon Sinek. The central notion here is to use the product vision to articulate your purpose. Everything follows from that. (Location 2467)
Don't be afraid to think big with vision. (Location 2472)
Too many companies ignore important trends for far too long. 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. (Location 2481)
Evangelize continuously and relentlessly. There is no such thing as over‐communicating when it comes to explaining and selling the vision. Especially in larger organizations, there is simply no escaping the need for near‐constant evangelization. You'll find that people in all corners of the company will at random times get nervous or scared about something they see or hear. Quickly reassure them before their fear infects others. (Location 2497)
The first principle is fundamentally about how to empower and motivate people to get them to do their best work, and the second is about how to meaningfully measure progress. (Location 2562)
Note: OKRs
Objectives should be qualitative; key results need to be quantitative/ measurable. Key results should be a measure of business results, not output or tasks. (Location 2578)
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. (Location 2603)
The key is that the cascading of OKRs in a product organization needs to be up from the cross‐functional product teams to the company or business‐unit level. (Location 2659)
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. (Location 2714)
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 big picture and how things hang together (or even if they hang together). A prototype lets them clearly see the forest and the trees. (Location 2724)
Share credit generously. Make sure the team views it as their product, not just your product. (Location 2733)
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. A demo is not training, and it's not a test. It's a persuasive tool. Get really, really good at it. (Location 2736)
Learn to show some enthusiasm. Assuming you're genuinely excited, it's amazing to me how many product managers are so bad or so uncomfortable at showing enthusiasm. This matters— a lot. 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. If your team is not co‐located, you'll need to make a special effort to travel there and do this at least every couple months. Spending some personal time with every last person on the team pays off big in their level of motivation and, as a result, in the velocity of the team. It's worth your time. (Location 2745)
Even harder, we need to make sure we come up with a single solution that works for many customers, and not a series of specials. To do this, we need to be able to test out many ideas, and we need to do this quickly and inexpensively. (Location 2814)
We need to learn fast, yet also release with confidence. (Location 2827)
So, 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. And, this is why we have so many different techniques in product discovery. (Location 2845)
The purpose of product discovery is to address these critical risks: Will the customer buy this, or choose to use it? (Value risk) Can the user figure out how to use it? (Usability risk) Can we build it? (Feasibility risk) Does this solution work for our business? (Business viability risk) And it's not enough that it's just the product manager's opinion on these questions. We need to collect evidence. (Location 2862)
we need to agree on the business objective we're focused on, the specific problem we are intending to solve for our customers, which user or customers you're solving that problem for, and how you will know if you've succeeded. These should align directly to your product team's objectives and key results. (Location 3030)
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) (Location 3088)
The idea is that the product manager frames the work ahead of the team by writing an imagined press release of what it would be like once this product launches. How does it improve the life of our customers? What are the real benefits to them? You've all read a press release before— the only difference is that this is entirely imagined. It is describing a future state we want to create. (Location 3138)
I much prefer the startup canvas to old‐style business plans, but I have also observed that many startup teams still spend too much time on the canvas and keep postponing that pesky little problem of discovering a solution that people want to buy (see the box “The Biggest Risk”). (Location 3183)
Story maps are one of the most generally useful techniques I know. They are essentially a framing and planning technique, but they are just as useful for ideation. They are also used as a design technique when working on prototypes, and they are great for communicating with your team and stakeholders. They also play a very practical role in managing and organizing your work. Further, a story map is helpful throughout product discovery and delivery. (Location 3249)
Let's be clear about what it means to be a reference customer: This is a real customer (not friends or family), who is running your product in production (not a trial or prototype), who has paid real money for the product (it wasn't given away to entice them to use it), and, most important, who is willing to tell others how much they love your product (voluntarily and sincerely). Please believe me when I say that there are few things more powerful to a product organization than reference customers. It is the single best sales tool you can provide to your sales and marketing organization, and it completely changes the dynamics between the product organization and the rest of the company. (Location 3295)
Note: Reference customers are incredibly important
We are discovering and developing a set of reference customers in parallel with discovering and developing the actual product. I will warn you that this technique takes substantial effort, primarily on the part of the product manager. I wish it were easier. But I will also say that if you do this technique, I consider it the single best leading indicator of future product success. (Location 3312)
We are looking for prospective customers that truly feel the pain and are near desperate for the solution we want to build. If they could find a solution that worked for them elsewhere, they would have already bought it. However, it's also important we screen out technologists. These people are mainly interested because of the technology, not because they desperately need the business value. (Location 3350)
It's critical to 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 one company (and they wouldn't want that in any case as they would be left with unsupported, dead‐end software). You are, however, deeply committed to coming up with a product that works extremely well for them and just a handful of other companies. (Location 3365)
Your job is to dive deep with each of the six customers and identify a single solution that works well for all six customers. (Location 3370)
This will take finesse at times, but it's important that the members of the customer discovery program be the right set, and no more than eight. However, it's no problem also having an early release program that is essentially unlimited for those customers that want the software early, but you determine aren't right for the customer discovery program. (Location 3380)
For customer‐enabling tools, such as a new dashboard for your customer service agents, we pick six to eight well‐respected, influential internal users/ employees— the individuals that the other agents look up to as thought leaders— and we work closely with them to discover the necessary product. Obviously, they are not customers and not paying anything, but instead we ask them to work closely with us through product discovery to make this tool great. Once they believe that the product is ready, we ask them to tell their colleagues how much they love the new tool. (Location 3411)
Note: NCAT is a customer-enabling tool like this
Let me also add that there are few things as powerful as a marketing person who's also strong at product. The combination is amazing. (Location 3502)
I am fairly certain you will get very excited by many of the ideas you discover. But that doesn't mean you should just go ahead and build them. In most cases, we will still need to test them to ensure they are valuable and usable for our customers, are feasible for our engineers, and are viable for our business. (Location 3521)
Here's what I'm always trying to understand: 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? (Location 3540)
talk primarily to people in your intended target market. You're looking for about an hour of their time. (Location 3550)
A concierge test is a relatively new name to describe an old but effective technique. The idea is that we do the customer's job for them— manually and personally. Just as if you went to a hotel concierge and asked if he could find you some theater tickets to a popular show. You don't really know the details of what that concierge is doing for you to get those tickets, but you do know that he is doing something. With this technique, you become the concierge. You do what the user or customer needs done for them. You may have to ask them to train you first, but you are in their shoes doing the tasks they would do. (Location 3575)
Some product people can get upset when they find customers using their products for unintended use cases. This concern is usually tied to the support obligations. I'm suggesting, however, that this special case can be very strategic and well worth the investment to support. If you find your customers using your product in ways you didn't predict, 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. (Location 3619)
The two main types of hack days are directed and undirected. In an undirected hack day, people can explore whatever product ideas they like, so long as it's at least loosely related to the mission of the company. This is one of my favorite techniques for building a team of missionaries rather than mercenaries. In a directed hack day, there's a customer problem (for example, something is really difficult to learn and use, or it takes too long to do) or business objective we've been assigned (for example, “Reduce the customer churn rate” or “Increase customer lifetime value”), and we ask people from the product teams to self‐organize and work on any ideas they like that might address this objective. (Location 3643)
Remember that product discovery is all about coming up with the fastest, cheapest way to test out our ideas. (Location 3698)
