Four Laws Of Software Economics (Part 3) | Rich Mironov Guest Post

At BoS USA 2015 Rich Mironov delivered a classic talk on Software Economics that are so common that they are not just theory, they are the law. See the talk here. After delivering the talk, Rich captured his laws in a series of posts, delivered originally on his site, and reposted with permission on the Business of Software blog.

Our two previous posts noted that your development team will never, ever be big enough to catch up with your dreams (pushing us to The Law of Ruthless Prioritization) and that all of the profits are in the nth copy (thus The Law of Build Once, Sell Many).

Part three starts with the observation that the software bits we release are not the product. Rather, they are part of the product. We may celebrate releasing code, but there’s more a software company needs in order to turn bits into money. Like giving a hungry man a can of soup, but no can opener. So what’s missing?

Tell Me a Story

What sales and marketing teams really want is a coherent, market-relevant, high-level story to help customers see how using our product (to do what they already do) will make their lives better. As soon as we start trying to tell the story, we see the gaps that our software doesn’t fill. Suddenly, we see that we need a can opener to get to the soup. Oh, and a bowl might be nice. And a spoon. Probably want to wash the bowl later, too.

Or maybe we’re serving soup on a first date – and we want the bowl to say “you should totally date this person who’s feeding you soup, this is the type of person who has an awesome bowl, and would be an awesome soul mate.”  Solving the I’m-hungry-and-lonely problem, not the give-me-a-can-of-soup problem.

Likewise with tech products. Our B2C cloud file backup should deliver a deep sense of security about the user’s unfinished novel and family pictures – through an effortless app. Our network troubleshooting tool makes heroes of network admins who can fix now production problems instantly.  Our small business payroll service should eliminate the panic of paying part-time employees the wrong amount – with AI-based forms completion. We need a story that matters to our audience and earns us their attention.

We retell this story in our key benefits (i.e. not just features), success stories or social proof, customer ROI calculators, detailed use cases, competitive analysis and celebrity endorsements. The right story gives prospects a reason to get excited, to pay us some attention, to overlook our foibles and notice the other guy’s quirks. To engage emotionally.

As analytical technologists, we’d like believe in a world of purely rational buyers: customers who correctly identify all of their own needs, scour the marketplace for relevant products, carefully compare the back of each data sheet (where specs live), prioritize and weigh the results in a spreadsheet, and pick the best possible fit.

In that world, selling would simply mean sharing technical specs with prospects and waiting to collect purchase orders. Top sales reps wouldn’t earn double what software architects make. Companies wouldn’t spend twice as much on marketing and sales as on development. And product managers would simply “collect” requirements: plucking them from a few interviews like daisies in the field.

Here on Earth, competitors are always offering similar products. Marketers are telling better stories. Sales teams are finding internal champions, highlighting the risks in wrong choices, and buying lunch. Our underlying software is necessary but not sufficient to make money.

Segmentation for fun and profit

Product strategy rests on clear, crisp descriptions of who (precisely) we’re building for, what problems (precisely) we choose to address, and how (precisely) we solve their problem better than the alternatives.  Segmentation. Are we targeting multi-nationals, enterprises or single-store SMBs? Skiing fanatics or occasional snow bunnies? Convenience-driven organic grocery shoppers or coupon-wielding savers? Professional accountants or weekend bookkeepers? It’s rarely enough to target “urban dual-income Millennials.”

Thoughtful segmentation has to happen before we get too deep into the development cycle, or we’ll build a one-size-fits-none monstrosity. Which fails to enthuse any particular audience. (Go back and read Laura Klein or Eric Ries if this isn’t top-of-mind.)  Most urgently, we must identify a narrow-enough market segment that not only likes our concept, but also willing to pay for it. Every startup (and every scrum team) can find a couple of interested customers, but the economics of software requires thousands of customers.

So commercial success demands excellent market thinking at the front, and the capture of genuine customer stories – so that we can do excellent marketing/selling at the end. But often we rush ahead to start building software because that’s what we’re good at.

My broad but unscientific analysis breaks down product failures this way:

Poorly choosing problems to solve, solving them badly, and failing to understand/express our differentiation account for half the pie. Marketing and Sales catastrophes cover the next slice. Pure engineering failures (gray areas) only represent the last quarter. In other words, most of the success of a product is determined before we assign our first developer or fill out our first story card. Great engineering is not the fix for poor market thinking.

<analogy> If we’ve started drilling in the wrong place, Engineering can’t dig us out of our product/market problem. And if we can’t tell a good story about petroleum versus solar, we can’t look to Engineering for the best storytellers.</analogy>

 

But My Company Builds APIs…

Lots of successful companies target other developers as their customers. That makes your development teams more simpatico with your customers. The same rules apply, though. For every Twilio or Slack, there are dozens of also-rans who failed to sign up high-profile early adopters; couldn’t build a vibrant developer community; overpriced their entry-level service; didn’t understand their ecosystem; or assumed that a “better” API would naturally lead to more adoption. Marketing an API is still marketing.

So circling back to our initial proposition that the software bits we release are only part of any solution, we arrive at…

The Law of Whole Product

Customers buy solutions, which include software but are framed by careful segmentation and great marketing/sales. We want to offer the shortest Mean-Time-To-Joy (MTTJ) such that customers find us, try us, immediately see our value, and sing our praises to others in the right segment.

As executives, we apply The Law of Whole Product by aligning incentives with customer success rather than raw revenue; breaking down organizational silos; and keeping the marketing/sales side in close communication with the product/engineering side.

Do you have a whole product? Here’s one way to be sure… ask a few customers. They’ll tell you what’s missing.  And whether your product story matches the software bits.

– See more at: http://www.mironov.com/4laws3/#sthash.QrQEa5qC.dpuf