Product Is Not a Playbook

Why do so many product transformations fail? Because leaders treat product like a science when it's mostly art.

Vidya Dinamani and Heather Samarin sit down with Chris Herring, Head of Product at Stride, the edtech company serving K-12 students through virtual public schools. Chris has been building AI products for over a decade — well before it was fashionable — including StoryStudio and MathBee, the math game that helped kids find out math doesn't suck.

From refusing to imitate what worked elsewhere, to piloting change with four teams before scaling to forty, to why trust is the currency that buys you permission to rebel, Chris shows what it takes to drive transformation from the inside.

Transcript

SPEAKER_01 0:00

I think so often what I've seen in my career is that a company comes in or a startup comes in or a product leader comes in and they try to just imitate and they they treat it like a playbook and they're like, well, this is what you do, and you do it just like this, and this is what so-and-so did. And I think if you're really gonna have the mindset that a product leader needs to have, which is be innovative and focused and disruptive, then you can't treat anything as a playbook because product's not a science. There's some science to it, but there's so much art and so much that is just not able to be scripted or predicted. And so for me, it's it's trying to always refuse to say this is the right way to do it.

SPEAKER_00 0:43

Hey product rebels, welcome back to another episode. Today we're joined by Chris Herring, head of product at Stride, the publicly traded education technology serving K-12 students through virtual public schools along with adult and career-focused learners. Chris spent more than 15 years at the University of Phoenix, where he rose through a series of product leadership roles, owning the self-service product roadmap and building predictive AI products way back when. Since joining Stride in 2023, Chris has owned the vision and strategy for their e-learning products with a focus on AI-first solutions, including things like Story Studio, a generative AI tool built for very young learners, and MathBe, a math game that improved elementary student scores and, in his words, helped kids find out that math does not suck. Chris has been working with AI for over a decade, well before it was fashionable, and has an interesting point of view on where it's headed. We're excited to hear what he's learned about driving change inside legacy organizations.

SPEAKER_02 1:44

Welcome, Chris. We're so appreciative that you're here and we're excited about the conversation today.

SPEAKER_01 1:49

Yeah, thank you so much for having me on.

SPEAKER_02 1:51

Absolutely. We're gonna start with the same question we ask everyone. What does a product rebel mean to you?

SPEAKER_01 1:57

I think a product rebel is someone that doesn't just do what other successful people have always done. Product development, product management is a field that has so much written about it. Yeah, I think some of our kind of cultural business icons come from product development. They, you know, they built some new software or some new platform or some new way of doing business. And we kind of put them on a pedestal. And then consultants want to study them, and Harvard Business School wants to uh teach a course about how they did it. And those are all awesome, helpful things that I think we've all learned about. But I think so often what I've seen in my career is that, you know, a company comes in or a startup comes in or a product leader comes in and they try to just imitate and they they treat it like a playbook, and they're like, well, this is what you do, and you do it just like this, and this is what so-and-so did. And I think if you're really gonna have, you know, the mindset that a product leader needs to have, which is be innovative and and focused and disruptive, then you can't treat anything as a playbook because product's not a science. There's some science to it, but there's so much art and so much that is just not able to be scripted or predicted. And so for me, it's it's trying to always refuse to say this is the right way to do it and just always say, okay, I got a big bag of tricks, and we're gonna see what we can pull out and use and that that'll work. And so sometimes at some companies that doesn't go well, right? That makes you a rebel because they're like, well, this is how we do product. It's like awesome. Do you want a good product? Or do we follow this method? And so, yeah, that's that's kind of been my experience of what it means to be a product rebel.

SPEAKER_00 3:29

I think that's so interesting, this kind of combination of you've got the playbooks, you know how things are done. But what I'm really hearing is like paying attention to exactly what's needed and like not necessarily just going by what you should do, but really paying attention to what is there. So tell us a time where I feel like you've had some of these experiences where you're supposed to have done something, but you actually paid attention and found out that the way forward was something else. Tell us about that.

SPEAKER_01 3:59

