📖 Inspired

How to Create Tech Products Customers Love by Marty Cagan

Find the original posting and other articles here. If you like my content and want to see more of it, sign up for my weekly newsletter on my website.

Top Learnings

• Behind every great product there is someone behind the scenes who led the product team to combine tech and design to solve real customer problems in a way that met business needs
• A company’s best product ideas are not sales or stakeholder driven, they are customer driven
• The two inconvenient truths of product managers: 1) At least half of our ideas won’t work mostly because customers just aren’t as excited about an idea as we are; 2) even when ideas do prove to have potential, they take several iterations to get to the point where business value is being delivered
• The four critical contributions a PM needs to bring to their team: deep knowledge of 1) your customer, 2) your data, 3) your business and its stakeholders and 4) your market and industry
• You should bring a strong POV but demonstrate to your team that you’re open minded, know how to listen and you want and need their help in coming up with the right solution
• A big goal of a PM is to minimize dependencies; this helps teams move faster and feel much more autonomous. A team should feel empowered, yet accountable for some significant part of the product offering
• As a product manager, you have the responsibility to understand the considerations and constraints of the various stakeholders and bring this knowledge into the product team

Secondary Learnings

• When you’re building a startup, nothing matters until you come up with a strong product that meets the needs of an initial market
• Once an idea makes the top of the list, the PM’s role is to talk to different stakeholders to flesh it out and come up with a list of requirements (via user stories or a functional spec), to communicate to designers and engineers what needs to be built
• The biggest cost of building something that doesn’t deliver true value is not money, but opportunity cost of what the organization could have and should have been doing instead
• Risks need to be tackled prior to deciding to build anything. There’s four types of risk — 1) value risk (whether customers will buy it), 2) usability risk (whether users can figure out how to use it), 3) feasibility risk (whether our engineers can build what we need with the time, skills and technology we have), and 4) business viability risk (whether this solution works for the various aspects of our business — sales, marketing, finance, legal, etc.)
• The old model -> PM defines requirement, designer designs a solution that delivers on those requirements, engineering builds when it’s unblocked by PM and design.
  The new model -> product, design and engineering work side by side, in a give-and-take way
• Product discovery: done for the purpose of separating the good ideas from the bad; the output is a validated product backlog
• 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
• As a PM, you need to have a deep understanding of the competitive landscape. Ideally, your product is not only compatible with the ecosystem of other products, but adds tremendous value to it
• Develop program literacy, not to tell eng how to do their job, but to improve your ability to engage and collaborate with them, and this knowledge will give you a much better appreciation for technology and the art of the possible
• Give your engineers as much latitude as possible in coming up with the best solution
• Date is incredibly important — The data we aggregate (from all sources) can be a gold mine. It often boils down to asking the right questions. But by exploring the data, we can find some very powerful product opportunities. Some of the best product work I see going on right now was inspired by the data. Yes, we often get great ideas by observing our customers, and we do often get great ideas by applying new technology. But studying the data itself can provide insights that lead to breakthrough product ideas. Largely, this is because the data often catches us off guard. We have a set of assumptions about how the product is used — most of which we are not even conscious of — and when we see the data, we’re surprised that it doesn’t track with those assumptions.
• The key to trusting relationships with stakeholders is to spend one-on-one time with them; sit down with them and listen!

Notable Quotes

• “It doesn’t matter how good your engineering team is if they are not given something worthwhile to build”
• “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.”
• “It’s all about solving problems, not implementing features. Conventional product roadmaps are all about output. Strong teams know it’s not only about implementing a solution. They must ensure that solution solves the underlying problem.”
• John Doerr, the famous Silicon Valley venture capitalist: “We need teams of missionaries, not teams of mercenaries.” Mercenaries build whatever they’re told to build. Missionaries are true believers in the vision and are committed to solving problems for their customers.
• “In strong teams today, the design informs the functionality at least as much as the functionality drives the design.”
• “There’s probably no more important relationship for a successful product manager than the one with your engineers.”
• “Some of the best venture capitalists only invest in founders who have already proved themselves as great product leaders.”
• “The idea behind business objectives is simple enough: tell the team what you need them to accomplish and how the results will be measured, and let the team figure out the best way to solve the problems.”
• “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.”
• To quote Marc Andreessen, “The most important thing is to know what you can’t know,” and we can’t know in advance which of our ideas will work with customers and which won’t.

