Roger: Hey everyone, welcome back! Okay, quick question right off the bat—has anyone ever used something and just thought, "Why does this even exist? Who would actually “use” this?" Or, flipped it, have you ever been on a team rushing to ship features, but wondering if any of it made a difference? Patricia: Oh, Roger, straight to the jugular, I like it. Yeah, I've definitely been on projects that felt more like feature factories than anything else. We were cranking stuff out... and let’s just say the story didn’t have a happy ending. Roger: Exactly! And that's the core problem that Melissa Perri addresses in her book, Escaping the Build Trap. The whole point is to shift us away from just churning out output—you know, features, ticking boxes—and get us focused on outcomes. We're talking about outcomes like actually creating value for customers, which then leads to sustainable growth for the company. Patricia: Right, “outcomes.” Sounds fantastic, theoretically. But how does that translate for teams buried in roadmaps and chasing KPIs? Roger: Good point. Perri really breaks it all down. She doesn't just point out the problem—this "build trap" where companies are constantly building, but not hitting the mark. She gives us practical strategies to change the culture, processes, and even leadership, all to deliver what truly matters. And yes, it’s full of examples and case studies to make these ideas concrete. Patricia: Case studies, eh? Now you're speaking my language. Roger: Knew that would grab you. So, today, we’ll kick things off by looking at why this build trap exists in the first place and why so many companies fall into it. Then, we'll talk about how product teams – with the right tools and thinking – can guide their organizations out of the mess and towards a clear, focused approach. Patricia: So, first we wallow in chaos, then we find clarity. Got it. And I'm guessing this involves some pretty big shifts in company culture, too? Roger: Absolutely. Real change can’t happen without creating the right environment. Perri covers everything from how we measure success to how we incentivize teams. It's a real guide for companies that are serious about becoming product-driven. Patricia: A guide, huh? Let’s hope it’s not one that's littered with pointless features along the way.

