Don’t be that API

On Versioning

If someone writes a line of code against your API today, it should work seamlessly and similarly in a decade.

Salesforce, whose force.com platform my cofounders helped make, sees things this way, and we’ve internalized that approach at Keen IO. API v1 was released a half decade ago. We’ve swapped out nearly every piece of the underlying system since then, but the API hasn’t changed. Calls to API v1 still work as advertised.

Twitter and Facebook on the other hand do not, and have created a legacy of abandoned API endpoints and end-of-life events breaking real business code. The developer community has a long memory for these sorts of infractions. If what you sell is ads like at those companies, maybe you can get away with this. If what you sell is the API itself, you should version strongly and deprecate rarely (or never!).


How to Build a Beautiful API Business

I’ve been studying API companies Stripe and Twilio since they hit the scene, first as an early user and customer of each. For the past 5 years, I’ve been running Keen IO, an API business which is modeled after both of them. These two companies, as well as SendGrid, are the elite examples of turning an API product into a business.

Here are the steps as we saw them and tried to reproduce them at our company, to some degree of effect, in our own market, broken down into 5 steps.

Product

In a self-service business with bottom-up adoption patterns, product is the most important ingredient in growth. In the API business specifically, this means first and foremost clean documentation around an elegant, painless, and rationally-designed API, plus a suite of SDKs that speak the local language without an accent. This sort of design is an exercise in threading the needle: if the API is too high-level, it won’t be customizable enough for broad developer adoption across use cases — and if it’s too low-level, it won’t be learnable enough to minimize time to eureka moment, nor expressive enough to minimize time to value. The true north in API design is to abstract away the messy, the repetitive, and the complicated — but to do so while still exposing enough flexibility/configurability to be useful in a variety of use cases, capturing nascent sub-markets quickly (and even without investment), before any non-API companies can form to address them. This is a critical advantage to future monetization, because the product’s Total Addressable Market (the sum of these sub-markets) grows on its own, in a more-or-less unbounded fashion.

Positioning

Telegraph that you’re a member of the developer tribe. The marketing sites, branding, documentation, and even HTML source code of Stripe and Twilio scream “there are legit software developers in charge of these companies.” While developers are growing in power and influence in the corporate world, that progress is uneven: only a small minority of companies have developers at the helm / on the board / in the C-suite, which means it’s still novel to see such tribal signal from a potential vendor. Since people like to buy from people like themselves, this gives these companies a huge advantage when it comes to selling to — and therefore selling through — developers.

Twilio’s landing page in 2017. Notice the “API key” call to action, and the logo-links to various developer libraries.

Viral placement

Create a global path to viral growth with a high K-factor. As I heard James Lindenbaum (founder of Heroku and Heavybit Industries) say a number of times: developer marketing has many elements of consumer marketing. Like all humans, developers like to find new products through word-of-mouth and their social graph. Unlike most humans, developers are not very susceptible to more in-your-face forms of persuasion, which makes word-of-mouth particularly important in this market. More than maybe any other profession, the viral distribution graph of developers ignores vertical (industry) and geographic lines, in favor of tech stack, community support, use case, and the social signals of who is using it (as Tim O’Reilly said, Follow the Alpha Geeks). How tactically you encourage this viral growth, once it exists, can vary: Twilio and SendGrid deployed dozens of magnetic, authentic developer evangelists on airplanes to visit local dev communities year-round; Stripe took another angle, focusing on online community & developer content channels. In the end, this leads to low (often zero) cost of sale, plus any paid customer acquisition costs are subsidized by the free acquisitions they bring downstream.

Utility pricing: metered, transparent, pay-as-you-go

As Jeff Lawson said at a recent conference, a revenue-generating customer starts at 1 cent. Sure, an account can grow to millions of dollars, but they don’t have to start that way, and pricing in this manner allows your customer’s monetary commitment to escalate gradually instead of in a step function. And yes, all things being equal, the finance people at the buyer would prefer monthly or annual consistency for all of their bills: but the engineering staff (closer to the utility and to the math driving their bill) sees things differently. Bundled, reserved, and flat-rate pricing can always be negotiated for enterprise and mid-market customers, but you won’t even get a chance to talk to a lot of mid-market customers unless their developers like your pricing model on the website.

There’s also a cultural advantage for the API company itself: usage-based pricing makes it possible to align the entire company around driving platform usage. Don’t underestimate the power of that alignment when compared to companies whose factions have warring incentives (for instance, at an open-source company who sells premium support packages, sales often develops a distaste for the free offering or the online community when it gives an alternative to buying anything). Hosted offerings can avoid this sort of problem altogether.

Keen IO’s metered, utility-based pricing (April 2017)

Customer support is sales — especially at first

Selling in this very different world requires a very different kind of sales motion. The inbound engine, viral growth, micro-transactions, and Power Law Distribution of account size mean that the very commercial nature of this business is more FarmVille than Workday. As such, digital onboarding, tutorial content, and especially customer support, are more important to get right first than sales and account management. Remember: driving usage is how you drive revenue. Later, once you add sales to the mix, this doesn’t really change because accelerating usage is the best way to start sales conversations. Each of these companies have really excelled at putting this new mode of thinking into practice.

This piece was adapted from a Quora post you can find here.

https://upsr.be/11c799/


Data Science Cultures: Archaeology vs. Astronomy

I’ve been writing a lot about intentionality in data science, about how having a sense of history (present and future), can be incredibly powerful for any enterprise.

Think about how archaeologists use data to seek the truth, as compared with how astronomers do it.

Clay pot remnants. Credit: Wessex Archaeology

Archaeology starts with digging. It’s all about studying the data that’s buried in the system (i.e. the fossil record), which means studying things that probably weren’t put there intentionally (depending on your belief system). Without a time machine, it’s impossible to change the structure of the record, to apply intention to the signal, so we do the best we can with what we’ve got: we mine through the accidental signals, discarding the (literal) mountains of noise, in an effort to find the truth about history. Perhaps as should be expected, this effort is expensive and leads to mixed results.

On the other hand, Astronomy is a very different field. Astronomy starts way earlier than digging — it starts with planting. At instrumentation-time, astronomers can point the telescopes where they want, measuring and recording the signals they want. Unlike archaeologists, astronomers have the ability to design the record and its structure, to choose the signals with intention. Doing this intentionally sets up the data record to yield the discoveries they already know they want to make, but also to be somewhat future-proof (which means it can yield unpredicted, emergent discoveries, to be harvested down the road — often by different people than the planters).

