Why having a bias for building
JC’s Newsletter #191
Dear friends,
Every week, I’m sharing an essay that relates to what we are building and learning at Alan. Those essays are fed by the article I’m lucky enough to read and capitalise on.
I’m going to try to be provocative in those essays to trigger a discussion with the community. Please answer, comment, and ping me!
If you are not subscribed yet, it's right here!
If you like it, please share it on social networks!
Our bias is to build when the product/feature is core to our business.
The reasons why
Building sometimes looks like a long and hard path and often it seems that relying on third parties is operationally and financially less risky.
In fact, it is likely that outsourcing is much riskier from the point of view of member experience and capacity to learn and iterate. Building is also an opportunity to increase margin, as we remove intermediaries.
Many companies that decide to enter a business area in which they have little internal expertise or capability choose to outsource. They end up being only able to pick from a menu of options from their outsourced provider. At best, we would be fast followers of what the innovators built in those cases.
We can’t outsource a customized, integrated, end-to-end experience.
Outsourcing can be a classic example of short-term decisions with devastating long-term implications. When internalised, we can tweak our offering to make things a little better every day and we build knowledge.
By choosing to build, we are choosing to innovate. Each challenge overcome, each improvement made, and each unique offering developed in-house adds to our competitive advantage. It's a compounding effect — the more we innovate, the more we stand out in the market, and the more value we can offer to our members.
Building sometimes “sucks” because it is hard to do, takes time and requires focus.
That should not stop us.
How to decide? core vs. non core
1) What is core and should be built?
At Alan, we are intentional about those decisions. In order to do that we assess if something is core to our offering.
There is no perfect framework for that assessment, we have to take a step back to think about it every time we are confronted with this question.
Everything that directly affects our member experience or customer (admins) experience is likely to be core.
For example, if we want to be the most-member-centric company in the world, we believe we should own all the interfaces with our members. It is core to our experience.
We can use services as APIs or infrastructure to support us (such as AWS for example), and in the case of customer service, we could use the Intercom infrastructure to support our chat but we want to control every touch point. The infrastructure is in most cases non-core for us today.
If there are no perfect frameworks, there are still some frameworks that can help drive decision making and perhaps one of the most straight-forward is the Build vs Buy matrix:
High Strategic Importance, High Internal Capabilities: We "Build". This is core to our business and we have the skills to do it, like our user-friendly health insurance platform.
High Strategic Importance, Low Internal Capabilities: We "Invest" to develop these capabilities in-house, even if we currently lack the skills. If Alan were to develop an AI tool for personalized healthcare recommendations, that would fall in this quadrant.
Low Strategic Importance, High Internal Capabilities: We "Experiment" with building it in-house or we may outsource if it gives us access to economies of scale for example.
Low Strategic Importance, Low Internal Capabilities: We "Outsource". This is not core, and we don't have the skills so we outsource, like payroll processing or IT infrastructure.
If we decide to partner for something core, we should define a "trigger to build".
We define what we want to learn with a partner, how to exit from the partnership, what needs to be true for us to start building.
For each partnership, we should know about building: what to start with, how to do it well, and when.
2) Where does outsourcing/partnering offers advantages
a) Increased Flexibility:
Outsourcing gives the illusion we can adapt quickly to changing circumstances (even if stopping or changing a partner is often complex).
It allows to scale up or down based on fluctuating demand, without the need to invest heavily in infrastructure or human resources. That is why it is very useful for infrastructure or to manage peak demand (like customer service).
b) Access to economies of scale:
By outsourcing, we can tap into a pool of specialized skills and technologies, without having to invest in developing them in-house.
That is the case of AWS where building our servers would likely be a lot more expensive.
c) To test an assumption “faster”:
If we believe a partnership is easy to integrate (which is rarely the case) or we have access to “standard infrastructure” we need, it allows us to test an assumption faster than having to build it ourselves.
Sometimes, we want to validate the market hypothesis before investing too much resources, and that is when outsourcing/partnering can help.
We should be careful as people tend to always underestimate the cost/time of partnering.
3) But has negative second order consequences
While outsourcing may sometimes seem like a magic bullet for operational efficiency, it's essential to consider the long term second-order consequences:
a) Innovation constraint:
When you outsource, you lose the ability to iterate, improve and tailor your offering.
You lose the opportunity to push the innovation frontier and build a moat with your experience: you can at best be a fast follower of what the innovators built.
A classical example of this is Formula 1, where being a fast follower has never paid off. The Red Bull Racing team has been using external engines for many years, often slowing down their success due to poor performance and reliability. They decided to change to building in-house from 2021 and they are on the verge of winning 3 titles in a row.
b) Dilution of experience/brand:
By outsourcing, we need to trust a partner to take care of a part of product and service.
It means that we lose control over the quality of a part of our experience.
Because our product is also our brand, we actually risk diluting massively our brand, something that we have put relentless efforts in building from day 1. A happy customer talks to 3, a unhappy customer talks to 10.
From a member experience standpoint, outsourcing is actually much riskier than building in house.
c) Fake perception of time to market/energy to be spent
It's really really hard work to make a partnership work well and it's really hard to size the amount of time and mental load you will spend trying to make that partnership work for you.
We should be wary about false time-to-market, where we learn little because we have outsourced. To get product market-fit on something you usually need a lot of iterations, and they can’t be provided when you outsource.
There is also a fallacy that outsourcing is cheap: it takes a lot of time and energy to manage partners and make the partnership successful.
External examples and quotes
Ro co-founder on vertical integration:
“One of the benefits of vertical integration is that we actually can decrease the cost at every single touch point. We're not paying anyone else to do our jobs.”
Google and their servers:
They decided to build their servers in 2003. They looked at it holistically, to have control from soup to nuts. They didn't buy the prescribed notion that you must buy your servers from HP and couple it with a Cisco router and software from Linux or Windows.
Apple, and the M1 chip:
Significantly increased margin by going vertical and it was very hard. The M1 chip, while certainly expensive relative to any other chip Apple has made, is equally certainly cheaper than buying a chip from Intel. The estimate is about $50 cheaper for the MacBook Air, which translates into an extra 500 basis points of margin. That certainly qualifies as a “cost savings”!
OpenAI x Microsoft
The level of dependence that companies have taken on each other is a little bit scary. It probably makes us both a little bit uncomfortable in different ways, and no contract in the world can protect you for that.
The way it has worked is not what I would’ve thought, which is the clean, bright line delineation, but actually just very close collaboration at each step.
If you think about GitHub CoPilot, it was just a lot of work to figure out how to turn that into a product and it was work across a whole bunch of different teams. So multiple parts of OpenAI, multiple parts of GitHub, and multiple parts of Microsoft — and that one was especially complicated because it was three organizations that are working together.
With these things, you never get the org design right. You never get the partnership right. You never get the agreement right. It’s either you trust each other and you like each other and you work together in good faith and eventually you work it all out or you don’t and you never work it all out and none of the rest of it can save you.
Shopify
“if you’re a startup, try not to waste your time talking to big companies unless you’re doing it deliberately. They have an absolutely endless capacity to consume your time with meetings.”
The art of getting these partnerships right is really solution architecture: making sure from the very beginning that someone who understands every piece involved can get them lined up right, and interacting the right way, from the very outset of the project.
Unless you really fix things quickly, the interface between your two companies (and the mechanics on both sides) just compounds with problems on both sides, and never get really fixed – just patched over and over.
Niantic
Every time two companies are trying to do something in a cooperative way, that process is just harder.
I mean, I’m sure you see that even inside your own organization: when trying to make decisions — and when more and more people join the table — it becomes harder and harder to move quickly. We just didn’t think we’re going to be able to get it done.”
Some articles I have read this week
👉Completely Obsessed (Farnam Street)
More often than not, the person is the problem, not the incentive system. No incentive system turns mediocre into extraordinary.
👉 Weekly Health Tech Reads 8/27 (Health Tech Nerds)
We can solve every concerns
👉A boy saw 17 doctors over 3 years for chronic pain. ChatGPT found the diagnosis (today.com)
Interesting to note how inefficient was the system to work together to provide an holistic medical -> I believe the Alan clinic can improves this
Impressing see how ChatGPT can take a big number of sources to define a global
👉TKP Insights: Philosophy - The Knowledge Project (Farnam Street)
“ You will be provoked. You will be angry. But I want you to recite every letter of the alphabet before you do anything.” ➡️ be patient when something pisses you off.
Focus with obsession on a goal, hit it, move to the next.
Gratitude journal: write down five things every evening
👉Weekly Health Tech Reads 7/9 (Health Tech Nerds)
The power of weight loss!
Weight seems like a top problem.
It’s already over! Please share JC’s Newsletter with your friends, and subscribe 👇
Let’s talk about this together on LinkedIn or on Twitter. Have a good week!