Post #1 noted that your development team will never, ever, ever be big enough to catch up with your dreams. – which led to The Law of Ruthless Prioritization. Here’s a second fundamental reality of software economics:
All of the profits are in the nth copy or nth user.
Building software is a mostly fixed-cost effort but additional copies are nearly free as long as we can resell the identical bits. We should be able to add more users (or licenses or subscriptions or photoblogs or virtual machines or virus scans or stock trades or big data queries or daily astrological forecasts or grocery delivery orders) at nearly zero incremental cost. That’s dramatically different from cars or breakfast cereals, where manufacturers worry about the marginal cost of producing one more Mini Cooper or another sugary box of Froot Loops.
Development teams aren’t cheap, though. Here in the US, a team of six (e.g. 3 developers, 1 UX/UI designer, 1 test automation engineer and a DevOps wizard) costs roughly $1M per year. And the financial markets demand a sizeable return on that investment: for public software companies, $1M spent in R&D is a promise to eventually deliver $6M+ in top-line revenue (my oversimplified math here). So each additional headcount on your development team is a future commitment to another $1M/year in revenue.
But that’s OK because our goal is not to minimize development costs, but maximize revenue. What can we build that tons of folks will want to use and pay for? What beautiful set of bits will excite millions of consumers to turn on their smartphones? Thousands of businesses to generate purchase orders?
That’s why almost every well-designed SaaS offering looks like this:
The prospect is presented with a very limited choice set: each tier targets a specific set of features. The Basic buyer gets everything in that column, and none of the upgrade items to the right. This helps mightily in the marketing/selling process, of course, keeping prospects from getting confused by too many choices and walking away. As well, it lets marketers describe the few use cases that nicely fit each bundle. (“Basic is best for small work groups that only share documents internally, and track expenses in another system…”)
BTW, getting the tiers right is life-or-death: the most critical part of this chart is the major upgrade feature that divides Basic from Expanded users. Our product team must have deep insight (and validated data) into our segments and use cases, so that Expanded users will naturally upsell themselves. And other Basic users can cheerfully succeed without that major upgrade.
This model is also critical for development productivity. If we have 3 or 4 tiered offerings, then assigning permissions or capabilities is straightforward: Advanced users get everything; Expanded users get most features; and Basic users get fewer. We’ve designed offerings that are easy to market, easy to manage, and easy to support. Easy to understand. Software economics drives us to have only a few versions, and to relentlessly sell only those few. Your company has at least one sales rep, however, lobbying for a unique assortment of features. (“McKesson wants most of the Expanded features and just one of the Advanced features. This is a big account: can’t we create a new super-user just for them? Should be really easy, probably only 10 lines of code.”) Before we know it, every customer has a different combination of features, and we’re supporting 2N configurations.
Focusing on the nth copy means that every one-off feature (built for a single customer) steals development leverage from something more interesting to our market segment. That dashboard redesign which will boost customer satisfaction… postponed for a one-off report for a UK bank. Final release of a partner API to enable automated sign-ons… thrown under the bus for last-minute IE7 support to mollify a laggard pharmaceutical firm. Etc.
We handpick our development teams to build software (superbly), not to defend the roadmap. As execs and product managers, it’s our job to hold back the chaos. Because there’s nothing more wasteful than brilliantly engineering a product that doesn’t sell.
And one-offs take us down the slippery slope to custom development.
What’s Wrong With Custom Development?
I think custom development (aka contract software aka outsourced engineering) is a great business. Huge companies have made their mark this way. I’d argue, however, that they are not in the software business – they are in professional services, which does not share any of the essential scale economies of revenue software companies. [I’m carefully distinguishing between revenue software companies – that live or die based on broad market willingness to pay for their intellectual property – and custom development shops that are paid to build what an individual client decides is worth building.]
This becomes obvious if we listen in on an executive team’s weekly staff meeting. Custom development (professional services) firms will be talking mostly about staff utilization, new deal pipelines, on-time delivery against statements of work, and attrition among the technical staff. Software firms will be talking about finding more paid users for the current product release, and when the next release is coming.
| Custom Development | Revenue Software | |
|---|---|---|
| Key Metric | Staff Utilization (busy developers) | Users (subscribers, licenses) |
| Business Model | Mark-up on staff hours | Re-use of identical bits |
| We track... | Projects/programs | Products/releases |
| Essential skills | Sales, business development | Segmentation, validation |
| Innovation ownership & risk | Client owns IP: we hope they pay and send more projects our way | We own IP: we hope target segment pays handsomely for perceived value |
| Graded first on... | On time, on budget, on spec | Market winner vs. competition |
| Customer wants a one-off? | "Great! Here's a change order" | "Let me put that (deep) into the backlog." |
| Plan to productize platforms? | Always sacrificed when paid projects run late | Essential part of product line planning |
I see radically different skills, attitudes, management approaches, hiring strategies and funding models between the two kinds of companies. Different DNA. Most importantly, I see custom development firms working under a different set of economic principles versus (revenue) software companies. Which means that combining the two — or running one firm that’s half contract and half market-driven software – seems destined to fail.
Here’s a picture of one company that’s blended both sets of DNA:
Be a horse, be a duck, but don’t try to be both.
How can you tell what kind of DNA your company has? Listen to the executive deal-making at end of quarter, before your revenue target has been reached. Software companies give away professional services (if they have any) to close the software deal, then offer discounts rather than one-off features. Custom development firms give away software (if they have any), then start cutting project margin. After all, we need to keep the staff busy, maybe just at break-even.
So taking us back to our second essential market fact, that all of the profits are in the nth copy, gives us our second take-away:
The Law of Build Once, Sell Many
Software has high fixed development costs but also the opportunity to add users at near-zero incremental cost. That means our job as software executives is to
- Keep everyone’s focus on segments of similar-enough customers
- Make sure that we’ve selling the same bits many times
- Push back on one-off feature requests that inch us toward custom development
SaaS after-thought: Luke Hohmann (friend and past business partner) points out that this discussion is framed in the old-style language of on-premise software: shipping bits. It’s worth rephrasing for the modern SaaS world.
- You should have one live production version of your SaaS solution for your mass of users and paying customers. (For simplicity, I’m ignoring staging, development, redundant failover instances, DevOps fallbacks, A/B tests, language options, etc.) This is what you promote, sell, and move new users into.
- Building and managing this is mostly fixed-price-per-time. In other words, your team of 24 — including development, operations, product management, security and AWS master craftspeople — costs about $1M/quarter whether you serve 100 users or 100,000 users.
- Adding a feature to your production system for only one customer takes a similar effort to adding a feature that thousands of users want. It also increases application clutter — one more option or menu or choice or workflow — that very few users will take advantage of, but some get in trouble with. Could we do other work that will bring in thousands of new users or make our current users happier? See Des Traynor’s thoughts on focusing effort on our few heavily-used features. UX suffers every time we lead people off the happy path into obscurity.
- You’re now tempted to create a separate version of your core SaaS just for the few customers who want some special feature. That means separate codelines or compilation switches, hosting instances, test harnesses, data segregation, failover strategies, specially trained technical support team, extra step in bug triage, etc. And a diversion of attention from your mass audience. More to remember, more to go wrong. Do a realistic headcount, particularly among DevOps: this probably needs several net-new people that each incur $1M/year in promised revenue. Have we wandered into custom development?
- I sometimes see SaaS companies with customer options for public, shared and private cloud deployment options. Mostly for enterprise applications, these companies attach very hefty upcharges for running a separate instance of the same version/codeline for customers who need separate servers, data stores, capacity, etc. But easy to slippery-slope ourselves into trouble that way.