The spacecraft Dawn’s spiral descent toward dwarf planet Ceres. Credit: NASA/JPL

Now let’s compare the results of these two fields.

Astronomy (with its cousin Astrophysics) has taught us amazing lessons, things about the motion of the galaxy, the origin of the universe, and the underlying physical principles of multi-dimensional reality.

Turning our gaze to the stars, we learn about the earth. That’s pretty impressive.

Meanwhile, as of last year, Archaeology is still struggling to figure out how many years ago Homo sapiens emerged. And they can’t seem to agree on it, even though all the data is right under our noses. This isn’t because they’re incompetent (some of the best pattern-seeking humans in all of science work in archaeology), but rather because the data sucks.

Clearly, one of these truth-seeking disciplines is a lot more powerful than the other, and at Keen IO, we contend this is because they can control the data model. Data modeling is powerful indeed.

Inspection of any kind — be it human introspection or scientific inquiry — is more powerful when you can apply a variety of observational frameworks, choosing the best of them.


Platforms vs Products

Let’s talk about platforms.

The word “platform” doesn’t just mean “an ambitious product” — products and platforms differ, not merely by degree, but by kind.

When someone makes a product, they go after product-market fit: they do lots of smart things to predict it and act on these predictions.

On the other hand, to make a platform, a person must have the discipline and patience *not* to act on their predictions about market-fit. This is because, in a platform business, product-market fit is an emergent phenomenon: a product is a plan, but a platform is a heuristic.

Meanwhile, the analytical tools of the venture capital world are ill-equipped to detect platform potential, as they are plan-dependent.

The true economic advantage of a platform business is that it can harness unpredictability. A platform is antifragile: it eats chaos.

But traditional business thinking is all about *increasing* predictability at all costs. This sort of thinking clearly predates software.

One way software businesses increase their predictability is by disempowering + disbelieving their users. (“You’re not using it right!”). But a platform business does the opposite: it hands the users a bunch of Legos, then says, “We can’t wait to see what you build!”

A platform business intentionally creates disorder, because it knows how to gain from the disorder and its product competitors do not.

What a product company sees as distraction, a platform sees as adaptation. Inconsistency -> diversity. Redundancy -> fault tolerance.

Product companies emerge from an individual’s need to control. Platforms, from a collective’s need to empower.

The paradox in VC is that platform companies need a lot more capital to start moving, but have a harder time raising it.

One big reason for this is the attempt to make an apples-to-apples revenue comparison between product and platform companies.

But a dollar earned by a platform is far more valuable than a dollar earned by a product, because it is diversified across use cases.

A true platform is not merely diversified across the use cases that exist today, but across the unbounded set of what will emerge tomorrow.

A product company must continue to innovate — internally — at an ever-increasing rate in order to grow.

A platform company can rely on its *user community* to create an escalating innovation curve, which grows said community even faster.

Minecraft will be increasingly fun and drive increasing revenue, even if the game’s creators stop creating things, because it users will not.

A product business is best when it is predictable, like a factory farm. A platform business is the inverse, like a rainforest.

Photo by Victoria Reay.

A rainforest teems with surprises, spontaneously generating new medicines and new species. In a farm, a surprise is called a “weed”.

We celebrate Jobs for the iPhone, ignoring the fact that he opposed the App Store. Control freaks always prefer products to platforms

But it was the platform (App Store) that made the iPhone product successful. Control-based business thinking is a relic of slower times.

Platform businesses can generate enormous, longterm economic value that is indexed across many industries. But that growth takes time, and requires a few key ingredients:

  1. Humility — platform makers believe that the minds *outside* our four walls are greater than the minds *inside*
  2. Patience — don’t take the Legos out of the kid’s hands because they haven’t made anything cool yet: they will!
  3. Trust — it’s impossible to create a platform if you don’t trust your users to act on their own insights (or if they don’t trust you)

This post was adapted from a tweet storm from May 2015.

Keen IO is a cloud-based event data platform that lets businesses collect, enrich, stream, analyze, and act on historical events at a truly massive scale — all via API.


The Future of History

Brahe & Kepler

When people ask me why we wanted to start Keen, I tell them this story of two scientists.

Tycho Brahe by Eduard Ender (1822–1883)

Tycho Brahe was a Danish astronomer in the 16th century. You probably haven’t heard of him. He wasn’t a great physicist or mathematician, but he had a really important insight, which was that the astronomers of the day were spending a lot of time working with really bad data. The data was longitudinally large (hundreds of years of star charts, handed down through the ages), but crappy. Brahe realized that he couldn’t draw useful conclusions from poor data, so his first step was to re-instrument the universe with the right data model. In each of his nightly “data snapshots,” Brahe wanted to document the position, motion, and brightness of every single celestial object in the sky.

To accomplish this, Brahe built several versions of his own observatory from scratch. He built all his own instruments, and he kept such extensive records that he even built his own paper mill just to keep up — data storage wasn’t quite as cheap back then as it is today. And after sacrificing much of his fortune (plus over 30 years of nightlife), he suddenly died.

Tycho Brahe’s Uraniborg from Brahe’s book Astronomiae instauratae mechanica (1598)

Luckily he had an assistant named Johannes Kepler. You probably have heard of him. Kepler spent over 20 years running calculations on Brahe’s data. In the end, he devised the laws of planetary motion, which inspired the work of Newton and Einstein and the foundation of modern physics.

According to NASA, Kepler’s work “launched the scientific revolution.”

Historical data not only helps us study the past, but it allows us to figure out the laws of our universe, which provide our only glimpses into the future. Powerful stuff, that historical data!

Left: Brahe’s star data. Right: NASA’s modern view of space.

The Digital Observatory

Brahe was always the person in this story that stood out to me. He wasn’t a scientific genius and isn’t remembered by very many people, but in my book he was every bit as impactful as the famous Kepler (moreso, even — many Kepler-level thinkers had probably come and gone, but it wasn’t til one worked with Brahe that things fundamentally changed).

Brahe, armed with a custom-built observatory, was just a really practical, methodical, large-scale record-keeper — with high standards for precision and a very broad data model.

That’s pretty much what Keen is, too.

