Olivia: Alright Jackson, I'm going to say a tech product, and you have to give me the brutally honest, one-sentence user manual. Jackson: Okay, I'm ready. Hit me. Olivia: Your company's internal expense reporting software. Jackson: Easy. 'Step 1: Open software. Step 2: Weep silently. Step 3: Give up and pay out of pocket.' Olivia: That's painfully accurate. And it's exactly why we need to talk about Marty Cagan's book, INSPIRED: How to Create Tech Products Customers Love. It's basically the bible for avoiding that exact feeling of user despair. Jackson: Marty Cagan... he's a big deal in Silicon Valley, right? Like, he was there for the dot-com boom? Olivia: He wasn't just there; he was helping build it. He was a VP at Netscape under Marc Andreessen and later led product at eBay. He wrote INSPIRED because he saw this huge gap between how the best companies build products and how... well, how everyone else builds the software that makes us want to weep silently. Jackson: I see. So he's seen both the promised land and the desolate wasteland of bad software. Olivia: Exactly. And his entire philosophy starts not with a success story, but with a spectacular failure of his own at HP back in the 80s.

Jackson: Whoa, a failure? I thought HP in the 80s was unstoppable. What happened? Olivia: That's the fascinating part. Cagan was a young, brilliant software engineer on a team tasked with creating AI-enabling technology on a low-cost workstation. This was cutting-edge stuff. The team worked tirelessly for over a year—nights, weekends, the whole nine yards. They developed the software, secured patents, got rave reviews from the press. They did everything right. Jackson: Okay, so it was a huge success. Olivia: It was a complete and total failure. A market flop. After all that work, they realized nobody actually wanted or needed what they had built. It was a technically impressive solution to a problem that didn't exist for most people. Jackson: Ouch. That is a soul-crushing outcome. So they built this amazing thing and literally no one bought it? How is that even possible? Olivia: It’s possible because of what Cagan calls the root cause of most failed product efforts. He says it doesn't matter how good your engineering team is if they are not given something worthwhile to build. And most companies, he argues, follow a deeply flawed process for deciding what's "worthwhile." Jackson: What does that flawed process look like? I feel like I might be living in it right now. Olivia: It's probably familiar. It starts with ideas coming from the top—executives or sales teams who want to please a big client. Then, they create these elaborate business cases to justify the idea, full of made-up numbers about how much revenue it will generate. Jackson: Ah, the "fantasy spreadsheet" phase. I know it well. Olivia: Precisely. Then these ideas get put on a product roadmap, which is basically a list of features with dates next to them. The product manager's job becomes just gathering requirements and passing them to designers, who then pass their work to engineers. It’s a waterfall, a relay race where each person just hands off the baton. Jackson: But hold on, everyone says they're Agile now. We have sprints and stand-ups. Isn't this an outdated problem? Olivia: That's the illusion! Cagan argues that many companies are just "Agile in name only." They use Agile for the delivery part—the engineering—but the entire front-end of the process, where the actual decisions are made, is still a rigid, sequential waterfall. They're just a feature factory, churning out items from a list without ever really asking the most important questions. Jackson: What are those questions? Olivia: Will customers actually use this? Can they figure out how to use it? Can we even build it with the tech we have? And does it even work for our business? In the typical process, you don't find out the answers until after you've launched, which is way too late. Jackson: So you spend a year building something only to find out nobody wants it, just like Cagan's team at HP. Olivia: Exactly. And Cagan says there are two inconvenient truths we have to accept. First, at least half of our ideas are just not going to work. And second, even the good ideas will take several iterations to get right. The traditional roadmap process ignores both of these truths. Jackson: Okay, so the process is broken. It's a 'feature factory.' How do the great companies avoid this trap? Is it just about hiring smarter people? Olivia: It's about the kind of people you have, and how you empower them. This leads to one of the most powerful ideas in the book: the difference between teams of missionaries and teams of mercenaries.

