Rich Mironov on The Four Laws of Software Economics

“Your Development Team Will Never, Ever, be Big Enough”

Rich is a seasoned Product Guy. He claims that great product people only stay in Product Management for 2/3 years before moving on – he has stayed for 25 years and counting. Reading into that what you may, he literally wrote the book on Product Management – ‘The Art of Product Management’ – and has a wealth of knowledge to offer on the subject of the strategic implications to produce great products.

Rich wrote a new talk for BoS USA 2015 –

The Four Laws of Software Economics

The talk is rich with insight and humour – an hour well spent.

Rich has also written up his four laws of software economics into fascinating blog posts. Keep checking back to see when they’ve been released.

• Part One – Law of Ruthless Prioritization
• Part Two – Law of Build Once, Sell Many
• Part Three – Law of Whole Product
• Part Four – Law of You Can’t Outsource Your Strategy

Find Rich’s talk video, slides, transcript, AMA, and more from Rich below.

Find out more about BoS

Get details about our next conference, subscribe to our newsletter, and watch more of the great BoS Talks you hear so much about.

---

Video

Slides

BoS2015 Rich Mironov – The Four Laws of Software Economics from Business of Software Conference

AMA

 

Transcript

Rich Mironov, Mironov Consulting: Thanks so much Mark, I really appreciate it! My first time here and I built a whole new set of materials so this is the first time for me, go easy when I stumble.

Anybody know who this is? It’s Isaac Newton, that’s right. By the way, contrary to some rumours, I’ve been in the software business for a very long time, now slightly more than 30 years in Silicon Valley but Isaac and I were not personal friends, I’m not that old, too humble to put myself on the stage with him. But we’re gonna talk a little bit about essentials.

So Isaac Newton is famous for lots of stuff! Anything in particular? Gravity!  Gravity is a pretty important thing. In fact, there’s a famous poster that we’ll see in a little bit that says “gravity is not just a good idea, it’s the law.”  And seemed like it’s a good inspiration for me, we won’t get to those levels of sophistication but it’s a start.

In fact, here’s that poster from the early 1980’s. I cut off the words but you can see the basic things, the apple and the head. And let me frame up the topic by saying I’ve spent maybe the last 15 years of my 30 years product management career with one foot in the engineering side of the world and one foot on the sales and marketing of the world. Often as an interim or temporary VP of product management for a software company. Now you wouldn’t really call me on being the interim or temporary VP of a software company if it were going really well. So in general, these are clients of mine whose name I won’t mention who didn’t mess it up at the individual product level or the feature level or the product line level. These tend to be executive level things, with marketing sales and firing small weaponry down the aisle at the engineering department and vice-versa.

So we’re talking about fundamental issues at the company level. And my observation is that this isn’t just about terminology, this is about world view.

I actually think that the technical side of the business and the marketing sales side of the business actually believe in different laws of physics.

They don’t see the world similarly enough, in very fundamental ways.  This is not just explaining in smaller words. This is how does the world work? This is – I don’t think your world view makes any sense, let me shout louder!

So we’ll dive in. I’ve created for us 4 laws of software economics and we’ll try to decompose them.  For each of them I’ve got a cold, ugly fact about the world which some of you may agree with and some of you may not, but I’ll claim are facts and then we’ll try to prove it. And then we’ll come out with each of the 4 laws, which if you’re an executive at a software company, are the things that you need to do or maybe just believe that are gonna help you on your route to make that software company more successful.  Because having laws of physics isn’t useful if you can’t take something back to your office or company and put it to work. And we’ve been speaking and talking about the divide between the more introverted, more fact-driven, technical side of the business (check your Myers Briggs square for me) versus the more outbound and emotional, sales and marketing-driven folks to complete the puzzle. And as a product management executive and practitioner, I’ve sat in the middle of that discussion a bunch of times.

Ok so here’s my first ugly fact. I don’t know if you guys know but this is true. There will never be, there has never been on the planet and there will never be on the planet a software company that has as many developers as it needs. Is this true?

Anybody at a company that has enough developers?

Ok. Now, part of this is that it’s hard to hire good developers. I looked on Indeed last night and I saw that there were something on the order of 7,000 open software developer jobs in the Boston area. So we know it’s hard. San Francisco has something on the order of 18,000 so anybody who you see packing up their software bags and moving to the golden city of San Francisco is pretty assured if they’re pretty damn good, they’re finding a software job. So you could say this is just about hiring and we’re one or two hires away from catching up,. You know, I can see it from here.

So I found a photo of last winter in Boston – anybody here from Boston?  There’s this belief that a lot of folks have that we’re pretty close to digging out, right? But it turns out the physics is not that way because everybody in this room can dream of new features that are not in your products faster than you’re thinking of implementing them.  It’s obvious on inspection and there’s proof for it, I can prove it to you because if you go to someone in your company who is in sales or marketing role and say we’ve got to half a day of white space in next week’s sprint. What happens next? You know that there’s a 400-person year developer schedule that’s about to come out, right?  How hard could it be? And so we will always, always, always be in a place where there’s more stuff in the backlog, there’s more stuff on the roadmap, there’s more things from customers and everybody else that we can ever, ever, ever possibly build. And so the definition of foolishness is doing the same thing and hoping of different results. Define the law of gravity here, I think means starting with the belief that we’re pretty close to being caught up and we’re just one release, one developer, one step away from finishing. And then it’ll be all ok.  (Not!)