Keen is the modern observatory for the digital universe. The trillions of data points our customers are collecting will be the foundation for their future discoveries.

Cerro Tololo Inter-American Observatory in Chile. Credit: Abbott and NOAO/AURA/NSF

Observatory Design Considerations

The most important factors in building a good observatory are:

  1. the field of view
  2. the precision of the instrumentation
  3. the breadth of the data model

Beyond that, the most important factors for making those future discoveries more likely are the portability and the accessibility of the data.

Humanity was lucky that Kepler happened to work onsite with Brahe, because physical reams of paper aren’t all that portable.

Fortunately, thanks to the Internet, a modern observatory could transcend such physical barriers. Imagine a cloud API that modern Brahe-like people can use to measure their worlds. And every one of those Brahe-like people would be able to expose their data to far more than one Kepler-like person.

Logical map of ARPANET, which eventually became the The Internet

APIs

These concepts of portability and accessibility are the reason we took an API-first approach to designing Keen.

In data systems generally:

Portability is high if I can get all or some of the data into other systems easily, and higher still if the form of those other systems can be arbitrary. The highest level of portability in a data system would be an API for extracting full-resolution chunks of the data, combined with an API for streaming the data out wholesale.

Accessibility of the data is higher through a Twilio-inspired REST API like Keen Compute versus, say, a giant and arcane data lake stored in SAP or Oracle or HBase or Teradata. In the latter, the data is guarded by a department full of data adepts, who require lots of meetings before maybe choosing to spend months of magician-time to give you an answer. In those sorts of systems, the API to get to that data is meetings + corporate politics + waiting around. The API into Keen data is, errr, an actual API.

This is nice for humans who want answers, but it’s even nicer for applications that want answers, since applications can’t have meetings or play politics. All they can really do is use APIs.

To put it another way, a well-abstracted REST API provides extremely high data accessibility to anything connected to the internet. When developers use those APIs to build data into software, we can achieve an even higher level of information accessibility. The beauty of making data-powered applications is that developers can put data into the hands of ordinary people. They don’t have to be Keplers.

Software Developers

As Marc Andreessen famously wrote, software is eating the world. What he really meant is that software is taking over the economy. Yes, leave it to a VC to accidentally conflate the economy with the whole world — but still, his point has merit.

Building of the Golden Gate Bridge in San Francisco. Source.

If he’s right, then that means software developers will have an enormous responsibility in architecting the future economy. Developers will be its carpenters, its plumbers, its masons, its general contractors, its architects. They will build its bridges, its cities, its transportation systems, and its parks. Developers will build an increasing percentage of everything, and build into everything.

And increasingly, developers will choose which tools & technologies they build it with.

The things (products, apps, businesses) they build will be increasingly intelligent, in a variety of ways. One of those ways is that these things will have a sense of history. You might call them “history-aware products” or “history-aware applications” or “history-aware businesses.”

A Sense of History

Imagine you’re a software application.

You’re a bunch of bits of code and logic, creating and consuming an intricate symphony of information.

Got it? Good.

Now, what would it mean for you to have a sense of history? To be history-aware?

In my view, it doesn’t merely mean that you have a good memory, although that’s important. A good memory means you’re aware of — and can recall — what’s happened in the past. A perfect memory would allow you to instantly recall arbitrary facts in perfect detail.

Imagine you (the application) are running on a Fitbit in the year 2020. Every Fitbit in the world is running one of your brothers or sisters. Perfect memory would mean you know the answer to questions like these: What was the 90th percentile heart-rate of audience members during that one perfect scene in that one amazing horror movie? Was it different depending on time of day? On which theater they were watching in? On how much alcohol they had consumed beforehand?

Perfect memory alone is clearly powerful. And being able to access your entire tribe’s perfect memory just by issuing an API call is a superpower. As an application, calling an API is as trivial for you as it would be for a human to speak a word of English.

But to be history-aware isn’t just about knowing what happened in the past. More broadly, it means you’re aware that history exists as a concept.

The 10,000 year clock. Source: The Long Now Foundation

What would it mean for you, the software application, to be history-aware in this way?

Not only would you remember all the events that happened previously and be able to run calculations across them, but that you would record your own observations in detail (like Brahe), so that in the future, other history-aware applications (including yourself in a future timeline!) can possess that same kind of perfect memory. For its members to have perfect memory, the entire tribe has to diligently record events as they pass.

Being a smart citizen means being aware of the history that’s already occurred. Being a good citizen means being history-aware in this broader context.

If you were a software application, this is a superpower you would probably find compelling.

Looking Forward

Much of the future economy will be built by developers. With great data tools and a sense of history, developers will not only make us contextually smarter, they will lay a foundation for ongoing discovery.

At Keen, our mission is to provide a ready-made digital observatory so that they don’t have to spend years building one like Brahe did.

The future is a place where anyone can study their universe or, like NASA did when they took Keen for a one-day spin, discover a pattern that has been eluding them for over a decade.

(And I think Kepler would find that pretty rad.)

Thanks to Michelle Wetzler, Micah Wolfe, Patrick Woods, Seth Bindernagel, Ursula Ayrout, inconshreveable, Sunil Dhaliwal, Ryan Spraetz, and Elias Bizannes for editing help.


Apache Kafka vs Amazon Kinesis to Build a High Performance Distributed System

At Keen IO, we’ve been running Apache Kafka in a pretty big production capacity for years, and are extremely happy with the technology. We also do some things with Amazon Kinesis and are excited to continue to explore it.

Apache Kafka vs Amazon Kinesis

For any given problem, if you’ve narrowed it down to choosing between Kinesis and Kafka for the solution, the choice usually depends more on your company’s size, stage, funding, and culture than it does on your use case (although I believe that for some use cases, the answer is obviously Kafka, as I’ll get to later). If you’re a Distributed Systems engineering practice, have lots of distributed dev ops / cluster management / auto-scale / streaming processing / sysadmin chops, and prefer to interact with Linux vs. interacting with an API, you may choose Kafka regardless of other factors. The inverse is true if you’re more of and web, bot, or app development practice, are fans of any services like Amazon RDS, Amazon EC2, Twilio, and SendGrid more than services like Apache ZooKeeper and Puppet.

