Bridging the PM Gap with Rich Mironov

Episode 48

Have you ever been told to be more “innovative” with your code? In this episode of Programming Leadership, Marcus and his guest, Rich Mironov, discuss the all too common disconnect between developers and those on the marketing side of organizations. According to Rich, this is the result of two very different work cultures existing in the same organization – one that’s collaborative and one that’s highly individualistic. The culture gap can be hard to cross. Thankfully, Rich has spent years coming up with solutions to bridge that gap. It’s not always easy, but Rich believes that it can be done through a better understanding of how the two cultures work along with constant education and communication.

 

 

Show Notes

• Differences in design principles between product and engineering management (1:35)
• Understanding the conflict between makers and marketers (6:22)
• How Rich helps marketers/sales develop a more useful frame for engineering (10:01)
• The “Innovation” Misconception (15:36)
• The culture gap between sales and development/product teams (21:46)
• Where does product management fit between sales and development? (26:31)
• Helping clients make effective organizational change (32:48)

 

Links:

• Guest’s Website: http://mironov.com
• Guest’s email: mailto:rich@mironov.com
• Programming Leadership: http://www.programmingleadership.com

 

Transcript

Announcer: Welcome to The Programming Leadership podcast, where we help great coders become skilled leaders, and build happy, high performing software teams.

 

Marcus: All right, welcome to the show. A bit of housekeeping as we begin, if you enjoy this podcast support us by leaving us a review. The stars matter a lot, the words are great, too. But our sponsors really like to see that people are listening, and we do too. Otherwise, we’re not sure anybody is actually out there. So, leave us a review on whatever platform you’re listening to this on. My guest today is Rich Mironov. Rich. Welcome to the show.

 

Rich: Thanks so much.

 

Marcus: Rich since I flubbed the first introduction and this is take two, would you introduce yourself for us? [laughing].

 

Rich: Sure. My name is Rich Mironov. I’m a 30-plus-year veteran, in Silicon Valley, of enterprise software product management. And these days, I coach heads-of-product. And I do a fair amount of design work on product management organizations and, sometimes, the larger product engineering design problem of how people fit together. And I’ve been a fan of yours for a long time, been following your writings and your daily send-outs, and it’s a pleasure to join you.

 

Marcus: Well, thank you, and I have really enjoyed your writing as well, you just write such good stuff. And we’re going to have a link at the end to the website where people can go and find more of your wonderful, wonderful content. But you really touched on something, I think, is so important, and that is this idea of designing organizations where people can really effectively work together. And I know that you work in the product management space oftentimes, and I know that people in the show also represent some of them, the engineering management space. Do you see a big difference between those two organizations in terms of how we think about the design principles for the organization?

 

Rich: I really do. And I think they’re adjacent, they’re related. But, mostly when we’re thinking about engineering organizations, we tend to want to talk about throughput or volume metrics. How efficient is the team? Can they get work done? I’ve never actually met an executive who told me that the development organization was fast enough. We know that, in the history of the world, we always believe that we’re one sprint, or one more hire, or one more release away from getting all the things we want. And honestly, it’s never been true. It’s never true, it’s never been true, and there’s this false economy that says the problem is throughput. The problem is speed. The problem is velocity. And when we put on our product management hats, we’re asking a very different set of questions. Are we building the most important thing or things? Because we know that the more we throw at the team, the less we get done. If we got nine projects, we’re going to finish none of them. So, if we were only going to get two things done this quarter that are really important, have we chosen the right ones? Key product question; exclusive OR question. Have we done good validation with our users and buyers in our market, so that when we shipped something beautiful, and perfect, and well-tested, and with lovely workflows, if nobody buys it, it doesn’t matter how good that work was? And so product folks are worried about the questions of, is there an audience? Will they pay for it? What about the competition? How do we make money, or monetize this if it’s supposed to make money? And then at the far end, how do we explain to the world what it is because, again, it may be obviously true to some people, but most of the world is not software development engineers, and so when we have the development team describe what they’re doing, most of the world doesn’t understand and then we fail. So, the product problem, I think, brackets the development problem, which is at the front end, are we doing the right things, in the right order, for the right reasons, with goals? And on the back end, are we delivering what the market wants and measuring success so we can tune and iterate the next time?

 

Marcus: It’s just fascinating because you’re exactly right. You’re one more—the quote-unquote, “one more syndrome” problem, we just need one more hire, one more sprint, one more server, one more of whatever, and that most of these engineering organizations are thought of as, how can—I hear the word streamlined. How can we streamline it, which sounds like a car, but of course, an engineering organization is actually nothing like a car. It’s a complex adaptive system. It’s an organic thing.

 

Rich: And I think there’s this weird, wrong analogy where we think of building software like building fences.

 

Marcus: Amen to that brother. Yes. [laughing].

 