Yes. I mean, one stands out in my mind, you know, a company I was at, portions of the company wanted to shift to become a product-led company. And they were willing to work with consultants and they were willing to try and change things up. There was a lot of legacy at the company, the people that had been there for decades. There's actually people that have been there since it was founded. And it was founded before I was born. And so there was a lot of history, and there had been a lot of periods of success, but the company had definitely come down from the heights of its success, knew it needed to modernize and change how it did business, but there was so much baggage. And so there was, there was a lot that was being attempted, and there was a desire to bring some structure within the chaos. And so I had a new boss at the time, and I was, I was fairly young in my career. And so I didn't have a proven track record to say, like, listen to me, I know what I'm doing. I've had a lot of success at the company, but not like, oh, I've gone and done this other places, and I've gone and you know, led these big transformations. So a new process was rolling out, and essentially, I mean, without going into the details of what the process was like, it was old school. There was a lot of paperwork involved. There was a lot of documentation, there were a lot of meetings. And the whole idea was to bring accountability and metrics and measurements to what teams were doing. Great things. We want all of those things. But it wasn't gonna make us at the time the goal was to become agile. And it wasn't gonna bring agility. Forget what playbook and definition you want to have for what agile means. It was not gonna bring agility. It was gonna do the opposite. It was not gonna help us shift mindsets to product led, meaning problems and solving problems and funding the solving of those problems is what kind of centralizes. We're not funding divisions or we're not funding just teams, we're we're funding the solution to problems. And so I was lucky I had a decent relationship. I had a new boss, but I had a decent existing relationship before this person was my boss. And I kind of decided that I had two choices. I felt what we were gonna be doing and what we were being asked to do and rollout to our teams was terrible. And it was just the teams were gonna hate it. We already had an attrition problem, and this was really gonna be bad. And so I kind of felt, well, I got I got two choices. I can leave and say this company is just not gonna get it. They're just not gonna make it. And I didn't want to do that because I really believed in what we were trying to do. Not just transformationally, but the the business we ran and the goals we had, what we were trying to build. So it was either leave or say no. Say, we're not, I'm not making my teams do this. And I, you know, that's dangerous. One, career-wise, that's dangerous. It's also something I don't normally promote. I don't normally promote being rebel doesn't mean telling your boss no most of the time. But in this case, I felt like I needed to go in and have a conversation candidly and say, I don't want to roll this out. And not because I'm being difficult, and not because I don't want to do the work, but really show that this was not gonna get us where we say we wanted to go. In order to do that, I needed to have like something to say, okay, what do you want to do instead, right? Like, what are you gonna do? And I and I knew that the goal was just to be better, right? Better outputs, better velocity, better KPI results. And so I kind of came up with what I thought the solution could be to get there. And I didn't have a buy-in on my team yet, which was even more risky. I hadn't like told them this we're gonna do because I didn't know if I would if I would have permission. But basically what I did was I took principles that I thought could work in small pockets that I, you know, I don't know if we could scale them, but let me just prove they can work and then let the company figure out how do we scale it. And so it was base basic stuff. It wasn't like a playbook I've rewritten. It was, hey, we're not gonna do long meetings with long PowerPoint decks. We're gonna do five minute standups. It's gonna be five minutes and we're gonna physically stand here. We were in the office still at the time, and we're gonna physically stand. And everyone's just gonna give like a one-sentence update. This is what I did yesterday, this is what I'm doing today. You have any problems that need to get escalated? No. These get escalated, cool. We're gonna write it down. I'm gonna take it and we're gonna get it resolved by the end of the day. We were gonna have KPIs that we could measure in weeks. If we can't measure it in weeks, we're not gonna be reporting on it. We're not doing a quarterly what happened last quarter, didn't shift gears. So it was a lot of basic things like that. And so I went in and basically said, look, all this extra paperwork, all these things you want me to fill out and report into these spreadsheets and present. And then I'm not gonna do that, but this is what I'll do. And this is what you can hold me to. And I said, Look, we're gonna, we're gonna beat every team in the company. And we were fairly large. At one point, we were third largest employer in the state where I was working. The government and Walmart were bigger, and then it was us. And we had shrunk from that, but we were still large. And so I said, Look, we're gonna beat every team in the company. Every KPI you care about, we're gonna, we're gonna beat it. We're gonna be number one. And if we're not, then I'll do it your way. And first quarter, we were probably around 10x, any other team. I mean, it was night and day. There was no competition, there was no question. And so then after that, it was okay, cool. We can now we got to figure out what can work at scale, right? Because in a microcosm with a team that's bought in and a and a leader that's bought in, right? And cool, that works. How do you how do you figure out what's gonna work at scale? What do the executives still need that maybe this didn't provide? But that was, I think, probably a risky career move that I made. But it really set me up because you know, the next five years, we became a product-led company. We moved to agile, self-forming product teams, and we set a five-year plan and we we hired a new CIO that was fantastic at helping us scale this. And so it became a chance to say we can do something different. It kind of built some confidence in our ability to get there. And then it took a lot of work and years to really get transformed. But yeah, that was probably the biggest risk I think I ever took. But I was young enough still to be like, okay, if this fails, I'll go do something else.