Roger: So, getting back to where we were, let's really dig into the “build trap” – what it is and why it's just so common. Basically, it's when companies think they're winning if they're churning out features, hitting deadlines, all that, without actually stopping to ask, "Hey, is any of this stuff helping our customers or even moving us toward our goals?" Patricia: Exactly, it’s like mistaking activity for progress. But okay, I'm still a little fuzzy on why smart companies fall into this trap in the first place. It's not like people wake up and say, "Let's build some useless stuff today!" Roger: Well, a big part of it is how things are set up. A lot of places reward teams for launching features and meeting deadlines, not necessarily for, you know, solving real problems. Imagine a product manager who gets praised for pushing out six new features in a quarter. Great, right? But what if nobody bothers to ask, "Did anyone actually want those features?" It turns into a box-checking exercise, not about adding value. Patricia: Yeah, that makes sense. Okay, but just playing devil's advocate here, is that really so bad? Deadlines are deadlines. Features are features, right? It’s just the cost of doing business. Roger: True, deadlines are important, but what if meeting deadlines means ignoring what your customers are actually telling you? Perri points out that companies deep in the build trap often rush half-baked products to market since they’re so focused on speed. They skip the critical step of validating ideas—testing whether a feature actually works for users before launch. The result is unhappy customers and wasted resources. Patricia: Ah, so you end up with that feature graveyard – that corner of the app that nobody ever uses. I remember, didn’t she mention some crazy statistic about like, what, 2% of features actually get used? Roger: Exactly. That's one of the most striking consequences of the build trap. Just how much effort gets wasted when companies don’t bother understanding what really matters to their customers. Imagine spending months, even years, developing features that were irrelevant from day one. Patricia: It does remind me of Lydia’s story in the book, right? She's that product manager who tries to get user research into the planning meetings, but she keeps getting shut down. Her team is all about churning out features, which leaves zero room for asking, “What problem are we even solving here?” Roger: Lydia’s experience really highlights another consequence of the build trap: it sidelines strategic thinking. When product managers can’t focus on the “why” behind their work, they just end up managing backlogs or chasing deadlines. It's really demotivating for talented folks like Lydia, who truly want to make a meaningful impact. Patricia: Which really feels like a leadership problem, right? Because honestly, it sounds like Lydia’s management created that "build, build, build" culture. I mean, if leadership's just asking, "How fast can we ship this?" Instead of "How's this going to improve the lives of our customers?" What else can you expect? Roger: I agree. Leadership is absolutely key here. According to Perri, it's not just the frontline teams that need to change; leaders need to shift their mindset too. That means redefining what success looks like, moving away from vanity metrics like the number of features delivered, and focusing instead on things like customer satisfaction, retention, or engagement. To your point earlier, Patricia, deadlines and shipping definitely aren't bad, but they need to serve a larger purpose. Patricia: Okay, but let's be real. Even if the leadership gets on board with focusing on outcomes, isn't that switch hard? I mean, the entire organization is built around these metrics, incentives, and processes. You can't just snap your fingers and say, "Hey, everyone, forget your quarterly KPIs. Let’s think long-term now!" Roger: And that's where tools and frameworks come in. Companies first need to spot the warning signs of the build trap, like those misaligned metrics or the constant pressure to deliver without checking the impact. Then, they can start using outcome-driven frameworks, like the Product Kata, which uses iterative experimentation to align work with customer needs and business goals. Patricia: Woah woah, hang on. Product Kata? Sounds a little fancy. Is it some buzzwordy way of saying, "Try things until something sticks?" Roger: It’s actually pretty structured. The idea is to run a series of small experiments focused on specific customer needs or goals. Teams ask questions like, "What problem are we trying to solve?" And "How are we going to measure success?" It’s about learning through quick iterations, rather than assuming you know the answer from the start. Patricia: Alright, that makes sense. But here’s what I’m wondering: What if you're in a company of, say, 500 people and only the product team buys into this experimental mindset? Meanwhile, leadership is still just banging the drum of "deliver more" and "deliver faster.” Roger: Right, and that's why escaping the build trap isn't just a team thing, it’s an organizational shift. Perri stresses the importance of creating open communication channels and aligning goals across every level. Everyone from the C-suite to the developers needs to understand how their work contributes to adding value. Patricia: And that's where it gets tricky, right? Open comms sounds great, but in the real world? You’ve got silos, legacy systems, and people who don’t want to change. Even if Lydia’s team embraced the Product Kata, would that have been enough to overcome leadership’s obsession with output? Roger: That’s a fair point, Patricia. And no, cultural shifts like that don’t just happen overnight. But Perri does give us examples, like Marquetly, a fictional company that managed to escape the build trap by fully committing to an outcome-oriented approach. They actively involved leadership, changed their metrics, and broke down silos to foster collaboration. Patricia: I mean, Marquetly’s story is all well and good, sure. But sounds almost too good to be true. What do you think is the biggest hurdle most companies face when transforming like that? Roger: Honestly? Probably fear. Fear of failure, fear of change, fear of taking time to experiment when you’ve got pressure to deliver now. But here's the irony: staying in the build trap is ultimately riskier than making those initial moves towards change. The costs of wasted resources, ineffective products, and lost customer trust are far greater. Patricia: So it’s about convincing people that slowing down, asking the right questions, and validating your ideas aren’t luxuries—they’re actually necessities.

