Four mistakes scaling teams make - Julia Barham (Author and Product Executive)

Julia Barham leads a CX acquisition team at Progressive Insurance and is the author of The Product Management Playbook, published by Rosenfeld Media in July 2026. She wrote it to close what she sees as a coaching gap in the profession: a decade of product transformations has produced far more people with the title than people who have been taught end-to-end craft. In this episode she makes the case for treating ambiguity as a condition of the job rather than a problem to be solved, and walks through the things that quietly break when a product starts to scale.

Key takeaways

1. Frameworks come and go, but the questions endure. Julia structured her book around why something matters, who it is for, what needs building and when, because no methodology eliminates ambiguity, it only reduces it.
2. Organisational ambiguity is the least discussed of the four ambiguities PMs face, and the one that separates individual contributors from leaders. Waiting for the perfect operating model, funding model or team shape is a way of not moving.
3. If you have to be in every room to answer every question, you are scaling chaos. Durable artefacts, bug severity rubrics and self-service dashboards let the team make calls without you.
4. Synthesis is where shared context gets built, and offloading it to an AI tool quietly removes the thing that made it valuable. Do it together, monthly, with the customer, platform and business data in the same room.
5. Chasing growth before product market fit turns your economics upside down. Products commonly take two years to find fit, sometimes five, and retention is the strongest signal that you have it.
6. Julia spent nine months fixing latency on an inherited platform because of shortcuts taken at launch. The cost was measured in millions of lost revenue, not just engineering time.
7. Attaching a monetary value to technical debt is what turns a product manager from a stick in the mud into a steward of the business. Treat your product like a P&L whether you own one or not.
8. A product at scale needs a portfolio, not a backlog: optimisation, strategic bets, capability work, and honest capacity set aside for run-the-business support.
9. AI belongs in the toolkit, not in the chair. If you cannot call BS on the output, you do not know enough to be doing the job.

Chapters

• (00:00) Don't scale chaos
• (01:01) Introducing Julia Barham
• (03:01) The coaching gap that prompted the book
• (03:57) Why the book is built around questions, not frameworks
• (06:06) Has product management ever been deterministic?
• (07:47) The four ambiguities every product manager faces
• (10:00) Does organisational ambiguity change with company size?
• (12:57) The 21 plays and how to use them
• (15:35) Getting your reps in across the product lifecycle
• (17:07) What breaks when products and teams scale
• (17:59) Mistake one: needing to be in every room
• (20:30) Building shared context across distributed teams
• (23:51) The ways of working exercise
• (24:19) Mistake two: chasing growth before product market fit
• (25:56) How to measure product market fit
• (27:16) Mistake three: scaling expensive problems
• (29:42) Putting a price on technical debt
• (31:54) When taking on debt is the right call
• (34:22) Naming the mode your product is in
• (35:09) Mistake four: running your product as a portfolio
• (37:39) The one problem Julia would make disappear
• (39:25) What AI changes, and what it does not
• (42:26) Wrap-up

Referenced

• The Product Management Playbook, Julia Barham, Rosenfeld Media: https://rosenfeldmedia.com/books/product-management-playbook/
• Use discount code MTP20 for 20% off at Rosenfeld Media
• Sample chapter: https://rosenfeldmedia.com/sample-chapter-the-product-management-playbook/
• Dan Olsen and the product market fit pyramid: https://dan-olsen.com
• Testing Business Ideas, David Bland
• Progressive Insurance: https://www.progressive.com
• Pioneers, settlers and town planners, Simon Wardley: https://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html

Our Hosts
Lily Smith enjoys working as a consultant product manager with early-stage and growing startups and as a mentor to other product managers. She’s currently Chief Product Officer at BBC Maestro, and has spent 13 years in the tech industry working with startups in the SaaS and mobile space. She’s worked on a diverse range of products – leading the product teams through discovery, prototyping, testing and delivery. Lily also founded ProductTank Bristol and runs ProductCamp in Bristol and Bath.

Randy Silver is a Leadership & Product Coach and Consultant. He gets teams unstuck, helping you to supercharge your results. Randy's held interim CPO and Leadership roles at scale-ups and SMEs, advised start-ups, and been Head of Product at HSBC and Sainsbury’s. He participated in Silicon Valley Product Group’s Coaching the Coaches forum, and speaks frequently at conferences and events. You can join one of communities he runs for CPOs (CPO Circles), Product Managers (Product In the {A}ether) and Product Coaches. He’s the author of What Do We Do Now? A Product Manager’s Guide to Strategy in the Time of COVID-19. A recovering music journalist and editor, Randy also launched Amazon’s music stores in the US & UK.

Transcript

Copy

SPEAKER_01 0:00

One of the mantras that I like to teach and coach on teams is don't scale chaos.

SPEAKER_00 0:04

Not planning for the day when you can't be in every room. What do you mean by that?

SPEAKER_01 0:08

