Missing the light at the end of the tunnel

How to kill a project by vastly underestimating it

July 27, 2019 · 4 min read

When we announced the sunsetting of Fieldbook over a year ago, I wrote a postmortem, in which I called out two major themes.

One was choosing the wrong flagship features: we focused on the ability to build a relational data model. This was squarely aimed at real problems experienced by our target customer, but it also turned out to be a huge challenge for marketing and user onboarding. Ultimately, it wasn’t the right fit for our target market and growth model: bottoms-up, freemium SaaS. (It’s a good illustration of Brian Balfour’s “four fits” framework: we might have had or been able to achieve market-product fit, but we were sorely lacking product-channel fit.) In contrast, I noted, Airtable highlighted simpler and more obvious features, such as mobile and collaboration.

The second theme was how hard it was to build momentum in what I called the “startup flywheel”: the reinforcing cycle of resources, shipping, and traction. When I tried to diagnose our struggles in the last year or two of Fieldbook, I kept going in circles: we couldn’t hire because we weren’t showing traction, because we weren’t shipping enough product, because we couldn’t hire, because….

The first problem seemed to have a clear answer: change the product focus. The second was not as obvious, and I could only speculate on what we could have done differently. My musings included this: “Maybe in this space, given the inherent sophistication of the products and the quality of the market alternatives, you just need a couple million to build a product that’s ready for growth?”

Now, with a year to digest, I think this is true and was a core mistake. I vastly underestimated the resources it was going to take—in time, effort and money—to build a launchable product in the space.

It turns out that information/productivity tools constitute a very mature space. You’re competing against free products from Google. The bar is set pretty high. I thought I could build a launchable product for under $1M; in hindsight, I should have budgeted closer to $3M for product development alone, completely in private beta, before any kind of launch or growth. You can see this from the funding histories of more-successful competitors like Airtable and Coda, and from near neighbors such as Superhuman (which is doing a ton of iteration and polish while still nominally in private beta) or Asana (which took something like four years and tens of millions of dollars before hitting real traction). Jason Lemkin was right: you can’t do crap with a $750k seed round in SaaS.

One lesson here is that the right time to launch depends on the maturity of the space. If the bar in your industry is set very low, if there are basically no alternatives, then sure, launch a rough, early prototype; if customers truly need what you are selling, early adopters will put up with a lack of polish. If you’re entering a mature space, as we were, the bar is higher and you should have a longer beta/development period.

But there’s also a deeper lesson, about projects and expectations.

---

In Jeff Bezos’s 2018 letter to Amazon shareholders, he discusses the topic of high standards: how to have them and how to get your team to have them. (As a side note, if you don’t read Bezos’s shareholder letters, you’re missing out. Even if you’ve already read all the business and startup advice in the world, you will find new and keen insights there.)

Bezos makes a few interesting points, but I’ll focus on one: To have high standards in practice, you need realistic expectations about the scope of effort required.

As a simple example, he mentions learning to do a handstand. Some people think they should be able to learn a handstand in two weeks; in reality, it takes six months. If you go in thinking it will take two weeks, not only do you not learn it in two weeks, you also don’t learn it in six months—you learn it never, because you get discouraged and quit. Bezos says a similar thing applies to the famous six-page memos that substitute for slide decks at Amazon (the ones that are read silently in meetings). Some people expect they can write a good memo the night before the meeting; in reality, you have to start a week before, in order to allow time for drafting, feedback, and editing.

I think this happened to us at Fieldbook.

---

Here’s how I think of it now: If you underestimate the resources you need for a project by 20%, then when you get close to the end of your resources, you can at least see the light at the end of the tunnel. You’re not there, but you know that you just need to keep going; you need an extension, a bridge.

But if you underestimate the resources you need by 3–5x, then when you get close to the end of them, you don’t even see the light at the end of the tunnel. And so you don’t know whether you’re in a tunnel, or just going deeper into a cave with a dead end. You start questioning everything about the project, including whether it’s even the right project. Instead of iterating towards product-market fit, you wonder whether you’re in the right market, and whether the market even exists.

By grossly underestimating what it would take to build and launch a new productivity tool, I set everyone’s expectations wrong: investors’ expectations, early adopters’, candidates’, the team’s, and most importantly my own. What could have, with the right expectations, felt like the first steps on a grand, ambitious journey, instead felt like struggle and failure.

And the wrong expectations caused us to simply make bad decisions. For instance, we launched too early, even though I knew that the user experience, especially the onboarding experience, wasn’t really there yet. Why? Just because we had been working on it so damn long and it felt like we had to get it out there. And because I felt the launch would be needed to raise our next round, which had to happen soon.

---

Of course, you can also fail by vastly overestimating the resources you need to hit a milestone. Too flush with resources, you can easily stay the course for too long, ignoring the signals you need to course-correct. You end up, in Eric Ries’s words, “achieving a failure”. (I experienced this first-hand at the first startup I joined.)

My conclusion is that, for success in any project, it’s very important to have accurate expectations of how success will unfold: what kinds of milestones should be expected on what schedule, with how much effort and resources. Without that, you can’t course-correct because you don’t know when to course-correct and how much.