In somewhat-artificial tests: Kafka today has more horsepower out of the box on rough numbers. Thus Kafka today can be tuned to outperform Kinesis in terms of raw numbers on practically any given test– but are you really going to do all that tuning? And are those really the factors that matter most to you, or are there other pros and cons to consider? By analogy: a Corvette can beat a Toyota Corolla in a lot of tests, but maybe gas mileage is what matters most to you; or longevity; or interoberability? Or, like lots of business decisions, is it Total Cost of Ownership (TCO) that wins the day?

What follows is a bit of a side-by-side breakdown of the big chunks of the TCO for each technology.

Performance (can it do what I want?)

For the vast, vast, vast majority of the use cases you may be considering them for, you really can’t go wrong with either of these technologies from a performance perspective. There are other great posts (Ingestion Comparison Kafka vs Kinesis) that point to the numbers demonstrating where Kafka really shines in this department.

Advantage: Kafka — but performance is often a pass/fail question, and for nearly all cases, both pass.

Setup (human costs)

I would say Kinesis more than just slightly easier to set up than Kafka. When compared with roll-your-own on Kafka, Kinesis abstracts away a lot of problems (you mentioned cross-region stuff, but also you’d otherwise have to learn and manage Apache ZooKeeper, cluster management/provisioning/failover, configuration management, etc). Especially if you’re a first-time user of Kafka, it’s easy to sink days or weeks into making Kafka into a scale-ready, production environment. Whereas Kinesis will take you a couple of hours max, and as it’s in AWS, it’s production-worthy from the start.

Advantage: Kinesis, by a mile.

Ongoing ops (human costs)

It also might be worth adding that there can be a big difference between the ongoing operational burden of running your own infrastructure (and a 24-hour pager rotation to deal with hiccups, building a run book over time based on your learnings, etc — the standard Site Reliability stuff), vs. just paying for the engineers at AWS to do it for you.

In many Kafka deployments, the human costs related to this part of your stack alone could easily become a high hundreds of thousands of dollars per year.

The comment below is right: That ops work still has to be done by someone if you’re outsourcing it to Amazon, but it’s probably fair to say that Amazon has more expertise running Kinesis than your company will ever have running Kafka, plus the multi-tenancy of Kinesis gives Amazon’s ops team significant economies of scale.

Advantage: Kinesis, by a mile.

Ongoing ops (machine costs)

This one is hard to peg down, as the only way to be _certain _for your use case is to build fully-functional deployments on Kafka and on Kinesis, then load-test them both for costs. This is worthwhile for some investments, but not others. But we can make an educated guess. However, as Kafka exposes low-level interfaces, and you have access to the Linux OS itself, Kafka is much more tunable. This means (if you invest the human time), your costs can gone down over time based on your team’s learning, seeing your workload in production, and optimizing for your particular usage. Whereas with Kinesis, your costs will probably go down over time automatically because that’s how AWS as a business tends to work, but that cost reduction curve won’t be tailored to your workload (mathematically, it’ll work more like an averaging-out of the various ways Amazon’s other customers are using Kinesis — this means the more typical your workload is for them, the more you’ll benefit from AWS’ inevitable price reduction).

Meanwhile — and this is quite like comparing cloud instance costs (e.g. EC2) to dedicated hardware costs — there’s the utilization question: to what degree are you paying for unused machine/instance capacity? On this front, Kinesis has the standard advantage of all multi-tenant services, from Heroku and SendGrid product to commuter trains to HOV Lanes: it is far less likely to be as over-provisioned as a single-tenant alternative would be, which means a given project’s cost curve can much better match the shape of its usage curve. Yes, the vendor makes a profit margin on your usage, but AWS (and all of Amazon, really) is a classic example of Penetration Pricing, never focused on extracting big margins.

Advantage: Probably Kinesis, unless your project is super special snowflake.

Incident Risk

Your risks of production issues will be far lower with Kinesis, as others have answered here.

After your team has built up a few hundred engineer-years of managing your Kafka cluster — or if you can find a way to hire this rare and valuable expertise from the outside — these risks will decline significantly, so long as you’re also investing in really good monitoring, alerting, 24-hour pager rotations, etc. The learning curve will be less steep if your team also manages other heavy distributed systems.

But between go-live and when you have grown or acquired that expertise, can you afford outages and lost data in the meantime? The impact depends on your case and where it fits into your business. The risk is difficult to model mathematically, because if you could a given service outage or data loss incident well enough to model their impact, you’d know enough to avoid the incident entirely.

Advantage: Kinesis

Conclusion

In conclusion, the TCO is probably significantly lower for Kinesis. So is the risk. And in most projects, risk-adjusted TCO should be the final arbiter.

Addendum

So why do my team and I use Kafka, despite the fact that the risk-adjusted TCO may be higher?

The first answer is historical: Kinesis was announced in November 2013, which was well after we had built on Kafka. But we would almost certainly choose Kafka even if we were making the call today.

Two core reasons:

  • Event streaming is extremely core to what we do at our company. In the vast majority of use cases, data engineering is auxiliary to the product, but for us it is product: one of our products is called Keen Streams, and is itself a large-scale streaming event data input + transformation + enrichment + output service. Kafka helps power the backbone of the product, so tunability is key for our case.
  • Nothing is more tunable than running an open source project on your own stack, where you can instrument and tweak any layer of the stack (on top of Kafka, within Kafka, code in the Linux boxes underneath, and configuration of those boxes to conform to a variety of workloads). And because what we sell is somewhere between PaaS and IaaS ourselves, and because performance is a product feature for us as opposed to an auxiliary nice-to-have on an internal tool, we’ve chosen to invest heavily into that tuning and into the talent base to perform that tuning.
  • Apache Kafka is open source and can be deployed anywhere. Given that infrastructure cost is a key input to our gross margins, we enjoy a lot of benefits by being able to deploy into various environments — we’re currently running in multiple data-centers in both IBM and AWS. Meanwhile, data location is a key input to some enterprise customers’ decision-making process, so it’s valuable for us to maintain control over where all of our services, including the event queue itself, are deployed.

At Keen IO, we built a massively scalable event database that allows you to stream, store, compute, and visualize all via our lovingly-crafted APIs. Keen’s platform uses a combination of Tornado, Apache Storm, Apache Kafka, and Apache Cassandra, which allows for a highly available and scalable, distributed database. Have an experience or content you’d like to share? We enjoy creating content that’s helpful and insightful. Enjoyed the article? Check us out! Or email us– we would love to hear from you.