Rich: That’s right. Because all we need are a piece of land, and something to dig holes in, and generic labor, and we know just how long it’s going to take to build a fence. Whereas building software is perhaps the most creative and complex thing that people do in the world, or certainly up there. And, for me, it’s much more like trying to write a hit song or a great jazz solo, than digging ditches or going down to Home Depot to get a few folks at 10 bucks an hour for cash to sit in front of keyboards.

 

Marcus: Oh, absolutely. In fact, I used to tell my clients—it’s funny, I used to say—because clients would approach me, and at my company, we built software for them. That’s a very common business model in the world. And I would say, “Now owning this software is more like owning a puppy than owning a fence.” That’s exactly what I would tell them, and because I wanted to set this expectation that there’s a lot of care and feeding involved. It’s not just every 10 years, you give it a whitewashing.

 

Rich: That’s exactly right. And we have this weird duality where on the one hand, we want to whip the development team faster, because we think if we could just get it out a week earlier, somehow it’s better. And then we’re all grumpy and complaining when folks aren’t excited by what we ship.

 

Marcus: Now Rich, I see a lot into the engineering side of organizations, but you see a lot into the product management side of organizations. Does product management have the same flawed mental models about post holes and whipping—whipping sounds terrible, but is there those same kinds of analogies or pressures at play?

 

Rich: I think good product management teams are the—they’re the interface. They’re the connector between what I would call all the makers: the developers, the designers, the tech writers, the test automation engineers, all the folks who actually do work. And generally—because I’m almost always working with software companies proper where the thing we build is software, and if it isn’t good, we’re out of business. But the rest of the house has this very simplistic view that, for instance, selling is hard but building software is easy. And so, what I see and what I spent a lot of my time doing is pushing back on the executive team on the marketing and sales side of the house to continually and repeatedly push the concept, which they’re not excited about, that building software is more crafting art than it is science and repetitiveness. And that’s just—it’s a concept that’s got a lot of resistance to it.

 

Marcus: Yeah, how do you think we got here? I just think it’s fascinating.

 

Rich: Part of it, I think if we go back to the classic IT organization—and we’ll save this up for a little later because I don’t work with IT organizations—I only work with engineering teams, because engineering teams are profit centers, and IT groups our cost centers. And if you go back 30 years and say, well, the IT folks are the ones who configured my laptop and wrote SQL reports against the customer database. And neither of those was conceptually difficult, or even really perhaps that challenging, and so if I wandered into my little IT group, and I said, “Hey, we’ve got a new employee, I need a laptop by noon.” “Okay, we can do that. Did you fill out the form?” And, “I need one more report. Can somebody bring up whatever, SQLite Report Writer we have because I need to switch the columns and put a total at the bottom.”

 

And those have not just only the feature that they’re straightforward, but we believe our senior users when they tell us what they want. So, if you’re the consumer of that one report, “Well, I guess you really know what you want, even if you’re not sure what you’re going to do with it.” And if you are the employee who needs that laptop, okay, you need a laptop. That idea that things are completely predictable, that they are repetitive, that they’re a manufacturing process, more than that, that if I asked for it, it’s because I’m entitled to it and I know what I want, are absolutely, for me, fundamental failures on the part of almost everybody on the non-makers side of the house, who are trained to write down on a post-it note what some random customer or buyer told them in eight words or less, assume it’s self-explanatory, it’s well thought out, it’s strategic and everybody wants it, and then walk that posted note over to some product manager, waiting for them to leap up and say, “Oh, yeah, I’d love to do that. We’ve been sitting idly just waiting for somebody with a good suggestion. And now we can feel fulfilled. Because we were just sitting around waiting for somebody to ask for something.”

 

Marcus: So, you mentioned that marketing and sales really misunderstands—they have the wrong mental model about what engineering—the whole way products are built. So, as somebody who’s working in product management, how do you start to help them have and create a more useful model that is beneficial?

 

Rich: I think there’s really two pieces to that. One is to recognize that it’s not their job to deeply understand the development process. So, we hire salespeople because they’re great salespeople, because they’re optimists, because they’re relentless, they never take no for an answer, you know, it’s not selling until the prospect’s said no three times. They’re great at escalating within the prospect’s organization if they don’t get what they want—which is whenever they come to a product manager and ask for something and get told no, you can count to 10 and know that they’ve gone to your CEO to go over your head—but that marketing and sales and a lot of the other groups, finance, it’s not their job to deeply grok how we build stuff. On the other hand, we need to endlessly teach and share and model that because the bad assumptions lead to lots of bad decisions.

 