I’m gonna suggest something we call magical thinking.  Magical thinking is that if I say the right thing, you’ll do it for me. We’ve all been here. By the way, we’re trained as small children to ask our parents for things and our parents and we’re gonna argue with them and we’re gonna come up with a good rationale because they should really want to give it to us – I have hundreds of these on my websites, but some of my favourites are… “It’s really important we promised it”

By the way, anybody here who’s a developer, ex-developer? Ok. If any of the other of you are in a room with these people, never use the words “it’s probably only 10 lines of code” unless they can see that you’re smiling and you’re not serious.

“We’ve been talking about it.”  “We’ve gone agile so have infinite capacity”  “My neighbours could do this.” There’s this theory and there’s the Home Depot school of software hiring, which says; this stuff isn’t so hard, I could just send a truck down to the nearest Home Depot, there are all these guys who hang out and for $10 an hour I can hire them and they can type as well as you can, right? So the reason this is magical thinking is because it comes at the world from an end point of view.  The thing I need is important because I promised it to a customer. The thing I need is important because it was my idea and I was thinking in the shower this morning and on my way to work and because a customer called me up and ripped me a new one.  Its importance is a singular thing.

And in the AND world, I always approach the world and say I know we have all this stuff in the roadmap AND the backlog, AND all these customer’s commitments, AND we’re supposed to get version 6.2 shipped this quarter AND I need this one little thing just this once.  It’s an AND world. Now unfortunately, your developers live in an EXCLUSIVE OR world.  For those of you from the sales and marketing side who don’t know what EXCLUSIVE OR is, come see me later.

But it turns out, and again basic law of physics, you can’t put something new in the roadmap without taking something of equal or similar or larger size out.  Because the idea that there’s a bunch of developers in the backroom, waiting for you, they’re reading Facebook, playing Quake, they’re making comic books, they’re just waiting – they’re sitting around, hoping that somebody will come up with a good suggestion so they can go back to work is magical thinking. But every sales person in your company, if you have – how many of you are at a company with sales people? We’ll get to them in a second. So sales people will approach this in an AND model:’  I know we committed all these things, AND I need this one more or I don’t get to go to club.

So we’re in this weird place where on the one hand, there’s this reality for all the people who build this stuff we sell and on the other hand there’s this reality for all the people who need things and they simply aren’t talking the same language. And it should be obvious on inspection that nobody is sitting around, waiting for that next project…oh by the way, another fallacy here, sometimes your non-technical employees will walk through the engineering or development area and they will see people sitting in a conference room and talking to each other and they may be drawing on the white board.  That’s not the same as being idle. Not typing is not the same as not building software. But there you are.

So let’s get to our first law and the first law says, I’m gonna call it:

The law of ruthless prioritisation.

Because no matter how many people we have in development, it’s never enough. And so we’re still left as executives and managers and directors with the problem of having an endless stream of AND requests but living in an EXCLUSIVE OR world. And so we also know, if anybody have been through any Agile courses in the last 15 years, you know that if you overload your team, you get less done. An 85% busy team gets more done than a 100% busy team and 110% busy team gets nothing done. So we can pretend that we just are gonna throw one more thing on and we’re only gonna do it this one time, I promise. But we actually succeed what the few important things are in each important level and getting them done. And everything else can wait, because by definition it’s less important.

So that’s the business unit level, we shouldn’t create business units willy nilly. It’s at the portfolio level. If we’re gonna create this new product, we’re gonna fully staff and fund it or maybe we shouldn’t create it or let’s kill another one! I’m sorry – I’m old school, I use the phrase end of life, ok? We’re gonna kill this product one way or another because we have to free up the team to build something new because it’s a finite universe, right? So we succeed by first figuring out what the most important things are and then getting those things done at the expense of things that are by definition less important, seems obvious. By the way, if you have a C or V title or you’re an executive, that’s what they pay you to do. Now you don’t have to have the right answers but you have to know who has them and you better enforce them.

Ok, so as an executive, here are my jobs. One; make hard trade-offs. The easy ones all got made, right? You delegated those. Again, you don’t have to be the smart person who knows the best answer, in fact, you’re probably not because those folks are in engineering. Quick quiz, how many of you know the proof that everybody in engineering is smarter than your executive team? It’s easy, just ask them. It’s not necessary for you as an executive to be the smartest person in the room, but you better be getting these people into the room and figuring out what the answer is. Your job is to make hard trade-offs, because the easy ones have been made and to battle the magical thinking of just one more. So that’s our first law.

So, the law of ruthless prioritisation.   Let’s take the second one and again, it should be obvious. This may be obvious to some of you if you’re in the software business; all of the money is in the 2^nd, 3^rd, 5th, 100,000th copy of the same identical bits that you shipped before. None of the money is in the first copy. This will seem obvious only for a minute. And here is our required 1950’s TV reference for those of you who are old enough to remember.