Two emails within the Wild family

Two emails within the Wild family

It happened again.

I received a chain email, forwarded from an unknown source and full of suspicious truthiness from my family back home. If you also grew up in the Bible Belt or on the Mason-Dixon Line, you probably won’t find this surprising.

Here’s the email they sent me:

https://gist.github.com/dorkitude/5fc51c4113d2d6bd0608

After over a decade of refuting this sort of garbage just by doing a simple Google search, I realized I wasn’t getting anywhere. So here’s what I wrote in response:


From Judge Kithil himself: “I’ve had calls from all over the country, 300 to 400 calls over three or four years on this,” he said. He pleads with the callers, “Don’t pass it on. It’s not accurate anymore. Trash it.”

This chain letter has been passed around the internet for five years. Like nearly all of these letters, it plays on fallacy in the logic of the reader.

Outrage is supposed to work like this:

  1. Learn something.
  2. Feel outraged.

But with opponents of Obamacare, I often see outrage working like this:

  1. Feel outraged about Obamacare.
  2. Latch on to each excuse that, if true, would justify that outrage.

The problem with this reversal of how one comes to believe something is that, when things are done in this order, there’s no will to disprove or fact-check. Rather, there’s significant will to believe at face-value, shortly followed by hitting “forward”. And so it goes, and goes, and goes, and so do many other falsehoods, and in combination these falsehoods serve to whip up the fervor of the base. Letters like this weren’t written by regular Americans, but rather, by shrewd political strategists who know how to manipulate the fears of their base.

Because you deeply want that outrage to be just, and believe it to be just, these “facts” also flow directly into your belief system — without having been passed through the rigor you normally apply to things — and as soon as these new “facts” register in your belief system, the outrage ratchets itself up another couple of steps. And then you’re even more susceptible to propaganda the next time. This positive feedback loop is how propagandists create fervor.

And once you’ve felt the fear and the outrage, you can’t unfeel it without a lot of honest self-reflection. In our busy world, most people don’t get enough time for honest self-reflection, and so the fears and anger persist even after the “facts” are revealed to be false. And so these lies, even if you only believe them temporarily, have permanent emotional impact: Humans have far deeper emotional memory than rational memory, and particularly (like all mammals), we have a very strong sense of fear memory: it doesn’t matter whether I rationally believe something is going to “jump out” of the dark and grab me, I still find myself running through the dark to the light switch, just like I did as a kid. Even with no real stimulus, my fear memory is strong (the amygdala has an immense amount of control over the brain.)

Moreover, once you’ve hit “forward”, you’ve passed this damage onto other people, and you can’t undo that damage either. And so it grows way beyond you.

There are a group of political strategists who have whipped up a toxic blend of fear and rage so strong that from my perspective it appears that nearly anything they write will now be believed and repeated by millions of Americans, so long as it’s sufficiently anti-Obama or anti-Obamacare. People have strong feelings in search of a rationale, rather than letting the honest, slow accumulation of a rationale drive their feelings. This is how people control crowds. This is how people start wars. This is how devious leaders rally the worst parts of human beings (fear, anger, and intellectual laziness) into what eventually becomes devastating action. Throughout human history it has been the intentional, manipulative application of emotional language that has led to war, genocide, and other atrocities committed en masse. The people committing these atrocities weren’t “bad” people — rather, they were just regular human beings who were then suspectible to the same kinds of mass manipulation that we are still susceptible to today, and who were gradually coaxed into becoming the monsters they became, by the men who had premeditated it all along.

I’m not asking you to change your opinions about Obama or Obamacare, though. It’s too late for that.

Just make sure you’re not being played, and for the love of God, don’t hit “forward” on this garbage unless and until you’re certain you aren’t helping add fuel to the fires of irrational hatred in our country. There are plenty of rational reasons for us to disagree, but it will be impossible to work together constructively towards solutions if people on both sides are buying into all this bullshit, letting this bullshit drive artificial wedges between us.

Pardon my French.

-kw


Entrepreneurship and Depression

Photo by Arkady Lifshits

In 2014, Brad Feld published a very heartfelt blog post on depression in startups called Founder Suicides. If you haven’t read it, please do.

Seriously, you have to go read it right now.

I’ll wait here.

So, I was in an emotionally vulnerable place when I came across Brad’s article, and it moved me to tears. It also moved me to write publicly about my own struggles with depression for the first time, and I did so in a lengthy comment at the bottom of the article. After reading my comment, some of my colleagues (including my wife Michelle Wetzler — probably the only person in the world to whom my comments didn’t come as a surprise) encouraged me to surface these remarks in a more accessible location, so other entrepreneurs could find them.

I deferred and demurred and delayed because, frankly, I was terrified of sharing this “unfortunate aspect of my brain chemistry” with you all in a more public forum — I was afraid of what it would mean for my reputation and for my business, but most of all, for my own internal sense of identity. Every time you say a true thing out loud, it becomes even more true.

Sure, what I had written was already out there on the World Wide Web, but it was buried at the bottom of a post on someone else’s blog, behind several clicks of the Load more comments button. Given its placement, even the people who did find it were sure to be supportive (and they have been). I felt comfortably distanced from it, and I couldn’t find the courage to reduce that distance and stand by what I wrote.

But today, I sat down with a good friend who’s a founder of a local startup and was seeking my advice. In our conversation, I realized that I was re-hashing many of the concepts from my post on Brad’s blog, and that it was helping this person. It hit me that people really needed to hear this stuff, and I needed to buck up.

So in the hopes it can help more people, I’ve reproduced my response to Brad’s blog below (you can also read it via this direct link).


This is an important and powerful post. Thanks for writing it, Brad.

My two cents below.

I’ve struggled with depression (from 1 week to 6 months at a time) at several junctures in my career, and I’m sure it’ll happen again. I’ve found that my best tools for coping with this unfortunate aspect of my brain chemistry are endurance exercise, meditation, musicianship, adventure travel, reading philosophy books & dialogues, and talking to people like Brad and Jerry.

Here’s the thing, though: these tools only work for me when I have adequate time and space in which to deploy them. But the predominant work culture in tech startups today is a culture of overwork; it’s a culture that eats away at one’s time and one’s space.