So, things I use, I look for the simplest possible tools. I have a paper version of a simple Kanban board that I carry around all the time, where for each team, or for each piece of the development organization, there’s a row, and in the far right column are the two or three most important things that we’re currently in building, so they’re in full development. The next column to the left, that is the things we’re doing architecture and design on because before we start full build, we should probably know how it’s going to work. And the column to the left of that is the validation column where we need to be going out in the market and finding out what good ideas are really not good ideas. And the reason to have it in a really simple printed form is because I’m always getting pulled aside in the hallway and somebody comes to me and says, “Oh, I need this thing. It’s really simple. It’s probably only 10 lines of code. I know we’re agile. Can’t we fit it into the current sprint? How hard could it be? We need to add teleportation to our ERP system.” Right?

 

Marcus: [laughing]. Right.

 

Rich: And rather than be the person who curses them out, and tells them they’re stupid, and kicks them in the butt, and offends them, what I want to do is I want to pull out my little printed version of my Kanban board—and it’s printed because I have no time in the hallway to go log on somewhere. If it’s an electronic system, I know nobody on the sales side will ever look at it. But we get to ask the question of which of the two things that this team is working on, that we agreed on Friday at the executive staff meeting are the two most important things for the company, do you think we should displace or delay or cancel for your new good idea that you thought of in the shower or in your commute in? And then, we agree that those things are really important. So, then we move one column to the left, say, “Well, okay, we could put your thing in, and put it right into design and architecture, but which of the two things that are waiting to go into full development that we’re doing design architecture, do you think aren’t important or aren’t as important?” Notice that keep framing this exclusive OR, but no one on the sales side believes in the existence of exclusive OR. And then we agree that the things in design or architecture are really the next good ones up. And so now we agree that we should put your good idea into the validation queue, and find out if it’s not just your good idea, but maybe other folks in our customer base or market care, and maybe they don’t, and so the best time to decide to not build something is before we start full development. So, that’s a whole dance to repetitively push into people’s faces in a polite way the idea that there’s not infinite capacity, the team’s not idling, waiting around. We have a plan. We can change the plan. But the things that are in the plan are the ones we’ve thoughtfully chosen for good reasons, and until we get a similarly good reason, we’re simply not going to throw the current work out, leave ourselves half-done, double-up on the whip, do all the things that development hates.

 

Marcus: Yeah, I really like that because it also tells me that nothing on the board was just thought of in the shower and tossed in. You mentioned these phases, validation phase, and we have planning and architecture, and design. Those all mean that there’s a process that people are going through. And yeah, and things just don’t get done on a whim.

 

Rich: Well, sometimes they do. So, in almost every organization, there’s somebody at the top of the organization chart who retains the right to walk over to the product and the development teams to say, “I know we had a plan, but there’s the system down, or there’s a big deal or I had a really good idea, and I’m the boss of you.” And so, we have to be prepared for changes in the plan, but we want to buffer them, we want to slow them down just a little bit because the rate of seemingly good ideas is 100x or 1000x our throughput. And so we’re never ever going to be in a place where good ideas just walk up to us, bite us on the butt that we didn’t see before. And we throw them into the mix. That assumes all kinds of things that don’t exist in the real world.

 

Marcus: Well, I want to kind of turn back to something we talked about. So, I’m imagining this very important person who begins thinking, “The right way, the way I can really get something done is just by telling someone, I’m the boss, you’re going to do it.” And my guess is this reaction to things not moving the way they want them to. Not moving fast enough, not being nimble enough, whatever the framing is, there’s some dissatisfiers, they decide to break glass and pull the fire alarm—and they’re going to use their power. And I have seen, and I’m wondering if you have too, that after a while, even when that starts to not work, sometimes people think some larger organizational change will fix the problem. That we’re just not structured right. And I wonder if you see that as well.

 

Rich: I see that in a lot of places, and often it’s described to me in very qualitative terms as we’re not innovative enough.

 

Marcus: Hmm. So, that would be the thing they want to increase.

 

Rich: That’s right. And generally behind that, if you say, “Well, why do you think that? Or, how do we know?” There’s usually some random set of inputs from the sales, or the marketing, or the support teams about stuff we haven’t done. The support organization always has a list as long as my arm of their top issues and bugs, and just as every system has a bottleneck, we know that if we fix the number one top bug, something else is now the number one top bug.

 

Marcus: There’ll be a new number one.

 

Rich: Right, and so even if we put 100 percent of all of our product, and design, and development, and engineering effort into fixing all the things that support wanted, we might never get to the bottom of that list. By the way, if we’re in the software business, we’re now out of business because we’ve neglected competitors, we’ve neglected new markets, we’ve neglected new features, we’ve just done the sustaining stuff. And ultimately, everybody walks away. Likewise, and again I’m mostly on the enterprise side, B2B, I’ve never met a B2B enterprise customer who didn’t want a few things that weren’t in my product. And usually, it’s a pretty short list of no more than eight- or nine-hundred items. [laughing]. And I know that anytime, we lose a deal—by the way, when we win deals—you may not know this, when we win deals, enterprise sales reps are able to explain that it’s because they are great sales reps. And when we lose deals, it’s either because we’re missing a feature, see list, or the price was too high. Those are the two reasons why salespeople explain we lost deals. So—

 