But the point here is if you’re in the software business and I will be careful to define this cause we’re gonna be talking about other businesses which are not in software business in just a sec. Your development process is essentially a fixed cost.  Per unit time. You have a team, you build a bunch of software and you either sell it a few times, you sell a tremendous number and you get a unicorn until it all pops or you sell none of it.  And the market upside and the market risk is on how many copies of that same software you sell, whether that’s download or software as a service or embedded or APIs. Whatever it is, you need a lot of people to use and love that software because it’s mostly fixed cost to build.  And if nobody comes and shows up to the party, you still spent the money. So we’re trying to find identical or nearly identical customers for it so that we can move the same bits more than once, again completely obvious.

So let’s talk a little bit about revenue. Because revenue is important. Again, I’ve spent my career with one foot on the engineering side, we’re building a beautiful thing and it’s important and one foot on the business side where if nobody pays us for it well it’s time to get the resumes out.  So let’s talk about the basic physics of spending money on R&D.  If I have a development team of 6 and let’s say that’s 3 developers and a UI person, a test automation person and a devs ops. I have a team of 6. What does it cost me every year to pay that team here in Boston or in the US? It’s $1 million, roughly speaking, the second decimal doesn’t matter. San Francisco it’s more because developers actually get to specify which snacks we stock! You haven’t lived till you’ve been through a hiring negotiation with a really senior development person who has a list of obscure demands, mostly to prove that he or she has the special stuff. We went through “I get to bring my dog to work” and “here are the snacks I need”.  There are gonna be all kinds of special demands mostly so they can prove that they have the winning side of it.  So $1 million a year to have your team of 6 building stuff.  Obvious.

So now there’s something else here which is an implied revenue commitment to your company, and I’m gonna exclude all the start-ups for a second, but who has a company with more than 500 people? Ok, anybody tell me what portion of the company’s money is spent on R&D?   I have a book for the right answer. Anybody? I heard 30%, 12%, 13%. Who said 13? Ok, here is your book. So if you open up the P&L’s of major companies like Oracle or Microsoft, what you find is they spend between 12 and 18% of their money on what they generally call R&D. So that’s all of the development or engineering, it’s the product management folks if that’s how they’re organised. Project management, docs, devs, all this stuff.

So they’re spending and I’m gonna pick the number 16 and 2/3% cause it’s gonna be rounded in a second. Which means they spend one of every $6 building product. It’s true, go look it up. If you’re a company you’re spending $1 out of $6 building product, what are the other $5 spent on? Sales and marketing, that’s right. So generally they spend three of those dollars on sales and marketing, they’re spending one of those (in theory) to pay their shareholders return and there’s another one that’s everything else: real estate and HR and assortment of things. But the preponderance of the money and the company is spent on sales and marketing once you get to a certain scale. And if you wanted to be acquired by one of those companies, you want to have some similar financials so you don’t dilute their earnings which means you’d want to be spending about a sixth of your money on development as you get big.

So we’re gonna flip this over, so what’s the implied revenue commitment for my $1 million? 6, is a good number, I chose this carefully. So what this means is, that if you’re a company of any size and you go spend $1 million on development, you’re making a soft or implied commitment to the company for $6 million worth of revenue. Now, it’s a new product and maybe it’s not this year so you’re up for $12 million next year. But if you’re not bringing in $6 million from your team that costs $1 million a year, somebody else is carrying your weight and bringing the revenue and you know that eventually the CFO is going to have a discussion with you.  You use the word strategic to justify products that don’t bring in money.

But the point here is if I put $1 million worth of people against something, I’m really starting off with $6 million worth of revenue. I can do the math another way and say for every developer you add to your team, you’re signing up for another $1 million worth of revenue, you better hope that the work that that developer is doing is worth $1 million a year.  Obvious? Good!

So what’s my incremental cost per user if I’m a software company or cost per license? You hope it’s not much, right? If you’re doing this right, we can add new users to the system, we can onboard some new Basecamp users, purely on their own steam. Now if you’re in the enterprise space, you’ve got selling and marketing costs, you may have post installation, but the goal of the software world here is that we get as close as possible to zero incremental cost. Again, obvious.  So my goal, unlike in corporate IT where we’re viewed as a cost centre… my goal if I’m a software company is not to minimise the cost of the developers or development or to outsource.  My goal is to generate more revenue and so I should always be asking the question: not am I keeping my developers busy? Because see before, we are actually keeping them busy. The question is; what we’re gonna do to generate money? Because we’re into money and that’s a good thing for me. Right, here’s our roll of money.

So, anybody running a SaaS service out to the market? So here’s a picture, this is your SaaS service, I’m hoping. If you did it right, you have a chart just like this on your website and maybe you aren’t? Ok, if it’s consumer service, and what we’ve got is we’ve got a set of features and some baseline capabilities, right? The basic products, expanded and advanced. It should all look this way and there’s a bunch of reasons why it should look this way.