You have to be the person that's making the call on the trade-off or the priority. You're scaling chaos. I see people that they launch their products, they become obsessed with growth right away. The focus needs to be more on product market fit. The reality is a lot of products actually take about two years to achieve product market fit. Some might even take up to five. Miro and Figma took them about five in a survey until they felt like they had actually reached product market fit. As a product manager, I wound up spending nine months working with the engineering team on resolving latency issues because the platform was too slow. Nine months that was also expensive for us because it ultimately cost us millions of dollars in revenue. If you're scaling complexity or not subtracting or simplifying, that's probably a signal that you're going to be hurting your future self and making it a little bit harder for the team.

SPEAKER_00 1:01

Julia, thank you for joining us this week. How are you doing?

SPEAKER_01 1:04

I am fantastic. How are you, Randy?

SPEAKER_00 1:07

I'm doing all right. And I've just uh gotten most of the way through your book. I haven't finally gotten the last 20 or 30 pages, but I'm gonna get there very soon. Um, and we'll talk more about that in a moment. But for people who haven't seen the book, who don't already know you, can you give a little introduction? How did you get into product in the first place? And what are you up to these days?

SPEAKER_01 1:30

Thank you for having me on the podcast. So happy to be here. Um, like many people, I stumbled into product management. So I know that's kind of a common story, but uh years ago, I was working for a newsletter subscription company that focused on financial news for investors, and I was asked to help improve conversion and retention. And long story short, it was around the same time jobs to be done and design thinking was popular, and had a few uh UX mentors that taught me a little bit about product and it opened the world, and it's kind of been uh a long runway ever since. So that was me kind of stumbling into it today. Kind of fast forward to today, I lead product teams. I actually work for Progressive Insurance, where I lead a CX acquisition team, and we really focus on bringing humanity to helping people uh protect the most important thing that they own, which is usually their home. So it's fun to bring customer centricity to that space. But my side hustle has been a little bit different lately. So I just uh launched a new book, the product management playbook, uh, with Rosenfeld Media in July, and uh the book's doing really well, just hit number one new releases on Amazon for its category this week, which has been cool. Um, and I wrote it because I think there's a massive coaching gap with product managers out there, and I think they deserve better from their leaders, and I want them to have that, and I want their leaders to have tools. So I've been on a mission to kind of bring that information out to uh product managers everywhere.

SPEAKER_00 3:01

Well, someone who makes their living as a coach and a consultant, I couldn't agree more. And anything that helps feed and make it easier for me to teach and help people, it's a wonderful thing. And like I said, I'm I'm 90% of the way through the book, and the book is a little bit different. It's called the the Product Management Playbook, and it's a little bit different in its structure than most of the other product books that I've read. And what I really liked and what I noticed was you know, most books will tell you here's what to do, here's the way to do it, here's the one good way of doing this thing, follow this method, follow my framework, and you'll do really well. And even the books that are more broad-spectrum overviews of the entire product management lifecycle and field tend to have one, maybe two ways of doing it. But you really dive into the fact that it's not that simple. So talk a little bit about the structure and why you you put the book together this way.

SPEAKER_01 3:57

Yes. So, in my view, um, frameworks come and go. I think if there was a perfect methodology or a perfect framework, we'd probably know it by now. We'd probably all be using it. But the truth of it is that this role and this type of work is very ambiguous. And the purpose of these types of methodologies and frameworks are to reduce ambiguity, but it's never going to eliminate it entirely. So I'm actually a very big fan of frameworks, but the way I structured the book was more around the questions that matter most that are durable, basically any in any problem and solution space. So, why does something matter? For whom are you solving it for? Um, what is it that you need to actually do to solve their problem or meet their needs? Uh, how and when are you going to be able to do that? So the book follows those kind of key questions, very similar to like the product development process. And then with within each of those areas, there are, I offer frameworks, tools, some that I've developed on my own, some that are just more across the industry to help people reduce ambiguity and get unstuck. And so for me, it was creating something that was a little bit more of a durable handbook that you could pick up for wherever you are, kind of in the product lifecycle, um, whether you needed a tool or an exercise to try with your team, just to build some momentum and keep moving forward.

SPEAKER_00 5:17

Yeah, so much of what we do, even though we talk about agile and being iterative, a lot of things that are out there is follow this process. This is the way that we did it. And fair enough, I love something that really goes deep on a framework and teaches you how to do it and do it well. And when it works, it works wonderfully. And I ran into a consultant a couple of years ago who said something like, uh, I've got a thousand frameworks, I love them all. If you don't like this one, I've got another one that might work for you. And but it it kind of it's been reminding me of the the way that a we think about AI, in that the fact that AI is non-deterministic and we acknowledge that. But have we been fooling ourselves and thinking that product is actually deterministic all these years?

SPEAKER_01 6:06