Marcus: Now this is a fundamental attribution error, right?

 

Rich: Yes it’s—

 

Marcus: It’s psychology.

 

Rich: —absolutely fundamental. And I’ve never met a good salesperson who admitted that they had any hand in losing a deal. It’s not who they are. It’s not what they’re paid for. It’s not how they’re rewarded. It’s not how they’re promoted. The good ones get to go to a club and Fiji, or Hawaii, and drink a lot and sleep around and do things I don’t know about because I’m not invited. But back to the innovation question, there’s an endless list of deals we didn’t win. And attached to every one of those deals is a handful of things that we either didn’t have, or we got told we didn’t have. They may not even be real, the customers may not even need them. Nobody’s vetted them, but there’s an endless list of stuff we didn’t do. And so the misconception here is, if we just got all of those things done—one, we’re never going to get them done and two, if you’ve ever tried to find a feature that you couldn’t find in Microsoft Office?

 

Marcus: Oh, yes.

 

Rich: It’s the result of 30-plus years of let’s add one new feature. And when you add all those features, your product becomes useless, it becomes unusable, it becomes worthless. And so the product problem here, as opposed to the development engineering problem is, how do we hold back all of the seemingly good ideas that are going to incrementally make my product less useful, less good, less friendly, harder to fix, harder to build? How do we push back on the one-off feature that’s just for one big customer that’s going to cause us to create another code line? How do we hold back the chaos, such that we can stay on track with building a product that the market wants, in volume, that’s usable, that’s beautiful, that’s good that’s tested, that works, in the face of the other half of the organization which endlessly forgets limitations and wants one more thing? So, there’s a lot of education here. Again, I don’t actually believe that the senior execs at my company will ever really embrace this thought. But it’s my job to keep reminding them until they’re starting to have some reaction. Back to your puppy analogy, you know, if your puppy pees on the carpet, and then you immediately give your puppy a treat, right?

 

Marcus: Yes.

 

Rich: We know how this works. And so when we have an enterprise sales team, where the salesperson came to the product team, and got a no, went around them to engineering, got a no, and then they went to the CEO who overrode product and engineering and gave them a yes. We’ve now established the peeing on the carpet model, where senior experienced salespeople at our company now know that the way to get things done is to escalate through the CEO and to override and to jam something into the backlog, in the top into the sprint via the CEO or the VP of sales. Because product and engineering don’t give me what I want.

 

Marcus: I have seen that many times, and it happens not just for sales. There’s a lot of different groups who find that whether it’s throwing a fit, or going around people, there’s reasons all these things happen.

 

Rich: And there’s good reasons for some, but as a behavioral model, it fails.

 

Marcus: It fails. Now I’m curious, I want to turn back just a moment. So, we’ve been talking a little bit about how these two organizations, we’ve talked about sales and product, how they interact. And I’m curious, do you see—because I really have no idea—sounds like you have a lot of visibility into the sales organization—do they do reorgs as often as I see engineering or products doing reorgs?

 

Rich: Not so much. They do something that is generally smaller than that. So, there’s a lot of rearranging of accounts or territories.

 

Marcus: Oh, yes, I’ve seen that.

 

Rich: Right. So, as your company grows, and you go from 10 salespeople to 20, you end up carving up smaller territories, and giving those folks more depth, more quota in their areas. And then you’ve got regional structures, and there’s usually some helpers. There’s like field sales engineers and other people who assist in the selling cycle. But I think—so it’s less about blanket changes, unless you, for instance, move from a channel model to a direct selling model, where you dramatically change your product set. Or when I see companies move from on-premise software to SaaS software, it gets a very different—the selling cycle, the teams, the—so when there’s major change like that, I see that happen, but there’s a lot of shuffling around. The other thing to note here is most salespeople are paid quarterly.

 

Marcus: Like, quarterly bonuses or quarterly, I’m sorry, can—

 

Rich: Well, so—commission. So I either hit my number or I don’t for the quarter. At the end of the quarter, I get a big fat check if I have hit my number, and then I start fresh. Now, I may drag some prospects from quarter to quarter. But it’s much more discreet in the sense that you could pick me up at the end of the quarter and plop me down on a new product or new territory, and yeah, I’ve lost some continuity on some things, but usually, you give me a little slack for that. And then I sell on what you give me in the territory you give me in the channels that you give me. And so there’s a lot of people leaving at the end of the quarter after they collect their big bonus, their commission check, to go do something else or go do it somewhere else.

 

Marcus: I feel like I’m—I just watched in the last month, Glengarry Glen Ross—“and the leads are terrible!” Or—

 