When an entrepreneur and/or their business is really struggling for an extended period of time, the main advice they hear from the echo chamber is to “keep hustling”, “shake more trees”, “leave no stone unturned”. I would submit that the advice they need to hear in those times is more like “climb a mountain”, “go for an inter-state bike ride”, “go to Burning Man”, “take a 5-day silent meditation retreat”, “go zip-lining across Costa Rica”, or the less extreme “try working half-days for a couple weeks”.

And yet, the knee-jerk response a founder hears when they do this sort of thing is “How can you leave your company for that much time? Are you not committed to it?” I know this, because I’ve heard this kinda stuff my whole career. Yes, I’m committed to the company! That’s precisely why I need to separate myself from it sometimes!

Ben Horowitz wrote in a great post on entrepreneurship (although I disagree with the ending): “The Most Difficult CEO Skill is Managing Your Own Psychology.” And as it turns out, most humans possess a psychology that requires taking breaks. Real breaks. Total disconnection from The Project At Hand. I believe this is even more critical for humans with clinical depression.

The eureka moment that breaks a spiral of depression can happen early in the cycle, late in the cycle, or (for those poor souls whom we’re mourning today) never. It can come in the form of a new personal psychological strategy, a silver lining, or a glimpse of meaning and purpose. It manifests as a sometimes sudden, sometimes gradual, but always visceral sensation of healing, and I’ve seen it be triggered variously by intense feelings of love, joy, laughter, connectedness, and awe. But here’s the catch: these intense, positive feelings are pretty hard to come across when you’re in grind-only mode for months on end.

As a community, we are setting people up to fail at developing this Most Difficult CEO Skill by creating workplaces that reinforce the idea that taking a break is a Bad Thing; workplaces that systematically fuse the concept of disconnecting with the emotion of guilt.

As a community, we are screwing this up, and people are fucking dying from it. We’ve got to fix this.

But I’m not merely trying to make a moral argument here — I’m making a capitalist one as well. Because I am pretty certain that we will see better business outcomes from companies who reject this culture of overwork as the poison it is. As an accidental byproduct of the industrial economy — a time when capital outputs scaled linearly with labor inputs.

That’s not how the tech industry works. This is an industry where success is derived from nonlinear outputs.

This is an industry that monetizes breakthroughs. And a breakthrough can only enter a clear mind.

A brilliant product strategy, a flash of the perfect pitch, a connection between seemingly disparate areas of business, a re-invention of go-to-market principles, a sudden synthesis of old wisdom into new, a clever design to solve an unprecedented engineering problem — these are the things that make a tech company great in a nonlinear fashion. This sort of lightning doesn’t strike very often when you’re in the weeds for 30 days in a row, and I know founders who’ve been in the weeds for a thousand days in a row (this isn’t an exaggeration).

This is why it’s strategic to reject the culture of overwork (not to mention the advantage such a company would garner in the talent market).

One thing my cofounders and I have been reflecting on a lot lately is that, when you’re faced with a decision, and one of the options before you is both highly strategic (examined in the most cynical light) and highly ethical (examined in the most idealistic light), the decision is easy.

We have to stop glamorizing the grind, stop the founder martyrdom, stop reinforcing the hero complex. Stop squeezing the lemon, when we should instead be figuring out how to build sustainable lemon orchards. Stop telling everyone to work harder instead of smarter, because we’re making their lives harder instead of making them smarter. And people are fucking dying from it.


A Major Milestone: Announcing Our Partnership with Sequoia Capital

Doubt and Hope

The story of any new endeavor is, at its core, a story about the twin forces of doubt and hope.

As a mentor for various startup accelerators, I get to meet a lot of new founders and see a lot of patterns. One pattern that stands out is that, when you start a company and begin to talk about your vision with new people, you’re probably going to meet a typhoon of doubt.

You might say the entire job of a new founder is to convert that doubt into hope, one person at a time, at an ever-increasing rate, until the consensus is one of hope instead of one of doubt. This is difficult and courageous work.

We’ve been doing this work for 2 ½ years ourselves, and we have certainly encountered our fair share of doubts. More than 60 investors turned us down in our first two years, and we were within 1 payroll cycle of running out of cash on multiple occasions. Doubt can swallow your company up like a plague, but we were either brave enough or stupid enough to keep trying.

I’m glad we did.

Nowadays we find ourselves surrounded by an incomparably positive, thoughtful, patient, and creative group of people — customers, partners, investors, and colleagues — all of whom share a sense of hopefulness about this company.

Today, we’re excited to announce we have joined forces with a new group of people who are hopeful for our success and share our vision for the future: Sequoia Capital.

About the Deal

We’ve raised a round of Series A financing worth $11.3 million, led by Sequoia Capital, with participation from our returning investors, Pelion, Amplify, and Rincon. Cloud Power Capital and one of our earliest angel investors, Morris Wheeler, also participated in the round.

It’s no secret that Sequoia is one of the most storied venture capital firms in the world. After all, they discovered Apple and Google and too many other great companies to name. But what drew us to this firm was the people. I have never met a group of people quite like the Sequoia team. They are at once intellectually challenging and collaborative, at once futuristic and pragmatic, at once eminently competent and humble. We are proud to call them partners — especially our newest board member, Aaref Hilaly, an extremely insightful human being with over a decade of firsthand entrepreneurial experience.

We will lean heavily on Aaref’s and Sequoia’s experience and advice as we continue on our quest to build a sustainable, long-lasting business.

Progress to Date

Developers from all around the world are showing up in ever-increasing numbers to invent new things on the Keen IO platform. Our customers are using our API to build a sense of history into a wide and fast-growing array of internet-connected products — from online games to SaaS email services, from smart watches to wifi lightbulbs, from automatic realtime bidding for ad placements to in-app dashboards for their customers.

While we predicted some of these use cases, most of them have totally surprised us. We continue to be surprised by the ingenuity of our developer community every single day, and our growth rate is accelerating remarkably quickly.

Usage of the Keen IO platform (measured by data volume) is up over 300% in 2014 so far, and it grew 50% month/month in April alone. Our platform has net negative churn, meaning that each month, our customers are far more likely to upgrade their accounts by X amount than to downgrade by X. To boot, we’ve accomplished all of this without a marketing budget: our customers come to us inbound via word-of-mouth.

Use of Funds

As of today, the plan is to establish a marketing budget, move into our own office, and staff up our increasingly diverse team.