I think we like to, you know, have a sense of confidence in product management. Our stakeholders need to feel a sense of confidence in the work that we're doing and a sense of predictability. But the reality of it is it's like the outputs have been deterministic in many ways for a long time. Um, but whether we achieved an outcome or not was always a little bit non-deterministic. There's a lot of external conditions, internal conditions. It's still very hypothesis-driven. And I think today what's really happening is now some of the outputs are becoming non-deterministic at the same time. But the craft is still very much the same. You need to state your hypothesis, you need to de-risk those assumptions, and you need in-market data to get feedback on how well your solutions are solving a problem or not. So a lot of the fundamentals I think are going to be durable long-term. But our tools, our technologies, our frameworks, they change. Um, but really it's about being able to answer those questions that matter most. And the question that matters most is are you building a product that matters to customers and solves a problem for a business at the same time?

SPEAKER_00 7:10

And a lot of the time we we tend to focus on how do we do that double diamond? How do we understand what the problem is and then how do we focus on the on the right solution? And that's things like feasibility and viability, usability, desirability. I mean, very classic stuff. But early on in the book, you actually focus on four other fundamental things. And I thought it was really interesting because it was less about you acknowledge everything about what do we need to make a successful product, but also the conditions within the organization to allow you and the team to succeed. So talk a little bit about those four things, if you don't mind.

SPEAKER_01 7:47

Yes, I'm happy to. And I do want to say, like, I'm a fan of frameworks. I talk about those illities a lot with my team. I think one of the beautiful parts of a framework is that they can often help coach teams on how to think about a problem or a topic from multiple different angles. So the ilities that you just mentioned, I share that, I evangelize that with my team. The product market fit pyramid is a big one for me that Dan Olson put together. Um, I've tweaked it a little bit for my teams and kind of added something to the bottom company objectives there. But again, I think these frameworks are great when you're really help trying to think about a topic from a few different angles. But the book that I, at the beginning of the book, I kind of start with those uh ambiguities that are the conditions that product managers often encounter. And part of that is just because this book is around um, it's really attempting to solve an answer. What makes product managers successful? Do you like this role? Are you interested in this role? What's the reality of an everyday PM? And the reality of it is it's highly ambiguous, whether it's problem ambiguity, solution ambiguity, you've got to figure those two things out. Everybody knows that. Priority ambiguity, that's a huge one. You're focused on one thing on a Monday, but by Thursday, it's three new fires. What trade-off do you make? And then the last ambiguity I talk about is organizational ambiguity. And I actually think this is one of the least talked about uh ambiguities in product management. And when I say organizational ambiguity, I think what I'm trying to get at is in a lot of the literature, it can feel like there's a perfect product operating model or there's a perfect product org. And I don't think that exists. And I think if we think we're waiting around for the perfect funding model or the perfect uh team size or the perfect skill set that you need, you're you're not able to move the ball forward. And some of the best PMs I know thrive in some of that organizational ambiguity, or maybe they don't thrive, but they accept it as a condition of the job and it doesn't hold them back. They figure out how to work around it and persevere. And that's one of the reasons why I wanted to bring that to the front of the book so that we all kind of accept that's just a condition of the job and you gotta be scrappy. That's just the nature of it.

SPEAKER_00 10:00

Is this do you think this is endemic to all product, or is this a function of size of an organization? Does this happen in in startups and early stage scale-ups, or is this really more larger SMEs uh enterprise where this really happens?

SPEAKER_01 10:18

I think you know, there's um there's a little bit of organizational ambiguity in any size company. I do think larger size companies have um a lot more of it because there's just more stakeholders, there's naturally more complexity, oftentimes there's more product lines, shared services that you're trying trying to integrate and interact with. So I've spent a lot of time at large companies. Um, and I think that for me, I've seen organizational ambiguity as kind of an everyday blocker for a lot of teams, especially when you have multiple product managers on a giant in a giant product org. Um, and so I think it's, you know, what I try to help coach teams on is don't wait for the perfect conditions to exist. Sometimes you have to make do with what you have. And that's why I really think it's important to kind of accept it to a certain extent. You want to influence it, but it can't become the ultimatum for you to be able to figure out how to move the ball forward a little bit.

SPEAKER_00 11:12

Yeah, I'm a big fan of the way you did this. You know, uh, I've got my own version of it. Uh, everyone has their own version of things, and you know, there's a thousand different ways of approaching it. Mine focuses on if you uh do you have the right priority, do you have the right people to do that priority? Do you have the right processes to allow them to do it? And then it's underscored by is there a shared perception across the organization to do it? And I think the only real difference is mine all start with the letter P. Um, trying to sell it that way. Um, but it's uh I love when other people come across this because when and whenever I'm talking to people at usually scale ups and and up, as they're describing their problems, everything slots nicely into one of the whether it's my four P's, whether it's your four, everything fits slots nicely into one of those areas, and you realize, oh, this is you might have three of the areas nailed, but you're you're screwing up because something is fundamentally broken in the fourth.

SPEAKER_01 12:07

Yeah, that makes a lot of sense. And I think these types of um categories really like if you can learn and accept and kind of be able to diagnose things as a junior product manager, they then become development areas for you as you think about growing into leadership. So a lot of times a junior product manager or individual contributor will focus on something like the problem, the solution, the priority, right? But when we start talking about things like organizational ambiguity, that's when you start to level up and develop some leadership chops. So it is what processes, what operating model, what's really holding me back funding, right? And when we start to be able to kind of name that and diagnose it a little bit, even if you're a junior PM, you start to ask different questions and learn how to be a little savvy to be able to influence your product success and move it forward.