Got Me Thinking

• Tech isn’t necessarily purely digital. Some of the best companies today are blends of online and offline experiences (finding a ride or a room for the night, sending an overnight package, etc.)
• In product, things always boil down to a tradeoff
• One of the most basic of all product lessons learned is that trying to please everybody at once will almost certainly please nobody
• You can release all the features you want, but if it doesn’t solve the underlying business problem, you haven’t really solved anything
• Product culture can be thought of along two dimensions — one is whether the company can consistently innovate to come up with valuable solutions for their customers, and two is execution… it doesn’t matter how great your ideas are if you can’t get a productized, shippable version delivered to your customers

[Bonus 1] 10 Key Principles for Coming Up with an Effective Product Vision

1. Start with why
2. Fall in love with the problem, not with the solution
3. Don’t be afraid to think big with vision
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 meaningful trends
7. Skate to where the puck is heading, not to where it was
8. Be stubborn on vision but flexible on the details
9. 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
10. Evangelize continuously and relentlessly

[Bonus 2] Good Teams vs. Bad Teams

Good teams have a compelling product vision that they pursue with a missionary‐like passion. Bad teams are mercenaries. Good teams get their inspiration and product ideas from their vision and objectives, from observing customers’ struggle, from analyzing the data customers generate from using their product, and from constantly seeking to apply new technology to solve real problems. Bad teams gather requirements from sales and customers. Good teams understand who each of their key stakeholders are, they understand the constraints that these stakeholders operate in, and they are committed to inventing solutions that work not just for users and customers, but also work within the constraints of the business. Bad teams gather requirements from stakeholders. Good teams are skilled in the many techniques to rapidly try out product ideas to determine which ones are truly worth building. Bad teams hold meetings to generate prioritized roadmaps. Good teams love to have brainstorming discussions with smart thought leaders from across the company. Bad teams get offended when someone outside their team dares to suggest they do something. Good teams have product, design, and engineering sit side by side, and they embrace the give and take between the functionality, the user experience, and the enabling technology. Bad teams sit in their respective silos, and ask that others make requests for their services in the form of documents and scheduling meetings. Good teams are constantly trying out new ideas to innovate, but doing so in ways that protect the revenue and protect the brand. Bad teams are still waiting for permission to run a test. Good teams insist they have the skill sets on their team, such as strong product design, necessary to create winning products. Bad teams don’t even know what product designers are. Good teams ensure that their engineers have time to try out the prototypes in discovery every day so that they can contribute their thoughts on how to make the product better. Bad teams show the prototypes to the engineers during sprint planning so they can estimate. Good teams engage directly with end users and customers every week, to better understand their customers, and to see the customer’s response to their latest ideas. Bad teams think they are the customer. Good teams know that many of their favorite ideas won’t end up working for customers, and even the ones that could will need several iterations to get to the point where they provide the desired outcome. Bad teams just build what’s on the roadmap, and are satisfied with meeting dates and ensuring quality. Good teams understand the need for speed and how rapid iteration is the key to innovation, and they understand this speed comes from the right techniques and not forced labor. Bad teams complain they are slow because their colleagues are not working hard enough. Good teams make high‐integrity commitments after they’ve evaluated the request and ensured they have a viable solution that will work for the customer and the business. Bad teams complain about being a sales‐driven company. Good teams instrument their work so they can immediately understand how their product is being used and make adjustments based on the data. Bad teams consider analytics and reporting a nice to have. Good teams integrate and release continuously, knowing that a constant stream of smaller releases provides a much more stable solution for their customers. Bad teams test manually at the end of a painful integration phase and then release everything at once. Good teams obsess over their reference customers. Bad teams obsess over their competitors. Good teams celebrate when they achieve a significant impact to the business results. Bad teams celebrate when they finally release something.

Recommended Books

User Story Mapping: Discover the Whole Story, Build the Right Product, by Jeff Patton (O’Reilly Media, 2014).

Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, by Jake Knapp, John Zeratsky, and Braden Kowitz.