What happened at Fieldbook

May 11, 2018 · 9 min read

In mid-2013 I started working on Fieldbook, an information tool that combined the best of a spreadsheet and a database. Today, almost five years later, we announced that we’re shutting it down. For our customers, it’s the sundown of a product; for us, it’s the sundown of a dream. I can’t save the Fieldbook vision anymore, but I’d like to at least tell its story.

Does the world really need another startup postmortem? I’m writing this first for everyone who believed in us: my team, our investors, and our customers. For everyone else, I’ll try to articulate some lessons here that I haven’t heard before in the startup canon.

A brief history of Fieldbook

The Fieldbook vision formed slowly for me over many years starting around 2007. By 2012, I couldn’t stop thinking about it. I had seen how often companies poured resources into in-house apps to manage workflows and information, and I had seen how often people turned to the spreadsheet to fill that gap when an internal project didn’t make sense. I deeply believed that the world needed a lightweight tool for working with structured data, and I was inspired to give data superpowers to non-technical end users.

MVP

From early on, I had a roadmap a mile long, but I knew I needed to find the minimum feature set that would actually be useful to customers. So I spent the first few months talking to users about the spreadsheets they used to run their businesses, and iterating on demos and prototypes. By October 2013 I had hit on a product concept that people were getting excited about, and that solved real problems I was seeing in the field. The flagship feature was a way to link sheets of data to create a relational structure.

Ben Bernard joined me as co-founder & CTO soon after that, and we raised a small seed round in early 2014. We hired Ada Cohen as our first employee, and the three of us built the first beta. We did hundreds of usability tests and got a ton of feedback in private beta, as we iterated on the product.

It was much harder than we expected for users to understand the core concepts and get started with the product—but this was the challenge we had signed up for, and we were confident we could crack it. We weren’t content to let Fieldbook become a clunky, technical product for IT people only, like so many “app builders”, nor did we want to dumb it down. We were determined to solve the onboarding problem through simplicity and clarity of the core conceptual model, and we believed this would be our biggest differentiator.

Launch

By 2015 we got our first paying customers and had enough confidence to launch the product to early adopters via Product Hunt. With that as a springboard, we raised a larger seed round in early 2016. We knew we needed to keep improving our retention and engagement metrics before we were ready to invest in marketing. But with two years of cash in the bank, we were more confident than ever that we could make it.

But the biggest obstacles were ahead. I struggled to grow the team: we recruited a head of growth quickly, but couldn’t close a designer or another engineer. With the team understaffed and myself prioritizing recruiting over product management, we didn’t make as much progress as we needed on improving core user metrics—especially activation rate, which reflected the difficulty of the onboarding problem we’d been grinding on since day one. And a major engineering effort to solve performance problems affecting our best customers slipped far behind schedule.

Final surge

In 2017, having finally recruited a great designer, we rallied for a major charge, launching an ambitious redesign to tackle the onboarding problems, and boosting top-of-funnel signups through an AppSumo promotion. But it wasn’t enough. By early 2018 we were still under $60k ARR, and we couldn’t see how we were going to increase our growth rate fast enough get profitable soon enough or to otherwise justify our existence.

When a major tech company reached out to us about a talent acquisition, Ben and I decided that it was the best path forward—a gut-wrenching choice, because we knew it would probably mean shutting down the product.

---

So what went wrong? To my mind, there are two major themes:

Failure to align product & growth model

From the beginning, we deliberately chose a self-service, freemium model for Fieldbook, inspired by products like Dropbox, Trello, and Slack. The product we envisioned would be so natural to get started with, and such a joy to use, that users would adopt it for both personal and business use cases.

In this model, an efficient self-service customer funnel, including silky-smooth user onboarding, is crucial. Without this, your CAC (customer acquisition cost) is too high, and your average $25/mo customer doesn’t justify it.

We knew this from day one, and prioritized onboarding and activation rates. What I didn’t grasp until too late was that the product focus we chose early on, essentially relational data modeling, is too complex to fit easily with this model. In contrast to the utter simplicity of Slack (chat rooms), Trello (a board of cards) or Dropbox (literally just a folder), Fieldbook required people to learn a new paradigm in order to fulfill the promise that had hooked them in. We worked on this long and hard, and the team did a great job at digging through many layers of incidental complexity, but in the end we hit a bedrock of essential complexity that we didn’t have the resources to drill through.

In contrast, our closest competitor, Airtable, seems to be getting more traction. Early on, their product focus was subtly different, with more emphasis on mobile experience and collaboration features than on data modeling or formulas. These aren’t the features that were most important to the users we talked to, but they’re easier to understand, and I suspect they made both marketing and onboarding easier for Airtable—maybe just enough to make all the difference.

Should we have moved upmarket?

Would a more upmarket, sales-driven approach have worked? There were a few things pointing in this direction: Our most enthusiastic customers had some of the largest and most complex use cases, and offering custom manual setup seemed to get people over the activation hump.

We happily did manual onboarding for early customers, even though it doesn’t scale. It’s a great way to learn and to build a brand. But as growth strategy, it inexorably turns into a sales model, which requires a higher price point, around $300/mo.

