Even a cursory glance at the worlds of technology and services (and the murky realm that lies between them) makes one thing clear: it is time for a new type of product company.
What’s wrong with the old one? Take enterprise resource planning as an example. ERP/supply chain management was once a world-changing problem, yet even after decades in which to evolve, the typical ERP system solution still costs tens or hundreds of millions of dollars and requires substantial time to implement - sometimes as long as or longer than the first versions. Why, then, does this model of “solution” persist so stubbornly?
One explanation is outdated reference points. The previous generation of product companies grew up in a world in which bespoke software was the only viable option. To solve a problem by conventional standards, they either had to build everything from scratch, or glue a bunch of existing products together into an uneasy coexistence. Given the obvious shortcomings of the latter approach, the former takes hold in many cases.
Of course, the bespoke approach has numerous shortcomings of its own. It is largely inefficient, and discounts the extent to which large classes of solutions can be productized. Interoperability with existing systems and future products invariably suffers. Many customers will commission products that should be reusable elsewhere, yet impose IP restrictions that prevent wider application. The largest companies may succeed in creating a continuum of seemingly complementary offerings (end-user software, administrative software, databases, mainframes, hardware, etc) - yet behind the kimono they are actually services businesses. Each additional piece of hardware or software exists to sell more services, and in doing so, consolidate ownership of customer environments.
However, the deeper (and much more destructive) phenomenon at work here is the matter of structural incentives. From the vendor’s perspective, the bespoke development model usually means each product has been developed on a specific, proprietary customer’s dime (indeed, it is hard to imagine a purely bespoke model working without rigid exclusivity clauses). The bespoke developer bills for the engineers’ hours, not the final product, and inevitably requires a legion of consultants to make the product work and provide further customization ad infinitum. Conveniently, the longer the project takes to complete, the more money the company makes. Even if there is no gross corruption, there is no incentive on the margin to make anything more efficient.
On the customer side, structural incentives should be better aligned, but loss aversion tends to create resistance to change, especially in big companies. The larger an organization’s technology purchasing infrastructure (and the more layers between it and the end-user), the more the incentive structure is influenced by the practical need to defend oneself to the outside world. Because appearance is everything, the relative downside of being associated with an unsuccessful technology acquisition is fairly high, while the relative upside of a successful new implementation is surprisingly low. As a result, “safe” decisions quite often win out over the best decisions, which are usually non-linear and difficult for everyone to easily recognize, even with the purest of motivations. The effects of loss aversion reverberate far beyond technical functionality – they limit the vision of the whole organization, even among those who ordinarily might embrace innovation. As consumers and as a society, we have not been as perceptive as we probably ought to be about the efficacy of the traditional approach to building products - if we were, we would be more willing to learn and iterate with a long-term outlook.
Left alone, the traditional approach, for all its faults, seems destined to persevere. Hence, I maintain that we need a new type of product company: one that actively takes responsibility for the outcome the product is supposed to deliver. This may sound intuitive enough, but it actually represents a revolutionary departure from traditional companies that deliver technologies or capabilities at best. This company must have both the skills to productize new technologies and the incentive to continue iterating until its products work out of the box (and working out of the box must sooner or later be seen as a firm requirement, not a nice-to-have). The tricky part, however, is that this incentive must be created alongside the product itself.
Let’s first consider the incentives driving the traditional model. Creeping development schedules and requirements reliably create larger and broader revenue opportunities. This results in an obvious disincentive to stay on schedule and under budget, but it is a commonly accepted model that many large customers are well-prepared to accommodate. Increased dependency on services creates more revenue opportunities, and has the additional benefit of locking in customers, who may not have the desire to administer their own technical systems (or even believe it to be possible). Finally, a subtle but profound incentive is that companies are rewarded for convincing customers that each of their problems is a unique snowflake and requires an equally unique solution, built from the ground up, at bespoke speeds.
The new model is a study in contrasts. There is no incentive to delay, partly because the company does not rent labor by the hour, but largely because working out of the box is a major part of the value proposition. The outcome-based model prizes efficiency for both customer and vendor, and as a result, the focus is on solving immediate problems with the subsequent goal of generalizing and productizing solutions to whole classes of problems. However, the desired outcome must be achieved without compromise, so there is also a strong incentive to create a product that is adaptable to very specific requirements. The overriding incentive, however, is to do something truly extraordinary, and realize substantially more value based on a substantially better outcome. If you can save a customer $1 billion, it is not unreasonable to charge $250 million for the privilege. By the same token, a solution that is duct-taped together over months and years and thrown over a wall, leaving the customer to struggle to realize a fraction of the savings themselves, should be rewarded proportionally.
This is the big bet driving the outcome concept: outsized rewards for outsized (and demonstrable) value. Of course, it will absolutely never happen this way overnight. No doubt the outcome model is much riskier business in the short term. The company must assume the risk of development costs, since the new model requires them to create value first before they can charge for it. Delivering a meaningful outcome also requires top engineering talent, which cannot simply be purchased, and certainly not as quickly as one would like. Finally, lest we forget, the structural incentives to avoid change are alive and well. In order to have any chance at all of making it, the entrepreneur must take on the lion’s share of the risk, betting that a fair price for a guaranteed outcome will be a lagging indicator in the best case scenario. In the short term, true outcomes will almost inevitably be undervalued, but the reality is that the burden of proof is on the innovator. (To be fair, there is risk for the customer as well, even if their initial monetary outlay is low. Ideal outcomes are not usually achieved all at once – early on, they will require the customer to invest their time, provide access to their hardest problems, and be willing to iterate without real certainty that the new company will necessarily succeed where previous vendors fell short).
A business model based purely on delivering outcomes would amount to a seismic shift – a wholesale reinvention of what it means to be a product company. So be it. This is unquestionably a difficult road, but if the past has taught us anything, it is that the only way for entrepreneurs to achieve the changes they desire is to see them through from inspiration to outcome – as high-tech companies everywhere like to say, end-to-end. More often than not, this means solving problems (and even conceptualizing them) vertically rather than horizontally. A truly vertical approach represents a major distinction and radical departure from the norm, and will be covered in depth in the next installment.