SPEAKER_00 12:57

So, one more question about the structure of the book, then let's go into talking about how to succeed in in an organization and some of the applied lessons from it. Um, you've got, I think it's 21 separate recipes in the book uh or approaches. Talk a little bit about that approach. What do what are these? Why did you structure it that way? Because I found that to be a really interesting way of uh putting things together.

SPEAKER_01 13:20

Yes. So again, I I wanted this to be something you could literally keep on your desk and pick up when you feel stuck. And the 21 plays as in the play. Sorry, not recipes. Sorry. No, that's great. I love recipes. Uh, I love that uh analogy as well. But they're really designed to be step-by-step ways that you could guide your own thinking or your team to get, again, unstuck in a certain scenario. So that could be you've inherited a product and everybody doesn't like there's a misalignment on what the business goals are. There's a play to run a business strategy workshop with your team and with your stakeholders to get clarity on that so that you can actually move forward and um continue your discovery and delivery work. So it starts really much, you know, very much at the beginning, business goals. There's a play around building a product vision, concept testing. There's several in the discovery phase of the product lifecycle. I think that tends to be a little undercoached as well. And then we go all the way in through delivery. What is it, you know, what does a successful release look like? What does optimizing a product in market look like, or even inheriting one that kind of stinks? There's a play for that, which is, I think, very common in product management. So the intention really was to give people some step-by-step guidance on things to try with their team or with their peers at work in order to create some clarity and again move forward.

SPEAKER_00 14:41

And one thing just to give one more endorsement of it and to uh reinforce for people, you know, even people who have been in this role for many, many years, there's situations that we've all been in and we're familiar with. And then there's going to be situations that we haven't done ever or not in a long time, and things have changed. So it's always useful to have these uh approaches to go back to and have people to talk to about how did you do this? What do you know, where be reminded, I love I love anything that gives me uh options like you do with things like um uh David Bland's testing business ideas, which is another great reference book to just leave on the table and just leaf through and get inspiration from once in a while. Uh yes, all these things that are really just nice. It it's not admitting that you're wrong or that you're weak to go back and look for inspiration in these types of things. It's a really, really useful thing.

SPEAKER_01 15:35

Oh, there's, you know, I've been in product for a long time. There's still some things I've never touched in product management. It's wide, right? And it's it's wide and it's exploded. So there's a lot to do. One thing I actually tell people that if they're interested in product leadership is get your reps in, get your tours of duty in, right? You could spend two or three years on a single product in one phase of the product lifecycle, and then all of a sudden you take a new assignment or a new stretch role in a zero-to-one product and you've never done um from scratch concept testing, right? That's very normal. And it's okay not to have um the toolkit and the skills to know how to do it. But that's why this book is here. It's really to help people when they start something new or in their a little bit more unfamiliar territory. There is a way and an approach that you can try to kind of continue to move that ball forward.

SPEAKER_00 16:22

Yeah, I can't tell you the number of stories I've heard about people recruited from fang companies to then uh run a startup or people from startups who then go into enterprise. And it's it's just a totally different world. And having a, you know, humility goes a long way in that, but also you just need to have references and be and uh have tools to be able to use and say, right, it just because it worked this way in my last company or in any number of other situations, I'm in a different one now.

SPEAKER_01 16:50

Yeah. I like to say product management is a practice, it's not just a title. Um, and there's many people that do that practice, they don't even have the product management title. So it's really about figuring out what's in your toolkit to be resilient and survive in the uh organizational context where you are right now.

SPEAKER_00 17:07

Okay, so we were gonna uh apply a specific lens to to some of this, but it's something that's not talked about as much. And you actually brought this up as an avenue to explore. And I love the idea. So let's talk about things that break when teams and organizations scale. You know, there's a lot that's written about enterprise product management, there's a lot that's written about startup, but the journey as you things are going well and things grow, uh, even if you're in a large organization and your team starts growing, things start to really change. Things that were simple, the lines of communication that were simple, uh just the the complexity grows in huge, huge ways. So uh you had a few different mistakes that you uh highlighted for this. So the first one was about not planning for the day when you can't be in every room. So what what do you mean by that?

SPEAKER_01 17:59