Rich: The leads—that’s right. And I keep that clip, that brilliant clip with Alec Baldwin who’s in that movie, he’s young and gorgeous. explaining that first prize is a Cadillac—

 

Marcus: Second prize is the steak knives.

 

Rich: Second prize is a set of steak knives, third prize—

 

Marcus: You’re fired.

 

Rich: —you’re fired, right. And I play that clip for a lot of my development teams and my product teams because folks simply don’t believe that that’s how life works on the sales side. There’s such a culture gap. There’s such a perception gap that it’s less fiction than you would like.

 

Marcus: Yeah, and we laugh about it here, and I’ve always kind of smiled at it. But it is an individualistic competition between people. They ra—like they think nothing of the ranking, right? the sales contest that is—

 

Rich: They live for the rankings.

 

Marcus: Absolutely. That is the standard way they—so therefore, and I’m just—the idea of let’s organize our group to work better together, doesn’t matter because everybody’s just an individual over there.

 

Rich: That’s right. And there might be small teams. For instance, there might be a senior sales rep, and a sales development person, and an [SE 00:25:16] as a team, but every sales organization has thermometers on the walls and competitions and spiffs. And it’s all about, were you in the top 10 percent? Did you beat your quota? Did you get to go to president’s club for the quarter? You get the little plaque on your desk. It’s intensely competitive. And so the idea that, for instance, you would have a development team, where we don’t call out an individual and say, that’s the best person on the team. We don’t have the star of the quarter. It’s bizarre. It’s weird. It’s—what do you mean? Because it is—sales is much more of an individual sport. And, we go to such great lengths to keep our teams working as teams, to reward the team, to bring out the team to the escape room, or the pizza, or the trip or whatever it is, to have metrics for the team, to help each other. In the standup say, I need help, is there somebody who can give me a hand? You don’t see that in the sales organization because it’s all personal score.

 

Marcus: Yes. I can’t even imagine a sales stand up. People would just not want to say [laughing] exactly right? To heck with you, buddy. I’m not revealing anything.

 

Rich: That’s right.

 

Marcus: Okay. Well, let me ask this. So, I’m imagining this along a spectrum so here, we’ve got the sales group; very individualistic, lots of competition. It’s an individual sport. And then we get engineering where more and more we’re hearing, and I think a good thing is, software development is a team sport and we want people to collaborate. We have mobbing and swarming, and so where along that spectrum does product management fit?

 

Rich: We get a bit schizophrenic. So, maybe one of the most important characteristics, or skills for a product manager is to vary their language choice from meeting to meeting. And so when I’m sitting with my development team, I need to both sound and act like somebody who fits in, who thinks about the long term, and the next release, and the backlog, and the process, and all this stuff. When I’m that very same person, and I’m in a meeting with a customer, or prospect, I’m mostly talking about benefits, and return on investment, and value, and why they should sign a piece of paper and give us a bunch of money for our stuff. And when I’m talking with my executive team, I’m mostly talking about money. Current costs, future costs, what’s this next release work? Why is that feature we’re going to add going to lead to more upsell, and revenue, and reduce churn. So, there’s this language mush where product folks have to, throughout the day, express the same ideas, and the same goals, and the same metrics, and the same intention in radically different language that matches up against what each of the groups cares about.

 

So, when I’m talking with my development team, I’m always trying to insert motivation. Here’s what I heard from the last customer call, here’s the interviews, how are we doing on numbers and sales, I want to have a recording of somebody either happy or complaining about something in the product because, honestly, my team doesn’t want to hear from me. They want to hear from the real end-users who matter. So, inward-looking, I’m always trying to inject reality, and market sense, and joy, and to be able to tell my team that the work they did was wonderful. And here’s a couple people talking about our new workflow, or whatever we fixed so that they can feel important and successful. But when I’m sitting with the sales team, I’m basically giving them a checklist that says, here’s the five or six qualifiers for our product. If you’re talking to somebody who doesn’t check five of these six boxes, move on and stop wasting your time. Because you’re trying to sell in the wrong place. And those concepts have to match. But the language is entirely different.

 

Marcus: Right. Do the product managers typically work together or—the way you’re describing it, I’m imagining me, if I were a product manager, in the morning I’m with engineering, I’m creating empathy and motivation. Later I’m with the sales team saying this is the perfect market, just ignore people who aren’t in it. And in the afternoon, I’m with the executives. But it’s all me in each place. Is there group work in product management?

 

