
Laws of Tech: Commoditize Your Complement (2018) - tosh
https://www.gwern.net/Complement
======
HillaryBriss
I've seen descriptions of this strategy before, but this particular article
lists _way more_ concrete examples than I've seen before, which makes me
wonder if it is now the default across the entire tech industry at all times.

Also: the strategy seems to depend upon a "greater fool," or just high risk-
takers to fill in the complement with what is ultimately low or zero profit
product. How can we guard against being that high-risk fool?

I mean, from the article, IBM tried to commoditize all of the peripheral
makers by publishing standard interface documents. But then they ultimately
lost out when Microsoft commoditized _the entire PC_ by licensing their OS to
other PC manufacturers. IBM didn't quite see this coming. They were out
commoditized.

OTOH, you look at the way Microsoft was paying app developers cold hard cash
out of pocket for listing apps in the MS mobile app store (which ultimately
failed) and you see that MS was out-commoditized by Google/Android/Play Store.

So how can _anyone_ be smart enough to spot the loser(s) in advance?

~~~
gwern
> I've seen descriptions of this strategy before, but this particular article
> lists way more concrete examples than I've seen before, which makes me
> wonder if it is now the default across the entire tech industry at all
> times.

If I missed any, I'm always happy to add more. (Sometimes the only way to
really nail down an abstract pattern for people is to provide an enormous list
of examples.)

~~~
HillaryBriss
well done. thank you. after i read it, i started to wonder if there are an
equal or greater number of examples where companies tried this strategy but
completely failed.

------
stcredzero
_Another way that I like to express that is "create a desert of profitability
around you". I once had a strategy professor define the Google business model
somewhat like that, where "Google tries to make every other business around it
free or irrelevant"…A desert of profitability shifts consumers to you, and
keeps competitors away._

Google seems to be doing this with YouTube and 10 minute online video
commentary.

------
ajuc
It should be called Spolsky's law :)

~~~
creamyhorror
Yeah, he deserves this one.

------
primroot
Somewhat unrelated, but doesn't this principle apply very often in
agriculture? I can see this as one of the reasons why only 12 plant species
provide 75% of world food. [0] I should say I take it as evident that raw food
is only a fungible commodity insofar as it adapts to market needs (which are
not necessarily immediate consumer needs).

[0]
[http://www.fao.org/docrep/007/y5609e/y5609e02.htm](http://www.fao.org/docrep/007/y5609e/y5609e02.htm)

------
zby
Another angle: [https://stratechery.com/2015/aggregation-
theory/](https://stratechery.com/2015/aggregation-theory/) The aggregated side
is the commodity.

------
firethief
See also: Google's support for Go, a language optimized for bus factors

~~~
dctoedt
> _Go, a language optimized for bus factors_

Can you say more about that? (I'm not much of a programmer and am not that
familiar with Go.)

~~~
firethief
_Bus factor: number of people with essential knowledge of the project such
that things would grind to a halt if they were hit by a bus._

[I'm by no means a Go expert, but languages are my thing and I have been
following Go's development.]

Go has an extreme focus on simplicity, to the extent that most of its virtues
and basically all of its faults can be attributed to this.

This includes simplicity of the language itself: I learned Go incidentally, by
referring to a program written in it when I was implementing an undocumented
protocol. You don't need to hire people who already know the language, because
it hardly matters; Go basically exists within whatever language they already
know.

It also includes a homogenizing effect. Different projects written in C++ can
use completely different corners of the language. Someone joining a Go project
has very little "how is this project written" to deal with--in fact, the only
advantages of Go I can think of that aren't rooted in simplicity are: _gofmt_
, a tool (and more importantly, a convention) for standardizing code style;
and goroutines, a standardized (and easy-to-learn) approach to the inherently
difficult problem of concurrency (that otherwise has a great diversity of
approaches).

So Go expands hiring pools by being so simple it's not important that
candidates have experience with it, and reduces onboarding time by making
projects as homogeneous as possible.

------
ham_sandwich
I think the key is to commoditize the complement when the complement is
embedded deeper in the value chain than your product.

~~~
stcredzero
IBM originally thought that software was the complement to hardware. Nowadays,
we think of hardware as the complement to software.

What does, "embedded deeper in the value chain than your product" mean in
layman's terms? Does it mean something which causally precedes the product?

~~~
mpweiher
> Nowadays, we think of hardware as the complement to software.

We used to think that.

Apple has been very successful in reversing that again on mobile, so software
is once again the complement.

"$1 for an app. Ripoff!!!"