SPEAKER_02 9:30

Yeah, I love it. Congratulations to being able to push back and actually get the permission to pilot, right? Because that in and of itself was challenging. Would love to hear kind of what were the things that you were able to do to get the pilot approved, right? That's sort of the first thing. What were some of the ways or tactics that you use that others can learn from? The second is this is sort of we can ask it for a longer discussion, maybe right after this, which is what does product led mean to you? You say that multiple times. We have a very clear definition. I'd love to hear what that means to you and practice. So those are the two questions I have right now for you. And you can choose which one you'd like to do first.

SPEAKER_01 10:11

Yeah, I think one thing is if you go into a new organization or if you're super young in your career and you have no history and no clout, I would not recommend trying to be a rebel from day one because it just looks like you're difficult to work with. You can find ways to push back where you know you can deliver results in the short term, kind of before anyone catches on that you've pushed back. And so if you can do that in short ways, especially if you're still an individual contributor, if you're still someone that's not managing others and you're just responsible for, say, your own outputs. Well, then if you can do small things where you push back a little bit and deliver results and then don't kind of share what you did to push back until the results are there, that helps. So in this situation, I had already been at this company for over a year. I had already been promoted to this company. And so I had enough bona fides, even though I didn't have a long career. I had enough bona fides to have some, hey, trust me a little bit. I also, like I said, I had a relationship with the leader I was working with. This was over a decade ago. I'm trying to think of the exact. It was over a decade ago. And this is one of the few leaders at that company, which I have not worked at for years. It's one of the few leaders at that company that I still talk to. You know, we still, well, hey, this happened. And here's a text message kind of thing, you know. So we still keep in touch because we had established some common ground. I think, namely, that we were both willing to take risks at the company because we believed in what we were doing. So once then we were working together, even though there was a power dynamic and this person was my boss at the time, there was an understanding of somewhat mutual trust of we're not at odds. We are working towards the same goal. So if you can establish that, if you can prove that and build some trust, trust gives you a lot of leeway. One of the, I'll say this for books. I said, I don't even know what this sort of books. A book I I love to recommend to people early in their career, late in their career, any stage, Speed of Trust. Stephen Covey's a popular author. He has a lot of books, not all of them I've subscribed to. Speed of Trust is a great book to show the power of a trusting relationship in a lot of different situations and ways to build trust and ways to kind of leverage trust without burning up that kind of social capital. So trust was a big part of it. So I think those are some, you know, you got to have a little bit built up. You got to have a little bit of kind of chips in the game. But if you can find small ways to push back, as long as you can get quick results and then say, like, hey, look at this great result. How'd you get that? I did this thing you maybe didn't like, but you know, I didn't break any big rules. And so can I keep doing it that way? Most of the time leaders say yeah. And then you can kind of feel out, you know, what the bigger pushbacks will look like. Product led. Yeah, product led is, I think that goes into what I what I said at the beginning. There's not one definition. There isn't. There's a lot of books that define it. There are some people I love that I think have defined parts of it. I love Teresa Torres. I don't know if you know Teresa Torres, but I love some of her work in terms of how she looks at customers and how she looks at defining problems with customers. I would put her in that product rebel camp, especially parts of her career. I'll take some stuff from her, so I'm gonna make sure I'm giving you know good attribution there. Customer comes first. And I think that's a general statement we all say, right? It's not the customer's always right, by the way. That is not what product led means because the customer often is completely wrong. Product led means the customer's at the center. Solving problems for that customer is everything. There isn't something else. There's a Venn diagram that you got to keep in your mind, though. Product is customer led, it's solving problems for the customer, but that Venn diagram is also making sure that the business benefits. If you check both of those boxes, then you're in the middle of that Venn diagram. But you don't want to start with the business box. You don't want to start with how do we make more money or how do we become more efficient or how do we better penetrate this market or whatever you're trying to do. Start with what problem does the customer have? And then say, okay, is there a way the business can reach their goals by solving it? Or is there a specific type of solution that helps us? Because there might be 50 solutions, but this one actually does what we're trying to do for the business. So that, I mean, that's the that's the root of it. But to get further, you really have to anchor that in some principles. I mentioned already, I'm a big believer in measure quickly. If you're gonna be product led, you can't be working on annual cycles or five-year plans. You can have them, but you have to expect, and in my experience, you should expect that they will change maybe every quarter because you should have feedback loops to that customer problem and you should have metrics to the business outcomes that are so rapid that you can quickly pivot and quickly pivot. The problems can stay the same and the business goals can stay the same, but how you're trying to solve them can quickly change, quickly change, quickly change until you're like, okay, now we're nailing it. Let's keep going with this path forward.