Yeah, so I'm what I want to what I want this conversation to be is to help product managers spot anti-patterns. And one of the anti-patterns is if your product is scaling and you have to be everywhere to answer all the questions. So one of the mantras that I like to teach and coach on teams is don't scale chaos. Um, I've worked on a lot of products that are kind of in this in-between phase. They have product market fit, but they're starting to get a lot more customer volume. And what I see is the team starts to scale a little bit of chaos because the operating model hasn't been updated to match the product's maturity for where it is. So a couple things that break when um the product starts scaling, and a couple things to look out for team context. So as your product starts to scale, you're likely adding more people to the work to support it. They have less history, they have less context on the overall vision, strategy, and roadmap. And if you have to be everywhere to answer all those questions, that's scaling chaos, right? Your artifacts need to be accessible, they need to be durable so that you can scale context across the team. Um, this one's a little ticky-tacky, but production support. I've seen this happen a lot too. Your product gets a lot more volume, you have a lot more people in the funnel, you get all of a sudden way more support tickets, way more bugs, and you might not have a process to uh address how you prioritize triage, solve those bugs, fix them. One of the things that you can do to fend off is to actually create SLAs or bug severity rubrics or some kind of process within the team that actually allows anyone on the team to make that call. So if you have to be the person that's making the call on the trade-off or the priority, you're scaling chaos again. And then the third thing is customer and business intelligence. This also starts to break down, usually early products. Um, maybe have a few people, they do some custom pools. All of a sudden, you got a product that's scaling, you don't have self-service dashboards, you got a lot more manual data that the team needs to pull. If you don't have that, all of a sudden it's becoming a little bit of a nightmare. Your inbox, your Slack, people can't access data on their own. It's not being democratized. So the gist of it is that products that are scaling, they just need more support. And when you're kind of hitting that threshold, you do need to stop and think about that team's operating model. And if you're scaling complexity or not subtracting or simplifying, there's that's probably a signal that you're going to be hurting your future self and making it a little bit harder for the team.

SPEAKER_00 20:30

So when back in the dark days, when I first started all this, it was normal to have your entire team or huge amounts of teams co-located and people were in the office every day or almost every day. And even though though we've gone through the remote cycle and a lot of there's a lot of return to office, a lot of it is hybrid, a lot of people have teams dispersed over multiple regions and time zones and things like that. So it used to be easy to create that shared context by putting things up on walls. I was a huge fan of physical artifact. You'd couldn't take over a room or a corner of the office and you'd walk by and do your stand-ups and things in front of it. Uh, we'd have these massive bore foam boards that we'd take from room to room with things on the to do demos and things like that. It you can do so much with you know Miro and Mural and other tools these days, but it's also incredibly easy to ignore. Um, it's not front and center all the time. So, what do you do to create that shared context? What's one or two tips that you've got for how you work with teams now to ensure that that context is shared as the team grows?

SPEAKER_01 21:38

Yep. There's two things. I'll I'll give you one thing that I do specifically, and then an exercise I actually talk about in the book. Um, one thing that I think is so important for teams to do is synthesis together. Um, synthesis is where everybody's kind of bringing, you know, uh all the input, all the insights that you have, and you really start to discuss again, what does it mean? Is It means anything different for our strategy? Did we learn something? Does do we need to update a hypothesis? I see, I'm seeing a lot of people synthesize by throwing data into an AI tool. And what is kind of being lost in that is the um the access that the team has in creating that shared context. So one life hack I would suggest is that once a month or once every two months, the team really gets together and kind of has a business review. Let's look at all the data, the customer data, the platform data, the business data, and let's synthesize what it means. Are we learning anything new? But do it together. I think that's really important. The second thing in terms of building shared context is I actually talk about a ways of working exercise in the book. And you had your framework that starts with P's. I kind of have one too. It's when I talk about ways of working, it's bringing together the leaders on a team, usually product, business, design, data, and talking about what is our plan for uh the next year or two. That's kind of the one everybody already knows what to do. What's the strategy? What's the roadmap? So what's that product plan? But then it's what are the people that we need to be successful to activate that plan? So that's you start looking into things like roles, responsibilities. Do you have coverage? Do you need to hire someone? Is there a new skill you need on the team? And then the third one is around process. So it's how we work together. Um, it is how do we do planning together? How do we do capacity planning? How do we estimate? What do we want our software delivery lifecycle to look like? Um, I think if you kind of go through that ways of working exercise, whether your product is scaling or you're joining a new team that's very confused and roles and responsibilities seem unclear, that's one uh tool that I give people to try with their team so that they can add a little bit of clarity, but you got to do it with your partners. You cannot do it by yourself. It will never work if you try something like that without your partners.

SPEAKER_00 23:51

I'd love to say grade minds think alike on this one, but the reality is anytime someone says something similar to something I think I came up with independently, I just feel validated and relieved that I didn't just get wrong. So that's wonderful. I'm obviously a big fan of that. And that's a really good topic.

SPEAKER_01 24:08

It's all that scar tissue we probably separately built, and now we've learned the hard way. And so we've had to create as leaders these tools to uh make sure we don't repeat sins of the past with our teams.

SPEAKER_00 24:19

Okay, so the the second mistake you talked to me about was uh you're panicking about growth after launch instead of product market fit. What do you mean by that?

SPEAKER_01 24:28

