“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 Business of Software –
The Four Laws of Software Economics
The talk is rich with insight and humour – an hour well spent.
We are also delighted to hear that Rich Mironov will be turning this talk into a book – watch this space.
Slides, Video, AMA & Transcript below
Slides from Rich Mironov’s talk here.
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
Video
AMA
Learn how great SaaS & software companies are run
We produce exceptional conferences & content that will help you build better products & companies.
Join our friendly list for event updates, ideas & inspiration.
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 2nd, 3rd, 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.
Learn how great SaaS & software companies are run
We produce exceptional conferences & content that will help you build better products & companies.
Join our friendly list for event updates, ideas & inspiration.
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?
Learn how great SaaS & software companies are run
We produce exceptional conferences & content that will help you build better products & companies.
Join our friendly list for event updates, ideas & inspiration.