SPEAKER_00 14:42

Let's jump into a couple of things because I think I love the little ribble by stealth. I think that's that's a really that's a really fun way, no matter, especially early in your career. One of the things that we found with product led is there's so many different things. And you mentioned this right in the beginning. There's so many different things that you can potentially move the needle on. Being product led is a transformation that often takes companies years. And we have been, you know, Heather and I have been lucky enough to help multiple organizations go through this. And one of the things that we actually put together as a result of, you know, so many things that have to happen is what we call a pulse check, is to kind of see where your organization is right now and then to understand, are you moving mindset? Are you moving sort of clear sort of competencies and skills? Do you have to focus on some of the leadership? And so when you think of all the different things, because you mentioned there was metrics, there's, you know, you have to measure, you you want to move sort of 25 things at once, but you narrowed in on like, I'm gonna start here. Why don't you take us through the thought process of why did you start where you started? How did you pinpoint in that product-led journey? We've got to start somewhere, we've got to focus. We can't move the needle on everything at once. Why did you pick the thing that you picked?

SPEAKER_01 16:01

Uh, keep going with the example I gave, right? Of that multi-year transformation. We recognized that our industry had changed. We were at one time overwhelmingly the leader in our space. So many new entrants, tons of startups, tons of new entrants had entered. There was no Goliath to take down. So for us, we looked at it and said, the only way to get competitive is to be able to act like we were smaller. And one way to act like you're smaller is to allow teams to almost act like their own business. That's very difficult to do in a corporate world and with corporate structures, especially corporate finance, whether you're publicly traded or venture back, there's things that are looking for, metrics they're looking for. They don't necessarily have a long leash either. So for us, we looked at it and said, okay, if we're going to compete with all these small entrants, we've we've got to be able to be nimble like them. And so we looked at product led and said, well, if we could have individual product teams kind of self-contain in everything they need to move forward, they kind of control and own, then we could fund them as if they were little small units of business, almost like you know, wholly held subsidiaries, even though they're in a corporate structure. That was gonna take time to do, right? Because not every version of that's gonna work, not all the personnel is gonna work. You got to change some finance and accounting mechanisms, all kinds of things need to change. We first started with four teams. To give you the growth cycle, we ended up between between 40 and 45 product teams. And so we started with four. And so at the time, I was, by this time, I was in a director role on the business side. So I was leading business teams. I also led an analyst team, but we had separate IT, right? And IT did code development, IT did maintenance, right? And the business is over here, and they're totally separate. And then there was business analysts over here, and there was marketing over here. And we kind of said, okay, everything's now gonna center around product, but we're gonna try it first small. So we took four teams. I took one team from my line of business that okay, we're gonna build a product team and we're gonna separate off and we're gonna fund differently, and we're gonna see can this team deliver results without having to pull in from all these different parts of the business. We did look at the time at some structures. We looked a lot at scaled agile because it was a structure that lent itself well to corporate transformation, right? Startups didn't really need it, but corporate transformation, it was a good way to look at how do you get a big structure to go agile. We took a lot of principles from that. We did work with them directly, but we took four teams and we said, okay, we're gonna start trying some things out. There were some things that I did on that first team. One, I got to hand pick a lot of my people, that was nice. But there were some things I did that I wanted to keep doing that I was like, well, this really works for us that wasn't scalable. There were things that was like, well, yeah, it's kind of hard to scale that that works because you hand picked your people and you're working on this particular product, but that won't work at scale. We can't train to that at scale, or we really can't just achieve that at scale. But starting small was important. We did set out from the beginning, like I said, a five-year, five-year kind of not a roadmap, but a set of milestones. To set at the end of year one, if we're doing well, what should we see? At the end of year two, if we're doing well, what should we see? Year three on that road map was really where we felt we would reach true enterprise product led. We weren't done yet, but that's where we felt we we should be before we really start to see all the metrics across the board start to add up, meaning all the efficiency gains we weren't going to see in year one and two, all of the increased velocity we might not see in year one at all. You might see a lot of going slower in year one. But we set that out. It was super important. I'll call this out. It was super important. We had a hundred percent buy-in from every member of the C-suite. CEO, CFO, CMO. We had a CXO that we brought in.

