This week we’re attending the Business of Software conference in Boston, which is always a fountain of brilliant ideas. So we thought we’d share some of the highlights. Please pardon their hastiness… we wanted to get them out sooner than later.
In this talk, Rich Mironov (@richmironov), CEO/Product Management Guru, Mironov, lays out a few fundamental laws of software economics that should drive executive-level decisions about business and product strategies. It’s easy to forget them, or decide they don’t apply to our special situation. But oh, how they do…
“Gravity is not just a good idea. It’s the law.” Let’s start with that. Whether you like it or not, that’s how it is.
And yet, technical folks and the marketing/sales side see the world with completely different laws of physics. The result may sound familiar on both sides:
“I don’t think this makes any sense, let me shout louder!”
Enter the 4 laws of software economics that will help everyone relate to the same universe…
#1 — Your Dev team will never be big enough.
Development can never build as fast as we can dream. You will always be in a situation where there’s more in the backlog and more requests from customers than we can ever possibly build. Defying the law of gravity starts with the belief that we are pretty close to catching up. You never will.
Even so, “Magical Thinking” takes over as you try to cram in just one more thing:
- “CEO says it’s really important”
- “We already promised it to a big prospect”
- “How hard could it be? Probably only 10 lines of code
- “We’ve been talking about this for months.”
- “We’ve gone agile, which gives us infinite capacity”
- “My neighbor’s kid could do this in an hour”
There’s a reason for this. Sales and marketing come to the world with an AND point of view. “I know we have all this stuff on the roadmap/in the backlog/committed to customers… AND I need this one thing…”
Developers live in an EXCLUSIVE OR (XOR) world: you can’t put something into the roadmap without taking something of equal or larger size out. Really. It’s not like these guys are not just sitting around on Facebook waiting for something to do.
These two groups just aren’t speaking the same language. Our companies get AND requests but execs need to make EXCLUSIVE OR decisions (you can only have one thing..).
Thus, you need the Law of Ruthless Prioritization: you will succeed by finishing a few critical things at the expense of things that are less important.
It’s the executive’s job to…
- Make hard trade-offs
- Battle magical thinking and one-offs
- You don’t have to have the right answers — but you have to know who does and you have to enforce it
#2 — All of the profits are made on the Nth copy. None of it is in the first copy.
Let’s do some math. If you have a development team of 6, it costs about $1M/year to support them.
Companies larger than 500 people typically spend about 12–18% of their budget on R&D (including all of engineering, product management, documentation, etc). That’s $1 of every $6 building product. They spend about $3 of every $6 on sales and marketing. Then $1 to pay shareholders a return. And the rest on real estate, etc.
So if you want to be acquired by one of these companies, you want to have similar balance sheet… otherwise you dilute their earnings.
That means for a team of 6 developers, the implied revenue commitment you need to generate is $6M. And for every developer you add to your team, you’re adding a commitment for another $1M of revenue. You better hope his/her work is worth $1M/year!
Of course, the goal is not to minimize costs, but to maximize revenue…
What is the major feature that will cause the customer to buy? Or buy the premium version of your product? Don’t count on the engineer to make that decision — it’s a product management problem. Meanwhile, Sales is clamoring for one-off special features to close a deal.
“There’s nothing more wasteful than brilliantly engineering a product that doesn’t sell.” Except selling one of it — because then you have to support it forever.
Enter the Law of Build Once, Sell Many. It means you need segmentation: the strategic art of choosing customers who want the same solution… who will make you money.
If you are always building one-offs for Sales to close deals, you will not be able to Sell Many.
The executive’s job to enforce the law of Build Once, Sell Many is very clear:
- Focus on segments, not deals. Don’t let the team get distracted by one-offs.
An aside…
We train our sales reps to be persuasive, understand customer organizations to see who can say yes, go around problems, escalate, etc. If you tell a sales person No, we’re not going to build that feature for you, they do what they do best… escalate! They go to their boss, the CEO… anyone who get remove roadblocks. The result?
We’re paying our sales reps to undermine our product plan. That’s their job. Execs need to be able to hold back the tide.
#3 — Software bits are not the product.
A product needs evangelists and sample code and videos and case study and such… and if you don’t have those, you don’t have a product. It’s insufficient.
The product is naked without
- deep customer understanding
- positioning, messaging, awareness
- sales and channels
- support, evangelism
A word about pricing: Someone who is not Sales or not an Engineer needs to set pricing. You don’t see the big picture in the engineering seat. And Sales looks at short term deals, not market segments.
In Rich’s experience, the most common reason for software to fail is companies try to solve the wrong problem (no one cares about it) or they build the wrong solution (you didn’t solve the problem well). They build the wrong thing, or for the wrong audience, or they haven’t thought it through.
Shocking fact: Most of the success or failure of a product is determined before we pick our first developer or fill out our first story card.
And thus we have the Law of Whole Products: Customers buy solutions (including software). The whole experience needs to work for them… you have very limited time to “hook” them into continuing to use your products. But you need to have the complete process, not just the bits.
The exec’s job here is to…
…See the full post at Xebialabs.com