We tried to nudge ourselves upmarket, offering higher-priced plans with custom manual setup, but we didn’t have enough takers. We just weren’t getting the right leads. To make this work, I think we would have had to relaunch as almost a different company. I concluded that you can’t nudge upmarket—you have to leap. And the enterprise version of this kind of tool was, in my judgment, a much smaller market, with long-established competition that I didn’t see how we’d differentiate against. It wasn’t what we wanted to bet the company on.

What did I miss?

We knew from early on that distribution would be our biggest challenge. Plenty of people gave us that feedback. Why did I still miss this?

My thinking in the early days was: “I can’t solve the growth problem until I know what product I’m even growing; I need to figure that out first. Value hypothesis before growth hypothesis. Once we have a product that people love, we’ll figure out how to market it. If the product/market fit is strong enough, there has to be some way to grow; if it’s not, nothing else matters.”

There is a deep truth in this, and I’ve seen multiple startups fail by pushing for growth before proving value. But I now understand how distribution issues can influence product choices early on, almost as much as user feedback can.

If I could send a message back in time to myself circa October 2013, I’d say: “Hey, you know those customers with the biggest, most complex spreadsheets? The ones who are frustrated because they really need a relational database? Yeah, they are the ones with the strongest pain point—but their problem is too complex to be solved in the simple, freemium model you’re going for. It’s a real problem, but it’s not the one you want to solve. Keep talking to users and find a different problem you can solve, a different product focus to get users excited about.”

I didn’t take distribution into account from the beginning because I literally didn’t know how. I didn’t see how distribution concerns could influence early product development, or how the inherent complexity of a problem could make it a bad fit for a freemium model, even if it’s a real problem and you make a great product to solve it.

Failure to build momentum in the flywheel

Every startup begins with a vision. The vision attracts co-founders and early investment. With money and talent you build a product, and a great product gains users. Traction helps you raise the next round and hire a bigger team. That lets you improve the product and market it, which leads to more growth.

This is a reinforcing cycle—for good or ill. I call it the flywheel because it has a ton of inertia, whether it’s working or not. It takes a long, hard effort to build up momentum, but once you do, it’s almost unstoppable. Great startups get the flywheel going so strong that part of their growth comes from the publicity about their growth. (!)

In our case, it worked against us. Yes, the growth problem was hard, but was it intractable? We had a lot of ideas we never tried, or had to downscope. Why? I never built the team (leaving us simultaneously understaffed and distracted by recruiting). Why couldn’t we close candidates? One of the top reasons seemed to be that we weren’t showing strong growth yet. Why didn’t we have the growth? We still had a lot to improve in the product: onboarding, features, performance. Why hadn’t we shipped that stuff yet? I hadn’t hired the team…

Blindsided

I was blindsided by the difficulty of hiring. Hiring was something I’d done successfully for years, including in the early days of Fieldbook and in a previous startup. But at a time when every engineer wanted to work on AI, self-driving cars or cryptocurrencies, a SaaS startup with modest, sporadic growth wasn’t very attractive. I knew that investors would need to see strong, consistent growth before our Series A, but I didn’t expect that engineers would need to see it to even join before Series A.

We weren’t a unicorn, but I thought we could be the cockroach, outlasting everything simply by being unkillable. We kept burn low and we buckled in for the long haul. And that wasn’t wrong. It was smart. What I didn’t appreciate was how much we would be judged not only by how much we had spent or raised to date, but also simply by how much time had gone by or the number of rounds we had raised (regardless of their size).

What could we have done?

Unlike the problem of product/model alignment, it’s less clear how we could have solved this one. Could we have done something tactically to accelerate recruiting and hire the full team during the few months of afterglow from our Product Hunt launch and seed round? Maybe engaging headhunters earlier, or raising our comp ranges closer to market levels earlier. Maybe even relocating to SF from the peninsula, or opening up to remote employees and becoming a distributed team. Or would it have been worth spending money on unsustainable growth channels just to keep up our numbers while we were still hiring?

Or, could I have done a better job raising more money with less traction? It’s good to run lean, but at some point you hit the laws of physics. Jason Lemkin says “you can’t do cr*p with a $750k seed round in SaaS”, and we had raised less than that by the time of our Product Hunt launch. 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?

It’s not clear I could have raised that much out of the gate. Maybe if I had put more emphasis on our big, bold vision in the pitch, rather than the utility of the initial product? My past experiences have made me jaded about sky-high visions untethered from bottoms-up usefulness: I had my eye on Everest, but I wanted to get to base camp first. That was good in terms of execution, but maybe it was wrong for fundraising.

---

You can’t A/B test your life, and we’ll never know how things would have turned out differently if we’d made different choices (or just had a different roll of the dice). There are other hypotheses about what happened, and an infinite list of what-ifs, but the themes above are the most significant to me.

Goodbye, and thank you

The Fieldbook team has found a new home at Flexport, and we’re excited for the future. At the same time, we’re heartbroken to be saying goodbye to the product we built.

To everyone who believed in us and made this journey possible: you have my eternal gratitude. The early adopters who patiently tested the app and gave thoughtful feedback, the customers who plunked down their hard-earned dollars, the investors who wrote us checks because they could squint and see the future, and especially the team who devoted long years and longer days to our mission—I thank you all. If it was painful to see it come to an end, I hope these reflections bring you a bit of closure, as they did for me.