Okay, so this is another anti-pattern. I see people that they launch their products, they become obsessed with growth right away. The focus needs to be more on product market fit, usually uh in the early stage. And when I say early, I think this is where there's a little bit of um tension between what some people consider early. But the reality of it is a lot of products actually take about two years to achieve product market fit. Some might even take up to five. Um, I think Miro and Figma took them about five uh in a survey until they felt like they had actually reached product market fit. So during that stage, when you've just kind of launched a product, that really needs to be your focus, right? Do you have strong signals of retention? Do you see turn? How do you address that? How do you make sure you understand who your ideal customer profile is? If you're launching a product and you immediately start thinking about growth, what you're gonna do is get your economics kind of upside down. All of a sudden, you're gonna invest more in growth, your customer acquisition cost is gonna go up, and you're gonna have a leaky bucket at the end of that. So that's one of these anti-patterns. We don't want people focusing too much on growth. We want you to focus first on retention and validating your hypothesis, validating sustainable business value. And then once you kind of see some of those signals, let's turn that growth spigot on, let's keep generating more and more volume so that you can actually grow and retain that business. Um, so that's one of those anti-patterns I want people to look out for as their products start scaling.

SPEAKER_00 25:56

Okay. So the the easy question on this one is how do I measure PMF if not by growth? And so what you're saying is it's it's a healthy definition of growth. It is retention as well as sustainable growth.

SPEAKER_01 26:12

Yep. And in the book, actually, I I interview a couple different experts. Dan Olson, who was kind of like one of my early idols, I interviewed him. We talked a lot about product market fit. So you'll see that in the interview in the book. But I asked him that question. I said, What do you think is the strongest sign of product market fit? And his answer was retention. Um, when you see that, it's like you know that you're gonna have a customer base that's sustainable. You also need to make sure the business model is probably sustainable and healthy too, right? You want to make sure you have a path towards value if you don't already have that value. And I've actually included a little bit of a sniff test in my book, like signals where you might not have product market fit versus signals where you might have product market fit to help product managers think a little bit about am I really ready for scale? Am I really ready for growth? Or do I maybe need to go back and pivot a couple of times or iterate a few more times until I really have tight product market fit?

SPEAKER_00 27:05

So going back to the illities, this is really focusing on desirable and viable. And if you got those really strong, then then that's how you're measuring PMF. That makes sense.

SPEAKER_01 27:15

100%.

SPEAKER_00 27:16

Okay, so mistake number three is that you're scaling expensive problems because you underinvested in experience and or or technical quality. Go on, tell me more about this.

SPEAKER_01 27:28

Yes, okay. I I like to say, you know, I said my mantra was don't scale problems. If there's a sub-bullet in that, it's definitely don't scale expensive problems. So I'm gonna give you an example. As a product manager, I inherited um a platform once and I wound up spending nine months working with the engineering team on resolving latency issues because the platform was too slow. Nine months. It was not the most glamorous part of product management. I think it was a little demotivating for the team. And when we really root cause, like why did that happen? It's because that we didn't build for quality up front. We were maybe taking a couple shortcuts when the company had first first launched that product. And then all of a sudden, that shortcut wasn't something people went and went back and fixed. And so they started scaling. And then we started seeing high rates of call times in the contact center. We started seeing really high rates of customer abandonment because they didn't want to wait for pages to load. And so that's an example of scaling a problem that was also expensive for us because it ultimately cost us millions of dollars in revenue. When I think about how to fend that off, it really comes down to a couple things. So when you're when your product's getting ready to scale or you're already in, sometimes it's actually already scaling and you're trying to catch up to it. You really need to go back and think about your technology strategy. Usually the the decisions you made for the MVP are not going to be durable and sustainable long term. So there's a couple things I look for on teams. I look to see if they have clear architectural principles that they're going to follow. So every net new feature they add, every new thing that they build, we need to have clear architecture patterns, clear um guardrails for the team so that they understand what where the quality bar is and how to make sure that what they're building is compatible and extensible. The second thing I look for, especially with product managers, is a clear set of non-functional requirements. That gets into things like do you have analytics for everything? Do you have observability? Did you set performance guidelines for your experiences? Those two things, if you can really make sure your team has a solid grasp on that, those are going to help you kind of avoid scaling some of those expensive things that become death by a thousand paper cuts.

SPEAKER_00 29:42

I see this a lot in people when they're dealing with in larger companies. There's a big difference between trying to launch a new thing and trying to add new features to an established product. And you've got the pioneers, the settlers, and the town planners kind of metaphor on this, in that you don't want to over-engineer something that you're just finding out if it is desirable, if it is going to be viable. You want to get it out there. But at the same time, you don't want to scale it when, even if it's exciting, when it's you're just scaling a problem. But you're often seen as a stick in the mud if you're trying, if you're the person saying, no, hold on, we need to go back and re-engineer, we need to make this fit for growth now. How do you navigate that that dichotomy?

SPEAKER_01 30:29

