How I Learned To Build Products People Care About

Two years ago I crashed and burned at Y Combinator’s Demo Day. When I realized what I had done wrong, I endeavored to build Draft, a new way to improve people’s writing, without repeating my mistakes–and I think it’s working. Here’s what I did differently.

How I Learned To Build Products People Care About

On August 23rd, 2011, I was sitting on the concrete in the Y Combinator parking lot, trying to find some space to be alone and call my wife. It was Demo Day, and the crowd was full of elite and celebrity investors. We even had a private chat with Ashton Kutcher. But there I was, calling my wife to tell her how terrible this day had been. It was a startup’s worst fear, realized: Nobody cared what we were working on.


Now, almost two years later, I’m building Draft, a new way to help people write better. It has things people need, like version control, professional editing, importing/exporting, transcription tools, and social analytics–and the response from users has been incredible. Here’s what I learned in the intervening two years that led me to a project that people care about.

Early in 2011, my first business, Inkling, had matured enough that I could make some large bets with my time. I decided to create a new project. I was fascinated with online gaming, and wanted to see if I could build a business helping companies advertise through games. So my partner and I built a neat gaming platform which a business could customize with their own images. For example: Instead of Bejeweled with jewels, images of Gap sweaters could appear in a version of the game sponsored by the Gap.

Within a few months, we had 10,000 people playing these branded games for over two hours a day. As far as the games went, it was a success. But when we talked with advertisers about solving a problem with their marketing using in-game ads, the conversations were painful–we couldn’t articulate how this method of marketing was any better than what they were currently doing.

It took us a few months, but finally we decided we didn’t have a future with what we were building. We had focused on cool software first, and problems second. And now we were paying the penalty.

After a few more fails at figuring out what I could do with the remnants of this company, I decided to take a six-month break and work on the technology team of the Obama re-election campaign. It was nice just being told what to build for once. But the time also offered me a chance to pound back into my brain the importance of starting your product with a problem.


I stumbled upon this book, Something Really New: Three Simple Steps to Creating Truly Innovative Products, by Denis J. Hauptly, which sums it up very nicely. In order to create a truly innovative product:

  1. Study the tasks people use a product for.
  2. Turn those tasks into a series of steps the person follows to get the task done.
  3. Finally, start eliminating steps. That’s it. Innovative products eliminate the friction of doing a task.

When the election was over, I forced myself to look at life through that lens. And that’s when I thought of Draft.

During the last 18 months, I’ve been blogging a lot on the SVBTLE blog network. It’s important to me. And it’s at least a weekly task to get a new post published to NinjasAndRobots. So I explored the steps I took to publish a post.

One thing that stood out was version control. I’d write a really terrible first draft, then save a copy into Evernote. Then I’d edit ruthlessly. Version 2 into Evernote. I’d have a dozen copy and pasted versions in Evernote before I was ready to hit publish. There had to be a better way.

I was tempted to use Git, a very popular version control system for software developers. But as much as a I love using Git for software, the steps to commit and push a new version of a blog post with Git was still too much friction.


So I created something to help me do simple version control. I could create a plain-text (or Markdown) document. Have it auto-save. But when I wanted to mark a major a new version, one click, and I was done.

And I could see how my document changed over time.

That’s how Draft started. And then I began exploring more tasks I had.

I’d send a blog post to my wife for her feedback. But instead of just emailing me back edits, she’d paste the work into Microsoft Word to track changes. And now I have to use Word to convert her feedback into my blog post. To make this task easier, I removed a bunch of those steps. This is Draft’s screen to accept changes my wife made on a document. No more emailing Word documents:

I kept finding tasks I had as a writer where I could remove steps. That’s the experiment you see at Draft. My attempt at making myself a better writer, by making the process easier. Today, Draft is evolving to help people write better using simple version control and collaboration. It’s far too early to call Draft a “success,” but so far I’m insanely grateful and blown away to have a lot of people enjoying the product. It’s been a bumpy road getting here.


Here’s one of my favorite examples of the impact Draft has had. I created a Chrome extension. All it does is make the process easier of getting the text of a Draft document into a text field you’re writing to on the web. So if you’re writing a blog comment, and you want to use Draft, you can use the Chrome extension to open Draft, write your blog comment, and then click a shortcut to switch back to the comment with the text filled in. It saves a few keystrokes. No big deal. I even hesitated releasing it. Will anyone really care?

But the response has been amazing:

For just “saving a few keystrokes.”

Draft continues to give me evidence that innovation by focusing on removing steps in tasks is a great way to build a product.

Is success or failure brought by chance or through one’s own actions? Do we owe it to luck or intuition? I think a great deal of where I’m at with Draft is about luck.


I got lucky a writer with a lot of clout took interest in my project–interest that started because he once worked on a similar project seven years prior, so he understood the challenges I was addressing.

I was lucky to hire a guy at my previous company, who introduced me to a new friend. That friend randomly recommended Draft to his friend, who in turn wrote a very affectionate article on Draft that helped bring me a lot of new attention.

I was lucky Ashton didn’t care about branded games that day. If he had, I might not have shifted my focus.

And I’m insanely lucky to have parents who taught me to persevere when I fell on my face. I’ve done that a lot getting here. But see, that’s the thing about luck. It has a funny way of showing up, when you keep showing up.

[Building Blocks: Titov Dmitriy via Shutterstock]