One of them, one of the really important reasons is because it makes it easier for your customers to buy. They can put themselves in column 1,2 or 3, they can check the box. Everybody wants these 3 choices because there’s this whole psychology around picking the right one. But the point is you’ve got this set up in a nice way. There’s another reason why you do this, because remember, we’re talking about software economics here – which you really like your development team to understand how we’re gonna sell and deliver this stuff. So it would be easier for them if we said: here’s a bunch of capabilities or permissions that are in the basic product and then in the medium product and advanced product. And you don’t let folks do the exercise, well I really want the concierge service, and the extra capacity but I don’t want to pay for it. So let me roll my own offering.

It’s great if you only want to sell this to 1, 2 or 3 folks, but if you’re trying to sell 10,000 of these, it’s madness, right? So we do this both because it works better for engineering and it works better for the sales side of the house. Now there’s one really important thing here, everybody draws this chart and a lot of folks get it wrong, all right? And the thing they get wrong and it’s hard, is this box right here. And the reason this box, this row is hard here, is because you actually have to do a huge amount of thought and segmenting and customer analysis and deep work with your customer base to figure out what feature it is that people are gonna pay extra money for to move from the basic to the expanded. Because if you get this wrong, end of job.  By the way, for old folks, that’s the last card in the stack of punch cards but for here we’ll just use it as “closing the company”.

You have to actually be right about which feature it is that’s gonna cause people to upgrade. Everything else here is just noise. The CEO welcome kit, somebody in marketing thought it up and we needed an extra row in the chart.  Usually, there’s a marketing newsletter, which you’re required to take in basic and expanded, but in advanced you’ve got the option to take out.  Ok, we’re gonna have a whole chart here and it’s gonna be full of thousands of things, but the only one that matters from basic to expanded is if you pick the right one feature which is in the use case that causes people to say “I’ll pay twice as much for the next one”  By the way, I don’t usually count on my engineers to know that answer, it’s more of a product management problem.  So the reason we do that is because we really want a lot of folks to buy, use or rent our software>  Because remember: all the profits are in the nth copy. So sometimes we get it wrong.

So here’s my contention: The engineering team is all about brilliantly building something. When we brilliantly build something and we bring it to market, and the silence is deafening, we’re not allowed to blame it on engineering. As executives, we really want to be thinking hard about what people are gonna buy. I had a product in mind here actually. Anybody remember the Amazon fire phone? Ok. So last October, Amazon wrote off I think $86 worth of inventory of their warehouse of all these phones they brought out, Android phones at $499, the next week they were $399 then $299 and $199. It was a brilliant product, except none of us on the consumer side could actually figure out what it was for. So here’s a company brilliantly known for their great analytics and their AB testing and consuming the universe and the software is gonna eat everything and they launched this phone which had a strategic need for Amazon to succeed, but nobody figured it out why anybody would want it. Now you can get it for – anybody know? $50, I don’t know. And you get free streaming movies from the Amazon catalogue so maybe the answer is that for $50 I’m willing to take all the movies from Amazon.  But unlikely was their strategy.

So the point here again is, because we’re talking about selling product to many, everything you ever read about in your lean start-up or your lean discovery or your customer development thing is really, really important. Because the last thing you want to do is roll some product out and hear crickets.  One other diversion here – I talked to a few folks last night who are a company that are either in the professional services – they’re doing contractor outsource software. Anybody has that kind of company? We’ll come back to you in a sec. I’ll tell you that contract or outsource software is a great business, but also it’s not the software business, it’s the professional services business. I have a picture of what the half and half firm looks like. It’s rare to find a firm that can be half outsourced or contract the professional services in half volume software product, you’ve got different problems, you’ve got different approaches and matrix, so here’s my picture of the company that wants to be half and half. Ok! I applaud you if you’re a software company and if you’re a contract development company. I really question your point if you’re trying to do half and half.  So I’ll let you make those investments, Mark.

And over and over again what I see is trying to do these in equal parts is really very difficult, maybe impossible. If I bug the conference room at your company for the Friday morning senior staff meeting – no, I wouldn’t do that because that would be wrong – and you’re a professional services company and you’re doing outsource software, what are the questions that you’ve got? You’re talking about new contracts that are coming in, whether the current contracts are on schedule, staffing, training and especially you’re talking about utilisation of your folks. The business you’re in – if you’re in the contract software businesses, you’re in the business of marking up the time of your developers.  Cost plus 40% if you’re good.  And the world is trying to push that down to 30%. Do you own any IP? Not so much, maybe none!  Do you own the market risk that the thing that’s gonna be built doesn’t sell? You don’t, actually, because the people who pay you the money, paid you for whatever reason they had in mind and if it was a bad reason, you still cashed the cheque. You may have some moral qualms, but you still cash the cheque.

