When ‘10x Better’ Isn’t Enough: Building Technical Products that Win
In the old days of IT, a handful of giants (Intel, Microsoft, Oracle, Cisco, etc.), controlled both the underlying hardware/software stack and distribution channels. In doing so, they were able to lock-in customers and lock-out new entrants with costly infrastructure and rigid licensing. These dynamics created an environment where the innovation cycle was top-down sales-driven. Applications and systems were designed with the CIO/CTO as the principal stakeholder, producing solutions that were feature-bloated and clunky; end-user experience was an afterthought. This “trickle-down,” “one-throat-to-choke” IT development, distribution and adoption paradigm was characterized by asymmetry between the handful of platform vendors’ solutions and end-users’ problems.
But today, in a world dominated by cloud and open source, barriers to innovation, distribution and adoption of IT have been eviscerated and that’s been both good news and bad news. The good news is that it’s never been easier to build and scale software and get that software into the hands of your users. The bad news is that it’s never been easier for your competitors to build and scale software and get that software into the hands of your users.
The result is a meritocratic IT paradigm where the best tool for a particular job wins. That’s generally great — particularly for customers — but creates its own set of issues, principally around decentralization, heterogeneity and tool and platform sprawl. For innovators in this environment, how do you stand above the noise?
The answer is more nuanced than “you have to be 10x better” than your substitute, which is necessary but no longer sufficient.
In the last decade, we’ve seen convergence of the software development, IT and business functions of organizations. This convergence has manifested itself in the DevOps movement — a set of practices and tools that emphasize and enable collaboration and integration between developers and IT ops (and often line-of-business). The implication is that everyone in the company with a credit card becomes an evaluator and buyer of IT. The reality for vendors is that you are no longer building products solely for the CIO, for IT, or for the developer; you are building products for all three stakeholders.
In this model, technical products and services that gain wide-spread adoption create a step-function improvement in the life of their target user, but also unlock value for the other critical stakeholders. Understanding and designing for the motivations of devs, ops and the c-suite becomes central to success.
Developers, principally, are motivated by complex, multi-dimensional problems, solving those and then moving on to the next ones. Provisioning new environments, writing functional tests, debugging old code, etc. are all necessary evils that stand in the way of shipping new, exciting features. Consequently, tools that enable devs to write better code faster and automate peripheral, process-oriented workflows are best friends.
Ops bridge code from developers’ terminals to end-users’ devices. They’re responsible for uptime, stability and performance of the application, which, in turn, necessitates infrastructure that is survivable and scales up and down with end-user demand. Given that, ops value products that are open, extensible and battle-tested. Perhaps most importantly they must abide by the sysadmin’s Hippocratic Oath: do no harm (to prod).
Management’s objective is to capture value from the symbiosis of devs and ops through growth or mitigation of risk. Consequently, tools and services that allow the organization to develop better software (growth), ship new features faster (growth), deliver code that is secure (risk), avoid vendor lock-in (risk) and/or contain costs (risk) are smiled upon.
Nailing product for any single persona is challenging enough, but threading the needle for three seems near impossible — and this is precisely why few technical products achieve escape velocity and instead toil as point solutions for acute pains. (This isn’t a knock against these tools and companies, but it does inform how you build and scale your organization.) However, when a product can seamlessly deliver value across dev, ops and line-of-business the results can be explosive. Just see Docker and New Relic as two more recent cases in point:
None of this, however, is to say that product and go-to-market strategy should target devs, ops AND line-of-business; much the opposite. Focus is critical. Principally serve the persona whose pain is most acute but always design and consider the cross-organizational impact of your product or service. Note that both Docker and New Relic achieved rabid adoration with one constituency — developers — before deploying resources or altering positioning to serve the other two (though the benefits were readily apparent to all three from day one).
For those seeking to build generational technology businesses, the message is clear: as technology transcends functional organizational boundaries, make sure your product can do the same.
