Make cyborgs, not software
Make cyborgs, not software
Most people in tech think they make products.
If you meet them at a bar, they might say: "My company makes software." If they are software engineers, they probably go to work thinking about the features they will implement, and the bugs they will fix.
But if all they do is make software, they will fail. And their companies will fail. And they will deserve to fail, because they have lost their way and forgotten their purpose.
The true purpose of every tech company should be to produce cyborgs. Tech workers, especially software engineers, often do not see beyond the veil of the user interface they build.
Beyond that UI veil, the world is full of uncertainty and things they do not control. Messy sacks of flesh ridden with irrational desires. Users who act like chaos monkeys, wreaking havoc on your plans. There are plenty of good reasons to ignore them.
But my startup makes cyborgs. You don't need prosthetic limbs, or an Iron Man suit, to be a cyborg. All you need is a human whose powers are extended by technology.
And the human is not just a sack of flesh, an accoutrement that gives us an excuse to build a palace of code. The tech is one half, and the human is the other. These are the two halves of the cyborg's original nature. Like Plato's lovers, neither one is complete without the other.
The human augments the technology just as much as the technology augments the human. How? Well, the human sees things that the technology can't. That is, a user makes choices technology cannot make, based on context that technology is not aware of. The tech is a function processing user input, and the human is a function processing tech input, and the world is a function processing cyborg input.
We want to enable cyborgs to send better input into the world.
Ephemeral cyborgs
People may only use the technology for a few moments, in which case, they are ephemeral cyborgs. That's fine. The cyborg is an emergent property of the interlocking of human and technology. Like a flock of birds, it emerges and dissolves.
When Vannevar Bush talks about the Memex, he is envisioning himself as a cyborg. When Douglas Engelbart talks about augmented intelligence based on a human-computer interface, he is talking about a cyborg. When Steve Jobs talks about computers as "bicycles for the mind", cyborgs.
What we're looking for, then, is to create those moments of emergence, when humans and technology become more powerful together. For both human and machine, it's almost a form of ecological release.
If you've ever been part of a tight feedback loop between product and users, where people want it so bad that they are using a product even though it's flawed, and coming back everyday to tell you what needs fixing, then you've seen a cyborg emerge. Those are your true integration tests. Birth can be painful. And exhilarating as hell.
Linguistic traps
There are other ways of saying "make cyborgs, not software." Paul Graham says: "Make something people want." Clayton Christiansen tells us to think about the "job to be done" by the product for the user. Kathy Sierra talks about turning users into "badasses."
All three of them are right, and the points they make are profound in their way, but I suspect there is a trap in their language, which is why I am writing this post.
If you talk about people and what they want, or products and what they do, then you end up thinking that the person and the product are separate.
They are not separate. Not when it matters. Each one is an extension of the other.
The moments you want to produce will blur the boundary between the user and the tech to create something larger. To think about them separately is to fall into a linguistic trap.
Cyborg, chimera, humachine
What matters is the cyborg as a system, the combination of user and technology. And ultimately how that hybrid being is able to operate and achieve its goals in a larger environment.
The Greeks used the word "chimera" to denote a "fire-breathing she-monster in Greek mythology having a lion's head, a goat's body, and a serpent's tail."
Later, the word would become shorthand for an illusion of the brain. But in genetics, chimera means "an individual, organ, or part consisting of tissues of diverse genetic constitution."
Anyone who has worked in a tech startup knows that the cyborg they mean to build starts out as a myth, and with luck, ends up as a real entity of diverse constitution arising from the meeting of their product with the people who need it. A fire-breathing she-monster.
Shoot me, but I like new words. Maybe the best ones to describe this new being and also slough off the connotations of cyborg and chimera would be "humachine," or in German, "Menschine".
Cyborg means product-market fit
The cyborg feedback loop, the reciprocal communication between those users and your product is the path to product-market fit. If that feedback loop is slow, broken, morbid or otherwise dysfunctional, you're not doing the thing you set out to do. You're failing, now matter how busy you feel, and how much "progress" you're making.
It's possible to spend months and even years building technology that you think the world needs (I have!), only to realize that you've wasted your time.
You and your engineering team can be extremely productive building all kinds of features, day after day, that will seem so cool and so necessary ... and the response will be crickets. That is because you are doing product development, and not cyborg development. You are neglecting half the system that you need to build.
By ignoring half the parts of your system, you are building something that will probably never be fixed. Because if you try to pivot that big half-thing, and glom it on to some innocent users, you will have a horrible case of tech debt.
The real challenge, then, is to find the humans who aspire to be a certain kind of cyborg, who feel that something is missing, and who will dive into cyborg development with you for free.
(The two biggest challenges in Silicon Valley are 1) bringing together the makers of technology with the potential human half of the cyborgs they seek to build; and 2) matching the capital with the cyborg development teams. The irony, of course, is that more than enough capital exists. More than enough aspiring cyborgs exist. And more than enough engineers exist. But they all face a deep and persistent matching problem in a market full of noise. Getting only one or two of those three things are the typical failures modes of the Valley. )
Sometimes the first volunteer cyborg is a founder of your company. Sometimes it is the husband or wife of the founder. But it always has to be somebody, and that somebody probably won't be paid much, if anything at all, for their work. (If you pay people for feedback, they are suddenly much less useful to create a cyborg. Most people, when asked about what you built, will lie to you to make you feel good. See The Mom Test.)
Good signs, bad signs
What are the signs that you're on the wrong path?
- You or the people close to you are not your users.
- You do not spend significant amounts of time in the same building with people who are your users.
- You have to hire consultants to do extensive user testing and research, to go find those users and understand them. (Especially in the early stages.)
- If someone asks you -- "Who's your cyborg right now?" -- you aren't able to answer in under two seconds.
What are the signs you are on the right path?
- You have more than one conversation per day between a super user and someone with authority and responsibility to build your product. A fast test-feedback-build cycle is the only momentum that matters early on.
- Those conversations change as you get deeper into the user's world, and you both discover more about their needs and use case, based on guided trial and error.
- Even with flawed technology, you see them closing the circle of value, doing the thing they sought to do, however imperfectly, and coming back with ideas about how to do it better, faster and more easily.