The business is really much more about business development and sales than it is about marketing because what you need to do is you need to keep projects in the pipeline. In fact, if you open up the staffing for that company, what you’re seeing is a lot of good, senior, excellent project managers and program managers because the way you’re graded at a contract or professional service software firm is on spec, on time, with reasonable quality.  You’re not graded on whether the thing we shipped met a market need.  So you’re asking a different set of questions and got a different set of skills, you’ve got a different measurement map and a set of talent on the software side of course you have project managers, you have product managers who are the people that you really want to help find where the money is gonna be and the ones you fire when they ship a product and nobody buys it. What you’re gonna see in those two companies is radically different kinds of folks. And so I contend that if you think your half contract and half market-driven high volume software – let’s talk!  I’m very concerned for the thing you’re trying to do because the culture clash, the metric clash, the hiring clash, the goal clash is so extreme when somebody comes in the door and says I really want you to build X, if you’re in a contract software firm, the first answer you give is YES.

So what I get out of that is I’m gonna call:

The law of build once, sell many.

I think it’s completely obvious, but it’s about segmentation. It’s about before you build it, you’d like to find a customer group that wants it and that’s more than one. You wanna be first finding the customer need and doing the lean discovery and finding out there’s a market for it before you start the work. Because otherwise you’re committed. And you wanna be focusing on segments, not deals.

Anybody who’s a sales person here? A lot of you, ok. So this will be easy. I’ve surveyed a lot of enterprise sales forces in my time and there’s one major reason we closed really big deals last quarter and there’s two major reasons we didn’t close deals last quarter. Who can tell me the number one reason we closed deals last quarter? That’s it!   The number one reason our sales forces closed big deals last quarter is because we are awesome. We have a great salesforce and we’re above average! And what the two reasons we didn’t close deals last quarter? Product problems and it’s missing these 4400 features and the price was too high  So really important that when I survey sales forces to figure out how to improve their product, what I learn is they are great sales people, and that we should lower the price and add hundreds of more features. But in fact, they’re doing the rational thing, because – how do we pay sales people? On commission. And the commission in not on how the company as a whole brings its numbers in, it’s on individual deals.

In fact, we hire, train, promote and reward a bunch of sales reps who have a bunch of very special talents which I don’t have, I failed at being a sales rep, I’ve been a CEO. But what do we want our sales reps to do? We want them to be persuasive, to understand the customer organisation and figure out who can say yes. We want them not to be blocked by somebody who doesn’t want to sign and we want them to escalate and be as persuasive about the benefits as possible and maybe understate some of the downsides.  Because by the way, if they don’t bring in the money, we’re all out of a job and they don’t get to go to the club. Now, we’re shocked when a sales rep comes back and says “well I just got off the phone with Deutsche Bank and they might be willing to write us that $15 million cheque if we just add this little feature, what’s it called? Teleportation. How hard can it be? It’s probably only 10 lines of code”  And I’m sitting in the product chair and I say something less polite than no. Hell no! One of the things I’m surprised they do, they escalate, they try to be more persuasive, they go around me, they go to the CEO, make better pitches, they undermine the roadmap. We’re paying our sales reps to undermine our product plan, that’s their job. We pay them to bring the money in, no matter what.

So on this side, we have to be as executives able to withhold or hold back the tide.   Because we have created an organisation on purpose, intentionally with people who are doing their best to subvert our goal, to sell many because they all know they need just this one more thing… and we’re almost done… and it’s got to fit at the top of the roadmap… So as executives, the thing we’ve got to do if we want to be in a software company and not a professional services company is we’ve got to hold back the tide of everybody who wants just one special thing that’s of use to just one special customer.

Actually I lied, about this! There is something more wasteful and horrible than building a product and have nobody buy it. Everyone know what that is? That’s right. It’s having one person buy it. So I’m in a software company I’m trying to build up scale, if nobody bought it, we’re good. Cancel and move on. We have 2 or 3 major customers who paid a lot of money for something else and they paid us not much money for this weird, silly thing and we’re stuck for 2 or 3 years’ worth of maintenance.  Man! That is worse than just throwing it away because we’re stuck!

So we get from ruthless prioritisation to build one, sell many.

The next piece of course is the software bits are not the product. Is this obvious to everybody? We have engineering teams, development teams and they ship it and it goes on the website or CD and they all say we’ve delivered business value. It shipped and we made money for the company. And they are half right cause the thing they do is absolutely necessary, invaluable but not sufficient.

Anybody know what this is? It’s a low margin product that you can find in any hardware store and the folks who make it don’t make very much money. And you can use it for almost anything, right?  This is a picture hanging kit and it has an 85% margin and it includes all the little bits you need and the level and all this stuff and it’s designed to meet a specific purpose.  If I want to hang a picture, this is more or less the stuff I need. And I’m gonna pay more for this kit than for the hammer, even though the piece parts here might be only 85 cents.

The products and services we build are more than just the bits, they are the positioning and the packaging and the message that we put out and vignettes we put on our website about why people love us and the evangelists who go and get people excited about it. If we’re in the API business, let’s imagine you’ve got some big data analytics thing up in the sky and customers can upload x bytes worth of stuff and figure out what their middle names are. And you’ve got all these APIs which are brilliant and built by your team and they say we’ve got version 2.6 up. We’ve succeeded! Well if you’re missing evangelists to go out and explain why someone wants this and ithe sample code that somebody can use and the video help and the online support and the case studies of the people who care, what you got are bits. You don’t have product.

