Practical Product Management · 2024-06-12 · 31 min
Key moments - from our scoring
Substance score
44 / 100
Five dimensions, 20 points each
Two experienced product leaders dissect the recurring bad habits that derail PMs and teams. Speaker A confesses to shipping vague user stories without acceptance criteria and holding opinions too rigidly, while Speaker B describes being overly solution-driven until a mentor (Gino) repeatedly asked 'why' until he admitted 'because that's the way I want it.' They identify a constellation of destructive patterns: premature solutioning and over-engineering (trying to be 'the Uber of shoes' when you lack Uber's scale), mistaking process for progress (forcing Scrum on teams better suited to Kanban or Waterfall), skipping customer conversations, misrepresenting status (false green metrics), and arbitrarily imposing delivery dates. The core insight: product managers must stay problem-focused, not solution-focused, and lead through metrics and customer understanding rather than opinion. For anyone managing technical teams, negotiating between business demands and engineering reality, or struggling to balance decisiveness with openness - this captures the practical middle ground between command-and-control and paralysis-by-committee.
Speaker A wrote vague user stories without acceptance criteria or details, expecting the team to 'figure it out' later. Months later, when engineers asked what a story meant, they couldn't even remember, creating confusion and rework.
Solution-focused PMs stop gathering information once they think they have the perfect answer (as Speaker B learned after hearing 'why' 16 times). They miss innovation and insights from the people building, designing, and selling the product because they're not listening with openness.
Larger companies like Uber and Amazon have specific cultures, thousands of people, and years of work behind their models. A small team can't replicate those conditions; instead, PMs should focus on their unique interface between customer and problem to unlock their own innovation.
When a business says 'May 31' and engineering says 'August,' the PM must ask why each side needs that date or timeline, not simply relay the conflicting numbers. Then negotiate scope, resources, or phased delivery - never just promise an arbitrary date to appease one side.
A user story is meant to be 'a promise to have a conversation,' not a detailed spec thrown over the wall. If PMs treat it like a locked requirement and engineers can't ask clarifying questions, it breaks the collaborative intent of Agile methodologies.
Our reviewer’s read on each dimension, with quotes from the episode.
Contains a handful of genuine PM lessons (problem vs. solution focus, user story as a promise for conversation, matching methodology to customer constraints, date negotiation via scope/resources), but they're diluted by long anecdotes, agreement, and pillow tangents.
we need to be problem focused, not solution focused
a user story is a commitment for a conversation. It's a promise to have a conversation
Largely recycled PM conventional wisdom - hold opinions loosely, talk to customers, mini-CEO is a myth, don't over-engineer - without contrarian or first-principles reframing.
the product manager is a mini CEO of the company
not. Not talking to anybody outside the building
Both speakers are experienced practitioners with real backgrounds (Amazon payments platform, Providence health tech telemedicine, a large NY financial company), which lends credibility even though it's a co-host chat rather than an interview.
I've worked in, at Amazon in the payments platform
I worked in Health Health Tech building telemedicine platforms
Names real companies and vivid anecdotes (Amazon checkout, Uber NYC launch, Pike Place, Tokyo pillow, Waterfall for financial clients), but almost no hard metrics or dollar figures beyond a vague "$10 million a year, $100 million a year."
they're paying in $10 million a year, $100 million a year to a group
we had teams that, that, uh, that were more efficient in Waterfall because their customers could only accept changes a couple times a year
Two co-hosts who almost entirely agree - constant "totally," "100%," "yeah" - with no genuine pushback, challenge, or probing follow-up questions.
No, totally. And I think the Uber example is a really good one
100% right
Computed from the transcript - who did the talking, and the words that came up most.
Leah and Marilyn discuss bad habits that product managers often fall into. They share their own experiences and provide insights on how to overcome these habits. Some of the bad habits discussed include avoiding detail work, being too opinionated, over-engineering solutions, trying to emulate larger companies, not talking to customers, and not being honest about project status. They emphasize the importance of being practical, focusing on customer value, and maintaining open communication with the team. Takeaways - Avoiding detail work and not providing clear acceptance criteria in user stories can lead to confusion and delays. Being too opinionated and inflexible can hinder collaboration and innovation within the team. Over-engineering solutions can waste time and resources, and simplicity should be prioritized. Trying to emulate larger companies without considering the unique strengths and limitations of your own organization can lead to unrealistic expectations. Not talking to customers and relying solely on internal perspectives can result in products that don't meet customer needs.
Transcribed and scored by The B2B Podcast Index.
Speaker A: Welcome back to Practical Product Management, the podcast. It's a lot of, uh, this mouthful. And today Marilyn and I are going to talk about bad habits. So I'll start. I'll start with my bad habit. So when I was a young product manager, um, we were talking about what our worst. What our worst habits were before we started this. And I was like, oh, I, I had some, I had some good ones, but I think there are two that I would stick with. One was that I really, really, really hated, like, all of the detail work that went into writing, like a user story. I was like, ah, we'll figure it out when we get there. And I would just sort of write a great user story, but none of the, like, acceptance criteria or any of that. And my team would be like, what does this mean? And I would not remember. So that was a bad habit because it would be months later, they'd be like, what did you want us to do here? I don't know. I don't even remember what I wanted you to do. So that was. That's one. Um, the second one that's probably more important and one that I still have to work with myself on is, you know, I always came with an opinion and I didn't always hold my opinion loosely. I often was like, this is my opinion. And by opinion I mean do what I want done. Um, do this thing this way. And I was always sort of driving. I wanted to drive the team in a direction and didn't like it if they wanted to take a detour. And I could get really worked up and struggly. So that those are. I would say those are my two. I think I'm better about both of those things. I mean, I don't write user stories anymore. That's how I got better at that. Um, but, um, I think I'm better at detail and I'm better now at holding things more loosely. But those I think are my, like, as a product manager, all of the people I worked with. I'm sorry, that's. I apologize.
Speaker B: Public service announcement. Announcement.
Speaker A: I apologize for all of those years that you had to put up with my. What about you? What do you think your bad habits.
Speaker B: I, I think, I mean, I think I have bad habits all the time. Um, I think that, uh, I get better at surrounding myself with people that can tell me the truth. Um, but I agree with you. Early on in my career, um, I just thought I knew best and I was very solution driven. And I remember sort of like, you know, we'll talk about Gino on our podcast, and we'll have him on eventually, so y' all can meet him. But, um, Gino is the master of why. And he will ask why over and over and over to get to the, to the bottom of the. What someone's striving for. Uh, and I remember one time in a conversation, sitting in his office, um, he asked me why 16 times in a row, and the last why? My answer was, because that's the way I want it.
Speaker A: I think it was just, like, all done answering this question, Gina. Exactly.
Speaker B: But I just. That's the way I wanted it. Like, I mean, I had good reasons and I had good thought process. Um, but I, I was done ingesting new information because I thought I had the perfect solution. And, And I do think that's a bit of a trap and. Because you have to, like. I think that you say it really eloquently, Leah. We have to be sort of like this epicenter of, uh, all of this information, and we have to be able to create, um, harmony, uh, out of all of this stuff that comes in and be able to point, Point a direction for the team. That does not mean getting, like, wrapped around the axle on your thing.
Speaker A: Yes. Yeah. As. As a matter of fact, if you do, if you get so, like, focused on your thing, whatever that thing is that you think is the way it needs to be done and how. What's going to work, you'll miss the innovation.
Speaker B: Yes.
Speaker A: Miss the opportunity. You'll miss. Because the voices in the room that are building it, designing it have to sell it. Right. Have to pay for it. Those people sometimes say stuff that you're like, wait a minute, that's. That's not a bad idea. But you have to be listening for that. And that openness is missed.
Speaker B: It's a, um, you also said it really eloquently is we need to be problem focused, not solution focused. I think you say that quite a lot, and I think. I don't think people understand that in depth enough. Um, and how I try to, to gift it to my product managers or I have over time, and it's really hard to adopt is what metric are you trying to move? I don't. I actually don't care what you build. I don't care what you build. But there is a metric and probably a subset of, of, um, associated metrics that tell you if you're solving the problem for the customer and the company.
Speaker A: Right.
Speaker B: And all I really want you to care about is the metric and the customer.
Speaker A: Yeah.
Speaker B: Don't actually care about your feature.
Speaker A: No, totally. And I think so. I think one of the bad habits that we talk, that we, you and I talked about a lot over the years is over solutioning over. Architecting a solution over, designing a solution over. And I love designers and I love engineers and I love product managers, but we can over. It's overkill.
Speaker B: Right.
Speaker A: And, and how we can sometimes come to the table. I think it's a bad habit to not think in simple to complex instead of complex to simple. Like this is. This, is this big problem we're going to solve. And it's like, are you solving this? Are you solving this, solve this and then build to that. Right. Um, but I think we can over engineer our solutions a lot.
Speaker B: Yeah. I also think it's a, it's a bad habit to, to, uh. Well, there's a couple bad habits in here. First is I think, I think a lot of smaller teams look to larger companies and are like, why can't we be the blah of this industry? Why the Uber of shoes? Or like, what? Like whatever. Like pick your analogy. That's a, that's a terrible habit. Like Uber. Uber is Uber for a reason. They have a culture, they have teams, they have thousands of people working there. They've been working on this problem for a very long time. And Uber wasn't even Uber for a really long time.
Speaker A: Right.
Speaker B: Who are you as a company and like, how, how are you focusing on that, that interface between the customer and their problem and you, uh, in a way that unlocks innovation?
Speaker A: No, totally. And I think the Uber example is a really good one. I remember the first time I took an Uber years ago in New York City. They had only launched in New York City and I was working for a CEO at the time at a startup who was like, let's try this new thing. And he had put it on his phone and he, you know, and when I think about it in my mind, I've made. So I've been so generous in being like, they were Uber back then too. But when I really think about what the experience looked like, I'm like, it, uh, wasn't great. It just wasn't a taxi. Yeah, it wasn't. And we were excited because it wasn't. We could see ourselves on the map. That was the thing that was different.
Speaker B: Right.
Speaker A: And, and it was just a car, not a yellow taxi. And I think like, oh, uh, they weren't even Uber then. But the generosity. If you do things really well and you have a good culture and you have a path forward and you Stick to it and you make mist and you. All the things Uber's done right along the way, people will be generous and remember you differently than you are. I mean, Amazon's the same way. Who Amazon was when we were there. I'm like, um, that ordering system was clunky as hell. Right? Yes. Right. And, and then you look at it and go, hmm, actually, hm, that's made a lot of progress and it's a lot. This does this thing.
Speaker B: Now the funniest thing about Amazon, though, and I think we were just talking about this the other day, Leah, um, is that. And it takes me back to that over engineering thing you just said. I think there are lots of people that want to build something beautiful and simple. And really what you just needed to do is solve a problem. The Amazon example is perfect because I get a lot of people that are like, well, checkout is easy. Everybody knows how to do it and they do. But if you, if you think about it, and I've got, I've got like, no shade to any of the design teams that have ever worked for me. I love them. Um, and their job really is to like, be user obsessed and come up with this beautiful solution. But it. You don't always need the simple and beautiful solution. You just need something that works.
Speaker A: Right, Right. I mean, I, you know my opinion. I mean, I've worked in, at Amazon in the payments platform, but to some degree the Amazon checkout's not beautiful. Yeah, but it works, right? It works every time. Tell, tell the people your story.
Speaker B: Oh, my gosh. Yes, it does. And I think it's because we're used to the patterns. Right? Okay, so this is a weird story I've told Leah. So, so sorry to the rest of you that now have to hear this. Um, I was in Tokyo a couple months ago staying at the Intercontinental Anna Hotel, and they had a pillow that changed my life. And I'm not overstating this. Um, I would actually advocate that you fly to Tokyo and stay at this hotel. It's like a, it's like a feather pillow on top, and the, the bottom is these little plastic beads. And I fell in love with this pillow. It's the best sleep I've ever had in my life. I went downstairs and I'm like, you have to sell me this pillow. And they're like, oh, no, sorry, they're specially made for us. We can't sell you the pillow. And so then I seriously considered stealing this pillow.
Speaker A: You're like, what clothes will I leave behind in order to take this pillow suitcase.
Speaker B: It was a huge pillow and I'm sure they make them a little oversized just for this reason. So I spent days searching for these little beads. Like I. I opened the pillow, I was touching everything. I was trying to figure out what this pillow was. It's, um, a product called coma beads. Um, I finally found it on Amazon Co jp. I speak no Japanese. I'm on my phone, I am. I'm on a screen this big. Um, I find these stupid bead pillows. Um, I created an account on Amazon code. I entered my shipping address. No problems, all in Japanese. I entered my payment method, I checked out. I bought a pillow. I paid three times more than the pillow for shipping.
Speaker A: That's worth it.
Speaker B: I did all this in minutes because the UX was intuitive. It wasn't beautiful. It was. To your point. It's ugly.
Speaker A: Yeah. It's wordy, it's clunky, it's.
Speaker B: But.
Speaker A: But I know that this is where the CVV code goes and I know that this is what has to happen if they need me to re. Enter my credit card number because it's been too long. And I know, like, I know where my address goes. I know what. I know all of that. I did the same thing to Germany. Like, I never translated Amazon de. Right. Never. It just. I just put the things in where they went because I knew how it was supposed to work.
Speaker B: Yeah.
Speaker A: And when I moved to the uk, I also didn't have to translate it, even though I don't speak good English. If you ask them. I don't think. Yeah. So I agree. I think there is this like over engineer, over design. What? You know, like, like thinking we're right. Right. Like our way is the only way. What are some others? What are some other bad habits the PMs get into?
Speaker B: Let's talk about user stories. Because you started there. Um, user story. People often say that a user story is a commitment for a conversation. It's a promise to have a conversation.
Speaker A: Yeah.
Speaker B: Um, and I think a lot of product managers write their user stories, either in a word, obviously. Word docs. I've seen them in Excel, I've seen them in zero. Like, here's a list of. It's like they hurt the garbage over the wall and then they get mad when the engineers want to have a conversation about stuff. And it's just like, mhm. That user story is not a requirement Stock.
Speaker A: Right. And I think, I mean this goes back to sort of our framework conversation too. Like, I think, you know, I am not. I. I like scrum I. If I'm choosing. If I'm choosing, I want to. I want points. I like Scrum. I like the ceremonies around Scrum when I'm the product manager. But if my team says, we want to run Kanban, or we want to run some hybrid version of what we call Scrumban. Right. Or whatever. Okay. Like, because the frame, that. That particular methodology, the build methodology, is a means to a conversation.
Speaker B: Yep.
Speaker A: And if you get evangelical about how you want it done, you will alienate your team. Yeah. If they say, you know, we could actually go faster if you would just let us do this, and you're like, no, we have to have points.
Speaker B: That's to be my way.
Speaker A: Calm down.
Speaker B: It's just, hey, you can have points.
Speaker A: You can. Okay. And then they'll just make them up anyway. They'll be like, three. You're like, okay, why? I don't know. Right. 14.
Speaker B: Not even a Fibonacci number.
Speaker A: Exactly. Exactly. And so it's like, I do think that we can be. We can get. So again, I think it goes back to the same. The same bad habit of thinking your ways the right way. Right. But we can get so, like, laser focused on, like, I like to do things this way that we're not, like, okay, what will work best for the team.
Speaker B: Yeah. I also think that not, uh, everybody has to be the same. Um, and I think there's this notion that everybody in the company must act in a homogenous manner. M. So, uh, at a. At a large financial company that I shall not name that. That was in New York. Um, we actually have TV.
Speaker A: If you go look at your LinkedIn profile.
Speaker B: Yeah, that one. Their logo is, like, red and yellow and gold.
Speaker A: Yes.
Speaker B: Um, we actually had teams that, that, uh, that were more efficient in Waterfall because their customers could only accept changes a couple times a year, and they needed to be well documented and delivered months in advance.
Speaker A: Yeah.
Speaker B: Scrum is never going to work for that use case. You can maybe deliver iteratively, but what. What benefit does that framework give to the team?
Speaker A: Yeah. Doesn't.
Speaker B: Because you still have to run Waterfall. So you've got all the ceremony of Scrum and all the ceremony and process of, uh, Waterfall. And it's like, all lumped together and sewing.
Speaker A: Yeah, totally, totally. It makes total sense. I mean, what you say makes total sense to me because, like, I worked in Health Health Tech building telemedicine platforms, and we ran Waterfall on the hardware because we had to. Hardware has to go that way in this. In that very meticulous hardware Space. And then we ran like some version of Scrum on the software. Actually, we ran pretty strict Scrum on the software because I was checking Velocity and then I had to. We had. As a team, we had to marry those things for delivery. And it can be done.
Speaker B: Yeah.
Speaker A: But it takes. How am I gonna bring this cycle together with these cycles? Right. But that's part of the job, right, Is the ability to do those things. I think it. I think you're absolutely right. Like, getting. You can just get. Like there are times when something else makes sense. Right. Um, or when putting two people in a room and saying, figure it out, build it, like that can also make sense. And there's no methodology that says, like, that fixes that. When you say, here's a problem, can you guys go away and make that happen? They go away and then they come back.
Speaker B: I've actually had some of my best and most innovative solutions. Were just, uh, two people going to figure out a problem, right? Just two people. All right. How about the bad habit of, uh, not. Not talking to anybody outside the building?
Speaker A: That's terrible.
Speaker B: I often will tell people, uh, anybody with a badge of the current company that we're in their. Their voice and opinion doesn't matter.
Speaker A: Yes.
Speaker B: I don't care. And they're like, but we haven't talked to anybody else. And it's just like, well, then you, my friend, are screwing up. You're screwing up.
Speaker A: Go out. Go out and ask questions. And it can be. I think it's something you have to learn how to do early in your PM career because you need to be able to do it always. Yeah. And it is hard sometimes for those of us who swing into the introvert space a bit. Right. To be like, I have to go out with these pieces of paper and do wireframes and, you know, or I have to, you know, whatever. Whatever your means is to going out and talking to other people. You have to. You have to.
Speaker B: And there's lots of excuses like, you know, oh, you know, the business doesn't want us talking to customers, or this group doesn't want us talking to customers, or, oh, we can't. And I'm like, well, you own the interface.
Speaker A: Yeah.
Speaker B: You can go talk to people on the street. Like, there are lots of ways to talk to people. Um, why are we letting someone else stop us? If our job is to ensure that we're creating the most value for the company with the, uh, you know, with the technical solutions that we build? Why. Why are we allowing ourselves to be stopped?
Speaker A: Yeah. No, it's so true. I mean, I sent one when I worked at Providence. I sent a group of people out into Columbia Tower, into the food court in Seattle with, like, literally, paper, like, wireframes, and said, go see what people touch. Go ask them, if you. If you start here, what would you do? And they were like, this is going to be horrible. And I'm all, yeah, it'll feel horrible. You're right. Go do it. And I did it, too. Like, I went. And I also was like, this is horrible. I hate talking to strangers. Right. But we got information we needed. Uh, it changed what we built. Like, literally, what happened that day in the food court changed what we did, because we were in our own little echo chamber of how it should work. And people were like, I don't know what to do here. And I'm like, okay, that's what I thought.
Speaker B: I remember our first product that we worked on together. Like, everybody thought they knew exactly what needed to be done. And when we went and just observed people in the wild, we didn't even interact with them, but we just watched what their day to day was like. You start to get a really, uh, strong empathy for. I mean, I think we sat in that flower market in Seattle, Pike Place.
Speaker A: Yeah.
Speaker B: To watch the merchants do their job. They probably thought we were weirdos.
Speaker A: Like, why are those people staring at us?
Speaker B: What's a day in your life look like? And then you sort of get the courage to be like, and what else are you worried about? You know, how. You know, what. What does it mean to run your business? And. But that. That level of understanding. And really, it's your job to bring that back to the team for sure.
Speaker A: No, 100%. I totally, totally agree. Um, what about the bad habit of not telling the truth when things are about to go wrong?
Speaker B: I mean, that one is one that just ruins teams and ruins product managers. I'm, uh. I think I learned that one the hard way really, really early on. And I am nothing if not brutal. Brutally honest right now. If we are red, I'm going to say it early. Uh, if we're running behind, I'm going to say it early. Like, people. Like people. I think. I think I get a fair amount of crap in my job now because I'm. I'm Amber a lot. And there's a lot of teams that are always green. They're always green.
Speaker A: You're not green. Right? There's no way you're green.
Speaker B: Well, and I don't want to tell them that sometimes they're green and they have a dependency on me, and I'm red, and I'm not quite sure how that works.
Speaker A: You're like, that's interesting.
Speaker B: Yeah. But someone. Someone's either not connecting dots or. Yeah. No, I'm. I'm the first person to say, like, hey, there's unknowns and there's risks and I'm managing them.
Speaker A: Right.
Speaker B: But don't ever lie.
Speaker A: Like, no. I remember Matt Swan saying, like, there's no light green. You either are green or not green. Right.
Speaker B: Yeah.
Speaker A: There's no light dark green or light green. Like, don't try to convince me it's light green. Right. It's like green trending to yellow. Just be yellow. Right? Yeah. Like, just say what you say. Tell the truth. Right. And I've. Even as a leader, I've told my teams, like, I will have hard conversations.
Speaker B: Yeah.
Speaker A: If you will tell me the truth. If. But I will make you have hard conversations if you don't tell me. And we get to the end and then it's like, oh, uh, somebody's got to tell them. Go ahead.
Speaker B: We're going to be another quarterly. Yeah.
Speaker A: But I will absolutely take the bullet for. We're going to be late. Yep. We learned. This is why we're going to be late. This is what happened. If you'll tell me. But if you don't tell me, good luck. I don't know how to support you in that.
Speaker B: The other side of that is not allowing the team, the. The TPM and the engineering leaders to set the. When is this going to be delivered? I think there's this, like, you know, I don't want to call it like, beating people with dates, but it's beating people with dates and just being like, this has to be out on June 2, because there really is only two. Two other things that can flex it's scope and resources. Sometimes more resources don't help, but it doesn't. You don't. You don't just pick a random date and then beat your team into submission and force them to get something out on a date. Like, that's. That is the worst bad habit.
Speaker A: Yeah. Ah, yeah. Yeah, totally. And agreeing. As a product manager, I think product managers often get squeezed between someone, a boss, a business, someone saying it has to be ready by May 31, and the team saying, we can't build it until August.
Speaker B: Yeah.
Speaker A: Like, when we ready? And you're like, um, okay, I'm going to tell them May 31, though. And it's like, no, no, no, don't do that. And, uh, now Your team doesn't trust you, right?
Speaker B: Yeah.
Speaker A: You just agree blatantly with your team saying we can't have it ready till August without interrogating their details. And so then you people August and they're like, not, no, that's an unex. And so you have to be a master negotiator, but you have to go in and actually interrogate. Why do you need it on May 31st? And why can't you build it till August? Right.
Speaker B: Yeah.
Speaker A: And if, and if the two things are still true, then now you are the keeper of the cut the scope scalpel. Right.
Speaker B: Or can you have resources?
Speaker A: Is.
Speaker B: Is it possible right in this instant?
Speaker A: Exactly.
Speaker B: I, I think that, that, that negotiating point is really powerful. Um, and I think that is the, like, you know, exactly what do you need by this date? You don't need the feature. You need something to happen. And then how, if it's not delivered this feature, can we make this something start to happen by May? And maybe it will not finish happening until August. But again, this is a, this is, this is where practicalities matter. This is the practical side of product management. It's not feature delivery. It's not feature delivery. Features don't matter.
Speaker A: No. And you're absolutely right. That's where it gets really. Like, how do you, how are you very practical in saying, like, okay, we need, we need to tell the truth. We need to be willing to tell the truth. We need to be willing to look at our reasons, look at what's happening, look at, you know, like, and you have to be willing to ask lots of questions. It's the job, right? Yeah. I became a coach because I learned how to ask questions as a product manager. Right. I coach people and ask questions all day long. Huh. Huh. I wonder how I learned how to do that. My whole life has been asking people questions.
Speaker B: So, yeah, I do think that perhaps one of the things that drives a lot of these bad behaviors is some of the flip anecdotes. The product manager is a mini CEO of the company.
Speaker A: Yeah.
Speaker B: I don't think that. I think that your job is far more complex, uh, and far more nuanced. And, uh, you know, I just, I think some of those, like, little statements that are great to put on a T shirt or a pair of socks, like, really? Again, when they're not practically applied within, within the framework of a company, just turn into really bad, toxic behavior. That, that, that means that you don't deliver, you don't deliver on time, you're always late, you're not actually Moving the company metrics, you can spend a lot on engineering and get limited value out of it.
Speaker A: No, I would say, I think it goes back to that. That conversation that, like, what's your motivation? What's your motivation? Like, if you want glory, if you want people to applaud you, if you want power, if you want, like, okay, that may. Maybe you can find that in this career, but you won't do it well, and you won't be very. You won't be very good at it. You won't have a team that will go with you.
Speaker B: Right.
Speaker A: Might not be very well liked. Right. But. And that's fine. You don't have to be well liked, but you might not even be good at the job. Right. Because your motivation is something that is not about it being in service to the customer and in service to the company and the team. Right.
Speaker B: Yeah.
Speaker A: Uh, I felt like as a. When I moved into leadership, I felt like I was constantly in this balancing act between what's good for my customer, what's good for my team, and trying to make sure I didn't take advantage of these people to give these people a solution. Right. And, uh, how do I make sure that they're cared for so that I can get something in the hands of the customer that is good and that. That's the job. I was the one. Now, this was my product, and I was the one managing the tension between how hard can I push these folks and what's good for them and what's the right culture for them, and what are we trying to do so that I could get something in the hands of the customer? That I really was like, oh, I'm so excited about this. Right. Yeah.
Speaker B: And then the third part of that triangle is that thing that you put in the hands of the customer actually delivers a business value because this has invested in the tech team.
Speaker A: Exactly, exactly.
Speaker B: They're paying in $10 million a year, $100 million a year to a group to get something out that delivers business value. And I think, again, I think that's where you get into this feature factory mindset. Like, I want the new button, I want the new widget, and without that, uh, full loop. Yeah, maybe the customer wants it, but it's not the right time for this business to deliver that thing. Right.
Speaker A: 100% right. And you can. I mean, going back to our. The product we worked on together, man, we had a scope creep problem. Right? When I look, when people, When I ask, when people ask me about failure, I say, oh, I. I mean, I. We I bombed the first thing I ever built at Amazon. And the primary reason was we just got hung up on what someone else was doing instead of what we needed to deliver and what we were good at.
Speaker B: And we never delivered incrementally. We always wanted to release the, you know, the killer app that was full done, um, that would solve everybody, everybody in the whole world's problem instead of just getting something.
Speaker A: Yeah. And we were. And I think we lost sight. I think this is also a bad habit, losing sight of, uh, what you're good at. We were going to be excellent at the customer service and we were going to be excellent at the money because we had money and none of our competitors had the money that we had and could put it in the people's bank accounts as fast as we could.
Speaker B: Yep.
Speaker A: Right. And so. But we got so hung up on the scope being huge and launching that it failed.
Speaker B: I mean, uh, actually, that one actually kills my soul just a little bit because that handling.
Speaker A: Exactly.
Speaker B: That was a product that should have probably survived.
Speaker A: It should have kicked ass. Right. But we got like as a group, not you and me individually, but we as a giant group of people, like, we got over focused on scope and flash and delivering a big thing instead of like, why don't we put something in the hands of people that need it as fast as possible and learn quickly and iterate? Because that's what we were all good at.
Speaker B: We lost. Right. Because you would have. You would have started to seeing value return to the business instead of a year late and no value. I mean, that was. It was pretty big. It was a pretty massive failure.
Speaker A: Yeah, totally. I mean, I joined in May. We were supposed to launch in August, and we did two years ago. It's like, what?
Speaker B: Because we just couldn't say no.
Speaker A: Yeah. Yeah. I mean, I replatformed twice.
Speaker B: Yeah.
Speaker A: Painful. And. And you're. Those of you who are watching are watching that we still feel pain about that thing. And it's not about being in love with the solution. We were in love with the problem and what it could do.
Speaker B: And the funny thing is that problem still exists.
Speaker A: Yep. True. You can still solve that one. If they want us to. Right. But you got to give us two engineers and one Geno and leave us alone.
Speaker B: Can we have five engineers?
Speaker A: Yeah. Okay. Five engineers and a designer. Because. Because I want you to have to draw the wireframes because I'm not doing it.
Speaker B: I mean, everything I drew had kittens and puppies in it. That's all I'm saying.
Speaker A: We need. We need we need. We need at least a good designer. We need a Julia. Awesome. Well, any other bad habits you want to touch on before we end this?
Speaker B: Um, I think this is a pretty good list, I would say to everybody watching. Um, there is a form at the back of our website. Um, talk to us about the bad habits that you see. Uh, and let's find practical ways around some of these bad habits for. For other folks.
Speaker A: Yeah. I mean, the good news is that you don't have to stay in the land of bad habits. Bad habits can change. Right. You just have to take a different step. You have to make a different decision. Right? So today, when you're about to step into your bad habit, say, oh, maybe I should do this differently. Maybe I should ask a different question. Right? Maybe I should make a different decision. Maybe I should ask someone else what they think we should do. Like, walk away from your bad decision into a new decision. Right. Um, and to Marilyn's point, like, if you are stuck in a bad decision, send us a m. Send us an email and. Or a message on our website, and we're happy to talk about that and help you sort through it, or we'll make it a whole topic. Okay. If it's that big a deal. So very cool. All right, Marilyn, thank you. It was good talking to you. And we will see everyone in the next episode.
Speaker B: Uh, bye.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.