How to compete and WIN in a software economy [Part 2]

In the previous part of this article, the discussion centered around the importance of increasing product velocity, especially in today’s software-centric environment. The section concluded with the idea that you should ‘focus on your core and outsource non-core services’.

Although outsourcing non-core development [via developer tools, i.e. infrastructure services] is clearly essential to increasing product velocity, understanding how to determine if something is non-core development is often less clear. Accordingly, in this next part, we'll discuss how to identify 'core' vs. 'non-core' development, and how thoughtful outsourcing can be used to develop process power.

First, let’s look at how one determines which elements are core or non-core to a business. Instead of proposing my own methodology I’ll instead lean on someone with more perspective and experience, and return to Jeetu Patel (referenced in part 1).

The excerpt below is from his techcrunch article, where he provides a framework for designating an element ‘non-core’, by asking three questions: Will the service provide your application an innovation tailwind? Can the service be substituted by another supplier? Will the service provide a neutral to incremental experience improvement for my customers?

1. Will the [non-core] service provide your application an innovation tailwind? This could happen for several reasons, such as the sheer innovation velocity by the specialist supplier in a highly competitive market where your company benefits by shelling out only a fraction of the cost. If an innovation tailwind occurs, then use specialists who provide such a service. For example, by using the payments stack from Braintree, Uber is able to benefit on all the payments advancements made by Braintree on their platform.

2. Can the service be substituted by another supplier? By definition, the ability to swap the service means it doesn’t warrant it to be your core competency. Uber switching between Google Maps and Mapbox, for example.

3. Will the service provide a neutral to incremental experience improvement for my customers? Most importantly, even if the answer is that its impact is neutral (the experience the specialist provides is just as good as the one you would’ve been able to provide had you built the service yourself), it makes little sense to keep doing it yourself.

The first question - Will the service provide your application an innovation tailwind? - is often the only question product owners (e.g. developers, PMs, founders) ask, because you get the best of all worlds. Not only does consuming these types of services improve your product indirectly, by allowing you to offload a non-core element [and focus on differentiators], but they also directly improve your product due to their own product velocity. This speed of innovation also makes the decision more obvious for product owners, as it’s clear to them that they are not going to build something better internally (at least not on any reasonable timeline).

The second question - Can the service be substituted by another supplier? - is considered less often, but is usually applied in practice consciously or unconsciously. Unconsciously because if there is a clear market for a certain service, it implies that there are already many buyers, and since people generally just follow the crowd, they believe they should just buy [as opposed to a build] as well. Consciously, if there are multiple services that can be interchanged, then using a service here would create optionality. You can quickly get the product element you need up and working with a service, and if for any reason your business needs change you can easily replace it. Whereas, if something built in-house doesn’t work well, it can manifest in much greater loss aversion - a logical fallacy which results in an unnecessary waste of resources. Additionally, If you can swap services, then that market is already fairly well defined and is likely becoming commoditized, and rebuilding a well-defined commodity product doesn’t make good sense.

Ultimately, the driving force behind innovation and commoditization is competition, and in competitive markets, innovation is driven up and/or cost is driven down, and it’s relatively easy to understand how you benefit from this dynamic. Understanding these two questions and applying them to every product decision will get you far, but to fully benefit from outsourcing, applying the last question - Will the service provide a neutral to incremental experience improvement for my customers? - is critical.

This third question is the one that product owners rarely ask, but is key to developing a competitive advantage around product velocity. Essentially, the question prompts you to outsource any element that would not have a negative impact on user experience. This is the question that unlocks outsourcing, and drives the highest degree of focus to the few items that will truly differentiate your business. We’ll revisit this last question later.

For now, let’s touch on how to turn this question framework into a durable competitive advantage. Returning to Geoff Charles who we referenced in part 1, “Simply put, having the best product is not a competitive advantage. Everything can, and will, be bested. Having the best product development velocity and culture is what it’s all about.”

Importantly, the key here is to build a process around these three questions – staying abreast of developer tool innovations, regularly reviewing/reevaluating core vs non-core services, and then, fully leveraging dev tools where appropriate. Creating a process around this allows you to consistently maintain an advantage over time, and consistency over time is what generates true power.

Specifically, the ability to consistently maintain faster product velocity relative to competition, while also decreasing (or at least, without increasing) the cost of development is what Hamilton Helmer calls process power - an embedded company organization and activity sets which enable lower costs and/or a superior product - which confers a massive advantage.

Helmer notes that the major barrier to developing process power is hysteresis - the phenomenon in which outputs significantly lag inputs. In this kind of system the inputs must be sustained, in order for the resulting output to become realized.

Returning to the framework we outlined earlier, this is another reason why question #2, and especially #3 are harder to grok. In the first case, where you adopt a highly innovative product there is usually an immediate and understandable short-term benefit (no lag in output). In the second case, much of the benefit comes from the creation of optionality, which is less obvious, but still fairly evident, since the benefits of optionality can come into play at any time (short, medium, or long term). In the third case, the benefits of increased focus and a reduction in technical debt and maintenance are longer-term and compound over many years. This hysteresis is what makes question #3 non-obvious, and since your peers are likely not thinking about outsourcing to this degree, it’s also what makes it a potential competitive advantage that can be sustained.

In summary, you should outsource an element if the service: is as good as (or better than) what you would have built yourself, can be substituted for another, or provides an innovation tailwind. And most importantly, by turning this 3-question framework into a process that is regularly applied to product decisions, over time you can develop process power.