And so the engineering side of the house is always believing that they’re the centre of the universe and of course they are because they’re smarter. But it’s insufficient  So if we’re shipping naked product, if we don’t understand what our customers are doing with the product it’s naked, if we don’t have positioning, messaging and awareness, or sales channels lined up, support and evangelism…is Jim still in the back? So Jim’s been doing something for more than 30 years which is helping companies price their software. And he’s brilliant and it’s great to see him in person again! You could let your engineering and development team decide how you’re gonna price your product.  But I don’t recommend it. Or you could let your sales reps decide for each deal how to price the product. Also not recommended. So someone at your company who is not a developer or a sales person probably needs to put the price sticker on and it either says it’s per year or per month, is it per month per gigabyte or stock trade? What’s the unit of price and what’s the number on it? Because you can’t sell it naked software, unless you’ve got some business planning and pricing to put on it.  Again, obvious. But when you’re sitting in the engineering seat, you don’t see it. Shipping is shipping.

So let me pull some data up here. So this is out of my personal data, I can’t share all the instances because that would be wrong, but I’ve worked with 100 companies out in Silicon Valley over the years and I’ve seen a lot of product failures. In fact, I’ll admit, I was only the CEO / founder of a start-up once and we had 100% failure. So good character building, right? Life learning experience, whatever it was. Anyway, when I look at the failure modes that I see in companies that ship products which fail, let’s go through the slices. The biggest slice is they’re either not solving a problem anybody cares about or they’re not delivering a solution that’s any good or useful or that matters. If you ship something that nobody cares about or you don’t solve it well…

The second one is; it works pretty well but we can’t explain it, it’s not differentiated and not positioned, we don’t have good words and forgot to tell people why it was good. We do have this 17-page data sheet.  But we forgot the very top 1 or 2 sentences or maybe 8 words because marketing people have a budget of 8 words, they start to forget after that… I’ve been a marketing person. What’s the positioning and the problem we solve? How do we talk about the user problem before we get into the 17 pages of specs?  If we can’t explain why our thing is better, much better, nobody is gonna buy it.

And the third big one is; we haven’t figured out how to sell it or what the channels are or whatever. Notice that all the red slices are not engineering failures. You can’t engineer your way out of solving the wrong problem. Now, scrum will tell me that we will bring into our customer showcase every week or two to look at the work and that’s how we’re figuring out if we build the wrong thing, but it turns out that almost every team can find two customers in the world who love what they’re doing.  And they tend to be your most fanatical customer, they’re the most technical, they already know how to use the product, they don’t care about the UI and want lots more features so if you let your two customers in your showcase steer your product, by the way, you rapidly end up in the custom software business because you left out the 10 million people in the world who never heard of you and can’t figure out what it does. Now sure we’ve seen products fail for being poor quality or being late, but I tell you that what we have here is mostly not an engineering failure. It’s a failure of whole product. What the f* are we doing to identify and solve and describe a real problem for a customer and deliver a solution?.

So here is my contention. And if the letters aren’t big enough, I guess we can make them bigger, all right? Over and over and over again I see companies failing utterly because they’re building the wrong thing or for the wrong audience or they haven’t thought clearly. And once they put a development team on it, they’re committed. Remember our $6 of revenue? Once you’ve put 20 developers on something and it’s costing you $3 million a year, everybody is committed and cancelling that is gonna be really hard. The moment to decide that you’re done and you’re gonna cancel and sunset, end of life, is before you ship it. So really important that we do that hard work.

So let’s come to our third law:

Customers buy solutions, and the solutions often include software.

You wanna have a whole product.  I’ve been talking with folks about something called Mean-Time-To-Joy. The consumer folks have known this forever. If you put a new app on your iPhone, or if folks under 25 put new apps on their iPhones, the app developer has about 12 seconds, maybe less, for that person to either say that was fun or I’m never gonna open it again.   In the enterprise space, often you get an hour, but if you’re doing some B2B online analysis product, you better be able to show your customers something tangible that they care about it, it’s fun and interesting in no more than 3 minutes and it better work on the website and they better not have to install or learn anything new.

Mean-Time-To-Joy is about whole product, user experience, getting the whole thing right. So the executive job: watch for the organisational silos, because the developers will give themselves a bonus when they ship and they deserve it cause they’re smarter but that’s not the whole thing. How we’re looking across the silos to make sure we’re shipping whole product and we’re not setting up incentives – and I’ll tell a very brief version of this story. So I was at Sybase in 1993 to 1996 when the database wars in those years was still raging and Oracle hadn’t yet won that round. And Sybase had SQL database version 4 and Oracle was at version 7. So our next version of course would have been 5 but we named it 10. So we came up with Sybase systems 10, we shipped it on time and with quality and the whole company got a big bonus, especially all the folks running the engineering department. I was in product management that reported up through engineering in those days. And it was great and terrific and has just one small side effect which was we had changed all of the client side APIs and calls so that if you want to go from system 4 to 10, all you had to do was rewrite all your Sybase applications from scratch. No biggie, right? So starting the week after that shipment, I was getting phone calls pretty regularly from customers who had just one question for me which was when is the end of life date for system 4 so that we know when we should move to Oracle? We had knelt down, handed the knife to our competitor and given them an opportunity here. But what – we did the right thing of course because we paid everybody a bonus. So it must have been right. And if you’re an executive, you really want to think hard about what you’re paying people for. Are you paying them for customer success and joy and retention — or output?  Really important.