SPEAKER_02 19:31

And so, Chris, these were cross-functional teams.

SPEAKER_01 19:33

These were so you These were cross-functional. Yeah, we had a product manager or a product owner. It depended. Actually, I'll say this. The first team I stood up, we had both. We had a product manager and a product owner on a single team. When we went to scale, I would say around year, around 18 months, maybe 24 months, we realized that was a redundancy we could eliminate. We did start with a scrum master on every team, engineers, an architect that was between two teams. And then we had dedicated representation from other functional groups. So each team would have a dedicated representative from marketing, from legal, from InfoSec. The devs, though, were there, we had a designer dedicated to each team initially. As we scaled out, the designer usually became a one to two. And so, especially if the product had three or four teams just working in different areas and it made a lot of sense for the same designer to be in slightly different areas.

SPEAKER_02 20:21

So let me let me stop there because I think this is interesting. I I really appreciate the outcome orientation, right? So you set the objectives for the year, the outcomes that you're shooting for. You brought the teams together in a cross-functional manner so they were all seeing and hearing what was happening and participating in those outcomes, right? Though we we find those as two really big principles. How did you get the teams to decide what to build? What were the criteria or the practices that ensured that what they were building was the right thing to build?

SPEAKER_01 20:54

That was a difficult piece. That did roll up. And so we did look at how do we get alignment across the organization? Essentially, it comes out of what are we going to fund. I would say at the VP level, and we didn't have a lot of a lot of levels. You had your C-suite, you had usually a VP kind of per business unit, and then you had kind of heads of product, and then maybe a product manager, product owner below them, but but there wasn't more levels than that. At the VP level, you know, the VPs of kind of each major line of business, everything that really affected revenue or cost, there were about six of them, I believe. They had to come to an agreement. There wasn't enough money to go around. So they had to agree what are the key metrics that we're gonna fund. And really, I know at the beginning it was kind of one per. Okay, VPU, what are you gonna drive that the business is saying yes? If you improve that, it matters. It makes us more money or saves us money. It was really that bottom line. So that that and then that kind of rolled down to the practical. Kind of the the idea of it is all the product outcomes were behavioral based, but all the business outcomes were financial based. So you started with the financial base at that level. You knew you wanted to solve a problem, but it didn't matter if you solved it, it's disfinanced. Outcome didn't happen. And then you said, okay, if the product's working, what behaviors am I going to see? If I see those behaviors, I should eventually see this financial result. That's the way we looked at it. I will say, even up through years four and five, and probably after I left, that was always a contentious piece. There was never a year or a quarter, or even actually a month, where we came together and there was not disagreement on those metrics. There was always either a pet project or just we just disagree. I think we should do this, you think we should do that, I think we should focus on top of funnel. You think I should focus on conversion. Yeah, we're gonna have to come together. And ultimately we have to agree. And once we agree, we move forward until we learn we're wrong.

SPEAKER_00 22:42

I want to move us because I think this is great. We could probably go down this rabbit hole because I'll just be completely open for everyone who's listening. We are not fans of scaled agile. So I feel like we could have a really passionate discussion, but it feels like that's quite old school. So let's move us to the present and talk about, like you said, start smaller. And I think as people sort of work with AI and we start thinking about experiments and we start thinking about like, how are we proving value? There's this this whole sort of like new resurrection and like what does this look like? How are you thinking about this? Like, you know, you've had all this experience with starting small, being product led. You know, this is where we spend most of our time now, which is how do you leverage AI effectively to continue to be product led, continue to be effective, and not fall into some of the traps that I think, you know, some of this conversation that that's a little sort of more dated reminds us of all the traps that we used to be part of when we were going through Agile and so forth. So tell us a little bit about how you're thinking about this.