Rich: There is some, and it depends a lot on your product set. So, if you’ve got five relatively standalone products, and five product managers assigned to those who all work for, let’s say, imagine I’m the head of product or the chief product whatever, I’m going to have five people working for me, and the interactions are actually pretty light because we really only have to get those folks working when there’s shared infrastructure, or competing goals, or one product or pieces going to support the other. Now, but if I’m in a suite, where there’s two or three layers of architecture, and a bunch of enabling technology, and maybe we sell one big block of stuff, but it’s broken up into 15 or 20 value streams. Now, my product managers have to be much more collegial, collaborating, we have to have shared goals. So, in the same way that there’s no one perfect organization for every company, if the company, and the products, and the customers need product managers to be much more collaborative, then we’ve got to force that to be in place because they are naturally solos. They tend to be a bit lone wolf. If you think about parents of kindergarteners right?

 

Marcus: Okay, I’ve got one in my mind. Yes.

 

Rich: Right. I don’t if you’ve ever met a parent of a kindergartner who didn’t tell you that their kid was the smartest, and the best athlete, and the best looking, and everything else, Right?

 

Marcus: Of course.

 

Rich: And when they get a report card back, their kid is not at the top of the class. They’re in, yelling at the teacher. Product management is a lot like raising children.

 

Marcus: Ohh.

 

Rich: Ohh, yeah. You, the parent, have to have a plan when your kid’s born to send them off to university someday maybe.

 

Marcus: Your goal is to get them to leave well.

 

Rich: That’s right, but if you think about the next 18 releases—

 

Marcus: [laughing]. Right.

 

Rich: —and the college fund you have to start now. Put that in protected category, if you don’t start saving for college till your kid’s 16, fewer options. You know that your newborn, your one-year-old, can’t yet play the violin but if you’re going to get your kid to Carnegie Hall, you’re driving your kid to a lot of practice, practice, practice. And so the product manager has to take the long view, has to protect that product from all the outsiders, has to give it a chance to thrive and grow and find its own market. Every product’s different, they’re all going to find their place, but almost all products are terrible in release one. Microsoft taught us that nothing works till release 3.1—

 

Marcus: 3.1, right. [laughing].

 

Rich: —but, if you let your product be shut down because in version one, it wasn’t very good, then you’re not a product manager. I have to defend, and protect, and plan, and it’s never a perfect plan. It’s never right, but how do we find, for some early customers and then some later customers, how do we grow the revenue line? How do we do all the things that we have to do over the long term in the face of organizations that think very short term?

 

Marcus: Yeah, absolutely. Okay, in the last part of this episode, I want to turn back to some of the organizational change things that you and I were talking about because before we hit record, we were having this really interesting conversation. So, I want to loop back and include the listeners. So, one of the things we were talking about was how creating organizational change, or are effective—maybe that’s the better way to say it—effective organizational change is more than just a new org chart, and then announcing who reports to who. So, when you see your clients wanting to make an organizational shift like that, how do you help them think about it in a way that’s more useful?

 

Rich: Got it. Yeah, so let’s take an example that I run into all the time. So, let’s imagine an organization that’s doing the narrow version of Scrum, where you’ve got a product owner, who only does what the scrum book says, which is, is available to the team twenty-four by seven, writes stories, accepts stories, and never ever, ever, ever speaks directly to a real user or customer, gets all their input from stakeholders and proxies, and other four-letter words. And then they also have somebody who’s charged with some kind of product title who looks out at the world and comes up with product strategy, and hasn’t a clue how anything’s built, never has to make an OR choice, assumes the development team is underperforming—because they don’t get what they want all the time—believes that roadmaps are perfect and good predictors of the future. And so, I look at organizations that have this particular split between a product owner and a marketing outward-facing product manager and I observe that they get pretty poor stuff built. If you’re in the software business, that’s no way to behave.

 

So, I come in and say, “Well, we need to merge, we need to have a single person who does the end to end product management job, which is half inward-facing, doing the product owner content or role, and half outward-facing spending lots of time with customers, and prospects, and partners in interviews, and competitors, so that when we write a user story, it turns out to be not just grammatically correct but useful.” If you’re not in the field, I believe most of the user stories you write aren’t very good. So, easy for me to say, “Well, let’s just reorganize everything.” But then you look around and notice that you’ve got 15 teams with 15, prod—well, sorry, 15 teams with 11 or 8 product owners, so we’re already short, and you should have had 15 outward facing product folks, and you’ve got 5. So, we’re short-handed, and most of the product owners don’t have, yet, the skills or experience to do customer interviews, market sizing, business cases, argue down sales and marketing. They are in an order-taking role because that’s how the old IT thing worked, and the outward-facing market folks or product folks are product light, their engineer light, they couldn’t find their way to sprints, and scrums if you gave them all the consonants in the right order—

 

Marcus: But they do think it’s like building a fence, probably?

 