Let’s go to the last law here.

You can’t outsource your strategy to a spreadsheet, to your customers, to the weighted shortest job first

So let’s give some examples. Here’s a bunch of places where you can get input about your product and I applaud them all. You – if you’re in a product or executive job, you better be talking to customers and doing surveys and crowd sourcing stuff and showcase customers. And industry analysts like Gardner are gonna come out and tell you what to do, read your competitor data sheets. You can talk to your smartest customers; I can’t recommend that as a segmentation if the only people who that can use your product are really smart people, not so good. The executive survey – you guys know about this? I was on a plane, I was talking to the woman next to me on the plane and she said you’re an investment banker who wants to go public and then wants to do everything to goose your revenue in the short term and kill your customers long term. Inflight magazine writing, everybody who read the piece on six sigma in the American Airlines magazine.  And your executive gets off a plane and says “well I know the competition is doing 6 sigma, we should do 8”   These are all really good sources of data, right? But they’re not a strategy. And if you’re outsourcing your strategy to your customers and letting them vote up, you deserve everything you get. Let’s do the example and come back to it.

So anybody who knows Noriaki Kano’s work from the 80’s – brilliant man. I’ll talk us through it. So he did a bunch of work where he surveyed a large number of people in Japan who bought consumer products and what their preferences were and he divided the features in 3 groups. So bottom to top, left to right is; did the product meet your needs? No, yes. Bottom to top is; did you feel satisfied? Which is an emotional question. No, yes. And the grey box is all the competitive products. What you see from this is the baseline or mandatory features are the ones that everybody has. The government mandates it all, the competitors have it, whatever. And what you see from this is that no matter how good you do at all, the checklist of items which everyone expects, you can meet their needs, but they never feel satisfied. They’re buying the same old thing.

There’s another group of things that he called performance or linear – more compute power, memory, longer battery, lighter weight – these are the ones that get more over time and you and your competitor know just what they are and sometimes this is the red queen problem from Alice in Wonderland that “I have to run faster and faster to stay even.” Your nearest competitors know just what that is and you’re all battling and this week this head and next week that head. The red line, the exciters or the delighters are the ones that most of your customers don’t yet know they want and we all know the company that dominates this market cause I don’t know what a retina screen is, but everyone wants one.

But let me give you an example that’s not from Apple. If we go back to the early days of GPS for cars, so there was a time in that market where you would go buy a gadget, a device with suction cups on the bottom that sat on your dashboard. Tom Tom, Magellan, Garman, everybody else. And you bought it and it was $400-$500 and it was cool and you brought your neighbour and took him around for the thing didn’t get lost in your own neighbourhood. And that was state of the art, but there was one of the car companies that was the first one to put an in-dash embedded GPS. Anybody remember what company that was? In the car, the car maker put the thing on the dashboard, it was Lexus at the high end of course, it was Toyota still the same company on the Prius. So the Prius shipped with – you could pay extra to get a GPS in a Prius and you could pay a lot more to get a Lexus with a GPS in the dash. So for about a year and a half, they were the only luxury car in the luxury market that had a GPS and they sold an awful lot more cars. So if you are gonna put down $85,000 for a luxury car, they moved a lot of people off of BMW and Mercedes and Audi to Lexus, because those folks in there were all men who brought their new cars home, they parked them in the driveway and then they went next door to the neighbour and said come take a ride with me around the neighbourhood, let me show you my GPS. Everybody said wow. So for 18 months, Lexus made a huge amount of sales because they had something nobody had and that was exciting and it was a differentiator. Then of course all the other car companies started shipping GPS’s in their high end cars. And what did that do for sales? Not a thing. Because the idea that you would now buy a Mercedes for $85,000 that didn’t include a GPS, that was a hard call. The GPS has fallen down to baseline. Imagine driving your new car home with the ribbon on top, and saying to your neighbour here is my new car and he says well where is the GPS?   If the thing you do is you survey your customers and you vote up and do the features that your customers most expect, they are all the features that the competitor shipped last year or the year before. Because that’s about how long it takes for everybody to notice. So if you live and die by your Voice of the Customer survey, not so good.

So the other thing everybody wants to do is they want to outsource their strategy to some analytics package.  We’re gonna do really good estimates of business value and engineering value and we’re gonna cross product and put them in our spreadsheet and we’re gonna do the things that score the highest. I gotta tell you it’s a nice approach, but doesn’t lead to good results. These are the ugly products that you get when you do this. The first reason is that everyone that estimates a business value forgets their estimates are even wider than the software development values.  We know that when we estimate a project on the development side, it’s a plus or minus –  a 100%, right? But the business value is actually plus or minus 250% cause we really don’t know and finance folks make us put a number on the spreadsheet, so we do. But the idea that we’re gonna grind these through some weighted shortest job first thing and actually get good product just doesn’t happen.

