The Fat Startup Revisited

The Fat Startup Revisited

Many software copywriters or developers dream of building their own company. Those that do will likely fall under the influence of the celebrated Lean Startup movement. My co-founders and I did. Over two years we built a software product that simplified how nonprofits plan and measure their social and environmental impact.

Yet the company failed -- more of a fat startup than a lean startup.

Based on painful personal experience, this article illustrates the that the Lean Startup theory is the best around but execution and extreme realism are critical too. 

The Jason Fried Fantasy

Naturally, as Lean Startup followers, we started our company by writing a lean canvas.

Our chosen problem was logic models, which are the non-profit equivalent of business plans. We first saw the problem when working with a consulting firm that was helping a client with two of their programs. In return for a substantial fee, the client received a long PowerPoint describing elaborate logic models. None of this work could be implemented by the client in a cost-effective way. To confirm our suspicions, we surveyed nearly a thousand people. The feedback showed that writing a logic model is confusing, complicated, and impractical. And no good software tools were available to help.

As long-time admirers of 37 Signals (now Basecamp) and its CEO, Jason Fried, we set out to apply their philosophy to building our software and company. We would combine simple, opinionated software with crisp software copywriting and a low-touch online sales model. In short, we would become the 37 Signals of nonprofit software. The Jason Fried Fantasy began.

Our original idea put on weight quickly, moving beyond the logic model to the broader category of impact management.  As profit is to traditional business, impact is to the nonprofit sector. Achieving impact – positive change in a social or environmental problem – is the purpose of every organization working in the sector. The value proposition for our software also fattened to “the first software application that helps nonprofit organizations show funders they are effective in creating impact. It helps customers create program strategies, plan change, monitor outcomes, and visualize impact.” 

Iterate and irritate

Our first customer, a Canadian social services department, was led by a Deputy Minister with a fondness for a wall chart showing the logic models under his charge. They wanted to move off the wall and into our software.

The assumptions behind our lean canvas cracked straightaway. We assumed customers would sign up online with a credit card. Instead, landing our first customer took a dinner in Toronto and umpteen phone calls. And instead of a credit card, we were paid by check. However, having the first customer was a glorious event and we readied for a demonstration in front of the key stakeholders.

Demo day came…and disaster. Our inaugural customer couldn’t access the software using an out-of-date Safari browser. Our developers pleaded with the client to “recreate” the problem. Though charmingly polite, our clients were humiliated by the demo and too irritated to “iterate” our minimum viable product with us.

Nevertheless as Lean Startup followers, we kept building, measuring, and learning. Hidden inside our minimum viable product was a separate mobile application to gather data on logic model performance. This mobile app mystified our customers. Why didn’t we let them input data online at their desks as a starting step? Because we suffered from “The San Francisco Folly:” assuming that the whole world spends its time on an iPad or iPhone fidgeting with apps [I was wrong on this too, now the world does do this]. Software builders are usually utterly unrepresentative of their users (we certainly were). And the mobile app wasn’t helped by gooey English in the button labels, such as “completion timeframe.”

We did, however, get plenty of positive feedback such as our software was a good way to tell the story of a program to funders. But intelligent iteration wasn’t possible because of our obese development costs, which left us without any funds to product iterations.

There were useful unlean lessons though.

First, the minimum viable product from Lean Startup needs to deliver solid value. Customers aren’t interested in funding your “learning.” They want reliable software that delivers value consistently. You must build the minimum desirable product, and if you don’t have a good understanding of what’s desirable before you start, then, don’t.

Second, the concepts of “early adopter” and “earlyvangelists” are often fictional characters. For every customer or prospect we talked with, the risks of innovation (failure and losing their job) far outweigh the hypothetical benefits we proclaimed. Customers just want reasonably priced software that does its job, not helping us and our [ad]venture.

Trials and terrors

Early morning was the time for coffee and a check on customer trials. The feedback from one customer was bracing. We gave him the name of, “The One-Hour Customer,” after the total time he took from starting his trial to cancelling. His e-mail stated:

“My opinion is that you have a ways to go before you're going to be successful with your software. I signed up for the demo and ran into a brick wall almost immediately with "access denied" messages when trying to edit data I added. I checked the Help tab for answers but they are very limited and focus more on the theory of the software than the actual function.”

The path to product/market fit zigged and zagged. With dozens of guided demos garnishing good reviews our marketing mostly worked. But once left alone in the software, errors haunted our customers. They fell over features that belonged in the product but didn’t work reliably. The cause: undisciplined development. They also bumped into features that worked, but didn’t belong in the product. The cause: casual product management.  

We did not pay enough attention to fundamentals. Our execution fell short, it was not a methodology problem.

First, you need rigorous product management. Don’t speculate. Build no feature unless you understand it thoroughly and have unshakeable evidence that multiple customers need it --urgently. Make the product backlog into a sacred text: the source of truth for all development.  Second, impose strict development discipline. Just as airplanes are rarely early, expect development will be late, over-budget, and bug ridden. Agile development methodologies can excuse lack of process and planning (still possible, just only as far as you can see). Third, as a startup, nobody knows who you are, so, you need a significant marketing budget. Inbound or content-driven marketing can differentiate you, but requires patience and several good writers. Remember in grown-up SaaS companies, the marketing budget, as a percentage of revenue, is typically twice that of R&D.

Finally and most importantly, control cash with messianic fervor. It’s easy for founders to combine free spending habits with fabulous optimism as to when revenue will arrive. We spent money democratically across developers, patents, e-mail platforms, and sales tools. 

Average brings breakdown

“Why’s pork the other white meat?”

A curious question for a startup looking for investment, especially, after already describing your company in a tweet and, inevitably, having to provide a link to our “lean or business model canvas.”

But this is what you get when your startup limps. By this stage, theory told us we should be scaling up. Instead we were sinking downwards. So, we did the next logical thing and pursued The Really Big Plan. Why not raise lots of money and build an enterprise software company? All just working at weekends.

The provocative pork question came from Vegas Tech Fund, the brain child of the Zappos founder. Yet, at least it was original and understandable.

Forays with other investors were more perplexing than productive. We encountered an “Intrapreneur Advisor” group. They offered: “a new model for growing our economy by creating new business models that benefit multiple stakeholders while moving innovative technologies to a global marketplace.” That’s a grade-level 21 sentence according to my readability checker. 

But they say persistence pays off. A European investor approved an investment for us to build release 2.0. Sadly, he had a nervous breakdown shortly after this approval. 

Our software had fallen into the mushy middle. It was too big for a tool and too small for enterprise software. We blew the basics by executing at average (or worse). Given most startups fail, average means failure. So we did too. 

After two years of burning spare time and much cash, I am left with four big unlean lessons for success in a software startup.

First, pursue achingly high standards in every aspect of your startup. Mediocre execution will suffocate your startup. Second, narrow the scope of your product until you can develop an exceptional product. Quality is the best business plan as Pixar says. The purpose of your first release (and every other release) is to give your customer immediate value. You are not launching a series of science experiments for you to learn what you should already know. Third, find enough funds for a substantial marketing budget. Finally, beware swallowing any methodology completely. What works is the only thing that matters. As Andrew Chen points out well: what works in the past probably doesn't work now.

Nobody thinks the startup failure statistics apply to them. But they will, unless you learn these unlean lessons. Good luck!


The Digital Transformation Maze

The Digital Transformation Maze

White Paper Work

White Paper Work