Rich: Yeah, how hard could it be? So, I want to come in and I want to merge those two jobs. But I know that most of the folks in those current jobs don’t yet have the skills, and we’re short. So, rather than fiat from the top, thundering from the mountains and we throw down two tablets, what I want to do is I want to find one team, with one product owner who seems to have the right stuff, who I can coach and mentor, and we’re going to take one team and we’re going to rearrange what they do, we’re going to take the outward-facing market product person and move them on something else. We’re going to take that one, opportunistic product owner and give her or him a bunch of training, and help, and support, and we’re going to try to show over the course of, say, three months that that works better. It’s classic agile retrospective, think about your situation. Because if we simply declared that everybody was in a new job, we’d find that nobody knows what that job is. Most of them either lack the skills or the interest. And everybody’s going to revert back to their old behaviors.

 

Marcus: But Rich, we gave them job descriptions.

 

Rich: Yes, that’s great, and the HR folks tell me that if we write a job description, everybody will read it and understand.

 

Marcus: So, maybe that’s not a perfect solution [crosstalk]—

 

Rich: Not a perfect solution. In fact, in that job description, often you’ll find—you’ll be told that product’s in charge of the what and development or engineering is in charge of the how. Now, I’ve actually never found that to be useful in practice, because they’re deeply wound around each other, and my team resents me when I come in and I tell them how to solve the problem, or what the problem is. We get much better results and much happier people if we collaborate together on making sure we all understand or agree on the problem before somebody writes down the solution. But the HR thing says, “Yeah, yeah, products in charge of what, and engineering is in charge of how,” and that just creates, definitional argument where, if I think it’s mine, I’ll tell you, it fits in my category.

 

Marcus: Right. Let’s back up just—I really like the way you frame this organizational change, you’ll find someone who’s doing something that resembles what you want. You will work with them. You’ll remove the person or the role that isn’t useful in the new way, and you’ll work with them to increase skill and to increase understanding about that role. For example, you’ve got somebody who’s normally facing inward, and you say, Well, you’ve got a little bit of outward-facing thinking going on. You’re really good at this. People seem to see that you’re also, probably, somewhat influential in the organization, so, let’s have you be are—and this little group is where you start that fire. Is that the way I’m hearing it?

 

Rich: That’s right. That’s spot on. I think back to Tom Sawyer. So the Tom Sawyer answer is how do we make it such that everybody else wants to paint my fence? And I think every good development side, agile transformation starts with a couple of groups that do it well, that get good coaching, that gets support, you get protection and umbrellas from above, so that everybody else can look at it and say, “Well, I want to be one of the smart kids. I want to play with the new toys. How come I didn’t get to do Kanban or Scrum or whatever thing we’re doing? How come they got to do this, and I didn’t?” When you’ve done it a little bit successfully with a small team, you can seed the concept, you can share the concept. And now people want to play. I observed that I can’t make anybody do anything. I can only make them want to do the things I want them to do.

 

Marcus: Okay, I have to grok that. I can only make them want to do the things—

 

Rich: That’s right.

 

Marcus: —I can’t make them do the th-, they have to make themselves do the things. But maybe I can paint a picture—I was just taking a course on systems thinking for leaders at Cornell, just last night. It talks about sharing the party photos with the fence-sitters and naysayers, the party photos being like, look how great this is at the party. And therefore you start to say, come on over this party is fantastic.

 

Rich: That’s right because anytime we change roles, or change jobs, or change any of this stuff, there’s resistance, there’s confusion, there’s the need for getting folks along in the right way. As a for instance, whenever I pick up one of these product owners who’s been all inward-facing, they don’t have experience pricing products, or packaging products, or end-of-lifeing products, or rolling them out, or doing migration plans, or there’s a whole stack of things that are going to come up in those first three months, and rather than throw them in the water and see how cold and deep it is, I want to be there to say, “Ah, next week we’re going to spend a couple hours talking about incremental release planning and upgrade planning, because you haven’t done it and you need it. And after we do it once or twice, you will have that skill, and nobody will have to help you anymore.”

 

Marcus: This is a beautiful reason to have somebody like you around, I have a feeling, that you light that fire, and you also enable the organization to get better, and you teach them these ways of self-modifying their structure.

 

Rich: You bet. For me, this is fun.

 

Marcus: Yeah, that’s really interesting. Rich, what else is on your mind right now? We’ve got a few more minutes. Let’s find a last quick topic here.

 

Rich: A challenge that I face every day that I was just on the phone with yesterday, somebody about, was professional services organizations versus product organizations—

 

Marcus: Yes. I have some—

 

Rich: —and let—

 

Marcus: —comfortability. Yeah, I have some experience with both.

 

Rich: And let me define carefully what I think I mean by that, which is a professional service organization is one where individual clients come, show up, or the sales team brings them in, and they have a thing they want you to build, and you build it once, and you charge them more than it cost you to make it.

 

Marcus: That’s profit.

 