SPEAKER_01 23:42

Yeah, I mean, I will say this. By the end of our transformation, we had stopped being truly scaled agile. We had kept pieces that we liked and kind of said, the rest of this doesn't work. Kind of like the having a PM and a PO. We said, look, if you're a fully self-contained internal platform-only team, we'll have a product owner that's kind of working day-to-day, translating within the business for the developers. You don't need a different role. And that's not what scaled agile teaches. If you're customer facing and a customer's going to be purchasing you from a market somewhere, you need a product manager that's focused on that market and that customer, but you don't need a separate person as a PO. We also developed some of our own roles. We became headless in IT, by the way. We did not have IT directors any longer at a certain point. So there were things that we decided would work for us. I was certified because the business asked me to be. In fact, I was the first person certified at that company in Scaled Agile. And I kept that certification for a couple years. I don't use scaled agile at the company I'm at now. Uh I haven't tried to, but there are lessons I learned of things that work. I think product right now is in a bit of a disrupted state, not like being disrupted, but but actively disrupted. AI is the biggest part of that. AI is making some things easier or sometimes fooling us into thinking they're easier, but it is forcing us to evaluate what does good velocity look like? How quick can iterative cycles work? Right. We've, I think for decades we've said it's two weeks, it's a sprint, it's two weeks. Can it be two to three days? And we pivot. Well, then how do you do predictive planning and how do you normalize velocity even once the team's mature? There are a lot of things that we're questioning right now. Do you need technical these and PMs?

SPEAKER_02 25:25

Yeah, I'm questioning kind of, I think going back to Vidia's question, which is what are you personally doing differently in reaction to some of what you're learning here? How has that changed the way you've either structured or the way you've the different practices that you've sort of implemented to protect you from some of the slop or the challenges that AI comes with? Um, talk to us a little bit about what you do differently now.

SPEAKER_01 25:50

I think my view of what a product manager is has changed a lot. I focus a lot less on the technical. It used to be in my mind that the technical aptitude was harder to develop because if you're not a technical person, maybe you're never gonna click with it. I think with AI that helped, there's a lot out there that can really help you translate techno if you don't come from that background. I focus, I think the most important skills that I see right now today in product is understanding people. It's your ability to have a high EQ. You've got to be extremely empathetic. You've got to be able to read and intuit people. And then I think communication, core communication skills, person to person. That is something that is eroding, by the way, within our education system. It's eroding within the college system, within our adult population. People are not good at having this conversation. People aren't comfortable doing those things. So those skills in my mind have become way more paramount because the ability to prototype, the ability to evaluate tech stack trade-offs, I think those things are becoming really easy. AI can assist with those, but your ability to look at a person and understand what they're going through and then translate those feelings into potential problems to solve for them, that's a soft skill. That is a soft skill that you've kind of got to have. So I think it's a con, I'm I don't know what you guys stand on this. I'm controversial on this idea of product sense. I believe product sense exists. I believe some people have this ambiguous term of product sense, meaning I can figure out what's going to help people enjoy my product, what's going to make them fall in love with what I'm trying to do. That is difficult to teach. I think it's more important than ever because AI is not replacing that.

SPEAKER_00 27:23

I think we wholeheartedly agree. But I think it's, yes, there's a strong part of sort of intuition and having this, but there's also, I think you can be taught. I think that the more time you spend with customers, the more time you're observing, the more time that you embed yourself. That's how you develop those things that you talked about, which is empathy. And we totally agree. I think there's no replacement for that, which is a really good thing for us in product management. This has been so interesting. I think you've taken us sort of like on this sort of like huge history tour from like, could know the roots of product. I love the fact that we've sort of like talked about the core of what's truly important. We brought it all the way back to customer and that sort of sense of like truly understanding. You've given us a lot of sort of product stealth and hacks and so forth. What's the one rebel hack that that you would recommend to someone? What's the thing that you've learned over your career that you say this is the thing that I would love for other leaders listening to this to know?

SPEAKER_01 28:19