On the hiring front, we’re currently looking for distributed systems engineers, web developers, open source developers, copywriters, partnership builders, and salespeople who are mission-driven (not commission-driven). More important than background is personal outlook: we like to hire broad, learning-oriented people who are introspective and collaborative in nature. Sound like someone you know? Have them email me at kyle@keen.io

Thank You

To our customers, developer community, the partners who’ve been with us for years, and the partners who just joined us this month:

Thank you for believing in us. The journey is just getting started.

Let’s make great things together!

Kyle Wild
Co-founder & CEO
on behalf of the entire team @ Keen IO

P.S. Thanks to Techstars for taking the very first bet on us :)


The dark side of HackerNews: negativity at best, suppression at worst

I’ve always been a believer in the open discussion promoted by HackerNews, a programmer & tech industry community I’ve been involved in for several years. In recent times, the emotional undercurrent in the community has gotten more negative, and I heard dozens (I dare say hundreds?) of my friends and colleagues mention this in 2012, and I fear it is accelerating.

But I still hadn’t really lost faith in HackerNews until this morning.

This morning, Michelle wrote a thoughtful post on this blog about sexism in tech, and she added it to HackerNews for discussion. In my opinion, Michelle’s dealing was completely fair and even-handed, but the reception on HackerNews was mixed. That’s not surprising, because like anything else involving civil rights of a minority, sexism in tech is a hugely controversial topic. Because of that, and because many different voices can be heard on HackerNews, we expected a lively debate.

That’s part of what I love about HackerNews. It’s a community given toward open and honest discussion. And however uncomfortable it can be at the time, I believe honest discussion creates more fairness in the longterm (it’s no mistake that one of our core values here at Keen IO is Confrontation Without Hostility and another is Radical Transparency, which is the name of this blog). I believe open & honest discussion, like what HackerNews promotes, is an accelerant to justice of all kinds, especially social justice.

“The arc of the moral universe is long, but it bends toward justice.” — Martin Luther King, Jr.

Within about ten minutes, Michelle’s post had about 20 comments, from different perspectives, and it was on the front page of HackerNews.

The debate raged for about an hour, and then out of nowhere, new post activity slowed markedly. A friend pointed out to us that, for some reason, Michelle’s post had been buried on the third page!

Now I’ll drop the formal tone. Something seriously fucked up is going on here. The numbers don’t add up.* Either:

  1. The post is being flagged en masse by our fellow HackerNews community members.
  2. Or the post is being intentionally suppressed by someone closer to the top of HackerNews.

Neither scenario makes me proud of HackerNews.

I’ve lost faith in HackerNews in the short term. I’m standing up and saying something about it because, hopefully, we can remedy this in the long term. After all, drawing attention to justice-oriented problems is most important ongoing tactic in solving them.

That’s all Michelle was trying to do in the first place.

-kw

* On the numbers: Here’s a screenshot of her post, ranked 82, despite having 88 comments in an hour. If you’re not familiar with HackerNews, here’s another screenshot for reference — it depicts the front page of HN at the same time, and far less active topics occupy the top five.


How to Write Your Demo Day Pitch

My cofounder Ryan recently published a very well-received post on how to practice and deliver a Demo Day pitch. I hope this post on writing will serve as a natural companion to Ryan’s post on performing.

image

I’m a big believer in Stephen Covey’s principle of Begin with the end in mind. So for starters, let’s talk about the goal.

Know your goal.

Think about it: why are you pitching at Demo Day in the first place? What’s the goal?

Most founders tend to answer with some variant of “to raise capital for my startup,” “to get published in TechCrunch,” or “to get Nike or Ikea etc. to become a customer.”

Of course these are all fine goals to have. But, these goals aren’t super instructive when it comes to designing your pitch, because they’re too long term. There isn’t a direct/adjacent causal relationship between pitching and any of these happy outcomes — it’s hard to imagine a world where you step off the stage at Demo Day and immediately someone writes you a check. The best you can really hope for is to get a first meeting.

So we’ve identified our goal: when you’re pitching at Demo Day, the goal is to get a first meeting.

Now on to some strategies that might help you achieve that goal :)

Grab credibility early.

If you’re credible (and I hope you are), demonstrate this fact early in your pitch.

If you’re looking for inspiration on what to say, just pretend your audience is asking you these questions: Why should I pay attention to the rest of your pitch? Why should I make an effort to remember your pitch instead of one of the many others I’ll hear today?

For example, did your team quit their jobs at Facebook to do this? Did Mark Cuban and Marc Benioff both invest in your company? Have Nike and Adobe both signed up to use your service in the last week? Might want to mention that.

If I wanted to write the credibility grab for this blog post (and I do, because I want you to know why I’m credible so you’ll keep reading!), I might communicate one or more of the following things:

  • Nine months ago, my company (Keen IO) gave the opening pitch at the inaugural TechStars Cloud Demo Day. I co-wrote the pitch with my cofounder Dan, and it was a massive success.
  • We invited our top three recruitment choices to come watch us at Demo Day, and within a month, all three of them joined the team!
  • We successfully raised a heavily oversubscribed seed financing from a brilliant investor group.
  • Our pitch was among the highest-rated pitches in TechStars history.
  • Two months after Demo Day, we were invited by GigaOm to compete at their Structure LaunchPad pitch competition, where we won first prize!

Phew. So. Now that you know why I’m a credible author on the subject, aren’t you more curious about the rest of this blog post?

That’s exactly the sort of curiosity you need to build in your audience on Demo Day.

If you have traction, lead with traction.

On a recent Geeks on a Plane trip, I heard my friend Dave McClure give this advice on stage at least a half-dozen times: If you have traction, lead with traction.

I couldn’t agree more, and I think traction is the best of all credibility grabs. Traction inoculates your audience against disbelief. Regardless of how well they understand your business from a five minute pitch, investors know they can rely on evidence of traction as a proxy for such understanding. Often, traction alone is enough to get the first meeting!

Priorities are: Entertain, Impress, Inform (in that order).

People will forget what you said. But people will never forget how you made them feel.

-Maya Angelou

The biggest mistake I see in Demo Day pitch content is this: most pitches focus far too much on information and far too little on entertainment.

This is one of Nicole Glaros’ (TechStars) golden rules. I firmly believe it’s the key to successfully pitching at Demo Day — that is, the key to getting a first meeting — is to prioritize your content in this order: Entertain, Impress, Inform (I don’t mean temporal order, but rather order of importance).