Roger: So, understanding this “build trap” naturally leads to the question: how do organizations actually escape it? That’s where Melissa Perri shifts the conversation, focusing on effective product management as the key. It’s not just about identifying the trap, but how product management can help organizations climb out. Patricia: Ah, finally, the knight in shining armor! Product management to the rescue, eh? Let me guess, it involves shuffling roles, maybe some new tools, and generally trying to make things a little less… chaotic, right? Roger: Precisely. The idea is that product managers bridge user needs and business goals, making sure whatever gets built is actually meaningful. And here’s the crucial part: it’s not just about doing more, or working harder, but about having the “right” processes, clearly defined roles, and some real discipline. Patricia: Sounds good on paper. But when you say "effective product management," doesn’t that get a little… amorphous? I mean, what does "effective" actually look like in practice? Roger: Good point. Let me break it down a bit. Truly effective product management is about measurable, value-driven results - the kinds we were just talking about. It starts with questions like: "Why are we building this? Whose problem are we solving?" And, importantly, the product manager's role isn’t just project management. It's about aligning teams, investigating user pain points, and steering the organization away from superficial metrics and towards real impact! Patricia: Alright, hold up. Isn't that where things usually fall apart? I’ve seen companies hiring “product managers” with job descriptions like, “Own the roadmap” or “Get features delivered.” Oh, and the infamous "Mini-CEO" description, where the product manager is expected to be some kind of all-knowing, all-doing superhero. That. Never. Works. Roger: Absolutely, I totally agree. Perri actually addresses that directly. Misdefining the role is a common way companies undermine their product managers from the get-go. That "Mini-CEO" thing leads to burnout because you're asking one person to handle everything – team alignment, user research, implementation, everything! Effective product managers aren't solo heroes, they're facilitators of collaboration. Patricia: Collaboration… so, it's not just about, “Stand aside, I’ve got this”? Roger: Exactly. The real value comes when product managers empower teams to make data-informed decisions. And speaking of which, Perri outlines some effective tools and methods that can help product managers do exactly that. Patricia: Ah, tools! My favorite things to… dissect. Let’s hear them. Roger: One method she covers is data-driven strategy development. Like Pirate Metrics, for example—have you come across those? Patricia: Sure, AARRR, right? Acquisition, Activation, Retention, Referral, Revenue. A pirate consultant’s dream framework, really. Roger: Yes, exactly. Pirate Metrics breaks down the customer journey into stages where product managers can pinpoint issues. Are users dropping off right after signing up? Maybe activation needs some work. Retention falling flat? Time to dig into engagement rate. The beauty of this is that it helps teams focus their efforts where they will have the biggest impact. Patricia: Alright, I’ll concede that metrics are important – but they are only as good as the story they tell. So, I'm guessing product managers also need to dive headfirst into user research to figure out what's actually going on? Roger: Definitely. User research is the foundation of strategic alignment. And that's where methods like the Product Kata come in. It's an iterative, problem-solving approach – almost like scientific experimentation – but in the context of product building. Patricia: Product Kata. Sounds like a martial art for product management. What's it all about? Roger: It’s a structured way of constantly questioning and testing assumptions. You start with a challenge, like "How do we improve first-time user engagement?" Then, you run small, low-risk experiments to test out potential solutions. Let's say you suspect that shorter forms improve user activation. Instead of spending development resources building a completely new onboarding flow, test it first with a simple mock-up or a concierge service. Patricia: So… fewer grand gestures, more testing before investing? Sounds logical, but does it actually get the support of leadership? Roger: That’s the tricky part, really. Perri emphasizes that escaping the "build trap" requires organizational buy-in from leadership. If leaders are still rewarding teams for churning out features instead of focusing on metrics like customer satisfaction or retention, all the experimentation in the world won’t make a difference. Leadership has to redefine those measurements of success. Patricia: Agreed. But let's be honest - redefining success in a corporate environment can feel like pushing a boulder uphill. When leadership’s been fixated on quarterly KPIs for decades, what exactly convinces them to change? Roger: Real-world evidence. One of Perri’s examples actually shows what happens when companies ignore outcome alignment. She talks about a software product with 30 developed features… only to find out after launch that only about 2% of the features were actually being used. That’s a waste! When organizations start to connect things like retention or customer satisfaction to fewer but more thoughtful developments, the impact is pretty obvious. Patricia: Oh, the infamous “2% of features used” statistic. Every product team’s recurring nightmare! It's insane how much money and time just evaporates into irrelevant functionality. Roger: Exactly, and that ties into collaboration – another key point. Product managers can’t fix problems in isolation. They need to bring in marketing, design, development – everyone – and challenge any assumptions. For example, instead of immediately saying, "Let's launch a new feature to fix X," teams need to align and ask, “What problem is X actually solving? And for whom?” Patricia: It's almost like therapy for cross-functional teams. Everyone gets to voice their perspective, unpack the assumptions, and move forward with some clarity. Roger: Therapy… but with a purpose! And to take it a step further, tools like scenario mapping can help teams visualize the long-term impact of their choices. You are not just thinking about what happens next month, you are actually planning for what success looks like in a year or more. Patricia: So we’ve got tools, research, collaboration… Sounds like product management isn't just about "managing." It’s really about creating alignment and focus. Roger: Which is the ultimate goal. Product managers are the glue holding it all together. They’re not just translating user needs into business goals, they are fostering a culture where the entire organization can focus on delivering value instead of just checking off boxes on a roadmap. Patricia: I'm almost convinced… almost. But I’d still like some real-world examples. Perri must have shared some stories of product managers grappling with these ideas, right? Roger: Oh, absolutely. Let's start with Nick—he’s a perfect example of what can go wrong when product managers don’t follow some of these ideas.