That's such a great question. I think oftentimes um we talk about on product teams, we talk about things in terms of like debt, right? So, in that example, what you've just scaled is technical debt, and now you have to pay for it. You either pay for it up front or you pay for it later. What I think teams need to do to go like take it one step further to really influence is actually estimate the value of that debt. And this is where a lot of times as product managers, we like to think about things like customer experience metrics or business metrics. But if you want to be really savvy, you also need to understand things like operational efficiency, the cost of running your team and the cost of work and how that is or is not holding back the cost of running your product. So um I know a lot of times in product, not everybody owns a PL, but think about your team and your product like a PL, whether you own it or not. And then all of a sudden you it becomes very clear to say, okay, this is actually costing us XYZ in engineering time or it's costing us in the call centers because we didn't fix it. Um, once you can add a dollar value onto the cost of a problem, it becomes a lot easier to influence. And you don't look like a stick in the mud anymore. You look like a steward of the business that's really focused on not just um supporting customers and thinking about customer metrics, but you're really thinking about internal operational efficiency metrics and how to really be a good steward of the platform.

SPEAKER_00 31:54

Is it always that simple, though? I mean, the reality is I found that it's a matter of negotiation with with people on the finance and business side of things and say, right, this is what the cost will be. We're just scaling the problem. And sometimes they do it anyway, because they're seeing something specific. We're optimizing for growth for certain numbers. We want an acquisition or or something like that right now. Uh, we need to gin up these numbers and we don't care about costs right now. And other times it's no, we're in ruthless efficiency mode. We need you to focus and cut no uh cut costs right now. So is it really just presenting the business case and saying, God damn it, I'm right, or is it that more of a negotiation?

SPEAKER_01 32:38

It is a negotiation, and I'm glad you said that. So sometimes you do make an intentional call to take on that debt, right? Um, the the point of what I'm trying to get at is that you're gonna pay for it one way or another. So it's about when you want to pay for it. And it to your point, if you're in growth mode, you're probably gonna have to make either a tough trade-off to pay for it, or it might not be the right time. But if your products at scale and your focus on optimizing, which are a lot of these big SaaS products or products that have millions of users, you do need to think about operational efficiency because the marginal changes really start to have big impacts because of the amount of volume that you're having on the product and interactions with customers. So you're exactly right. It's always a negotiation, there's always a trade-off to be made. But one thing I want to encourage teams and product managers not to do is uh to avoid sizing it with business value. You always really want to come with a true business case and then look at it in the total context of all the priorities on the product.

SPEAKER_00 33:39

I think one of the key things there is uh just getting your mental model ready for it and saying, okay, right now the business is shifting and we were in growth mode before, but now we're in optimization mode or or something else. I had an experience earlier in my career where the company was changing modes and I just was not ready for it and I did not handle it very well. And I've seen teams not handle it well and people atrophy from from teams because they were up for a certain type of mission, but not a different kind. So I think it's really key what you're saying here is the idea of knowing where you are, knowing what the reason is, knowing what the trade-offs are going to be and whether you're taking them consciously or not, uh, and what the effect is gonna be.

SPEAKER_01 34:22

And and this is a thing I think sometimes can be a little undercoached, right? Like the product um maturity lifecycle. I actually talk about that a little bit in the book as well. Typically, your goals are gonna change, your activities are gonna change, your metrics are gonna change if you're zero to one, one to n, even you know, you could you could have a product at scale that stinks, and there's some criteria for sunsetting a product in the book. Um, a couple of red flags that I want people to know about. So, to your point, what's really important and what I want people to be able to do is to name it and to be able to step back a little bit and understand the context they're operating in. So, where do we think our product is right now? What does that mean in terms of my goals? That way you don't wind up with some of these mismatches in terms of expectations versus reality of what you're working on and working on things that matter.

SPEAKER_00 35:09

And I think we've uh touched on the the fourth mistake that you brought up, which is not thinking about your in-marking product like a portfolio. And I love the the portfolio metaphor, but expand on that a bit.

SPEAKER_01 35:21

Yes. Um, this one actually I I've kind of learned a little bit the hard way. You know, in product, you as a junior PM, you think a lot about I'm gonna run every A-B test, and um, I have this litany of things I want to put in front of the customer. And what I learned actually is one of the fastest ways to develop a bad relationship with your partners is to pretend that you don't have other work that you also have to get done and not seeing your product holistically and kind of seeing the nature of the work holistically. So, for example, product managers that uh they have separate backlogs. They have their customer backlog, but they don't think about technical platform work in their backlog. That's probably an anti-pattern. You're not really thinking about your product like a portfolio, you're thinking about that one single outcome you're trying to drive. But when you think about it, you know, typically I like to say there's four different slices of the pie that you're probably gonna need to solve for, especially if your product's at scale. There's either um one of the slices is gonna be innovation and strategic bets, right? A product at scale. Yes, of course, you're gonna optimize it. That's probably the first slice, optimizing. You know, what are you doing to optimize that product? But the second one is like, how are you fending off true disruptive innovation and technology? So you probably always need one part of the pie working on optimization, another part of the pie working on something that's a little more innovative or a strategic bet so that you've got a nice balance in that portfolio. The other two pieces of the of the pie I like to talk about would be capability work. Um, so this gets into a little bit more like that platform conversation we were having. While you're growing your product, are you making it easier for things to get done? Is it easier to ship something? Is it easier to solve something? Is it fast? Can you run as many A-B tests as you want? Right. Like a lot of times you have to create your own capabilities so that you can then consume them. So that's a third part of the pie. And then the last one is just good old production support and run the business work. It's part of our job. We've got a plan for it on some teams in the past. Um, we've said, hey, we're always going to hold back 20% capacity because we know it happened. So like let's stop pretending like it doesn't. And that gives everybody a little bit more permission to not feel such a squeeze and really think more holistically again about their product, like a portfolio and being able to allocate some capacity or at least plan and think about how they want to address each of those slices.