When it comes to the information in your pitch, less is more.

Substance is overrated.

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius — and a lot of courage — to move in the opposite direction.

- Albert Einstein

If you’re feeling uneasy about removing substance from your presentation and focusing instead on style: I get it. You’re a super-smart team, and you’ve been working all day and night to make something you’re passionate about. Your business is a complex and integrated web of concepts, technologies, and people, and you and your cofounders hold the whole damn thing in your heads. You’re aching to express all of these insights to the world, because you don’t want to risk having anyone in the room walk away from Demo Day with any doubts about your business or your team’s understanding of your business.

I get it.

But there’s a whole universe of potential doubts. You can’t preemptively defend against this universe of doubt in a single pitch.

Also, I’m not saying to have zero substance, just to have the right substance, and to remove the wrong substance. During TechStars, Nicole told us, “The audience is only going to remember two or three points from your pitch.” If that’s true, then isn’t the best strategy to be intentional about those two or three points? If you’ve buried them with hundreds of other little factoids, it will make it harder to remember the two or three things that you want them to remember.

I remember spending a lot of time during TechStars soul-searching with Dan and Ryan about this one, and the resulting clarity was super valuable both for our pitch and for our actual business. We decided our message would be: (1) We’re a killer team that’s (2) reinventing analytics. (3) We’re focused on mobile first.

It’s certainly possible that giving a rapid-fire-jargon-heavy-brain-dump of your business can get you a meeting with some super smart audience member — an audience member who has the domain expertise and the brainpower to process your entire company strategy even when it’s compressed down to a few minutes of realtime theater. But you could also get their attention with a more minimal pitch, so why alienate everyone else in the audience?

Reduce communication bandwidth.

During TechStars, I remember Jason Seats telling a lot of the teams (not least our own) that they needed to “reduce communication bandwidth.” Rather than dwell on the hypocrisy of those three words, I’ll explain what he meant and why he said it.

Here’s what happens if you try to explain your whole business in a five minute pitch: You find yourselves running up against the time limit, and there are only a few ways you could cram more information into a fixed-length pitch. First, you could speak faster, which is bad for listener comprehension. Second, you could use bigger words and more abstract jargon, which is bad for listener comprehension. Finally, you could pile a bunch of extra visual information into the slides themselves, which is just plain awful for listener comprehension.

Rather than trying to optimize for more information by increasing the communication bandwidth of your pitch (i.e. saying more in the same amount of time), you should probably be optimizing for more entertainment and clarity by reducing it.

And honestly, what’s the point of jamming in all this information in the first place? After all, recall that the stated goal of your pitch is not to deliver a firm understanding of all of the intricacies of your business. The goal isn’t to educate them about your market, your team, your traction, your corporate history, whatever. The goal isn’t even to wow everyone with a sexy product demo. Sure, your pitch will include some (or all) of these pieces of information, but those are not the goal. Remember: the goal is to get a first meeting.

For further reading about this, I highly recommend Words That Work: It’s Not What You Say, It’s What People Hear, by Frank Luntz. I read it during TechStars, and it had a huge impact on the specific word choices we made in our pitch. In case you don’t want to invest in reading the whole thing, I dug up this review, which has a decent summary.

Entertainment equals storytelling.

Everyone is entertained by a good story. I’ve seen a lot of pitches that have a story in them, but they’re often not very good. Good storytelling is about making the story fascinating, rather than merely using it as a device for information. For a quick read about this topic, check out Sally Hogshead’s book Fascinate: Your 7 Triggers to Persuasion and Captivation.

For example, we opened our Demo Day pitch with a 60-second story about a pair of mustachioed astronomers from the 16th century. It was a hit. Feel free to check it out on YouTube here.

Oh, and if you’re funny, it helps to use that too :P

If you want more reading on this subject, I recommend checking out Made to Stick: Why Some Ideas Survive and Others Die.

I’ll leave you with a story of my own.

In the weeks that followed Demo Day, we climbed quickly to become the #1 trending startup on AngelList. This put us in the sidebar on almost every page on the AngelList website, and it also meant we were featured at the top of the weekly mass email that AngelList sends to every single registered member. The video of our pitch was featured prominently at the very top of our AngelList profile, and according to YouTube, thousands of people watched it.

We fielded a crush of inbound interest from would-be investors, and in the end we were very much oversubscribed, meaning we had the luxury of choosing the most value-adding investors we could imagine.

And we owe a ton of it to our Demo Day pitch.

I think you can do the same, and I want to help you get there. Hopefully this blog post provides a good starting point, but if you have specific follow-up questions, please ask me on the Hacker News thread here, or mention me on Twitter at @dorkitude.


How we used Twitter ads to generate word-of-mouth hype

Kyle Wild is the co-founder & CEO of Keen IO. You should follow him on Twitter here.


It started last month at the Global Accelerator Network’s Founder Conference in Boston, where the always original Saul Colt gave a hilarious and irreverent talk about word-of-mouth marketing. True to form, I think I’ve referenced his talk in a dozen conversations since then.

Saul’s talk was loaded with good advice, but the main thing that stuck with me was this: instead of obsessing about the “right” word-of-mouth marketing campaign, you should Try 100 Things. Makes sense, right? It forces you to ideate freely, and any given campaign isn’t super expensive (Saul also has a talk online about creating word-of-mouth campaigns with no budget).

We really took this concept to heart. In fact, on a Thanksgiving flight the following week, Michelle and I brainstormed at least two dozen guerrilla / word-of-mouth marketing concepts that we can implement on the cheap. Of those, I’m confident that a handful will work.

Here’s one that’s working already!

Yesterday, I posted this tongue-in-cheek tweet on the Keen IO Twitter account, then promoted the tweet with $100:

Don’t click this tweet, because it’s promoted, and that would cost us money. Instead, just type this into your browser: Keen.IO

Results to date:

  • $60.09 spent
  • 937 paid clicks (that’s 6.4 cents per click)
  • 20 Retweets (generating an unknown # of unpaid clicks)
  • 10 favorites
  • 10 mentions, mostly complimentary

And at least one person typed in the URL manually!

Photographic evidence:


Kyle Wild is the co-founder & CEO of Keen IO. You should follow him on Twitter here.