Roger: Okay, so we've talked about the product management framework. Now comes the really transformative part: embedding those principles into your organizational culture. In "Escaping the Build Trap," Melissa Perri really digs into how to transition to a product-led organization. We're talking about organizational transformation—taking those frameworks we've already discussed and applying them company-wide to shift from output-driven chaos to an outcome-oriented approach. Patricia: Right, which I'm guessing is a lot easier said than done! Reshaping an entire culture? I mean, isn't that like trying to reroute a fully-loaded supertanker mid-ocean? Roger: Exactly, Patricia! That's precisely the challenge. Perri emphasizes that it's not just tweaking processes or reorganizing a team here and there. It's a complete structural and cultural shift. We're talking about reorienting everything—teams, leadership, even incentives—around one core goal: delivering customer value to the customer. And yeah, it takes time, effort, and buy-in from absolutely everyone. Patricia: So, more like tearing down the house to rebuild the foundation while you're still living in it, then. Roger: That's a great metaphor actually. The transition calls for reorganizing teams around value streams, embedding roles like Product Operations to keep things aligned, and creating environments where people feel safe to experiment. You need teams laser-focused on understanding and solving customer problems, and you need leadership clearing the way for them to do their best work. It's as much about structure as it is about culture. Patricia: Alright, so let's zoom in a bit before we go macro. What's this "value streams" idea? Sounds like prime buzzword territory. Does it just mean handing out team shirts that say "VALUE" on the back? Roger: It's definitely more than that! Value streams are about structuring teams, not by departments or technical skills, but by the specific outcomes they're meant to achieve for the customer or the business. For example, instead of having one big development team working on every single feature, you might have dedicated teams—one focused on retention, one on acquiring new users, and another on improving the first-time user experience. Patricia: Okay, so you're breaking down those silos we all know and love to hate, then? But how does that actually work in practice? I mean, give me an example where this kind of reorg didn't just sound good on paper but actually delivered results. Roger: Well, one example Perri often uses is TransferWise, now Wise. They really restructured their teams around specific customer goals. One team, for instance, was focused on reducing churn by figuring out why users stopped transferring money. Another zeroed in on enabling transactions in new currencies. These small, cross-functional teams had full ownership of their outcomes, from the initial research all the way to execution. Patricia: And I bet those teams had insane levels of autonomy, right? Roger: Exactly! It's the secret sauce. TransferWise trusted these teams to manage themselves and make decisions, as long as those decisions directly contributed to their defined outcomes. It’s a model where every team operates like a startup within the larger company, aligned under a central mission but agile enough to solve their specific problems. This cuts down on redundancy, reduces communication bottlenecks, and most importantly, keeps the focus squarely on the customer. Patricia: Interesting. Now, let's address the elephant in the room: doesn't giving teams this much freedom eventually lead to chaos? What stops the retention team from obsessing over vanity metrics while another is busy actually innovating something meaningful? Roger: Okay, that's where the second key thing Perri talks about comes in: Product Operations. It's a role that may not have gotten much attention a few years ago, but it's essential now. Product Ops ensures there's alignment among all the teams. They centralize tasks like maintaining roadmaps, tracking experiments, and managing customer insights so no one's duplicating efforts or running in parallel without awareness. Patricia: Ah, so Product Ops is like the air traffic controller, making sure all the teams don't fly into each other chasing different goals. Got it. Do you have an example of this role actually untangling messy operations somewhere? Roger: For sure, Marquetly, that fictional company Perri uses throughout the book, is a great example. Before they introduced Product Ops, Marquetly's teams were constantly stepping on each other’s toes – features targeting the same user issues, multiple experiments messing up their data, the works. Product Ops stepped in to streamline communication, align objectives, and make sure all experiments were properly tracked. With that level of visibility and oversight, the teams could finally collaborate effectively and drive better outcomes. Patricia: So, Product Ops is like air traffic control. Making sure planes—or in this case, features, experiments, and strategies—don't crash into each other while staying on course. Sounds great… until you realize that pulling off "course correction," even with the best alignment, still requires leadership backing. Leaders have to want this change, right? Roger: Absolutely. And that's where fostering psychological safety comes in. Leadership needs to create an environment where teams feel safe to experiment, fail, and adapt without fear of being punished. Perri talks about Netflix's big learning moment with Qwikster. Remember that? Their attempt to split streaming and DVD rentals into two separate brands? Patricia: Oh yeah, that was a disaster! Roger: It totally backfired. And yet, instead of punishing the teams involved, the leadership took accountability, learned from the mistake, and doubled down on innovation. Patricia: Qwikster is such a fascinating case, though. Not only did Netflix recover, but they used what they learned to just totally dominate streaming and even disrupt their own business model. Talk about commitment to experimentation. But here's the thing... how many companies are really willing to stomach that level of public failure? Roger: Not many, honestly! Fear of failure is a big hurdle to overcome in adopting a product-led mindset. But what Netflix shows us is that failure isn't fatal if you treat it like a stepping stone. By embracing experimentation, paired with accountability, companies can innovate, adapt, and “really” thrive. Patricia: So, psychological safety isn't just about giving teams warm hugs and saying, "It's okay to fail." It's about creating an environment where risk-taking is strategic and constructive. Roger: Exactly. And when you combine that with tools like value-stream-oriented teams and operational alignment through Product Ops, you get the best of both worlds. You can experiment boldly while staying laser-focused on outcomes. Patricia: Okay, Roger, I'm hearing lots of theory here. But where's the tangible proof? Did Perri share more real-world examples of this actually working on a large scale? Roger: Absolutely. Netflix's streaming pivot, TransferWise's agility... those are just a couple of standout examples that prove this can work, even at a pretty massive scale.