Rich: And we call that margin or profit. And then the next thing comes in and we blow up the team and we put a new team together to build the next thing somebody wants. And so it’s a sequence of one-off custom, sometimes they say bespoke, right?

 

Marcus: They do like to say that these days.

 

Rich: That’s right. And the way you make money is you keep your technical team busy and billing. And there’s never been a project that came in the door that we said no to because the way we make money is we hire more people, and we put them to work doing whatever individual clients want us to do.

 

Marcus: And we call that a scalable or elastic workforce.

 

Rich: Okay, good, great. Now there’s a name for it. In the product game, we do exactly the opposite. So, the goal of a product is that we build it once—and let’s pretend it’s software because that’s where I live—we can—and by the way, it cost us $5 or $10 million to build that first unit, but the second copy we sell costs us nothing. And the third copy costs us nothing. And so, in the product business, it’s all about finding a price point that the market wants, figuring out what the breakeven is. Okay, we need 100 customers to break even. The hundred and first customer is almost 100 percent profit, but what that means is we have to first do our homework. And so professional service organizations don’t have product managers.

 

Marcus: No, and they don’t have homework. They’re mercenaries, they are hired guns.

 

Rich: They’re mercenaries, right. And so they have project managers who make things deliver on time. But if you want to give him $100,000, or $500,000, to build something, the answer is yes, right?

 

Marcus: That’s right.

 

Rich: In the product business, it’s the reverse. We don’t want to start building anything. Unless we know there’s 100 customers for it. And so we can’t take any one customer’s word for that. We have to do our homework, we have to do our research, we have to do our market sizing, we have to see what the competition’s doing because we’re going to charge less for each copy than it costs to build it. Because that’s how the software product business works. And so it’s all about volume, it’s all about resisting one-offs and specials. It’s all about keeping people in a small number of packages or prices, single units, because we need to sell 100 or 1000 or 100,000 because that’s how you make money in the software product business. But that’s a tremendous—conceptually for folks in the services side who think they want to get into the product business, because they put a product team together. And then a week later, some new project comes in and we say, oh, we’re just going to borrow a couple of those folks for just a few days,

 

Marcus: I have literally done this. Literally at my company, and we tried for years and kept getting, quote, “interrupted” with paying customers waving dollar bills at us.

 

Rich: That’s right. And either of those models is good. But the intersection of those models is a failure.

 

Marcus: It’s terrible.

 

Rich: It’s terrible.

 

Rich: In fact, the only way we—we actually released an iPad product—the only way it happened was that our biggest customer unexpectedly disappeared. And we had this wonderful mobile engineer, and we said, “Well, we bet some more work’s going to come along,” and we were able to fund that person working for four months, and then release a small iPad project uninterrupted, but had anything come in—

 

Rich: That’s right. And if you have a mostly services company, and you’re trying to build something big, it’s going to take a team of nine a year to do it. And then, just this once, every Tuesday, Thursday and Friday, we borrow just one or two people from the team—or maybe all 10—everywhere I go, I see the same pattern playing out, where we think we’re in the product business, but we’re not.

 

Marcus: Knowing what business you’re in, I’ve found, is extremely important, and not falling for the grass is always greener fallacy because you’re right, both businesses are great, and you can make a lot of money, but if you get confused, it’s death.

 

Rich: That’s it. And so I’m always encouraging folks who want to get in the product business to find a partner company that’s in the services business. So we can do the product work, and we can throw all of the hourly and project work to our partner. And they get to make money, and we get to make money. But we have very radically different organizations, managed differently, goals differently, hired differently. I can look at an org chart and tell you which of the two kinds of companies you’re in.

 

Marcus: Mm. Fascinating. Okay, you heard it first; if you’re trying to be both, stop it. [laughing]. If that’s all you walk away with if you’re a product company and you think, “Let’s offer some services,” or you’re a services company and say, “Hey, we build products for other people, let’s just do it for ourselves,” just don’t do that.

 

Rich, it’s been a real pleasure to get to chat with you today. Where can people find you online and engage with your work?

 

Rich: I’ve cleverly gotten a domain name that’s the same as my last name. So, I’ll spell it because it’s hard M-I-R-O-N-as in Nancy-O-V, as in Victory. So, I’m at mironov.com, and I’ve cleverly taken the email handle rich@mironov.com.

 

Marcus: That is clever.

 

Rich: So, easy to find, and there’s 18 years worth of blog posts and videos and tools and templates on my website, so everybody should take that and just grab whatever is useful.

 

Marcus: It is a treasure trove, absolutely. Thank you so much for being on the show with us today.

 

Rich: I loved it, thanks for letting me join.

 

Announcer: Thank you for listening to Programming Leadership. You can keep up with the latest on the podcast at www.programmingleadership.com and on iTunes, Spotify, Google Play, or wherever fine podcasts are distributed. Thanks again for listening, and we’ll see you next time.