Tiêu đề Module 1 [Tài liệu đọc - Bắt buộc] - Giới thiệu Product Management & Tư duy sản phẩm ✅

Chương 1 của The Product Book CHAPTER ONE “Nobody asked you to show up.” Every experienced product manager has heard some version of those words at some point in their career. In this case, those painfully frustrating words are from Ken Norton, partner at Google Ventures, in a blog post titled “How to Hire a Product Manager.” Think about a company for a second. Engineers build the product. Designers make sure it has a great user experience and looks good. Marketing makes sure customers know about the product. Sales gets potential customers to open their wallets to buy the product. What more does a company need? Where does a product manager fit into that mix? Those simple questions are what cause not only the confusion, but also the opportunity that comes with product management. Heck, if you’re transitioning into product management, these questions might make you worry that product managers are irrelevant. And if you are currently a product manager, you might feel a sudden need to justify your existence. Truthfully, without a product manager a company will continue to operate pretty well—to a point. Yet with a strong product manager a company can become great. WHAT DO PRODUCT MANAGERS DO? Put simply, a product manager (PM) represents the customer. No one buys a product because they want to give the company money. Customers buy and use products because the products address their needs. Done properly, the products let the customers be awesome. The end result of representing the customer is that a PM helps the customer be awesome. There’s a lot behind this simple definition, though. Adam Nash, CEO of Wealthfront and former VP of product at LinkedIn, summed up product management by saying, PMs figure out what game a company is playing, and how it keeps score (hint: it’s not always about how much money the company makes). Day to day, PMs must understand both business strategy and execution. They must first figure out who the customers are and what problems the customers have. They must know how to set a vision, finding the right opportunities in a sea of possibilities, by using both data and intuition. They must know how to define success, for the customer and the product, by prioritizing doing what is right over doing what is easy. They must know how to work with engineers and designers to get the right product built, keeping it as simple as possible. They must know how to work with marketing to explain to the customer how the product fills the customer’s need better than a competitor’s product. They must do whatever’s needed to help ship the product, finding solutions rather than excuses. Sometimes, this even means a PM getting coffee for a team that’s working long hours to show appreciation. By the way, PMs manage products, not people, so they must achieve everything using soft influence, effective communication, leadership, and trust—not orders. Even though it’s not always obvious what PMs do from the outside, they genuinely do a lot! PMs do so much that they’re sometimes even called “Mini CEOs.” Ironically, the thing a PM does the most is say “no.” Some people believe that product managers just dictate what features to build. Given everyone has lots of ideas for features, why bother with a PM?

work on a software API where the end customer is a software developer. Technical PMs won’t be writing the code or performing technical tasks, but they need to understand the details of what goes into those tasks. Another specialization is strategic product management. This role is the complement to a technical PM, and it’s someone who has a strong business-oriented background. Once in a while, you’ll also see titles linked to specific verticals or tasks, such as growth product manager or mobile product manager. These roles are more focused than the general PM role, and a person in such a role will have a more specific set of skills, such as being an expert in all the different things you can do to grow a product—that is, get more customers using it HOW PRODUCT MANAGERS GET PRODUCTS BUILT While sometimes it might seem like the CEO imagines a product in the shower, and then tells the engineering team to build it, any one who has been a CEO knows this is not the case. Product management is similarly misunderstood by the general public. On TV you’re likely to see the guy get out of the shower and start hacking on a laptop with bright green text, occasionally solving a hard problem by drawing on glass. The real world doesn’t work like that. So, how do products get built? What does a product manager really do, and how? In reality, products continuously undergo a product-development life cycle, and a product manager shepherds the product through each phase, owning some phases and contributing to others. The product development life cycle involves discrete steps, and each step emphasizes a different leg of the Product Triangle. While the steps are well defined, there are multiple approaches to how these steps can be implemented. On one end of the spectrum there’s the lean approach, based on Toyota’s manufacturing methods and adapted to software/product development by Steve Blank and Eric Ries. The lean methodology focuses on very fast, iterative cycles where your goal is to make something small, release it, learn from it, and use that knowledge to figure out what to do next. Lean cycles might happen in just a few days. On the opposite end of the spectrum you have the waterfall approach, where you build something big in a very linear fashion—you spend a lot of time planning a product, and once you’ve decided what to do, that’s what you’re going to build and ship even if it takes a long time. The product moves through each process step by step and, like a waterfall, things flow one way, and—almost—never change once they’re defined it. Waterfall cycles might take a year or more. For software product development, larger and older companies tend to use a waterfall approach, whereas many start-ups use a lean approach. As you might expect intuitively—and there have been many studies to back this up—building products with a lean approach is more successful because you’re not risking everything on a potentially long, slow-tocreate project. Instead, you risk a little bit to build something small, learn from it, and iterate. For that reason, even larger and older companies are shifting towards a lean approach, moving away from waterfall. The most common approach you’ll encounter is a hybrid of water- fall and lean where the PM will plan a bit upfront to find the right opportunity, but then the teams will implement the product in an iterative way. This is nice because it lets you keep a big-picture goal in mind, but change course if needed such as if you find a significant technical obstacle or find that customers don’t want the product you’re building. We’ll mainly focus on a hybrid approach in this book.