When you prioritise this way, you end up with weird, ugly products.

I did see somebody from Microsoft here but I’m gonna ask anyway. Anybody used Microsoft Office? Microsoft Office is the end result of 30 years of – well they wanted this and that; and how about we add a new ribbon; and 15 ways to sort data; and almost nobody can use all of the features.

And the last one is you’re actually making trade-offs among unlike things. So you always have the argument that one more feature vs one more bug fix versus a little bit of investment in R&D versus the infrastructure that the developer ops teams needs to get things done. And you’re trying to trade these off in the same way that when your kid comes to you and says the new hot band is coming to town and I have no idea who it is. Florence and the Machine are coming to town and I want to take my friends and the tickets are cheap, they’re only $200 apiece and they’re 11 of us, right? Your faced with the decision of; do we pay rent this month and have food, saving the college account or am I my kid’s best friends for 3 hours while I buy tickets? And the unlike trade-off is really hard because we’re trading off things that don’t naturally balance against each other in a way that’s unnatural.

I’m gonna suggest that when we do prioritisation, we’re gonna put them in buckets.  We’re willing to spend this quarter 50% of our rare, precious story points or whatever we’re mentioning on new features for the new release and; we’re willing to spend 15% of our rare previous story points on test automation and quality and infrastructure and we’re willing to spend 3% on some big R&D project and it’s either teleportation or something else, right? And there’s a bunch of overheads we’ve never talked about in engineering before because if we talk about it, the executive cancel it.

But that let us ask good rational questions: which of the features in the feature bucket for the next quarter, do we think are gonna generate the most money and customer love without stealing from the 15% that we’re spending on quality and infrastructure otherwise? So the other thing that happens in almost every team is we make this trade off just this week, right? We’re gonna borrow all the points for quality over to a feature just this week and next week of course we’ll put it back and this is equivalent to – I don’t know if you know this, but joining a health club has no health benefits. Going to a health club has some benefits, but most of the folks in America who have gone through the big season of overeating and watching too much football, whatever is on television, join a gym. And it has no health benefits because they keep talking about how this week I’m really busy but next week I’m going to the gym. When we don’t put things in buckets, what we find out is that we keep making the same wrong trade-offs and we keep trading off the future and quality for some feature that didn’t make any sense.

Ok, two to go and we’ll see where we are. I try to avoid quoting Steve Jobs but it’s ok if I quote him quoting Wayne Gretzky. I usually stay away from sports analogies, but here we are.  So he said “I skate to where the puck is going to be, not where it’s been.“ When you outsource your strategy to your engineering team or your spreadsheet or your customers, what you’re doing is you’re looking retrospectively at what was a success last year.  As an executive, you must have some point of view on where the market is going.  If you’re a laptop manufacturer, or a server manufacturer, you’ve known for the last decade that phones and tablets are gonna replace laptops. Not a surprise, everybody in the business knows that. It would be helpful to take that strategy into effect because it’s gonna happen. So as an executive you have to have a point of view. It’s ok to be wrong and to change your mind, you have to have a vision of where we’re going. Otherwise you end up with a random assortment of ugly stuff that doesn’t lead you anywhere.

Ok, so that takes us here.  We’ve got Four Laws and this is an attempt to get the conversation going back again between the technical side of the house and the market side and what we conclude is we as executives have to be willing and ruthless about our prioritisation cause it won’t all get done. We want to focus every moment on shipping more of the thing we built, not building one off for the next person who wants some crazy thing, no matter how big they are. We want to make sure we’re not just shipping bits, because they are insufficient, we got to ship something that solves a customer problem. And last, we’re paid as executives to take a position and to mediate and to figure it out.  If we hoped that somebody else is gonna make those decisions for us, not so good! Ok, and here’s how to find me. Questions?

Find out more about BoS

Get details about our next conference, subscribe to our newsletter, and watch more of the great BoS Talks you hear so much about.

---

Rich Mironov

Rich is a seasoned executive and serial entrepreneur – he has been the ‘product guy’ (as CEO/VP Product) at six startups. With deep technical roots in B2B infrastructure, SaaS and consumer online, Rich combines ‘what-we-can-build’ with ‘what-markets-want’.

He has been relentlessly blogging, speaking, teaching and mentoring on software strategy, product management for two decades. Today he coaches executives, product management teams and agile organizations. He has spoken at BoS Conference before, always to rave reviews, on topics such as the Four Laws of Software Economics, Solving Your Real Roadmapping Questions and, The Art of Software Pricing Demystified.

Rich has three big things he cares a lot about:

• Organizing the product organization.
• Cross-functional leadership.
• Building what users actually need.

He wrote The Art of Product Management and is a voice for the scrappy entrepreneur in all of us.

More From Rich.