SPEAKER_00 37:39

Julie, this has been fantastic. I've got time, I think, for just two more questions. So uh let's get into them. The first is if you had a magic wand uh and you could wave it and get rid of one problem that you just see product teams making over and over and over again, uh, that something that you address in the book. What what do you really hope this book would make go away?

SPEAKER_01 38:04

Oh man. Well, I've I've kind of said it before, and I don't even necessarily think it's uh the team. Um it's a it's a problem that affects teams, but I really see it as a leadership gap. It's the undercoaching and lack of investment in the product manager trading. Again, so many companies kind of went through these transformations over the last decade. I refer to them sometimes as half-baked because we have a lot more people in this product management title and practice. And many of them just did not ever get some of that end-to-end thinking. You know, they don't have exposure to discovery or they just were doing delivery, or vice versa. To me, I think to be a true, well-rounded product manager and to be a product leader, you need end-to-end knowledge, you need an end-to-end toolkit, and you need exposure to different types of products, different uh parts of the product lifecycle. Because as a leader, one day, you're gonna have to be able to manage a portfolio that's a little bit of everything. So to me, the biggest thing that I want to solve for on product teams is this massive gap in undercoaching. And I always solved it by listening to podcasts, reading Mind the Product, going to conferences. But it's funny, I don't think there's a lot of literature out there where you could really just sit down and read for a little bit or have a handbook. And so that's one of the main reasons why I wrote the book is to just kind of help people, right, get unstuck and get some of that coaching they might not be getting.

SPEAKER_00 39:25

Fantastic. Okay, and last question is something that I'm uh contractually obligated these days to ask about, uh, not actually in the contract, but uh need to ask about uh in every interview these days. And we you do address it in the book, but we haven't really talked about AI at all in this in this chat. How do you see that changing things or or not changing things?

SPEAKER_01 39:48

Well, I still think the fundamentals are very important, right? Like the most important thing is as a product manager, I like to say is have your own point of view. And nothing should replace that, right? You can't farm out AI to have a point of view, and all of a sudden you're in an exec meeting and you get asked a question and you don't really have an informed answer. You don't want to be caught that way, right? So I think AI is there to assist you and we should be using it, right? You can use it for synthesis, just don't use it to do everything in synthesis. Use it with the team, synthesize with the team. I think you have to start small. We have to adopt it. It's it is an amazing tool in technology. We just don't want it to replace the true craft of why this role is so hard. It is at the intersection of so many functional areas. Um, and really a lot of times the PM has the best context to make calls. So I do think that it's so important that we use these tools, but we don't allow it to or expect it to replace having our own point of view.

SPEAKER_00 40:47

Yeah, I think uh the way I've found in working with with LLMs has been very much like working with other people on the team. I have to have enough context to be able to call BS on them. Because you know, you'll notice when you work with one, uh, when it's giving you information back about something you know, you know exactly where the problems are and how stupid it can be. When it you're working with it on something you don't have the knowledge about, it sounds very plausible and you don't know what to call. So if you don't be that that critical thinking, that critical conversation skill that you would have with the human, if you don't have enough information to do that with the AI, then you're just not doing the job well enough.

SPEAKER_01 41:26

Totally. I mean, a long time ago, um, well, maybe not even that long ago, it was design thinking, it was cloud services, it was all the, you know, you really needed to understand that and stay modern. Today it's AI and growth loops and kind of the all the new new parts of product management. In 10 years, it's gonna be something totally different, right? Our job is to stay current. We have to stay current, we have to learn. Probably the most important thing in product management, too, is to have that point of view is being curious, right? So we've got to be curious, we've got to learn and lean in. Um, but at the end of the day, you still have to have that uh critical thinking skill that you mentioned earlier. So I think the sky's the limit for a lot of product managers. I'm really excited for the future of product management. I'm excited about this book. We actually have a discount code for your listeners. It's MTP20. You get 20% off from uh Rosenfeld Media. Um, but yeah, I'm I'm really excited about what's happening in product management today. And uh I'm just so thrilled to be able to come on the podcast and share a little bit more from those lessons learned.

SPEAKER_00 42:26

And we'll put the link to the shop in with the discount code in the show notes. So definitely check that out. And Julia, thank you so much for joining us. This has been fantastic.

SPEAKER_01 42:36

Same to you, Randy. I hope you have a great weekend. You too. Thank you.

SPEAKER_00 42:40

The product experience hosts are me, Lily Smith, host by night and chief product officer by day. And me, Randy Silver, also host by night. And I spend my days working with product and leadership teams, helping their teams to do amazing work.

SPEAKER_01 42:56

Luran Pratt is our producer, and Luke Smith is our editor.