Great. Thanks so much, Steve, appreciate the chance to join in and have some fun.
So I first came across your work at a conference called the business of software conference. And at that speaking engagement, you gave a talk on a four part blog post that you had posted called the Four Laws of software economics. And at the time, it was a profoundly important discovery for me as a software CEO. And you know, five, six years later, I still find myself regularly revisiting that four part blog post. So even though there's a ton of content to cover as briefly as you can, can you please describe to our listeners what those four basic laws of software economics are?
Sure, and I'm so glad that worked for you, you know, sometimes we write things or do talks, and they don't land that one seems to have helped to to have been of use to folks, let me just recap the first two, I think which the first one that seems really important is that our development teams will never be big enough. This seems like it's contrary to, you know, fact or opinion, but I've never met a development team that could do all the things that the executives and the customers and the product managers and the sales folks in the marketing folks wanted, it's impossible, we can think of things that we want our software team to build, you know, 10 times 50 times 1000 times faster than they can ever get anything done. So that's important, because it means that, as executives and as product leaders, we must must, must be really willing to be ruthlessly prioritizing what we're going to do, because 90% 95% of all the requests aren't ever going to get met. That's uncomfortable. But it's the starting point, I think, for everything that product managers do. And the other one that was probably most relevant for folks who were software CEOs is that in the software product business, where we're trying to sell the same bits over and over again to lots of people, all of the money that we make all the profitability, all the goodness isn't in the first customer or the first copy, or the first seat that we sell, it's in the "nth" one, right. So if you built a great ERP system, you make money, because the first 10 gets you to break even, and the next 1000 are all cash. If you're in the airline seat reservation business, you know, the first seat doesn't matter, it may take you 10,000 seats a month to hit breakeven. After that. It's all profitability, and it's all margin. So when we're thinking as strategic product folks as software CEOs, for me, it's all about the volume, the uniformity, how can we sell or deliver the same bits over and over again to lots of folks and not rebuild them, not do special work, not do custom or professional services. The word I hate most i think is bespoke, right? If you're in the software, product business, you got to build products that a lot of folks are going to want in nearly identical form. If you're in the software services business, honestly, people pay you to build whatever they want you to build. And if it's useless, that's okay. But you don't make any money on the second copy. You have to you have to charge enough in the services business to make it all back on the first one.
And so that has to do with I believe you coined the term "build once sell many times" as opposed to build many times and sell each of them once.
Oh, that's not mine. That I mean, I think we're going back to the 60s on that. But certainly, I've made an effort to push that phrase, right? build one sell many. Because the most expensive thing you've got is the development cycle and the expensive people building the stuff.
Right. Right. Okay, awesome. How about laws three and four?
Um, I don't think they're so relevant. You know, what one is that you can outsource your strategy. So, you know, the idea that you're going to pick up a Gartner report or something from McKinsey, or read it in the Wall Street Journal. And there's a trend, I think it's really easy to as an executive to think you can hop on that train or that bandwagon, and nobody else is going to notice. The real answer is every single one of your competitors has all the same data, all the same reports and futures. And you have to figure out how your team your market, your focus is going to be different is going to have some advantage. You know, what is what is your talent pool have that the other folks don't have? What focus do you have that the other folks don't have? Because there's very few really new ideas. The idea that you folks are going to invent something entirely fresh in the in the world that the universe is never seen. Pretty Long odds.
So let's let's dig in. Because I agree with you that that kind of law one and two are the ones that are, are of particular interest. Let's let's kind of dig into number two first. Every software CEO listening to this, including myself, and I still have the scars on my back to prove it, has encountered a situation where a large sales transaction is pending and is close to closing. But the customer needs just one little thing. In fact, at my company, we refer to it as "JOLT", just one little thing. And we tried to minimize JOLTs as much as possible. But in the real world, as you know, those happen all the time. Does law number two suggest that you should say no, every single time? Or does it suggest a certain framework, if you will, or a series of questions that CEOs should ask to figure out whether or not this is something that we should kind of blindly say no to? Or is this something that maybe we should think about accommodating?
Well, I'm an enterprise guy as you are Steve. So and in the enterprise space, we're always going to make some concessions sometimes, occasionally, for big customers to close big deals. So the idea that we're going to get all huffy about this and decide that there are no specials and that big customers aren't entitled to anything, I think is ignoring reality. But but the the other side of that is that it's really, really easy. And I've seen it dozens of times, to fall into this sort of self congratulatory or self explanation model where we convince ourselves that what, you know, JP Morgan Chase wants or British Telecom wants, or ford motor company wants is really what the market needs. And and part of that is is just recency bias, part of that is our deep desire to not believe that we're doing something special. But maybe the biggest part of that is to remember that our sales teams, our enterprise sales teams are strongly incented, to convince us that that's something that we should put into the roadmap, in spite of all the good reasons, right. And so part of my job as the head of product, if I'm the head of product, is to be the opposite side of that, to be deeply skeptical of nearly everything that my own enterprise sales team tells me about why this is important. To really run the numbers, questions, you know, that a CEO wants to ask, our has engineering has engineering and product actually sized this work? And believe it's small? Or is this the sales team telling us that either they know it's small, they believe it's small, or if they lie to us and tell us it's small, somehow we'll approve it, right? The the folks who are going to do the work are in fact, the engineering and product folks. And if they haven't lined up, you know, on my side, if I haven't stood up and said, Yes, done our due diligence, it's really small, then we very quickly end up in this place where we take our roadmap, and one piece at a time we chop it out for the next special item for the next special deal. So you know that that's the, that's the syndrome, I see. The other thing I think is really important here is in an enterprise sale, we know it takes months quarters, sometimes years to close that deal. So there shouldn't ever be a surprise. If If you know big customer x, Deutsche Telekom is going to hold us up, you know, at gunpoint for some special security protocol. We should know that six months in advance, maybe nine, right? The idea that this is an emergency, I think is a failure on all sides, but especially on the product management side. Because we should have the time and you know, a week, six weeks, whatever it takes to go deep do the investigation, figure out how hard it is. And even more importantly, maybe go out to a bunch of other customers and see what demand is for this in the broader customer base. Because the individual account team that's calling on that one account, doesn't actually work with many other accounts at the same time. And they're strongly incented to tell me as the head of product that everybody wants, what this one customer wants. So you know, so as an executive, you know, how does the executive team resist the general urge, say, "Oh, yeah, can't be that big. It's only $20,000, whatever, whatever. We're just going to wave it through". As soon as the executive team establishes with sales that sales can get its way without any counterbalance. Then generally the whole roadmap is gone. And our plan for innovation and maintenance and growing the markets is gone. And we're in a body shop mode, we're in a bespoke mode where sales teams, you know, write things into contracts.
Yeah, that's such a good point. I mean, this happened to us so many times. And to be honest, I'm not sure if we managed it particularly well. I mean, what ended up happening with us over years and years is that there was, it's hard to find the correct word. But maybe I would say an unspoken degree of conflict between our sales and product management teams and members of each respective team likely felt that their respective incentives were misaligned. So, you know, maybe this is potentially an unfair question for you. Maybe this is a question better suited for a sales professional. But have you ever seen a sales VP, create some sort of incentive structure or incentive alignment structure, So that the sales team doesn't put just one little thing a week before, you know, closing? Have you ever seen anyone create incentives that would prevent a salesperson from doing that?
I have actually, and I've done that myself in partnership with my sales VP, partner, right? So I think putting this on sales is inappropriate, right? So we, we pay our head of sales to maximize current quarter revenue every quarter. And if you know, if he/she doesn't bring in the numbers, we fired them, right. So I think laying this on sales entirely is probably wrong. On the other hand, putting it at product or engineering's door, you know, without the political support of the rest of the executive team, this is never going to happen. So So things that we might do, and in fact, I have done. So one of my companies, I had an agreement with the head of sales, that every quarter, he would get one engineer week, for whatever he wanted, right? So so one time during the quarter, he could come to me and say, Hey, we need this thing. It's small, it's, you know, I believe it will take one engineer less than a week or two engineers a half a week, whatever it was, and every quarter, he was entitled to one of those. Part of that, what we did was, we had a little token, in this case, it was actually an empty shell casing, because we had a joke about it being the magic bullet for the quarter, right. But the essential activity was that when he came to me and said, this is the thing I want to use my magic bullet on, I took from him the little physical token, and I put it in my desk instead of his desk. And that was important, because throughout the quarter, it would turn out that he like all salespeople would forget that they've spent their magic bullet. So in week two, he made the choice. So week four, he looked in his desk, and that token was gone. Ah, okay. And, and the reason that was helpful was because the VP of sales or the worldwide sales revenue officer, whatever it is, is incented to maximize revenue for the whole company, right for the whole quarter, not just one deal. And that let me take all of the interrupts coming from his/my enterprise sales people, I could send them back to him and say, Well, if this is really the biggest deal, this quarter that needs one week of engineering, and your boss, the head of sales agrees with you, because who's on that weekly pipeline call and who knows which deals are real. And you know, which of the sales people are telling what stories? I didn't have to adjudicate that I didn't have to sort that I could send people back to their boss, and whoever could convince him that that was the right way to spend their one week of engineering. Great. And the incentives are now lined up. And and we carefully set that up so that it wouldn't consume the whole roadmap. Other things we can do, or one can do on the sales side, you know, late breaking requirements, maybe we don't pay full commission, right. So let's think about the only thing that matters most to sales reps is how we're going to comp them. So if we tweak the comp plan to say, you know, big enterprise deals need to have all of their requirements and items in 65 days before signing, or you lose a quarter of your commission. I think there's a lot of incentive for folks on the sales side to really dig in on what these interrupts are going to be, instead of waiting until, you know, two days before because because that's a great hostage situation, right? Here's the biggest deal of the quarter, I just found out that they need teleportation added to the product. And that's not so hard. It's probably only 10 lines of code. So I wrote it into the contract and it's two hours before end of quarter. Are we going to miss our number or not?
I love the physical token that represented the magic bullet as a visual reminder that he'd already kind of spent his magic bullet and, you know, look, people do what they are incented to do. So you add incentives to incent behavior and you take away incentives to disincent behavior. And the idea of impacting commission is a really interesting one. So let's move to you know, I think what a lot of software companies struggle with, which is prioritization, how do you prioritize features, functions, products, and this, this kind of speaks to law number one, which is your development team will never be big enough. So in your experience then, knowing that that's true, what are some best practices that product management teams should implement into their process? So for example, we used checklists for feature requests. Are there monthly or quarterly prioritization meetings, are there business case templates, are there blocks of developer hours that are untouchable? What are some of the mechanical things that you see as best practice for prioritization?
Yeah, this is this is a hard problem. And it's a hard problem, I think, because it's not simply a mathematical problem. And so, so we could have an infinite number of checklists, or ROI spreadsheets or calculators. And first of all, that that's going to be sort of lopsided for how the business works. And, and there's a lot of incentives for everybody to inflate their numbers. So I usually back up and ask maybe a more strategic question. If we think of our, if we think of our engineering investment as an investment portfolio, right, we got 20, or 50, or 790, developers and designers, whatever it is, right? If we think of their work as a pie chart, classic and you know, sort of financial investment model, generally, what I'd look for in an enterprise company is about half of what we spend out of engineering is going to be visible features, that real customers are going to ask for and notice and care about. So those are, you know, all of the things that come in on the sales side, most of the things that get voted up on you know, user boards, all the tickets that come in, they want a new workflow, they want a color change, they want some new reports, whatever it is, I expect about half of our points or engineer weeks, whatever we're counting is going to be on things that customers actually asked for. And about, I don't know, 30% to 35% are the things we have to keep doing to stay in the software business that customers assume and don't ask for. So scalability, security, failover, you know, data backups, you know, technical debt, reduction, fixing bugs, there's a bunch of things that honestly, if your customers are calling up and complaining about the scalability of your back end transaction system, well, you're a year late fixing it. Right. So we've got the biggest slice is visible features. The next big slice is infrastructure, tech debt quality, etc. And then the last two bits, the one is product, particularly, but the engineering team as a whole should be doing real discovery and validation, testing new ideas, bringing prototypes out, etc. That's probably between five and 10%. And then what's left ends up in the enterprise business being the "specials", right? So the, the one off the deal closer, the fingers crossed, everybody wants it. But it's really only for General Motors kind of thing. When I see that get above maybe 10%, I really worry about the health of the company. So now that we've divided those into slices, now we can figure out who the stakeholders are for the different pieces. So on the tech debt and quality and infrastructure side, I'm much more likely to look to my tech support or customer success team for the things that are tripping up current customers and getting folks on board. Because that's going to go into that slice. Whereas on the feature side, I'm much more attuned to what sales and marketing, say partners, customers, surveys, other inputs. And that lets us make trade offs sort of within categories. The thing I worry about most here, and if I take a quick side trip for a second, a lot of us tend to overeat in the December holidays, we join gyms in January to get the weight off. And then by March we realize we've never gone to the gym. And, and it turns out that there's no health benefits to joining a gym. There's only health benefits if you go to the gym and workout and sweat. Right. And the reason that's relevant here is there's always this drumbeat that in the current quarter, we're short on revenue, we got some big deals for just this quarter. Just this month, we're going to steal from the infrastructure side, we're going to steal from the quality side, we're going to steal from discovery and validation, just this once and put it all into features, we need to close deals. And that becomes a habit right away. And we discover we got tech debt up to the ceiling, because we had a strategy for how we're going to spend our engineering, and then we're not following it, because we're, they're shiny objects. So within that, anyway, now we can apply some good ROI tools, market research, weighing one account off another or segment against another for the half of the spending that's on features. And, you know, so we're gonna bring a lot of those classic tools in, what's the size of the deal? And, you know, how big a special is it? And can we open up some new segment or geography or language group by adding some new features?
So in terms of getting that feedback, I mean, you know, speaking incredibly broadly, I suppose there's two ways to solicit that feedback. One is through talking to customers themselves, which of course, is kind of always first prize. But option number two is to solicit feedback from internal stakeholders, groups, like sales or customer success, or any any group who's you know, customer facing more broadly. I've seen some companies utilize various product management tools to allow internal stakeholders to vote, they will give a thumbs up or thumbs down to features that have entered the bucket of things that we could work on. Now, you know, companies who use that say, hey, these folks, you know, they might not be the customers themselves, but they are effectively the internal voice of the customer, therefore, they are best suited to vote on these. Yet, as we've already discussed, at times, different internal groups have different internal incentives. So are you generally in favor of having internal stakeholders vote and have a voice on features and functions to be prioritized? Or is that solely within the realm of the product management group.
So I'm all up for voice, I'm all up for contribution and suggestion. And to the extent that we say vote means that group has ordered a list that they're going to bring forward and negotiate on, I think that's fine. Um, with one exception, I'll call out in a sec. I'm completely against voting where the voting enacts something where because it got voted up, it gets in the plan, there's, again, tremendous incentives for abuse here. And if we look around the company, what we'll find is that each group has its own completely expected sampling bias. So if you're in the support organization, and you're taking calls from current customers, your deep and obvious sampling bias is the only people who call you our current paying customers who have big issues that are big enough to annoy them to open up a ticket, right. So on the support side, of course, you miss everybody who didn't buy, and everybody who's not interested, and every new segment you're considering. And it tends to be kind of feature level, some feature level, I want to move these these columns on the report stuff. So those are critically important, but they can't be your whole diet, right? It's just, you know, chocolate cake. On the sales side. If you split new account sales from renewals, for instance, the new account teams are only sampling customers who haven't bought yet. And they're heavily weighted toward the few largest accounts, whereas the renewal folks are not talking to those people at all. They're talking to current customers, who are much more legitimately involved in the products and know what they need to stay, but also know that they can hold hostage their renewal rep by asking for something that might not be in there. One last sort of vote up thing, if we go to those sort of internet boards, where all of your users get to vote things up. Really good source of input, really good source of insight. But the sampling bias is it's almost all either massive enthusiasts who love your product, or people who hate it. If you look at, oh, any of the movie review sites. Almost all the reviews are either one star four stars or five stars, right? Because if you're gonna give it a two or three stars, you don't bother reviewing the movie. Right? So it's important as we go around the organization to note that every single group has a strong sampling bias and strong incentive, that's going to lead them in a different direction. So somebody has to actually be the neutral arbiter be the, you know, the, the independent thinker here, who's got the whole product in mind, and that's product management. There is one group that I I almost always give votes to. So if we go back to the support team, what I'd say to them is you guys You can order your bug list any way you want, we'll fix the top three or four that you give us, regardless of what they are. Because you guys are on the frontlines, you have no incentive to lie to us. It's all about reducing tickets. If one of those is really hard, then maybe you only get one fixed, but we'll spend, whatever our units are right 116 story points a quarter, fixing whatever bugs you guys think are the worst, we're going to reduce your overhead the most or reduce the calls in the tickets the most. Because honestly, it's directly aligned with the company to reduce that load and to make people happier.
Sure, let's move on to hiring. If you are a CEO, and let's say you're looking to hire an a product management leader, whatever title that person may have, that the head of your product management group, what are what are some things that you're specifically looking for in that interview? And perhaps, you know, what questions might you ask to tease those things out? And the reason why I asked this is because product management is such a multidisciplinary part of any software organization, these people need to be good, you know, they need to have a reasonable brain vis-a-vis technology, they need to have a reasonable brain vis-a-vis business, they need to be able to put together a quantifiable business case, I mean, there's a lot of skills that comprise a good product management professional, so you're CEO, you're looking to hire your head, you know, what specifically are you looking for, and maybe what are you asking that person?
Sure. And, again, if we step back just a moment and ask about the strategy here, there's a failure mode, I see not everywhere, but you know, good half of my 170 clients over the last couple of decades have fallen into a problem where the person they hire, as the head of product, VP, product, Chief Product officer, whatever it is, turns out not to be a product person. And, it blows my mind. But everywhere I go, I see this, which is, you know, we took somebody who's really good at sales, or engineering or finance or something else. And we kind of figured that the product job wasn't so hard, or we didn't think about the fact that the product job is hard and special. And so the person we put in charge of all the product people and getting the right things built, turns out to have zero product management experience. And I'm embarrassed to say it, but there you go. Now, as a CEO, you'd probably never hire a VP of sales or worldwide revenue officer, who hadn't carried a bag for a long time knew what quota was, could manage a sales team and could bring in the money. You probably wouldn't hire a CFO, who wasn't familiar with, gosh, how we cover payroll and you know, and taxes and how much money we have in the bank, and, you know, terms and conditions for raising money, you wouldn't do that you wouldn't hire a VP of engineering, who hadn't built a ton of software in a career. And, you know, but instead said, Oh, software's kind of cool. I'd love to be in charge of a software team pick me mom. Right? But, but here, we see over and over again, that the first the first instinct is to hire either somebody just like the rest of the executive team, or somebody who's really good at a thing that's not product. So, you know, that's the big red flag. So within that, you know, what are we looking for lots of questions, um, you know, tell me how many products you've launched, and how big a team you've run, you know, if somebody hasn't actually managed a team of product managers, then they're not a head of product, right? Make them an individual contributor. But I wouldn't hire anybody as the head of product who hadn't run a product team of a similar size before. Then what are we looking for, we're looking for, you know, good organizational skills, we're looking for humility, we're looking for somebody who thinks really, really hard about how to match what actual customers are actually going to want out of the product with what we're building and engineering. So questions I'd ask, right, pitch me your last product, you know, whatever you were working on most recently. And and I'd be listening really carefully for their connection of why customers buy, how you know how customers measure value. Is this a product that's supposed to you know, reduce effort or increase sales or get the assembly line running faster, or, you know, pick and put items off of the assembly line in the factory faster, whatever. Product folks must be able to describe why customers are going to buy something, and how they're going to measure success. And then they have to be able to tie that back to whatever crazy cool technology got built. So that those things match. So telling a story about how Oh, my team built machine learning this, and AI, that natural language processing is great. But you're out the door unless you can explain why that really delivered value to customers in a way that, you know, traditional software didn't, or, you know, you're in the network security space, you better be able to explain how your stuff is better from a customer point of view. So, anyway, that's a long answer, but trying to tie together, what they built, why they built it, who was for and why it made money, right? I mean, it seems obvious, but you know, what's the economic case for it. And then, the other thing I'm usually probing for, because nothing worse, nothing more toxic than Chief Product officer who's too self important, and thinks that they get to make all the decisions. They might, but you know, they should never say it. So I'm always trying to probe for instances where the head of product was humble, and a good partner with the other functional groups. You know, as a head of product, I never want to throw my VP of engineering under the bus, right? I always want to be explaining that sales is really important, because sales brings in money, which nobody else does, you know, I should have an appreciation of what marketing does and why it's important where it interfaces with products. So, you know, probe for situations where there had to be compromise, or were not everybody got what they wanted, which is every situation. And I'd be listening really carefully for the "we" word, right? We did x whenever it was a successful outcome. And the "I" word for when it didn't write good product, folks will say, you know, I probably made the wrong call on that. But we as a group executed well, gosh, that's a phrase I love.
Now, one of the variables that a lot of CEOs consider when they're hiring, either the head of product or perhaps a head of product, hiring an individual pm is this balance between prior experience in that same industry, or, you know, generally being a good athlete as it relates to product management. So assuming that it's very hard or very rare to find someone who has both domain expertise and product management expertise, as a CEO, how do you think about kind of weighing those two options when hiring, let's say, your product management leader? If I'm selling, you know, software to trucking companies, which is what I used to sell, how important is it that I hire a head of product management who has sold software to trucking companies before?
Yeah. Hard, hard problem. And and yes, if you're looking for heads of product who've worked at companies that build trucking software before, you know, there's only three of them, and you know, their names, right. So I would back up a little bit and say, I believe that the product management skills are 10 times harder to learn and grow than the particular market and subject area. But there's some adjacencies. So I usually draw a pretty big line between b2b and b2c. So folks who do b2b Enterprise are pretty different and think very differently from mass market consumer, you know, you're working on, you know, consumer audio equipment, or dating apps or travel sites, you're working in, you know, 10s of millions of people per day, and the science is pretty good. In the enterprise space, you might be closing, you know, 11 or 41 accounts a quarter. And the politics is very different. The, the tools are different. So I'd say, you know, imagine we were building for trucking companies, I'd look for anybody who had good solid product leadership experience in some near related field. So ERP, you know, network security, anything having to do with logistics, I wouldn't get stuck on trucking. But I'd stay away from, you know, if you're doing streaming video stuff, it's gonna have very little to do with this the sort of business heads down, stuff that you find the trucking area.
So as it relates to the head of product, let's so we're talking specifically CEOs here who manage rather small businesses, so we can define that, you know, let's define it as from a revenue standpoint, 30 million or less, you know, size of pm team? I don't know, 10 or less size of developer team. Yeah, no, I don't know. 30 or less something in that ballpark. Right. How involved as a CEO, how involved should your head of product be in the day to day of product management? Do we expect this person to be you know, writing user stories and gathering requirements, or do we expect this person to be managing the people who are doing that? Because though it sounds like a potentially simple question I know a lot of CEOs struggle with, to what extent Am I asking my head of product actually roll up her sleeves herself and actually do the work on the ground?
Yeah, and I think that's entirely about size. So let's, let's back into how big the product team is first. So, generally, you know, my thought, my advice is, you need one product manager for every something between eight and 10, of what I'd call makers. So that's developers, designers, tech Ops, testing, folks, whatever, right. So if you count up, everybody who's actually building the things that go into the product, if you've got more than, say, nine to one to your product team, your product managers are gonna fail. So if you had an engineering combined team of 30, then I'm gonna guess you have three product managers and one head of product one, Chief Product, something at that rate, there's a lot of things to do that the head of product does that are not on the ground writing stories. And and I'd suggest that unless there's a an open position, you know, we're trying to hire your head of product isn't sitting in all the stand ups, your head of product isn't writing user stories, your head of product isn't actually even doing very many, or any end user interviews. But is, you know, hawkishly looking over the backs of those three product managers to make sure they're doing those things. And, and key activities for the head of product are, you know, making sure that there's a portfolio theory. So, you know, each product manager is going to want to steal resources and, you know, get their piece of the product best. And it's a little bit like, you know, if you, if you go to the kindergarten, every parent believes that their kid is the smartest best looking and is going to be the biggest athlete someday, right? So product managers are deeply emotionally tied to whatever piece of the products that they have. So there's a lot of portfolio level settling of issues. And, but but the other key things that the head of products doing back to prioritization back to sorting out how we're going to resolve issues, and is really the counterweight on the executive team for all the product issues. So pricing, go to market strategies, partnered with marketing, packaging, sort of adjudicating all these special cases where we got to do something special. Really, the products executive is an executive first, I think, with a small team of product managers has to know how to do those jobs and mentor and coach, particularly if you hire somebody in who's a first time product person, honestly, they don't know how to do their job. So somebody has to teach him. But I wouldn't expect Well, at a company. Let's see, if you have 30 folks in development, it's probably a company of 60 by now, right? Yep. So at a company of 60, a company of 50, or 100, the head of product should be the voice of product and the representative, in the same way that the head of sales, mostly doesn't close deals, I hope, except except in those special cases where they need that.
That makes a lot of sense. How about, how about the CEO? So the question is, how involved should a CEO be in product, and I'll give you some context. So on one hand, there's a set of old adages that say something to the effect of the CEO knows the customers better than anybody, the CEO, you know, let's call it a CEO/Founder knows the market better than anybody, they're very close to the customers, they should be the company's best salesperson, etc, etc. And yet, on the other hand, there's a long road of CEOs who have had pet projects that, because they came from the CEO or Founder, were not subject to the same rigor as other requests. And those CEO pet projects kind of failed. So as a CEO, it's very difficult to kind of evaluate yourself, because presumably, all the ideas that you come up with are the great ideas. So how involved should a CEO be in product? Should they, for the good of the company, kind of stay out of it, so to speak, or for the good of the company, should they be deeply involved in?
Not surprisingly, I'm going to tell you, I'm going to take someplace in between those, right. So clearly, if we, if we go back to the founding of the company, you know, it's the CEO and some technical founder and maybe a couple other folks. If their original idea wasn't very good, well, the company never got to the stage, right. So there's, on the one hand, there's greatness, there's goodness in the fact that we got to be a 30, or a 50 person company, or $10 million company, whatever it was, on the backs of the best judgment of the founding team, right. But the survivor bias there is that we believe, based on that, that we were smarter than everybody else. And what I see instead is at least on the Silicon Valley side, you know, we spin up 1000 companies a month, or whatever it is, and almost all of them fail. The ones that succeed don't necessarily succeed just because the CEO is smarter. Right, there's a lot of luck involved and being in the right place. And that's a hard message for CEOs. Because, you know, we want to believe that, that it's our own, you know, our own steam and our own hard work that got us here. So, so what I'd suggest is, CEOs actually do talk to a lot of folks, they do have really good opinions. But, you know, how do we restrain ourselves so that we're proposing those things as ideas or suggestions, instead of demands? I yeah, Everywhere I go, I see that the CEOs pet project wasn't well thought out, wasn't well grounded. And nobody's allowed to say no to the CEO. And so we're doing it. And you know, there's a third of our engineering for the next three years sunk. That's really hard. The other part of that, and let me come back to sampling bias for a second. Yes, of course, the CEOs are talking to customers all the time. But there's this illusion that they're getting a representative sample. And I see that as completely wrong. So once you're at a company of 30, or 50, or 60, people, the CEO is getting a very small subset of input, they're hearing from the largest deals that the enterprise sales team believes they can push across the line. They're hearing from the largest customers who have a complaint. And they're hearing from the largest customers who are up for renewals, right? That's the, that's the sampling bias that CEOs get, which means they're not hearing from the rank and file customers, they're not hearing from the 1000s of smaller customers who just want more usability, they're not hearing from market segments that are uncovered, right, they might have dinner with somebody who tells them about some new market opportunity. But that's the complete opposite of thoughtful, analytic research. So, you know, as a CEO to do a little introspection, and identify that you're not getting a uniform sample. And then based on that, you know, you're welcome to have lots of suggestions, which ideally, the product team takes very seriously, chase down, do the analysis, do the market research, talk to 25 more customers. Is it a good idea? If the CEOs idea, well, then by definition, we give it more weight. But, you know, half the time, they're good, and half the time they're not.
In terms of these ideas, you know, obviously, every software CEO is familiar with the concept of a roadmap, or or at least, at least they should be. I want to ask you how long into the future, do you think a roadmap should go out? Because on one hand, if you've got a rather short roadmap, that might be disadvantageous, because you aren't able to provide the long term clarity that external stakeholders like customers might want. On the other hand, presumably, your certainty of execution is higher in the near term, and you recognize the fact that, you know, the further out you go, the less certain your assumptions become. On the other hand, if you have a long roadmap, you're able to provide that clarity to external stakeholders. However, the further you go, kind of the more and more it's written in pencil, because, you know, you simply don't know what the world's gonna look like, you know, x months, certainly x years from now. So how do you balance that? And how long do you think a roadmap should go out into the future?
Yeah, it's, it's a funny problem. In fact, whichever edge we pick, you know, we're going to kick ourselves later. Because if we have a really solid locked down three and a half year roadmap, the very next day, in the executive session, we're going to talk about some new need or some new opportunity or customer. And we're going to berate the engineering and product team for not being agile enough for not being, you know, right to move with the day. And then the day after that we're presenting to some huge customer who, for reasons that nobody really understands, wants a 10 year roadmap, right? And we're gonna berate the product and engineering team for not having a solid enough 10 year roadmap to close the deal. So, you know, rock and hard place by the way rock and hard places the definition of the product management job, but and timeframes vary a little bit. If we were in The pharmaceutical business and we're inventing new drugs. You know, honestly, the roadmap is five to 15 years long, because that's how long it takes to get FDA approval. But, you know, enterprise space, what I'd say is, I really like a roadmap that's got, oh, 90%, you know, likelihood for the current quarter. And let's say 65 to 70% likelihood for the one quarter out and, you know, vaguely 40, or 50% ish for the third and fourth quarters out. And next year, is pretty speculative. Right? So and you can represent that on the roadmap. So imagine that in the current quarter, everything that's shown is in a big black box with heavy borders and full type and, you know, looks impressive. And next quarter, we're using boxes that have lighter outlines and itallics in them. And then the out quarters, we're using dashed lines are pictures of clouds, right. And so, so the important concept, I think, here is that we do have much more near term expectation, believability and prediction. And we've got to have less and less of that over time, because not only does the world change in the market change, but stuff happens, right? So, you know, the, the idea that we're really going to have a three year roadmap that we execute against is mostly fiction, but you can't run an enterprise company, without, you know, some two quarter outlook. So we know what we're launching and how we're marketing it and what we're messaging. A dirty secret, I think here is every enterprise customer demands to see a roadmap, very few of them, I think, actually expect us to live up to that in its exact form. Right? I think of that conversation, as the start of a negotiation. So when we present our two and a half or four year roadmap to an enterprise customer, what do they do? First thing they do is they look for the half dozen things they want from us, they find two of them, they don't find the other four. And so now we're into the negotiation about how they're going to pressure us to add things to the roadmap that they individually want that we took out of that because we're doing something else that's higher value. So, you know, rather than thinking that this is a comfort, a one time comfort to the enterprise customers, I think of it as part of the sales process.
Very interesting. Now, some of the things that we had on our product roadmap, we had the decision: Do we build it ourselves? Or do we partner with somebody else who has already built this feature or function or product? And whenever I had that question, I would lean on both my engineering team and my product management team. And what I kind of came to understand after a while is that anytime I posed the question to the engineering team, it was highly likely that they would suggest that we build it in house. In fact, I don't think I ever got a response that said, Yes, someone else should build that, the engineers kind of always want to build it themselves. But of course, as you know, there's there's there's a million different considerations, and do we build it ourselves? versus do we partner with someone else who's already done that? So what are some questions that you think CEOs or maybe heads of the PM group should be asking when contemplating a build versus buy versus partner type of question?
Yeah, really, really important. I think you hit it exactly right. Engineers are optimists, engineers want to build things. That's why they're engineers. And, you know, given the choice of licensing some existing commercial product or building it themselves, almost inevitably, how hard could it be? we'll knock it out over the weekend. Right? So putting our product management hat on, I think the questions I'd ask are all about sort of unique differentiated value here. So, you know, your product needs to communicate out to users on mobile devices via SMS and text and email. Well, gosh, there's, there's 100 vendors out there, you know, go to Twilio. And you can basically rent that software for nearly nothing. They maintain it, they got 1000s of people, you don't need to spend your time on it. You know, would you build your own database? I hope you wouldn't, unless you're in the database business, right? Would you build your own cloud hosting control panels? Not unless you're in the cloud hosting Control Panel business. So, you know, can users actually see the difference between these? is there is there real strategic value, um, if you were in let's say, the retirement investment portfolio business, then the algorithms you use to decide which stocks and bonds to buy the go into those portfolios is a central part of your business and you probably should build it yourself. Everything else? Not so much.
So is it safe to say that one kind of filter that you would put on this is, "Is this a required core competency in order for us to kind of operate and succeed in our industry?"
I I'd even go further, I'd say, Is this a differentiated requirement? So, you know, there's, gosh, there's 1000s of companies out there that are doing infrastructure for software as a service for enterprise, right. And anything, I think, anything you can license, that's pretty close to what you needed, and puts all the effort and maintenance and growth on that vendor. You know, that's my default. So unless somebody can make a case for why we truly have to do it. So back to like the machine learning thought, again, if we're going to use machine learning, we should certainly have some data scientists who build the models that run our machine learning stuff, cuz that's custom to us. But we don't want to be building any of the AI machine learning tools to run this stuff and sort this stuff and put it up in the cloud. And, you know, there's whole industries full of folks who are doing all the tooling, all the piece parts for almost everything in your stack.
Yeah, yeah, I think that's a great point.
And, and there's a, the other part of it, too, is time to market, right? So remember, before you go all the way back to the the Four Laws here, my team is 110% busy, right? So if we're going to build something that's not strategic, we're going to take something else, that we at great expense figured out with strategic and push it back, and we're going to take six months, and we're going to learn how hard it is the Dunning Kruger effect, where things we know less about we believe, are easier, right? So your, your development team believes it's really easy to build all these things until they get into them. And then we realize why whole companies and industries are putting dozens, hundreds of engineers against something that isn't important to us.
And not only time to market, but financial considerations as well, right? I mean, one can quantify if your partner, you know, so for example, we had a document scanning application, and for the underlying AI based optical character recognition products, our partner charged us, you know, one cent a page or something like that. And we knew we could put reasonable estimates around how many pages how many customers, etc. And then, of course, so we could, you know, quantify that cost reasonably. And then, of course, we can attempt to quantify the fully loaded costs of building it in house, which is engineering hours, QA hours, devop hours, you fully loaded for overhead expenses, plus, you know, probably anywhere between 10 to 50%, "under-estimation" buffer, because, as you said, people are probably gonna assume it's gonna be faster than it is, then, of course, you can quantify the the the cost of each option, I think it's an important step that, you know, I'm embarrassed to say that some CEOs don't make they make it either all technical considerations, or all product considerations, or maybe all time to market decisions, or considerations, I should say, but they fail to put that financial layer on it.
Absolutely. And one last thought there, which is, if you're going out to a partner who builds this for a lot of their customers, which you'd only be one customer, they're able to amortize their development costs, over a lot of customers over a lot of clients over a lot of users. So they may be charging you one cent per page. But remember, back to all the money is in the "nth" page. They don't have to actually amortize the full cost of that development over your pages, because they're amortizing over hundreds or 1000s of customers with millions of pages. So you may never be able to get to the place where your amortized costs are as low as somebody who does just that for their regular business.
Right, right. Second, last question for you, before we conclude. The job of engineering groups, and you know, of product management groups as well as to ship. Right? I mean, ultimately, we have to ship a finished product. There are instances in which software CEOs aren't sure who to hold accountable when products don't get shipped on time. So for example, in my experience, engineering would sometimes blame it on product, they would say the requirements were unclear or there was scope creep, or you know, whatever. And then sometimes product management might blame the engineers they would say, well, that too slow. They built too many bugs, you know, whatever the case may be. As the CEO of product is not regularly shipping on time. The question isn't who to blame. The question is, what process Do you go through to get smarter on was this a product management issue? Or was this an engineering issue or was it some mix of both?
It's it's really, really hard to tear those apart. Maybe it's impossible. And, and I'd say if you're in a situation where the head of product is blaming a head of engineering, and head of engineering is, is blaming the head of product, you've got bigger issues than the fact that something didn't ship, right. So those are two senior folks on your team who at least in public better look like they're working shoulder to shoulder on every issue. They may fight like cats and dogs in private, right? But mom and dad never fight in front of the kids. So you know, organizationally, that's an issue. But But let's let's separate how product adds value from how engineering adds value, right? So the engineering folks are the ones who actually build the stuff. So if we're late on the thing we agree to do, it really falls to engineering, the product choices that there aren't very many, right, so when things run late, and and I've been in the software business for 40 years, I remember a couple of projects that didn't run late, I think, one in the 90s, I'm not sure but right, you know, with the assumption we have is software projects are always 27%. Late, even if you count the 20% write it You're always like, so the product managers choices are few. One is we're going to ship with less feature function, but we're going to ship on time. The other is we're going to delay to get that next piece of feature function done, and we're going to ship late those are, those are the only two choices you have on the product side, because products not in control of any of the engineers or any of the makers. So, you know, if we carefully separate that out and say, Can we ship now with less? What's the implications for markets and customers and revenue? And whatever? Or do we have to wait? And that's the hard product question. I put the head of product on, you know, on the spot there and ask that very question. The how do we make engineering more efficient? You know, are we hiring the right engineers? Do we need better tools? engineering question, right? product folks have lots of opinions, which are not worth more than anybody else's opinions. Really. You know, we should be the cheerleaders for getting engineering whatever they say they need in order to be more efficient, more effective, get more done, but not our call.
Sure, that makes sense. Rich, last question for you today. If you could scream something from the proverbial mountaintops, and every CEO of every small to medium sized software business could hear you and fully digest what you are saying. What would you be screaming from the top of the mountains? And why?
Gosh, give me the mountain Give me the megaphone, right? I think the thing I'd be screaming is that product management's actually a set of disciplines and tools and thinking that you have to learn, that doesn't leap naturally out of your head just because you've done something else well, so if you're trying to be strategic and have real product management, look for folks who know what that is. Because at your small company, you may not have anybody who's either been a real product manager, or has seen it run really smoothly. Don't don't don't grab the random people who weren't fitting into some other role that you hired them for. Give them a badge, send them into the battle as product managers, and expect anything good to come out of it.
That makes a lot of sense. Rich, thank you so much for your time today. If people are interested in finding you online, where should they go?
Ah, clever question. So I happen to buy my last name is my domain name in the early 90s. Before for instance, the Soviet Union was on the net. So so hard name to spell mirinov is MIRONOV. But once you get that right, my website is Mironov.com. There's 20 years of blog posts, and talks and tools there. My email cleverly is rich@mironov.com. That's my Twitter handle. That's my LinkedIn, whatever. I'm easy to find. So just google me. And, you know, the Four Laws of economics are up there in both long form prose and video format. But there's there's probably 250 bits of posts over the years that some of which are useful.
Yeah, and for whatever this is worth to anybody listening. I have listened to almost every one of Rich's talks. I've read almost every one of his blog posts, I've got a copy of his book and there are decades of accumulated product knowledge in there. And business knowledge more broadly and time spent reading his content in my opinion is time very, very well spent. Rich, thank you so much for your time. We really appreciate it.
Oh, it's my pleasure and I'm so glad you're putting this series together.