Yeah, I think, you know, if you're going to develop a skill that you're always going to want to have, I don't know if I'd call it a hack, because I think a hack seems like a shortcut. You know, I call it a thousand ways to say no. If you don't have in your back pocket, it's not a thousand, right? We're being facetious, but if you don't have a whole bunch of different methods that essentially allows you to not say yes, but also not say no, you're eventually going to back yourself into a corner in product development. This is, I didn't plan this. This is something that happened today. I was talking to a peer, and they don't work for me or you know, with anything I'm working on or anything. He was basically describing a problem he was having with his product. And, you know, we kind of went through it and I gave him advice. Like, look, based on what you're telling me, this this is what I would say to go do. And he said, Yeah, but my VP said, I have to go build X. And I said, Well, you you gotta you gotta be able to tell, like, tell him why that's not a good idea. And he said, Well, you know, I knew his former boss, and I said, you know, you gotta be able to do this. He goes, Well, with so and so, I could do that. I could push back and we could have a conversation. He goes, with with the new boss. Um, his words, I've lost the ability to say no. To me, I really I got scared for him. And this was this morning's conversation. Like that I didn't plan this with the podcast going on. It just happened to be the conversation from this morning. I got scared for him because if you as a product manager feel that you have lost the ability to say no, you are really powerless to do your job. Your core job is to shoot down every bad idea, every bad feature, and to be that advocate for the customer and the business together and prove why you are correct in what you're doing. So if you don't have a thousand ways to say no, you can't have one method or two methods because you're gonna come across a boss or a CEO or a client that is difficult or persuasive or something, or just doesn't like to be given feedback. So that's a that's a really, really big one. That is one you can absolutely learn and constantly add to your bag of tricks. How do I get to know? So I'll give you one that I do. I love the enthusiastic yes because it's the opposite of no. And every person thinks that they're hearing yes when you're saying no. And the enthusiastic yes looks like this. You are usually an executive and you don't like to be told you're wrong. And so cool, I'm not gonna tell you you're wrong because no matter how right I am, I'm still gonna lose my job. So I'm not gonna tell you you're wrong. You're gonna say, Chris, I think we should go build this. And I'm gonna say, awesome. All right, so you want to go build that? Let me do this for you. Let me take a couple days because you know it's an exciting idea. Let me go a couple, take a couple days. Let me outline how we get there. And I'm gonna come back in just a couple days. I'm gonna show you a full plan to get there so that we can start executing on that. And by making it a short term, they see that I'm enthusiastic and they're like, couple days, awesome, all right, he's on board. And I'm gonna come back with that plan. That plan's gonna be accurate because I'm gonna show them all the things we can't do if we choose to do that idea. I'm gonna let them know what metrics, because anything I'm doing should have a metric. And I'm gonna say, we're gonna we're gonna stop doing these things so we can go do this idea. And that means we won't hit these metrics, but we're gonna, we're gonna do your idea. And if it works, we don't know if it works. We haven't researched, but we're gonna get it done, and here's the plan, and here's the amount of money we're gonna spend. Usually they're gonna look at that and they're gonna say, Well, I don't get this, and I don't get that, and I don't get this, and we had all these goals and we were gonna hit these things. And then they're gonna ask me, Well, what, well, if we'll if we do this idea, what am I gonna get? And I'm gonna say, Well, we haven't done the research yet, so I really haven't proven this one. I mean, it sounds like a great idea, so I'm sure, you know. Then they start to kind of show themselves, maybe do I really want to commit to this? Because it's on me. That usually works. That's that's one technique. Okay, I gotta have a thousand others, but that's one technique that I that I go to with that uh that one person that does not want to hear no ever.

SPEAKER_02 32:04

I love it. I mean, I this is something that we actually coach our teams on how to say no. It's not, it is the enthusiastic yes, and it's let me get back to you in 24 hours or whatever with a plan and and showing the true data. I think everyone is logical. If we all have the same data, we usually come to the same conclusion. And so we love it. We we call it shared vision. So certainly one of the greatest tools ever. But Chris, thank you so much for your time. This has been so helpful and insightful. And we really appreciate your time, your energy, and and we wish you the best in your next set of endeavors.

SPEAKER_01 32:46

Yeah, thank you both so much. Really appreciate having me on.

SPEAKER_03 32:49

Thanks for listening to this episode of the Product Rebels Podcast. If you enjoyed this conversation and want to learn more from Product Rebels from companies like Netflix, Amplitude, and beyond, please follow us wherever you listen to podcasts and join us for another impactful interview in about two weeks.