Roger: Okay, let's wrap things up. Today we talked about the whole “build trap” thing, right? Where companies get so caught up in just doing – shipping features, hitting deadlines – that they forget to ask if they're actually creating something useful. Melissa Perri's book really pushes us to rethink that, to really focus on results that benefit both the customer and the business. Patricia: Exactly. We also dug into some potential solutions. Like empowering product managers to really be those essential connectors, and using tools like the Product Kata and Pirate Metrics to help teams stay focused on the right problems. But here’s the thing, you can't just apply a framework and think you're done. It’s really about a fundamental shift in how you approach things – reorganizing around value, encouraging teamwork, and allowing for experimentation. Roger: Precisely! It's not only about the process, it's also about leadership. Leaders need to redefine what success means, rewarding outcomes that prioritize the customer, and encouraging teams to take smart risks. I mean, just look at success stories like Netflix and TransferWise – they show that committing to this kind of shift can really lead to some incredible growth and staying power. Patricia: So, here’s the big question. If you're swamped with features or drowning in metrics that don't show if anyone actually cares, you’ve got to ask yourself: Are we stuck in the build trap? And, more importantly, what’s our plan to get out? Roger: Because honestly, the risk of staying stuck in that trap – wasted money, frustrated employees, irrelevant product – is way bigger than the effort it takes to change your approach. You can start with very small steps— use data, ask insightful questions, and get your teams aligned to customer outcomes. These small steps can lead to lasting change tomorrow. Patricia: Yeah, and remember, escaping the build trap doesn't happen overnight. Be patient. Rome wasn’t built in a day! But with the right mindset, frameworks, and support from leadership, it’s not only possible, it’s essential. Roger: I totally agree. Thanks for joining us as we delved into “Escaping the Build Trap”. Let’s keep building—but let’s make sure we're building something worthwhile. See you next time! Patricia: Right and let’s aim for a feature usage rate higher than two percent, alright? See you!