Jackson: Missionaries versus mercenaries. That sounds dramatic. What's the difference? Olivia: Mercenaries are skilled people who are paid to build what you tell them to build. They execute the feature list. Missionaries, on the other hand, are people who are true believers in the vision. They're obsessed with solving the customer's problem, not just shipping a feature. Cagan argues that the best companies build teams of missionaries. Jackson: And how do you do that? What does a missionary team look like? Olivia: It's a small, cross-functional team, usually with a product manager, a product designer, and a handful of engineers. They are given clear objectives, but they are empowered and accountable for figuring out the best way to achieve them. The product manager is like the CEO of the product—they have deep knowledge of the customer, the data, the business, and the market. They lead through influence, not authority. Jackson: That sounds amazing, but being a 'missionary' also sounds exhausting. And isn't giving one product manager that much power risky? What if they go rogue? Olivia: It is a demanding role, which is why Cagan says the best PMs are smart, creative, and persistent. But they don't operate in a vacuum. They collaborate intensely with their designer and their tech lead. The magic happens when those three roles work together to discover a solution. A perfect example of this is the story of how Google AdWords was created. Jackson: I'm listening. That thing prints money for them. Olivia: Well, in the beginning, almost nobody at Google wanted to build it. The idea of a self-service ad platform was terrifying to the sales team. They were making a fortune selling keywords to big brands and thought this would cannibalize their sales. Jackson: Okay, that makes sense. What about the engineers? Olivia: The engineers hated it even more! They were obsessed with providing pure, relevant search results. They saw ads as a contamination of their beautiful product, something that would frustrate users. So you had massive internal resistance. Jackson: So how did it ever get built? Olivia: A young engineering manager named Jane Manning was assigned to be the product manager. She was a true missionary. She didn't just take orders; she went and deeply understood the concerns of both sales and engineering. She worked to find a solution that could work for everyone. She persuaded key engineers, like Georges Harik, to get on board. Jackson: And what was the solution? Olivia: It was brilliant. They placed the self-service AdWords on the side of the page, clearly separate from the premium, salesperson-sold ads at the top. And to address the engineers' concerns about relevance, they created a formula where ad placement wasn't just about who paid the most, but also about the ad's performance—its click-through rate. This ensured that even the ads were relevant to the user. Jane and her team weren't just building a feature; they were solving a complex, multi-sided problem. Jackson: Wow. So she wasn't a mercenary just checking a box. She was a missionary who had to convert her own company first. Olivia: Exactly. And that kind of leadership, that focus on solving the real, underlying problem, is what enables the alternative to the broken process we started with. It’s how you escape the feature factory. It's about getting rid of the traditional product roadmap.

Jackson: Whoa, get rid of the roadmap? Every manager I've ever had lives and dies by the roadmap! It’s the sacred document! How can a business function without one? Olivia: It's a great question, and Cagan acknowledges that executives need roadmaps for two reasons: to make sure teams are working on important things, and to have some sense of when things will be done for planning purposes. His alternative has to solve for those needs, but in a better way. Jackson: Okay, so what's the alternative? Chaos? Olivia: Not at all. It's about replacing a list of features with a set of business objectives. Instead of telling a team, "Build a new checkout flow by Q3," you tell them, "Your objective is to reduce shopping cart abandonment by 25% this quarter. How you do it is up to you." Jackson: Ah, so the team is given a problem to solve, not a solution to build. That's where the creativity comes in. Olivia: Precisely! This is often managed with a system like OKRs—Objectives and Key Results. The team is accountable for the outcome (the key result), not the output (the feature). This empowers them to be missionaries. They can now use product discovery techniques—like building rapid prototypes and testing them with real users—to find the best way to solve the problem. Jackson: That makes so much sense. It lets them test that "half of ideas that won't work" before they spend six months building them. Olivia: You got it. A fantastic case study of this is Netflix's early pivot. They started with a pay-per-rental model for DVDs, just like Blockbuster but online. And it was failing. Customers would rent once and never come back. Jackson: I remember those red envelopes! So what was their business objective? Olivia: Their objective was survival! They realized the only viable business model was a subscription service. But that created a new problem: new release movies were super expensive for them to stock, and if everyone only rented new releases, Netflix would go bankrupt. Jackson: So their objective became: "Figure out how to make a subscription model profitable." Olivia: Exactly. And the product team, led by Kate Arnold, didn't just get a feature list. They had to invent solutions to that problem. They came up with the Queue, which encouraged users to list older, more profitable movies. They created the rating system and the recommendation engine to surface those older titles and guide users to content they'd love but might not have known about. Jackson: So the queue and the recommendation engine weren't just cool features. They were solutions to a critical business viability problem. Olivia: They were the entire business! Those features were the product of a team that was focused on an outcome—making the subscription model work—not just delivering a list of features from a roadmap. They were solving a problem, not just building something.

Jackson: So we started with this story of a brilliant failure at HP, realized the common process was the problem, then saw that the solution is about empowering the right people—the missionaries—and giving them problems to solve, not just a checklist to follow. Olivia: Exactly. The big takeaway from INSPIRED is that building great products isn't about having a perfect plan. It's about creating a system for rapid learning. It’s about having the humility to accept that at least half of your ideas are probably wrong... Jackson: Which is a tough pill for a lot of smart people to swallow. Olivia: It is. But it’s also about having the courage to find out which half is wrong, as quickly and cheaply as possible, before you bet the farm on it. It’s a shift from a culture of delivery to a culture of discovery. Jackson: That's a powerful shift in mindset. It makes me wonder, for our listeners out there, how many are working in a feature factory right now? And what's one small step they could take to start focusing on an outcome instead of just an output? Olivia: That's the perfect question to reflect on. Maybe it's as simple as asking "why" on the next feature request you get. We'd love to hear your thoughts. Find us on our socials and share your experience. Jackson: This is Aibrary, signing off.