Tom Blomfield

Partner at Y Combinator. Co-founded Monzo and GoCardless. Based in San Francisco.

[tomblomfield]

Vibecoding a production app

TL;DR I built and launched a recipe app with about 20 hours of work - recipeninja.ai

Background: I'm a startup founder turned investor. I taught myself (bad) PHP in 2000, and picked up Ruby on Rails in 2011. I'd guess 2015 was the last time I wrote a line of Ruby professionally. I've built small side projects over the years, but nothing with any significant usage. So it's fair to say I'm a little rusty, and I never really bothered to learn front end code or design.

In my day job at Y Combinator, I'm around founders who are building amazing stuff with AI every day and I kept hearing about the advances in tools like Lovable, Cursor and Windsurf. I love building stuff and I've always got a list of little apps I want to build if I had more free time.

About a month ago, I started playing with Lovable to build a word game based on Articulate (it's similar to Heads Up or Taboo). I got a working version, but I quickly ran into limitations - I found it very complicated to add a supabase backend, and it kept re-writing large parts of my app logic when I only wanted to make cosmetic changes. It felt like a toy - not ready to build real applications yet.

But I kept hearing great things about tools like Windsurf. A couple of weeks ago, I looked again at my list of app ideas to build and saw "Recipe App". I've wanted to build a hands-free recipe app for years. I love to cook, but the problem with most recipe websites is that they're optimized for SEO, not for humans. So you have pages and pages of descriptive crap to scroll through before you actually get to the recipe. I've used the recipe app Paprika to store my recipes in one place, but honestly it feels like it was built in 2009. The UI isn't great for actually cooking. My hands are covered in food and I don't really want to touch my phone or computer when I'm following a recipe.

So I set out to build what would become RecipeNinja.ai

For this project, I decided to use Windsurf. I wanted a Rails 8 API backend and React front-end app and Windsurf set this up for me in no time. Setting up homebrew on a new laptop, installing npm and making sure I'm on the right version of Ruby is always a pain. Windsurf did this for me step-by-step. I needed to set up SSH keys so I could push to GitHub and Heroku. Windsurf did this for me as well, in about 20% of the time it would have taken me to Google all of the relevant commands.

I was impressed that it started using the Rails conventions straight out of the box. For database migrations, it used the Rails command-line tool, which then generated the correct file names and used all the correct Rails conventions. I didn't prompt this specifically - it just knew how to do it. It one-shotted pretty complex changes across the React front end and Rails backend to work seamlessly together.

To start with, the main piece of functionality was to generate a complete step-by-step recipe from a simple input ("Lasagne"), generate an image of the finished dish, and then allow the user to progress through the recipe step-by-step with voice narration of each step. I used OpenAI for the LLM and ElevenLabs for voice. "Grandpa Spuds Oxley" gave it a friendly southern accent.

Recipe summary:

And the recipe step-by-step view:

I was pretty astonished that Windsurf managed to integrate both the OpenAI and Elevenlabs APIs without me doing very much at all. After we had a couple of problems with the open AI Ruby library, it quickly fell back to a raw ruby HTTP client implementation, but I honestly didn't care. As long as it worked, I didn't really mind if it used 20 lines of code or two lines of code. And Windsurf was pretty good about enforcing reasonable security practices. I wanted to call Elevenlabs directly from the front end while I was still prototyping stuff, and Windsurf objected very strongly, telling me that I was risking exposing my private API credentials to the Internet. I promised I'd fix it before I deployed to production and it finally acquiesced.

I decided I wanted to add "Advanced Import" functionality where you could take a picture of a recipe (this could be a handwritten note or a picture from a favourite a recipe book) and RecipeNinja would import the recipe. This took a handful of minutes.

Pretty quickly, a pattern emerged; I would prompt for a feature. It would read relevant files and make changes for two or three minutes, and then I would test the backend and front end together. I could quickly see from the JavaScript console or the Rails logs if there was an error, and I would just copy paste this error straight back into Windsurf with little or no explanation. 80% of the time, Windsurf would correct the mistake and the site would work. Pretty quickly, I didn't even look at the code it generated at all. I just accepted all changes and then checked if it worked in the front end.

After a couple of hours of work on the recipe generation, I decided to add the concept of "Users" and include Google Auth as a login option. This would require extensive changes across the front end and backend - a database migration, a new model, new controller and entirely new UI. Windsurf one-shotted the code. It didn't actually work straight away because I had to configure Google Auth to add `localhost` as a valid origin domain, but Windsurf talked me through the changes I needed to make on the Google Auth website. I took a screenshot of the Google Auth config page and pasted it back into Windsurf and it caught an error I had made. I could login to my app immediately after I made this config change. Pretty mindblowing. You can now see who's created each recipe, keep a list of your own recipes, and toggle each recipe to public or private visibility. When I needed to set up Heroku to host my app online, Windsurf generated a bunch of terminal commands to configure my Heroku apps correctly. It went slightly off track at one point because it was using old Heroku APIs, so I pointed it to the Heroku docs page and it fixed it up correctly.

I always dreaded adding custom domains to my projects - I hate dealing with Registrars and configuring DNS to point at the right nameservers. But Windsurf told me how to configure my GoDaddy domain name DNS to work with Heroku, telling me exactly what buttons to press and what values to paste into the DNS config page. I pointed it at the Heroku docs again and Windsurf used the Heroku command line tool to add the "Custom Domain" add-ons I needed and fetch the right Heroku nameservers. I took a screenshot of the GoDaddy DNS settings and it confirmed it was right.

I can see very soon that tools like Cursor & Windsurf will integrate something like Browser Use so that an AI agent will do all this browser-based configuration work with zero user input.

I'm also impressed that Windsurf will sometimes start up a Rails server and use curl commands to check that an API is working correctly, or start my React project and load up a web preview and check the front end works. This functionality didn't always seem to work consistently, and so I fell back to testing it manually myself most of the time.

When I was happy with the code, it wrote git commits for me and pushed code to Heroku from the in-built command line terminal. Pretty cool!

I do have a few niggles still. Sometimes it's a little over-eager - it will make more changes than I want, without checking with me that I'm happy or the code works. For example, it might try to commit code and deploy to production, and I need to press "Stop" and actually test the app myself. When I asked it to add analytics, it went overboard and added 100 different analytics events in pretty insignificant places. When it got trigger-happy like this, I reverted the changes and gave it more precise commands to follow one by one.

The one thing I haven't got working yet is automated testing that's executed by the agent before it decides a task is complete; there's probably a way to do it with custom rules (I have spent zero time investigating this). It feels like I should be able to have an integration test suite that is run automatically after every code change, and then any test failures should be rectified automatically by the AI before it says it's finished.

Also, the AI should be able to tail my Rails logs to look for errors. It should spot things like database queries and automatically optimize my Active Record queries to make my app perform better. At the moment I'm copy-pasting in excerpts of the Rails logs, and then Windsurf quickly figures out that I've got an N+1 query problem and fixes it. Pretty cool.

Refactoring is also kind of painful. I've ended up with several files that are 700-900 lines long and contain duplicate functionality. For example, list recipes by tag and list recipes by user are basically the same.

Recipes by user:

This should really be identical to list recipes by tag, but Windsurf has implemented them separately.

Recipes by tag:

If I ask Windsurf to refactor these two pages, it randomly changes stuff like renaming analytics events, rewriting user-facing alerts, and changing random little UX stuff, when I really want to keep the functionality exactly the same and only move duplicate code into shared modules. Instead, to successfully refactor, I had to ask Windsurf to list out ideas for refactoring, then prompt it specifically to refactor these things one by one, touching nothing else. That worked a little better, but it still wasn't perfect

Sometimes, adding minor functionality to the Rails API will often change the entire API response, rather just adding a couple of fields. Eg It will occasionally change Index Recipes to nest responses in an object { "recipes": [ ] }, versus just returning an array, which breaks the frontend. And then another minor change will revert it. This is where adding tests to identify and prevent these kinds of API changes would be really useful. When I ask Windsurf to fix these API changes, it will instead change the front end to accept the new API json format and also leave the old implementation in for "backwards compatibility". This ends up with a tangled mess of code that isn't really necessary. But I'm vibecoding so I didn't bother to fix it.

Then there was some changes that just didn't work at all. Trying to implement Posthog analytics in the front end seemed to break my entire app multiple times. I tried to add user voice commands ("Go to the next step"), but this conflicted with the eleven labs voice recordings. Having really good git discipline makes vibe coding much easier and less stressful. If something doesn't work after 10 minutes, I can just git reset head --hard. I've not lost very much time, and it frees me up to try more ambitious prompts to see what the AI can do. Less technical users who aren't familiar with git have lost months of work when the AI goes off on a vision quest and the inbuilt revert functionality doesn't work properly. It seems like adding more native support for version control could be a massive win for these AI coding tools.

Another complaint I've heard is that the AI coding tools don't write "production" code that can scale. So I decided to put this to the test by asking Windsurf for some tips on how to make the application more performant. It identified I was downloading 3 MB image files for each recipe, and suggested a Rails feature for adding lower resolution image variants automatically. Two minutes later, I had thumbnail and midsize variants that decrease the loading time of each page by 80%. Similarly, it identified inefficient N+1 active record queries and rewrote them to be more efficient. There are a ton more performance features that come built into Rails - caching would be the next thing I'd probably add if usage really ballooned.

Before going to production, I kept my promise to move my Elevenlabs API keys to the backend. Almost as an afterthought, I asked asked Windsurf to cache the voice responses so that I'd only make an Elevenlabs API call once for each recipe step; after that, the audio file was stored in S3 using Rails ActiveStorage and served without costing me more credits. Two minutes later, it was done. Awesome.

At the end of a vibecoding session, I'd write a list of 10 or 15 new ideas for functionality that I wanted to add the next time I came back to the project. In the past, these lists would've built up over time and never gotten done. Each task might've taken me five minutes to an hour to complete manually. With Windsurf, I was astonished how quickly I could work through these lists. Changes took one or two minutes each, and within 30 minutes I'd completed my entire to do list from the day before. It was astonishing how productive I felt. I can create the features faster than I can come up with ideas.

Before launching, I wanted to improve the design, so I took a quick look at a couple of recipe sites. They were much more visual than my site, and so I simply told Windsurf to make my design more visual, emphasizing photos of food. Its first try was great. I showed it to a couple of friends and they suggested I should add recipe categories - "Thai" or "Mexican" or "Pizza" for example. They showed me the DoorDash app, so I took a screenshot of it and pasted it into Windsurf. My prompt was "Give me a carousel of food icons that look like this". Again, this worked in one shot. I think my version actually looks better than Doordash 🤷‍♂️

Doordash:

My carousel:

I also saw I was getting a console error from missing Favicon. I always struggle to make Favicon for previous sites because I could never figure out where they were supposed to go or what file format they needed. I got OpenAI to generate me a little recipe ninja icon with a transparent background and I saved it into my project directory. I asked Windsurf what file format I need and it listed out nine different sizes and file formats. Seems annoying. I wondered if Windsurf could just do it all for me. It quickly wrote a series of Bash commands to create a temporary folder, resize the image and create the nine variants I needed. It put them into the right directory and then cleaned up the temporary directory. I laughed in amazement. I've never been good at bash scripting and I didn't know if it was even possible to do what I was asking via the command line. I guess it is possible.

After launching and posting on Twitter, a few hundred users visited the site and generated about 1000 recipes. I was pretty happy! Unfortunately, the next day I woke up and saw that I had a $700 OpenAI bill. Someone had been abusing the site and costing me a lot of OpenAI credits by creating a single recipe over and over again - "Pasta with Shallots and Pineapple". They did this 12,000 times. Obviously, I had not put any rate limiting in.

Still, I was determined not to write any code. I explained the problem and asked Windsurf to come up with solutions. Seconds later, I had 15 pretty good suggestions. I implemented several (but not all) of the ideas in about 10 minutes and the abuse stopped dead in its tracks. I won't tell you which ones I chose in case Mr Shallots and Pineapple is reading. The app's security is not perfect, but I'm pretty happy with it for the scale I'm at. If I continue to grow and get more abuse, I'll implement more robust measures.

Overall, I am astonished how productive Windsurf has made me in the last two weeks. I'm not a good designer or frontend developer, and I'm a very rusty rails dev. I got this project into production 5 to 10 times faster than it would've taken me manually, and the level of polish on the front end is much higher than I could've achieved on my own.  Over and over again, I would ask for a change and be astonished at the speed and quality with which Windsurf implemented it. I just sat laughing as the computer wrote code.

The next thing I want to change is making the recipe generation process much more immediate and responsive. Right now, it takes about 20 seconds to generate a recipe and for a new user it feels like maybe the app just isn't doing anything.

Instead, I'm experimenting with using Websockets to show a streaming response as the recipe is created. This gives the user immediate feedback that something is happening. It would also make editing the recipe really fun - you could ask it to "add nuts" to the recipe, and see as the recipe dynamically updates 2-3 seconds later. You could also say "Increase the quantities to cook for 8 people" or "Change from imperial to metric measurements".

I have a basic implementation working, but there are still some rough edges. I might actually go and read the code this time to figure out what it's doing!

I also want to add a full voice agent interface so that you don't have to touch the screen at all. Halfway through cooking a recipe, you might ask "I don't have cilantro - what could I use instead?" or say "Set a timer for 30 minutes". That would be my dream recipe app!

Tools like Windsurf or Cursor aren't yet as useful for non-technical users - they're extremely powerful and there are still too many ways to blow your own face off. I have a fairly good idea of the architecture that I want Windsurf to implement, and I could quickly spot when it was going off track or choosing a solution that was inappropriately complicated for the feature I was building. At the moment, a technical background is a massive advantage for using Windsurf. As a rusty developer, it made me feel like I had superpowers.

But I believe within a couple of months, when things like log tailing and automated testing and native version control get implemented, it will be an extremely powerful tool for even non-technical people to write production-quality apps. The AI will be able to make complex changes and then verify those changes are actually working. At the moment, it feels like it's making a best guess at what will work and then leaving the user to test it. Implementing better feedback loops will enable a truly agentic, recursive, self-healing development flow. It doesn't feel like it needs any breakthrough in technology to enable this. It's just about adding a few tool calls to the existing LLMs. My mind races as I try to think through the implications for professional software developers.

Meanwhile, the LLMs aren't going to sit still. They're getting better at a frightening rate. I spoke to several very capable software engineers who are Y Combinator founders in the last week. About a quarter of them told me that 95% of their code is written by AI. In six or twelve months, I just don't think software engineering is going exist in the same way as it does today. The cost of creating high-quality, custom software is quickly trending towards zero.

You can try the site yourself at recipeninja.ai

Here's a complete list of functionality. Of course, Windsurf just generated this list for me 🫠

RecipeNinja: Comprehensive Functionality Overview

Core Concept: the app appears to be a cooking assistant application that provides voice-guided recipe instructions, allowing users to cook hands-free while following step-by-step recipe guidance.

Backend (Rails API) Functionality

User Authentication & Authorization

Google OAuth integration for user authentication

User account management with secure authentication flows

Authorization system ensuring users can only access their own private recipes or public recipes

Recipe Management

Recipe Model Features:

Unique public IDs (format: "r_" + 14 random alphanumeric characters) for security

User ownership (user_id field with NOT NULL constraint)

Public/private visibility toggle (default: private)

Comprehensive recipe data storage (title, ingredients, steps, cooking time, etc.)

Image attachment capability using Active Storage with S3 storage in production

Recipe Tagging System:

Many-to-many relationship between recipes and tags

Tag model with unique name attribute

RecipeTag join model for the relationship

Helper methods for adding/removing tags from recipes

Recipe API Endpoints:

CRUD operations for recipes

Pagination support with metadata (current_page, per_page, total_pages, total_count)

Default sorting by newest first (created_at DESC)

Filtering recipes by tags

Different serializers for list view (RecipeSummarySerializer) and detail view (RecipeSerializer)

Voice Generation

Voice Recording System:

VoiceRecording model linked to recipes

Integration with Eleven Labs API for text-to-speech conversion

Caching of voice recordings in S3 to reduce API calls

Unique identifiers combining recipe_id, step_id, and voice_id

Force regeneration option for refreshing recordings

Audio Processing:

Using streamio-ffmpeg gem for audio file analysis

Active Storage integration for audio file management

S3 storage for audio files in production

Recipe Import & Generation

RecipeImporter Service:

OpenAI integration for recipe generation

Conversion of text recipes into structured format

Parsing and normalization of recipe data

Import from photos functionality

Frontend (React) Functionality

User Interface Components

Recipe Selection & Browsing:

Recipe listing with pagination

Real-time updates with 10-second polling mechanism

Tag filtering functionality

Recipe cards showing summary information (without images)

"View Details" and "Start Cooking" buttons for each recipe

Recipe Detail View:

Complete recipe information display

Recipe image display

Tag display with clickable tags

Option to start cooking from this view

Cooking Experience:

Step-by-step recipe navigation

Voice guidance for each step

Keyboard shortcuts for hands-free control:

Arrow keys for step navigation

Space for play/pause audio

Escape to return to recipe selection

URL-based step tracking (e.g., /recipe/r_xlxG4bcTLs9jbM/classic-lasagna/steps/1)

State Management & Data Flow

Recipe Service:

API integration for fetching recipes

Support for pagination parameters

Tag-based filtering

Caching mechanisms for recipe data

Image URL handling for detailed views

Authentication Flow:

Google OAuth integration using environment variables

User session management

Authorization header management for API requests

Progressive Web App Features

PWA capabilities for installation on devices

Responsive design for various screen sizes

Favicon and app icon support

Deployment Architecture

Two-App Structure:

cook-voice-api: Rails backend on Heroku

cook-voice-wizard: React frontend/PWA on Heroku

Backend Infrastructure:

Ruby 3.2.2

PostgreSQL database (Heroku PostgreSQL addon)

Amazon S3 for file storage

Environment variables for configuration

Frontend Infrastructure:

React application

Environment variable configuration

Static buildpack on Heroku

SPA routing configuration

Security Measures:

HTTPS enforcement

Rails credentials system

Environment variables for sensitive information

Public ID system to mask database IDs

This comprehensive overview covers the major functionality of the Cook Voice application based on the available information. The application appears to be a sophisticated cooking assistant that combines recipe management with voice guidance to create a hands-free cooking experience.

[tomblomfield]

What is "founder mode"?

We held a YC event a couple of months ago where Brian Chesky from Airbnb gave a passionate talk about his experience running Airbnb over the last 17 years. He believed that as Airbnb hired more professional managers, he lost a close connection with the details of the end product and the company suffered as a result.

It clearly touched a nerve with a lot of people present. It was uncomfortable to realize that I made many of the same mistakes when I ran my startup, yet somehow comforting to know I was in good company.

Paul Graham wrote an essay about a few weeks later, the now-famous Founder Mode, which I want to explore today.

Leaders in "manager mode" will “treat subtrees of the org chart as black boxes. You tell your direct reports what to do, and it's up to them to figure out how. But you don't get involved in the details of what they do.”

On the other hand “there are things founders can do that managers can't” - this is “founder mode” - and it’s left largely undefined. PG’s essay is perhaps best read as an invitation to founders to compare notes to discover a better way of running companies at scale.

But the essay left me questioning whether "founder mode" and "manager mode" are useful labels. They certainly generated a lot of controversy online, but if you hire bad executives and let them run your company with minimal intervention or oversight, you’re in for a bad time whether you’re a founder or not. 

And, empirically, we can point to numerous examples of both founders and hired CEOs who have either been extremely successful or totally useless. Whether someone is a founder seems largely orthogonal to whether they’re a competent leader. 

Maybe my quibble is just a semantic one - these labels distract from the debate. I do believe there is a really interesting question here - how do good leaders stay in the detail and run great companies at scale? Are there areas where founders really do have a persisting advantage?  And that’s what I want to explore in more detail here.

I think the general pattern that Brian was identifying was the following. A young, inexperienced founder with limited management experience is running a rapidly scaling company. Famous VCs invest a lot of money and join the board. Headcount passes 100 and quickly grows beyond 1000. The VCs (who often have never run anything themselves) encourage the founder to hire "executives" with "scaling experience".

The founder is told to "empower" these executives, who typically then implement techniques that worked for them at previous companies. But, too often, these techniques fail in the new company. The founder is too nervous to intervene - these people are supposed to be "experts" - or is rebuffed by the experienced executives for "micromanaging". Things don't go well, and the company slowly stagnates. The founder gets sad and eventually quits or is pushed out.

Now, it's very common to hire executives who are ineffective. Every CEO has that experience. But it's not sensible to give those executives unverified trust and free reign from day one. I don’t think any competent CEO should treat "subtrees of the org chart as black boxes". 

As a leader, of course you constantly need to do skip-level meetings with people further down in the organization. You need to have your finger on the pulse of the company and be able drill down into each area when necessary.

The process of building and maintaining trust between a CEO and an exec involves the CEO repeatedly going incredibly deep on niche subjects, verifying that the exec really knows what's going on in their department, and has a good grasp on the problems. As the exec builds trust, these deep-dives can become less frequent, but they never totally disappear. If the exec repeatedly doesn't have a good grasp of the details as you dive deep into their domain, you quickly realize that you need to replace them.

To do this, leaders need an extremely detailed and nuanced understanding of their business. There’s a cliched idea of clueless MBAs jumping from company to company, treating them as black boxes that might as well be making widgets. They clearly don’t have the domain expertise to dive into any kind of detail. This is not a successful way to run a company.

Over time, and without constant pruning, companies do seem to accumulate layers of management who do very little. These managers spend their time coordinating people, trying to establish consensus, and padding out their promotion packets to ascend to the next rung of the corporate ladder. Instead, I believe that great leaders have to be able to dig into the details, have an incredibly high bar for quality, and ultimately do great IC work themselves. Great managers have to manage the work - they should primarily be responsible for quality and speed of output. Managing people must be secondary to managing the product.

At Monzo, we experimented with some pretty wacky management structures at times. There was a period when our middle managers were basically just responsible for "pastoral care" of each employee. They were not connected at all with the output that the ICs were producing. It was totally insane and overlapped with our period of lowest productivity by far.

As you scale a company, you do have to figure out which executives you can trust with what kind of work, and delegate decisions to them appropriately. The limiting factor in any scaling company is usually management bandwidth. I believe one of the best articulations of this idea is Keith Rabois's Barrels vs Ammunition (at 14:32, but the whole video is excellent)

If you think about people, there are two categories of high-quality people: there is the ammunition, and then there are the barrels. You can add all the ammunition you want, but if you have only five barrels in your company, you can literally do only five things simultaneously.

Finding those barrels that you can shoot through — someone who can take an idea from conception to live and it’s almost perfect — are incredibly difficult to find. This kind of person can pull people with them. They can charge up the hill. They can motivate their team, and they can edit themselves autonomously.

Once someone demonstrates "barrel-like" ability, you should quickly put more on their plate. Often, the best leaders at your company will have been promoted from within, over a period of several years. They’ve established huge amounts of trust and have deep domain knowledge. Constantly micromanaging these people is a waste of your time and will actually limit the great work your company can do. You must empower them.

On the other hand, trying to hire in senior executives from outside the company is fraught with difficulty. Sadly, many really are just “professional fakers”. These people have run hundreds of job interviews in their career and are experts at “managing up” to a CEO. This makes standard interviews almost entirely useless. Instead, I would try to pick previous projects they’ve run and dig into as much detail as you can. See how granular they can go on the problems they encountered, the decisions they made and the results they achieved. I would do a very large number of reference checks - try to find bosses, peers and subordinates and talk to them in detail about the person you are about to hire. Every time I failed to do detailed reference checks on an executive hire, I deeply regretted it. Spend significant time with the person before hiring them. I spent about a year meeting TS Anil (the now-CEO) before hiring him at Monzo, and 9 months meeting with Sujata, the COO. They are two of the best executive hires I ever made, and I’m sad I didn’t get to work with them for longer. 

Once you’ve hired someone, you need to ensure they’re doing a good job before giving them free-reign in your company. Are they really a “barrel”? Sadly, at least 50% of executive hires don’t work out. It’s essential that you identify these people early and weed them out. And the way you do this is dive deep with them into their domain and see if they can keep up. When a CEO takes their eye off the details, the career politicians and bureaucrats thrive.

I've heard from many founders that their senior managers - C levels and VPs - react badly when young founders want to dig into the details. They seem to say "You hired us to be the experts here. Now you need to get out of the way while we run the company." As PG's essay says, "Founders feel like they're being gaslit from both sides — by the [VCs] telling them they have to run their companies like managers, and by the [execs] working for them when they do." They "hire professional fakers and let them drive the company into the ground." This is also the pattern that Brian identified in his talk, and I think it’s absolutely destructive. 

I have to say that this generally wasn't my experience - I had access to all metrics from across the company, on dozens of pages of real time dashboards. I'd frequently roam the office and sit next to a random employee and start talking to them about their work. Teams would often have their dashboards up on walls and I loved digging into what the data was showing. I had an obsession with extremely granular metrics - it cost us £4.40 to onboard a single customer, split between KYC cost, debit card manufacturing, postage and packaging. Our CAC varied between £10.50 and £14.00 depending on channel. Our NPS started at +78 and declined to +71 (and we spent a really long time trying to figure out why). The average customer transacted on their Monzo card 7.4 times a week, with an average spend of £14.10 per transaction. They deposited £600 month (which grew to £950 after 18 months of using Monzo) and they opened the app 22 times per week. I could go on and on - I was obsessed with these metrics. 

We insisted that everyone at Monzo - including the entire senior management team - do customer service for one day a month. This was a great way to make sure everyone stayed closely connected to the issues customers really cared about. We stopped doing this in about year 4 or 5, and it seemed to coincide with a sharp reduction in the pace of execution.

Sadly, I hired a number of bad executives, but the techniques above generally allowed me to identify them pretty quickly, and we ended up firing a lot of senior people. There were certainly times when I was too busy and didn't have the time, or I didn't feel like I had the expertise to really dive in. Certain teams' work was so alien to me that I couldn't effectively go deep. In retrospect, they were also the lowest performing teams when I was there.

I think that the final part of successful leadership is the ability to make hard decisions in the absence of complete information. At some point or another, companies will encounter these bet-the-company moments, and maybe this is one area that founders do have an advantage over professional managers. Having the moral authority to take a really hard decision comes with the founder title. Zuckerberg’s decision to go all-in on mobile 2012 is an example of this. Professional managers inevitably have a level of risk aversion due to the insecurity of their job position - if it goes wrong, the founder is less likely to lose their job. Zuckerberg’s bet on the Metaverse would probably have gotten a professional CEO fired.

But there are relatively few of these bet-the-company decisions. Everything slows to a crawl if the CEO needs to be consulted every time a decision needs to be made. You want your (competent) execs and your top ICs to be making great decisions every day - and you as the CEO should dive in only occasionally to spot-check these decisions. This is how you scale leadership. 

I’ve worked at a startup where the founder CEO came in every Monday with a new idea. He seemed to spend every weekend talking to investors and then turned up with heaps of enthusiasm for a new initiative. But we never had time to actually make progress on the idea before he’d change his mind again. This kind of leadership thrash is depressingly common with inexperienced founder-CEOs. 

I encountered a similar thing at my own company - I learned that I had to be really careful about sharing half-formed opinions and ideas, especially with less experienced team members (and as the company grew past 1000 people). I would sometimes get enthusiastic about a new half-formed product idea, or make an off-the-cuff remark about something I found interesting. Without intending to, I’d derail an entire team for weeks. You need to be deliberate and intentional about CEO-level interventions when you’re running a company of thousands.

I learned that if I wanted the company to focus, I had to have a singular message that I repeated endlessly. I would write a 3-4 page letter to the entire company about every 6 months, outlining the one or two things we needed to focus on. At our weekly all-hands, I would just repeat the same message in different ways. I think I said “fix unit economics” several thousand times in 2018. It became a meme at the company. But it worked.

I sat in every weekly product review meeting with my CPO and CTO, even as we got to 2000 team-members. Our main input to the teams was typically to try to cut scope and launch faster. 

I learned to save my open-ended product brainstorming for a much smaller group - VP Marketing, VP Design, CPO, CTO, and a couple of very senior engineering ICs. We’d meet every 2-3 weeks and spend a couple of hours jamming on the kinds of things we could build in future. These meetings were the most fun I had at Monzo. Some of these became a core part of the product, others were just a fun way to blow off steam without distracting the company.

I’m not saying I have all the answers here - and I was far from a perfect CEO. I don’t think I really ever figured out how to balance the extremely onerous regulatory constraints of running a bank with a desire to move quickly and delight our customers. Especially as we grew past 500 people, I think we lost a lot of the early intensity and focus that I loved so much. We raised hundreds of millions of dollars, so when new employees turned up to a fancy office with catered lunches they believed they had joined a company like Google, and everything slowed down. 

Personally, I was in the detail to such an extent that I couldn’t ever really disconnect from the company. I treated every criticism of Monzo as an attack on me personally. I found it impossible to keep a sense of perspective or any balance in my life, and ultimately I burned out. I believe this is the biggest danger for founders once they’ve hit product-market-fit.

I return to the original questions - how do good leaders stay in the detail and run great companies at scale? Are there areas where founders really do have a persisting advantage?  I’ve shared some of my views here - I would insist that all CEOs stay connected to the details of their product, have an incredibly high bar for quality, manage for output, and delegate only to the extent that your leaders have earned your trust. Don't feel embarrassed about the way you want to run your company.

I would love to hear how others run their companies, whether you're founders or not.

[tomblomfield]

Taking Risk

I just spent a week talking with some exceptional students from three of the UK's top universities; Cambridge, Oxford and Imperial College. Along with UCL, these British universities represent 4 of the top 10 universities in the world. The US - a country with 5x more people and 8x higher GDP - has the same number of universities in the global top 10.

On these visits, I was struck by the world-class quality of technical talent, especially in AI and biosciences. But I was also struck by something else. After their studies, most of these smart young people wanted to go and work at companies like McKinsey, Goldman Sachs or Google.

I now live in San Francisco and invest in early-stage startups at Y Combinator, and it's striking how undergraduates at top US universities start companies at more than 5x the rate of their British-educated peers. Oxford is ranked 50th in the world, while Cambridge is 61st. Imperial just makes the list at #100. I have been thinking a lot about why this is. The UK certainly doesn't lack the talent or education, and I don't think it's any longer about access to capital.

People like to talk about the role of government incentives, but San Francisco politicians certainly haven't done much to help the startup ecosystem over the last few years, while the UK government has passed a raft of supportive measures.

Instead, I think it's something more deep-rooted - in the UK, the ideas of taking risk and of brazen, commercial ambition are seen as negatives. The American dream is the belief that anyone can be successful if they are smart enough and work hard enough. Whether or not it is the reality for most Americans, Silicon Valley thrives on this optimism.

The US has a positive-sum mindset that business growth will create more wealth and prosperity and that most people overall will benefit as a result. The approach to business in the UK and Europe feels zero-sum. Our instinct is to regulate and tax the technologies that are being pioneered in California, in the misguided belief that it will give us some kind of competitive advantage.

Young people who consider starting businesses are discouraged and the vast majority of our smart, technical graduates take "safe" jobs at prestigious employers. I am trying to figure out why that is.

___

Growing up, every successful adult in my life seemed to be a banker, a lawyer or perhaps a civil engineer, like my father. I didn't know a single person who programmed computers as a job. I taught myself to code entirely from books and the internet in the late 1990s. The pinnacle of my parents' ambition for me was to go to Oxford and study law.

And so I did. While at university, the high-status thing was to work for a prestigious law firm, an investment bank or a management consultancy, and then perhaps move to Private Equity after 3 or 4 years. But while other students were getting summer internships, I launched a startup with two friends. It was an online student marketplace - a bit like eBay - for students. We tried to raise money in the UK in 2006, but found it impossible. One of my cofounders, Kulveer, had a full-time job at Deutsche Bank in London which he left to focus on the startup. His friends were incredulous - they were worried he'd become homeless. My two cofounders eventually got sick of trying to raise money in the UK and moved out to San Francisco. I was too risk-averse to join them - I quit the startup to finish my law degree and then became a management consultant - it seemed like the thing that smart, ambitious students should do. The idea that I could launch a startup instead of getting a "real" job seemed totally implausible.

But in 2011, I turned down a job at McKinsey to start a company, a payments business called GoCardless, with two more friends from university. We managed to get an offer of investment (in the US) just days before my start date at McKinsey, which finally gave me the confidence to choose the startup over a prestigious job offer. My parents were very worried and a friend of my father, who was an investment banker at the time, took me to one side to warn me that this would be the worst decision I ever made. Thirteen years later, GoCardless is worth $2.3bn.

I had a similar experience in 2016, when I was starting Monzo, I had to go through regulatory interviews before I was allowed to work as the CEO of a bank. We hired lawyers and consultants to run mock interviews - and they told me plainly that I was wasting my time. It was inconceivable that the Bank of England would authorise me, a 31 year old who'd never even worked in a bank, to act as the CEO of the UK's newest bank. (It turned out they did.) So much of the UK felt like it was pushing against me as an aspiring entrepreneur. It was like an immune system fighting against a foreign body. The reception I got in the US was dramatically different - people were overwhelmingly encouraging, supportive and helpful. For the benefit of readers who aren't from the UK, I hope it's fair to say that Monzo is now quite successful as well.

___

I don't think I was any smarter or harder working than many of the recent law graduates around me at Oxford. But I probably had an unusual attitude to risk. When we started GoCardless, we were 25 years old, had good degrees, no kids and supportive families. When fundraising was going poorly, we discussed using my parents' garage as an office. McKinsey had told me to contact them if I ever wanted a job in future. I wonder if the offer still stands.

Of course, I benefitted from immense privilege. I had a supportive family whose garage I could have used as an office. I had a good, state-funded education. I lived in a safe, democratic country with free healthcare. And I had a job offer if things didn't work out. And so the downside of the risks we were taking just didn't seem that great.

But there's a pessimism in the UK that often makes people believe they're destined to fail before they start. That it's wrong to even think about being different. Our smartest, most technical young people aspire to work for big companies with prestigious brands, rather than take a risk and start something of their own.

And I still believe the downside risk is small, especially for privileged, smart young people with a great education, a supportive family, and before they accumulate responsibilities like childcare or a mortgage. If you spend a year or two running a startup and it fails, it's not a big deal - the job at Google or McKinsey is still there at the end of it anyway. The potential upside is that you create a product that millions of people use and earn enough money that you never have to work again if you don't want to.

This view is obviously elitist - I'm aware it's not attainable for everyone. But, as a country, we should absolutely want our smartest and hardest working people building very successful companies - these companies are the engines of economic growth. They will employ thousands of people and generate billions in tax revenues. The prosperity that they create will make the entire country wealthier. We need to make our pie bigger, not fight over the economic leftovers of the US. Imagine how different the UK would feel if Google, Microsoft and Facebook were all founded here.

___

When I was talking with many of these smart students this week, many asked me how these American founders get away with all their wild claims. They seem to have limitless ambition and make outlandish claims about their goals - how can they be so sure it will pan out like that? There's always so much uncertainty, especially in scientific research. Aren't they all just bullshitters? Founders in the UK often tell me "I just want to be more realistic," and they pitch their business describing the median expected outcome, which for most startups is failure.

The difference is simple - startup founders in the US imagine the range of possible scenarios and pitch the top one percent outcome. When we were starting Monzo, I said we wanted to build a bank for a billion people around the world. That's a bold ambition, and one it's perhaps unlikely Monzo will meet. Even if we miss that goal, we've still succeeded in building a profitable bank from scratch that has almost 10 million customers.

And it turns out that this approach matches exactly what venture capitalists are looking for. It is an industry based on outlier returns, especially at the earliest stages. Perhaps 70% of investments will fail completely, and another 29% might make a modest return - 1x to 3x the capital invested. But 1% of investments will be worth 1000x what was initially paid. Those 1% of successes easily pay for all the other failures.

On the contrary, many UK investors take an extremely risk-averse view to new business - I lost count of the times that a British investor would ask for me a 3 year cash-flow forecast, and expect the company to break even within that time. UK investors spend too much time trying to mitigate downside risk with all sorts of protective provisions. US venture capital investors are more likely to ask "if this is wildly successful, how big could it be?". The downside of early-stage investing is that you lose 1x your money - it's genuinely not worth worrying much about. The upside is that you make 1000x. This is where you should focus your attention.

___

A thriving tech ecosystem is a virtuous cycle - there's a flywheel effect that takes several revolutions to get up-to-speed. Early pioneers start companies, raise a little money and employ some people. The most successful of these might get acquired or even IPO. The founders get rich and become venture capital investors. The early employees start their own companies or become angel investors. Later employees learn how to scale up these businesses and use their expertise to become the executives of the next wave of successful growth-stage startups.

Skype was a great early example of this - Niklas Zenstrom, the co-founder, launched the VC Atomico. Early employees of Skype started Transferwise or became seed investors at funds like Passion Capital, which invested in both GoCardless and Monzo. Alumni of those two companies have created more than 30 startups between them. Matt Robinson, my cofounder at GoCardless, was one of the UK's most prolific angel investors, before recently becoming a Partner at Accel, one of the top VCs in the world. Relative to 15 or 20 years ago, the UK tech ecosystem is flourishing - our flywheel is starting to accelerate. Silicon Valley has just had a 50 year head start.

There is no longer a shortage of capital for great founders in the UK (although most of the capital still comes from overseas investors). I just believe that people with the highest potential aren't choosing to launch companies, and I want that to change.

___

I don’t think the world is prepared for the tidal wave of technological change that’s about to hit over the next handful of years. Primarily because of the advances in AI, companies are being started this year that are going to transform entire industries over the next decade.

It doesn't seem hyperbolic to say that we should expect to see very significant breakthroughs in quantum computers, nuclear fusion, self-driving vehicles, space exploration and drug discovery in the next 10 or 20 years. I think we are about to enter the biggest period of transformation humanity has ever seen.

Instead of taking safe, well-paying jobs at Goldman Sachs or McKinsey, our young people should take the lead as the world is being rebuilt around us.

[tomblomfield]

Monzo growth

I've been asked a few times recently how we got customers to sign up to Monzo in the early years and I haven't been able to give a satisfactory answer in a sufficiently short space of time. I thought I'd write out my thoughts in a longer piece so I can feel less bad about giving an incomplete answer - anyone who wants to know the details can read this instead.

Let's start with a rough timeline, which I'll then flesh out below.

2015

Started the company in February 2015.

We had a big, ambitious goal - to start a bank - and worked hard to get press coverage before publicly launching.

Ended the year with 3k "Alpha" cardholders and a waitlist of 20k.

2016

We launched an early prototype and continuously improved it.

Scarcity (waitlist) seemed to drive more signups - there was a standard "invite a friends and we'll bump you up the queue" mechanic.

A lot of hustle and hard work (100+ in-person events).

Community + Mission + Transparency - lots of blogging and social media. Crowdfunding.

Ended the year with about 70k "Beta" cardholders.

2017

Genuinely great product.

Market-leading customer service.

Hot coral card!

We consciously worked on viral product features & referral mechanics for the first time.

Ended the year with about 600k "Beta" customers.

2018

Full banking licence.

Hit 1m customers in September!

---

First, a note about the context. We started the company in the UK in February 2015, when "digital banks" weren't yet a popular idea. BankSimple had launched in 2012 with some big plans, but sold to BBVA in early 2014 with about 100,000 accounts, having struggled to raise sufficient funding to continue. N26 started development in late 2013, initially as a card for kids, while Revolut was founded a few months after Monzo, in April 2015. At around the same time, the UK regulator had announced plans to make it easier to start new banks, following the "too-big-to-fail" mess of the financial crisis, and it was on the back of this initiative that Monzo was born. 

We spent the first couple of months of the company’s life furiously writing a banking licence application, believing that the licence might be granted within 12 months. In fact, it took 3 years before we were able to open full bank accounts for the bulk of our customers. Even 12 months felt slow; it had only been a handful of years since I'd gone through Y Combinator with my previous startup, GoCardless, and I was terrified of spending too much time building something without a real indication that customers wanted what we were building. Going back through my notes from the time, I found I'd peppered them with YC mantras like "Do things that don't scale", "Launch early and talk to users" and "Make something people want". So we looked for ways to get a product into users’ hands as soon as possible.

Pretty quickly we figured out that we could use prepaid debit cards as a sort of hacky prototype for a full bank. Before that point, prepaid cards had only really been used for kids' accounts (Osper and GoHenry had both been founded in 2012) and the financially excluded - people who couldn't get full bank accounts. These prepaid cards were horribly loss-making, and lacked about 60% of the functionality of a full bank account, so we budgeted for 10,000 cards. At the time, we couldn’t imagine more than 10,000 people would be willing to test out an incomplete bank account. In fact, we had almost 600,000 active prepaid cards by the time we transferred all customers to the full bank almost 3 years later. Despite the cost, these prepaid cards let us get a product into the hands of real users, who could help us figure out what product features to focus on.

---

So, about 3 months after the company was formed, we had a couple of dozen live prepaid cards linked to our backend systems and a very, very basic iOS app. We gave Eileen Burbidge, our first investor, one of the very earliest prototype cards and she was so excited about the payment push notifications that she immediately tweeted about it, which led to a Techcrunch article in May (and a reply from the N26 founder saying that it was nothing special 😆)

I don't think we were really ready for the press - we quickly scrambled to get a waitlist up on the website and launched our blog a few days later. 

In any case, we got so much interest following the Techcrunch article that we doubled down on PR as a strategy. One of my notes at the time said we were aiming to get "Press at fever-pitch". Eileen seemed to know everyone in the UK press, and I worked really hard to meet journalists and explain what we were trying to build. More press followed over the next few months:

We were covered in the Guardian, The Memo, Bloomberg (complete with weird sci-fi photoshoot), Business Insider, Techcrunch again, plus a bunch more. It's important to note that we had zero real customers at this stage. Just two dozen internal test prepaid cards, a very basic iOS app and a lot of storytelling.

I spoke to Kiki recently (now the Director Of Communications at Monzo) about a conversation we had at the time. “I remember you turning up to my office when I was at the Sunday Times, signing me up with a Monzo account and telling me all about your plans to grow the business (and deep fry your Christmas turkey that year!)

You invested in forging relationships with the press and that paid dividends for you and Monzo. You were never too important to pick up the phone and explain simple stuff or go for a coffee with a journalist. Something many start-up founders don't do because they think it's all about finding angles and firing out press releases.”

PR is not a strategy that works for all early stage startups. I've been thinking a little about how it worked so well for Monzo in 2015 and 2016. Timing and context were important - the UK press was getting interested in startups (the Social Network movie honestly felt like a tipping point), but there weren't actually that many successful startups to write about in the UK in 2015. I had started another startup previously, and Eileen, our first investor, was very well known in the tech press, so I guess journalists were interested in covering us.

Probably more importantly, it seemed like we were embarking on a bold, ambitious project - to build a new bank from scratch - and we felt like underdogs in the way that the British press loves. So we got a lot of press, and I was the very visible figurehead. I'm pretty sure all that press was the reason for the hype and user signups we got by the end of 2015 - we didn't have a product live with users, nor did we really have any other meaningful marketing activity that year.

Looking back, I'm not sure how I feel about it. At the start, it was exciting to see my face in newspapers and it felt good when my friends and family told me that they'd seen me in an article or on TV. I guess I felt important, and it seemed to drive user signups. It was also a Faustian bargain. When we became a national brand name 4 years later, we were no longer the underdog - we were a big bank that the press could criticise.

I'm also not sure it was great for my relationship with my cofounders - we had 5 cofounders at the start, but it was often just my face in the picture. It was impractical to interview or photograph 5 people. They were busy working. Or at least that's what I told myself.

---

"Is it a bit early to hire a Head of Marketing?" - conversation with Eileen in June 2015, four months into the life of the company. Throughout June, July and August 2015 we were interviewing marketing candidates.

Although the hiring process was slow and frustrating, we learned a lot. We wanted to assess the paid social media ad skills of one candidate, so we had him set up and run 4 small Facebook campaigns. The first three were focussed on product benefits - "Here's a card that has no FX fees", "Turn off your overdraft", "Instant notifications". They all performed fine. But the fourth campaign outperformed the others by almost 300% - "Help us build a bank you'd be proud to call your own". This was to become a core part of our marketing over the next couple of years.

I eventually interviewed about 10 or 15 candidates, finally picking a woman who had decades of experience at a very large tech company and a UK media company. We hired her as a CMO. Looking back on my notes, all our conversations were about picking the right agency to run PR and another agency to run our paid social campaigns. She was used to running teams that were bigger than the entire headcount of the company at the time. I think she lasted less than 4 months.

At the same time, we interviewed and hired a young guy called Tristan as a community manager - he was in his early twenties, he'd graduated in Economics and spent the previous year in Egypt working with a local startup, where he'd picked up Arabic. He'd taught himself web development as a young teenager, and seemed to be extremely hands-on and impact-focussed.

Looking back, I think I would have counselled myself to think about what we wanted this person to do for the next ~12 months or so. If you hire a big-name CMO from a large, international brand, they are going to naturally assume there's a budget to spend on agencies and a marketing team. Even if they talk about being "hands-on" and "scrappy", that's probably only true relative to their previous work. For the first 12 months, what we really wanted was someone to write blog posts, respond to social media and edit the copy for our app and website. Tristan was perfect for us because he was representative of our customer base. Young, cosmopolitan lifestyle, socially conscious. He had never employed a marketing agency or really hired anyone at all, so it just didn't really occur to him to do that stuff. It was just obvious to him that he should write our Twitter posts himself.

We made another Head of Marketing hire later in 2016 who also didn't work out, and from that point onwards Tristan was put in charge of all marketing at Monzo.

---

Before talking about the launch of the product - the Alpha and then Beta programmes, I want to touch on a couple of things that didn't work.

First, we repeatedly thought about trying to pitch a TV production company to make a fly-on-the-wall documentary about Monzo in the early days. I still think that this might have been a great marketing idea to propel the brand onto a national stage (although may have made the eventual press backlash even harsher), but we just never followed through on it. Maybe it was just a vanity project!

We spent more time on a second idea - hackathons and developer relations. A lot of the early team (including me) were software developers and we were really excited about the idea of a bank account with an API. We ran 3 or 4 hackathons early on (even before we had live prepaid cards) and folks came up with a handful of interesting ideas, but we realised pretty quickly that this wasn't going to be a big growth mechanic. We only got 300 extra users, but it definitely helped hire several early engineers.

---

We finally got the "Alpha" prepaid debit card programme live to the public by November 2015 - it was a chance for people to get a card, try out the app and give us feedback to help improve the product. We capped the number of customers at 3000 because I think that was the limit for Testflight. There wasn't even a public release of the app you could download from the App Store.

What was the rationale here? The product wasn't even nearly "complete" - the list of things that were missing before you could call it a full bank account spanned several pages. Customers had to come to an event at our office to pick up the card because we hadn't yet built the functionality to collect customers’ postal addresses or post out cards. As a consequence, I met all 3000 of these users face-to-face - many of them would turn up to company events for the next 6 years and greet me with a smile.

Even though the app wasn't polished, exclusivity & scarcity was a big part of the strategy early on (drawing on early Gmail launch tactics). I read somewhere that human brains are basically wired to seek out scarce resources and perceive them as more valuable than those that are abundant. Being "in the know" - the first amongst your peers to get access to some new product or service - is a badge of honour amongst early adopters, and we harnessed that. Even the physical cards had "Alpha" printed on them - people would brag years later how early they'd signed up to Monzo. For these people, finding a bug wasn't an annoyance - it was proof that they were experiencing something at the bleeding edge of development, and they were excited to help improve the product. So we ran with that.

This is the first archived version of our website I can find - "We’ve only got 3000 invites for our Alpha Preview. Sign up now to be in with a chance"

It turns out this strategy also works on tech journalists. The early preview accounts we gave to Techcrunch and Business Insider journalists led to great coverage. 

This strategy also let us organise events at a number of London's top companies. We would promise to come along with 50 or 100 Monzo cards, give a 20 minute presentation during the lunch break, and enable attendees to skip the waiting list. This proved irresistible - I got into companies like Transferwise, McKinsey and the BBC. Much like the hackathons, it didn’t actually turn out to be a very effective way to sign up users, but it was an incredibly strong recruiting strategy. We'd get a flood of inbound CVs a week or two after each talk.

Looking back, it’s quite surprising how many major pieces of functionality were missing from the app. You couldn’t make bank transfers or pay bills, for example, because we didn’t yet have access to the payments infrastructure we needed. Instead, we obsessed over the tiny details that we could control - accurate merchant logos that represented your spending, rather than the cryptic data you normally find on bank statements. Jonas (one of our cofounders) first came up with the idea to add emojis to the push notification customers received to alert them about spending. Plane tickets might show 🛫, while spend at a coffee shop would show ☕. I have so many notes from that first year about improving the logos - I even wrote some of the early code to put the right emojis onto transactions. We really cared about making it a delightful experience.

Even before we'd opened up the product to the full waitlist, we decided to run a £1m crowdfunding campaign early in 2016. Again, we ran the "scarcity" and "exclusivity" playbooks. We anticipated the round would sell out, so we set up a pre-registration system so that our customers could invest before the general public, and we capped individual investment at £1000 to maximise the number of people who could invest. Along with owning shares in the company, investors would get "Investor" printed on their debit card (and this is still honoured to this day). Investors would also be able to skip the main queue and get access to a Monzo card if they didn't already have one.

The campaign turned out to be a huge PR coup, but mainly for reasons we had not anticipated. Approaching the launch date, we told our crowdfunding partner to expect larger than normal volumes of people looking to invest, as we already had 6500 pre registrations. For whatever reason, they did not take this warning very seriously, and their servers buckled under the load just seconds after the round opened on Monday. This was very annoying and stressful at the time, especially since 6500 simultaneous visitors is not a huge amount of load. We quickly decided we'd rebuild the investment registration page ourselves, and planned to relaunch the campaign a few days later.

While our engineers rebuilt the site, we thought about how to communicate this to the press and our customers. It was an absolute gift of a PR story - we had so much demand to invest that the crowdfunding site had crashed. This story ran continually over the next couple of days. By Thursday, the campaign relaunched and sold out in 96 seconds, making it the fastest crowdfunding in history, and the press attention was intense.

We ultimately raised £1m from 1861 investors, out of the 6500 people who had pre-registered. In comparison, we only had 3000 cardholders who up to that point had only spent £1m in total on our cards. I'm not sure how repeatable this lesson is - lots of companies have tried crowdfunding since, and it's no longer newsworthy. I think we had an incredible amount of hype at the time, and we played the scarcity/exclusivity angles well. It also helped that we already had 45,000 customers on a waitlist, and £5m investment committed from Passion Capital - this was an extra £1m investment that normal people could get access to on the same terms as a VC.

---

Soon after the crowdfunding completed, we announced a public Beta in March 2016, the Alpha having capped out at 3000 users (the Testflight limit). This was 13 months after the company was founded.

Anyone (as long as they were an iOS user) could download the Monzo app and see their place in the queue. People could improve their place in the queue by inviting friends to join and a certain number of people at the top of the queue every week would have a card sent out. In the spirit of “doing things that don’t scale”, we figured out a basic system for collecting addresses in the app and posting cards directly from our office. When we had a particularly big week of signups, the whole team would have to stop their regular work to help stuff all the prepaid cards into envelopes to catch the last post. I vividly remember stuffing envelopes at the time, thinking “each of these cards is another person who wants to use our product”. It really felt like customers were signing up faster than we could ship out cards - one of the first indications that we had “product-market fit”. It seemed like we were on the verge of something huge.

I think there are a couple of interesting things worth mentioning in 2016 - both related to company values. The first is our name-change. We had been threatened with a trademark lawsuit from a German fintech company which had a similar brand name (we were "Mondo" at the time) and considerably more funding than us. I fought this for several months (against the counsel of my board and investors), before accepting we had to change our name. To make the most of a bad situation, we decided we'd ask our community members - our customers - to suggest new names. The only constraint was that it had to begin with "M" because we had recently designed a great new logo that we didn't want to give up. Incredibly, bearing in mind we only had around 20,000 customers at the time, we received 12,000 suggestions in about two weeks. 6 people suggested the name we chose - Matt from Bristol had studied a rock called "Monzonite" and another customer, Ashley, told us it was slang for money when he was a kid in Scotland. We hosted a big party and live-streamed the announcement of the new name - Monzo.

Predictably, our power-users overwhelmingly hated it, suggesting it sounded too much like  "gonzo" (a form of first-person journalism and, later, pornography). It took a little while to stick, but I like it - it sounds much more dynamic and active than "Mondo", which now feels quite staid to me.

The second was our transparent Product Roadmap. In a world where the big banks had huge head offices and enormous marketing budgets, but very little personal trust, we wanted to come across as different. Where big banks were faceless and corporate, we would be human and personal. Where they were impenetrable and secretive, we would be transparent and approachable. So, in May 2016, we announced we'd publish the plans for our product, and take input from our community. In other situations, when things went wrong, we'd proactively tell our users about it and explain what we were doing to fix the situation. Invariably, this transparency generated more customer goodwill and positive PR.

These two core values - Community and Transparency -  permeated almost everything we did throughout the life of the company. They became a fundamental part of our brand. Prior to Monzo, I didn’t really believe in the concept of “brand” - I thought it was a made-up thing that marketing agencies tried to sell you. And that “brand” didn’t really extend beyond a company’s name and logo. I now believe it can be a superpower for any company - and particularly consumer-facing businesses.

There’s been good stuff written about brand-building elsewhere, so I won’t try to recreate it all - I’ll offer just a handful of thoughts. A great brand is like a promise you make to your customers. It’s a shared set of beliefs, or the “why” behind the company. Building your brand is not a one-off thing; you build (or damage) your brand with every decision you make. Events like crowdfunding and the company rename were perfect examples to reinforce the brand. It has to be authentic - a lot of big banks’ marketing towards younger customers felt really painful. Monzo, in contrast, felt human and relatable.

And when a brand really resonates with a customer, it becomes an extension of their identity. I wear Patagonia. I drive a Tesla. I use an iPhone. I bank with Monzo. I think a lot of customers were proud to pull out their Monzo card and feel like they were part of something. 

In the UK, at least, Monzo has become a verb.

---

We grew from about 3,000 users at the start of 2016 to 70,000 by year-end, which seemed pretty good, but I think we realised in the summer of 2016 that our strategies so far weren't going to scale to drive the kind of continued growth we ultimately needed. So, towards the end of the year we really started to think about product features with network effects, and referral mechanics. Pretty quickly, this became "Monzo with Friends" - we aimed to build a product that worked better and better as more of your friends joined. We started working on ideas, but nothing really launched until early 2017, so I'll talk about this more in the next section.

Before that though, here are two things that failed in 2016. First was the idea of "Campus Insiders" - university students that we employed to represent the Monzo brand and sign up new customers. They required a lot of babysitting and delivered no measurable impact, as far as I can tell. One of our early ideas was to have a custom Monzo card for each university - similar to how we had "Alpha" and "Beta" subtly printed on the corner of the card. Students might get Monzo "Oxford" or Monzo "Birmingham" if they signed up with a student email address. This could have maybe extended into discounts at local shops, but it seemed like too much work and we never followed through with it.

The second was a campaign to work with local businesses in the Old Street area of London in the run up to Christmas. I think we had folks out flyering and offering discounts in local shops, but again it was a lot of manual work with no discernible impact.

---

2017 was the year of product-driven growth.  We had a slide in several of our early investor presentations that said "Viral mechanics will get us to the first million customers", but investors overwhelmingly didn't believe it. We set out to prove them wrong.

I'll make a distinction between two related ideas - viral mechanics and network effects. A "viral mechanic" normally uses the existing customer base to spread the product to friends. It’s sometimes called "member-get-member", and it can be incentivised or free. An example is the way Wordle allowed you to post your "score" to social media. Other people see it and sign up for Wordle themselves. The game isn't really improved in any way by having your friends join - they're just curious to check it out. Gmail used a viral waitlist + invitation mechanic in the early days - again, your experience of Gmail wasn't really improved if you convinced your friends to switch from Outlook.

A network effect is different - the product itself actually improves as more of your network joins. Whatsapp and Skype are great examples. The more of your friends who join, the more people you can communicate with for free. That was a big hook at a time when people paid for SMS and international phone calls.

Great products have both network effects and viral mechanics. Facebook's early photo tagging is an example. "You've been tagged in a photo" email - prompts you to sign up for Facebook, see the photos you're in, upload your own photos, tag more friends, repeat. The network gets more valuable and drives more growth as more users join.

At Monzo we had both of these, and 2017 was the year they really took off.

I'll talk about "Golden Tickets" first - a silly allusion to the Willy Wonka story. We had a pretty big waiting list at this point, but the "Invite friends to get bumped up the queue" felt a little old and ineffective. People who wanted an account enough would just create a bunch of throwaway email addresses. We figured that the best people to be making referrals were those who were already actively using the product. Presumably they liked it enough because they kept using it, and they'd all had the experience of having to wait in the queue, so they perceived a Monzo account to be both scarce and valuable. 

Rather than paying our users to refer friends like most apps did, we decided that once you'd used the account for about two weeks, we'd send you a single "Golden Ticket". This was a one-time-use invitation that you could send to one friend to enable them to skip the queue entirely and get a Monzo account straight away. You can think about the psychology by analogy - you've queued all afternoon to attend a cool new event in your city, you’ve just managed to get in the door, and you've been able to talk the bouncer into getting your friend a queue-jump ticket. You get the early-adopter social credibility of having known about the event before your friends, plus you’ve done your friend a favour by getting them access. It just worked incredibly well - about 40% of our signups in 2017 came from Golden Tickets, and it cost us nothing.

Second, "Monzo with friends" was our drive to make Monzo work better if you invited your friends to use it. This might sound obvious now, but I can't really think of any other bank that had previously done this, beyond suggesting you get a joint account with your spouse. If you used Barclays and your friends used Natwest, there was no change in how useful the account was, right? We wanted to change that.

We started with peer-to-peer payments, based on the contact-list of your mobile phone. For US audiences, this was Venmo, but inside your bank account. UK banks already allowed you to pay any other UK account holder instantly, for free, but you needed to know their account number and sort-code, and the interface was really clunky. It basically worked, but it wasn't a delightful experience. We asked people to share their phone contact lists (using some clever encryption so that we'd never actually saw your friends' mobile phone numbers), and then allowed you to pay your friends on Monzo with just a couple of taps. For contacts who weren't on Monzo, that's where Golden Tickets came in! It was a really slick interface, and we allowed you to include longer-than-normal messages with the payment, including emoji. Later that year, we added "Reactions" - if you'd received money from a friend, you could send a quick response - just a single emoji. This was just a quick way of saying "thanks, payment received". And we let people quickly upload profile pictures to make it feel more personal.

We then added "Split the bill" functionality for a single payment, plus a more general "Request money" feature, and finally more complex "Shared Tabs" for multi-day trips away with friends and family that might include dividing several payments. If your friends weren't on Monzo, you could still request money with your personal Monzo.me link, which would allow folks to pay you using another bank card or Apple/Google Pay (and Monzo covered the transaction fees), and included a little upsell for Monzo at the end. Mine is https://monzo.me/tomblomfield. If you clicked on this link with a Monzo app installed, it would just deep-link straight into the Monzo account with all the payment information pre-populated. 

Alternatively, if you went for dinner or drinks and wanted to split a bill with someone who already had Monzo, but who wasn’t in your phone’s contact list, you could securely broadcast your account details by bluetooth, so you could pay each other without having to type in any account information. It's an incredibly slick experience that I am proud of to this day.

Peer-to-peer payments drove massive adoption - time and time again we saw Monzo take hold in a new group of friends and then quickly spread to the entire group. At the start of 2017, only 5% of our users had 10 or more friends on Monzo. By the end of 2017, more than 40% of our users had 10+ friends on Monzo. Today, the average Monzo user has more than 100 friends on Monzo. This is network effect in full force.

2017 was also the year that we really got a handle on our metrics - particularly retention. There are much more complete retention guides out there, but I'll give a quick summary here. Say 100 users sign up for Monzo, complete KYC, register a card and load money into the account. That's the denominator - 100 funded accounts. Fast forward say three months - how many are still using the account? Maybe 60? That's the numerator. So we have 60% (60/100) retention at Month 3 (or day 90). You can draw a curve to show how quickly retention falls off day by day since signup.

What does "still using the account" actually mean? We decided to count "at least one financial transaction in the 7 days" would make you a Weekly Active User (WAU). "At least one financial transaction in the preceding 30 days" would make you a Monthly Active User (MAU). Clearly, a WAU was more engaged than a MAU. I dug out our stats for 2017 - about 60% of our signups were WAU on day 90.

These retention rates still strike me as surprisingly high, especially considering that every user had to proactively add money to the account every time they ran low on funds. This wasn't (yet) a bank account where you sort of "defaulted" into retention once a customer set up the account - users could not deposit their salary into the account until 2018, and there was no auto-top up functionality.

Monzo started 2017 on 70k users and ended the year on around 650k - averaging just under 5% compounding weekly growth for 52 weeks of the year. 

So why did it grow organically and retain so well?  First of all, I think the day-to-day product experience (for all its functional limitations) was world-class - it was a delight to use, especially compared to the clunky old banking apps in the market. Without that, basically nothing else would have mattered. The customer service was also exceptional - this was often mentioned in our NPS surveys (NPS was around +70 at the time).

Secondly, I think the brand we had started to build really resonated with people. Our mission and values (mainly transparency and community) seemed to strike a chord with customers. Even the card itself was visibly different to traditional banks. The Monzo card was "hot coral" (aka bright pink) - the colour alone often started a conversation when customers pulled it out of their wallets to pay. Our tone of voice was youthful, direct and extremely personal. By 2019, Monzo was the single most recommended brand in the UK.

And third, the network effect really started to kick in - if you had 3+ friends on Monzo when you joined, you had a 70% chance of being a WAU by day 90, versus only a 50% chance if you didn't have any friends on the platform.

As a result of these things, Monzo hit 1 million customers in September 2018, without having spent any significant money on marketing.

---

This feels like a good place to draw this chapter of a story to a close. There are other topics I’d like to write about - getting a full UK banking licence, fixing unit economics, and spending money on paid advertising to catapult the bank from 1m to 4m customers - but they will have to wait for another time.

[tomblomfield]

How to raise investment

Update: I am no longer personally angel investing - I'm focussed on other things at the moment. Please don't ask me to invest in your company! 🙂

I started angel-investing in 2021, and a large proportion of the companies I put money into asked for help raising an investment round. So I wrote up my standard advice as a guide here.

This guide is based on my experience raising about $400m at Monzo over the last 6 years and investing in about 75 seed deals as an angel in 2021.

It will be most relevant for founders who are raising a Seed or Series A round, with some amount of product development and early customer traction.

I believe the following advice is mostly correct as of September 2021. The market is changing so quickly that it may not stay correct for long. I plan to update it periodically.

General Approach

First, a couple of warnings.

If you build a strong business, fundraising will normally be easy. If you're too focussed on fundraising, you may never actually build a strong business.

It's very easy to get sucked into the competition of raising at the highest valuation of all your peers. This may feel like winning, but it is not. Seed-stage valuations don’t correlate well with success. Success to me means building a sustainable, profitable company that makes something people love. Investment is just a tool to help you do this.

Airbnb raised its first round out of YC at a $1.8m valuation. They've done pretty well. An extra 3-5% dilution isn't going to matter if you build a very successful company.

Conventional wisdom says you should aim to raise enough money to fund your business for the next 18 to 24 months, or until you hit a major milestone that's going to create a step-change in the valuation of the business. If that next milestone is "reaching breakeven", you will have a dramatically easier time fundraising in future - you can decide whether to raise more to grow faster, or run the business for profit. You have all the power.

I have always spent approximately double what I've forecast (oops), so I'd advise doubling whatever you estimate.

Fundraising is extremely distracting. If you have multiple founders, nominate one to run the fundraising process. He or she should be the primary point of contact for investors. VCs may want to meet all the founders once or twice, but all founders don't need to be in every meeting. As an angel investor now, it’s normally a red flag if there are 2 or more founders on the initial phone call. It typically makes the conversation more awkward as the founders talk over each other, or one person sits silently in the background.

If you have a CEO, this is the obvious person to run the fundraising. If you don't have a CEO, you're in for a potentially awkward discussion about who runs fundraising. This is one of many reasons I recommend deciding on a CEO earlier rather than later. We did not do this at GoCardless and it was painful.

Fundraising will become all-consuming, so you need to ensure your day to day job is covered by others for the duration of the process. If you are responsible for sales, for example, expect sales to dramatically slow during fundraising unless someone else covers it.

The VC Business Model

Before diving into the details of fundraising, it’s worth briefly understanding how the venture capital model works.

VC returns are extremely skewed by a tiny number of outsized successes. a16z's shareholding in Coinbase at IPO was worth about $10bn - roughly equivalent to all the funds a16z raised during their first 10 years of existence. Passion Capital's Monzo shareholding is worth about 5x the size of all their raised funds combined. The initial investment in Monzo has currently increased in value by approximately 100x, even after dilution - and I believe that will continue to increase (I may be biased).

VC returns are driven by outlier companies.

So VC investment decision-making is driven by fairly straightforward psychology. It's the fear of missing out on one of these apparently "hot" deals. This can then create a very aggressive bidding war. A hot round may get done in a handful of days.

Conversely, a VC doesn't really want to look stupid in front of all their buddies by investing in a crazy idea that comes to nothing. However, economically, it's much better for a VC to invest in a few extra "duds" than to risk missing out on the single hot deal of the year.

There's a second factor here - a massive global over-supply of capital. Recently, late-stage investing has been dramatically shaken up by investors like Softbank and Tiger Global deploying astonishing amounts of money into growth-stage companies in just a handful of days. Traditional growth stage investors are finding that they're too slow, or being consistently outbid on price. Their response has been to invest more money, faster, and into earlier-stage companies. This then squeezes the Series A investors who are now doing more and more seed deals.

The combination of these factors has lead to a massive rise in "pre-emptive" termsheets. VCs will try to offer termsheets to founders before they've had the chance to talk to a wide range of VCs in the market, with the aim of avoiding an expensive bidding war. Predictably, this just further increases valuations.

Raising with just an idea

This is this biggest mistake I see first-time founders make. Especially non-technical founders without a very strong CV. Trying to raise money from VCs with just an idea and a pitch deck is extraordinarily difficult unless you've successfully started a company in the past (or maybe been an early employee at a successful startup).

Instead, you should spend your time developing a prototype of your product and testing it out with customers. If you can't build it yourself, you should learn to code or recruit a technical cofounder. If you can't successfully do either these, you're probably not going to persuade investors to give you money yet. You could think about applying to an incubator like Entrepreneur First.

As an investor, it's basically the first filter I apply to exclude people who can't get stuff done. Of 50 investments I've made this year, 45 had a working product and active customers. Of the remaining 5, 3 had a working prototype and launched to customers within weeks of my investment. Only two raised on the strength of the founders and the idea alone - and in each case the founders had previously started businesses worth more than $100m.

Even the most minimal prototype and customer usage is better than nothing. I'll write a separate guide to building and launching a prototype at some point in the next few months.

So, as well as a great idea and impressive founders, you ideally need....

Traction

Traction is a phrase that investors seem to love. It reminds me of a medieval torture device, but perhaps that's because I have spent too much of the last 10 years fundraising.

You want to show investors some early metrics that can be extrapolated to show that you're going to build a very big business very quickly. This is "traction".

The best kind of metric is profit. This is very uncommon for early stage startups. The next best kind of metric is revenue - especially recurring revenue (if it's recurring, you don't have to keep acquiring users to simply maintain stable revenue levels). If you can't show revenue, try to show active users plus a coherent plan of how you're going to make revenue in the future. Total signups, app downloads or waiting-list signups are the next best metrics in order, but they're much less compelling than revenue or active users. Waiting list signups are widely ignored unless they're absolutely explosive. Monzo had a peak waiting list of about 300,000 people in the UK.

Letters of Intent for B2B companies are a bit like waiting list signups. Mostly useless.

The absolute value of your metrics is less important than the rate of growth. Hitting £100k monthly revenue after three years is much less impressive than £10k monthly revenue that's doubling every month.

"A good growth rate [at seed stage] is 5-7% a week. If you can hit 10% a week you're doing exceptionally well. If you can only manage 1%, it's a sign you haven't yet figured out what you're doing."

Tactics

With this in mind, you want to think about how to create a sense of scarcity and urgency about your round. You should aim to appear to be the hot deal of the year.

I would start by developing close relationships with perhaps 5 of your top target VCs. You might meet them for coffee every 2-3 months and share your plans, but say "We're not raising yet - maybe in 6 months". Share awesome product demos, social media buzz and impressive new customers. You can include them in your monthly shareholder update emails, and (hopefully) show metrics going up month after month, along with any major milestones you’ve hit. This is evidence of your "traction". I find this much more compelling than a polished pitch deck.

If you already have angel investors, use them to backchannel into VCs. They'll say "this is going to be an exceptionally hot round, you need to get in before they run a full process."

You want to project quiet confidence, huge ambition and relentless determination. UK founders often come across as extremely understated when compared to US counterparts. The front page of Monzo's first pitch deck said "We're building a powerful financial control centre for a billion people around the world".

You will know if you have succeeded in creating this buzz because you will have 5 new best friends. You’ll get phone calls every day and they will reply to your emails in seconds. I have had VCs show up at my house to try to get into deals. They’ll take you to fancy restaurants and buy you drinks.

Some of these VCs might try to “pre-empt” your round by offering you a termsheet before other VCs have had a chance to learn about your business. In general, companies that run a process with multiple competing VCs tend to get better terms than companies that accept a pre-emptive termsheet. But you may still consider accepting the pre-emptive offer if it is ridiculously good. I have done both in the past.

Running a Process

As you’re raising a seed round or Series A, this process can be pretty lightweight. As you get into Series B and onwards, it may get more complicated.

First, start with a list of perhaps 8-10 relevant VCs. These should be funds who you know will invest in your industry, geography and company stage. It’s pointless pitching a sovereign wealth fund for a seed stage investment, or a B2B SaaS fund if you’re a consumer-focused company. This is one of the most common mistakes I see new founders making. You’re wasting your time.

Pre-seed and Seed investors tend to focus on one geography, while later-stage investors are often more global. Having said that, funds are investing earlier and more globally than ever before. I’ve seen Index and Sequoia recently making a bunch of seed-stage investments in Africa, for example. This would not have happened even 3 years ago.

Next, put together a deck. YC has a great Series A pitch deck guide here. I think that advice still applies for seed rounds.

I would practice your pitch on 2-3 friendlier (or lower value) VCs first and ask for their feedback. Make a note of the common questions they ask, and make sure you have good answers to these. If you want to tweak your deck, do it now. This should take 2-3 days max.

Then, without too much delay, get introduced to the remaining VCs on your list. This is where early angel investors can be extremely useful. You want to avoid cold emails if at all possible.

Your aim is to schedule as many of your first meetings in parallel - perhaps the same week or two-week period. This creates a competitive dynamic that works in your favour.

If your round is dragging out over several months, you'll lose this advantage. It's still entirely possible to get the round done, but it will be harder work and your valuation will be lower. Probably 30% of the rounds I’ve raised have been “hot” - and very fast. 70% have been hard work, slow and stressful. This latter kind is normal. But we generally only read about the hot rounds in the press, so popular opinion is skewed towards thinking most companies raise money in 1 or 2 weeks.

Initial Call / Pitch Meetings

You generally want to be pitching the most relevant General Partner at the fund. That’s the most senior partner who covers your area. Larger funds will have pretty rigid specialisations, so a certain person does all the fintech deals. That’s fine - just figure out who that is.

Associates, analysts, “venture partners”, or EIRs (entrepreneurs in residence) will almost always carry less weight. Try to get introduced to a full partner if possible. Some funds have tried to combat this tactic by calling almost everyone a “partner”

It can be useful to build relationships with associates before raising, especially if you can’t get to a partner directly. Our first VC investment at GoCardless happened because I was introduced to an associate at Accel called Tyler several months earlier.

Since the Covid pandemic, almost all initial meetings are conducted on video conference. I would recommend that everyone spends ~$200 on an external camera, mic and lighting. Make sure you have somewhere quiet to take the call and a good internet connection. It makes a massive difference and it's surprising how many founder neglect this.

The best pitches start with an element of story-telling (perhaps 2-3 minutes) and then develop into a great conversation. If you are delivering a monologue for 30 minutes, you’re doing it wrong. Engage the investor in the conversation by asking them questions - how would they think about a potential challenge you’re facing, for example. Try to figure out what gets them excited, and double down on that. Don’t feel like you need to cover your whole pitch-deck in the intro meeting.

Follow-Ups and Monday Partner Meetings

If your meeting goes well, the investor will ask you follow-up questions (perhaps for some additional data) and may ask to meet you again, or have you meet with another (or several) of their partners. These are all good signs, and will usually happen rapidly.

If the investor doesn’t get back to you pretty quickly (within a couple of days), it’s normally a bad sign. You can send one polite follow-up email, but it’s usually pointless after that. If you’ve not heard from the investor in weeks, I wouldn’t bother chasing. They’re a) not interested (fine) and b) disrespectful of your time (not fine). The best investors always reply promptly (whether it's positive or negative).

Conversely, you should make sure to reply promptly to any follow-up requests they have. If you promise to send something by a certain day/time, make sure it happens. It’s the investor’s first impression of how you do business. Keep all your contacts in a spreadsheet (or lightweight CRM) and track what you've promised to each investor and by when.

Investment rounds are getting done faster and faster - it may only take a couple of partner meetings over a handful of days to get a termsheet for a seed round.

How you get to a “yes” decision - an offer to invest - varies from fund to fund.

Some funds will let any single partner make an investment if they have conviction. For solo-GP funds this is always the case!

Other funds will require a majority vote or (near) unanimous consent from amongst the partner group. This is quite common.

The worst funds have a strict hierarchy - the deal won’t get done unless the top guy (sadly it is almost always a man) says “yes”. I’d avoid working with these funds if you have a choice.

The fund may ask you to present to their whole partnership at a Monday Partner meeting. I have no idea why these are always on Mondays. I’ve done one of these Monday Partner meetings perhaps 4 times ever in my life, and I’ve raised probably 10 rounds of investment across various companies. It feels like they’re getting rarer.

If you get a “no” from the investor, it can be emotionally tough. But I’m afraid that’s part of the process. A normal company might get 20 “no” responses before they get a “yes”.

Unfortunately, many investors will send quite a lot of bullshit reasons for a “no”, rather than reveal their true rationale - which is normally that you did not sufficiently impress them, or your traction is too far behind comparable peers. Unless you really trust and respect the VC, take the “no” part onboard and discard the rest. I found Michael Abramson at Sequoia and Angela Strange at a16z both exceptional for writing really thoughtful rejection emails.

If you've been fundraising for 3-6 months and you’ve had 30-40 “no”s from decent VCs, then you’re in a tough spot. What you are doing isn’t working, and so you probably need to change your approach. There’s a point past which perseverance becomes destructive.

At this point, you need to become a cockroach - impossible to kill. Reduce costs, seek out revenue and keep burn to an absolute minimum. At this stage, it’s worth looking for the 1-2 common rejection themes from the VCs and working to fix them. For early-stage companies, this is generally that you don’t have enough traction with customers - people don’t seem to care about what you’re building. You need to find product-market fit, possibly by changing your core product. This is a subject that deserves more time in another post.

Termsheets and Legals

If a VC wants to invest in your company, they'll issue a termsheet to be the lead investor.

It will contain the main terms of the investment - pre-money valuation, investment amount, board seat, and perhaps 2-3 other key terms. You should have talked about the approximate amount you're looking to raise before a VC issues a termsheet, but I would suggest letting the lead VC suggest the price first.

The exception might be an ultra-early pre-emptive offer, when you really don't need the money yet. You might say "we don't need money for the next 12-18 months, and at that point we will be targeting a £1bn valuation, because we will have hit all these milestones. So for me to accept money now, that's the valuation I'd be looking for. Otherwise, it makes sense for me to wait". In this case, just think of the most outrageous price you can say with a straight face.

The termsheet will often leave room to bring in additional investors. Eg, the VC might offer to invest £1m in a round of up to £1.5m total, at a pre-money valuation of £4.5m. You can work with the lead VC to bring in other angels or VCs for the remaining £500k.

A termsheet is not binding on the VC (they can still technically back out), but prohibits you from soliciting investment from other VCs after you've signed it, usually for a period of 30 or 45 days.

Personally, I have only experienced investors reneging on signed termsheets once - as COVID took the world into lockdown. It's very, very rare for a top-quality VC to pull a termsheet. Shitty VCs may pull termsheets more often, but they quickly develop a bad reputation for doing so.

You will usually be given a few days or perhaps a week to sign the termsheet, or decline it. It is considered bad form to share the contents of a termsheet with other investors, but it is pretty standard practice to let any other firms in the running know that you've received a termsheet. Doing this with some level of deniability (eg, get an angel to do it for you) is sometimes useful. This will spur other VCs to make a faster decision, and potentially trigger a bidding process. It's a very useful forcing function.

You do not want to be seen "shopping around" your unsigned termsheet, but you can say something like:

There are two other interested firms, and they've already put in a lot of work with us, so I want to respect that work and give them a chance to get to the end of their process. They'll need another 5 days. Is that ok?

This is why it's important to keep a small number of VCs regularly updated. If you get a very early pre-emptive termsheet, other firms may be too far behind to get up to speed in 5 days from a standing start. This is less of a problem at seed stage - since it's more of a gut judgement about the quality of the founders, rather than any detailed analysis of business metrics, it can be done in a few hours.

You generally want to avoid naming the other VCs who are in the running, because it can encourage collusion. The VCs may just get on the phone to each other and agree to split the round at the already-agreed price. Instead, you ideally want them bidding each other up.

Only bad VCs will ask who else is looking at the deal, and you can just reply with something like “the usual folks you’d expect at this stage”. If they insist, you can simply refuse to answer. Treat this as a big red flag.

Picking a VC

If you’re in the fortunate position of having multiple, competing termsheets, you need to think about how to pick.

Along with the money, you should pay attention to the individual leading the investment from the VC firm. Arguably, choosing the right person is more important than the choice of the VC firm itself. You will be spending a lot of time with this person over the next 5-10 years, and it's almost impossible to get rid of them if you don't get on.

A fair valuation with clean terms and a VC you like is much better than a market-leading valuation with horrible terms, or a VC who behaves badly.

The first data point is the way the investor has behaved during the pitch process (and previous interactions). Did they show up on time? Did they follow-up promptly? Were they inquisitive and courteous during your pitches, or distracted and disrespectful?

I've worked with some fabulous investors over the years - Eileen and her partners at Passion, Anu at Y Combinator, Sonali at Accel, Adam Valkin at General Catalyst, Ed (now at Alpine) and Chi-Hua at Goodwater, Miles at Thrive (now Benchmark), Michael Moritz, the Stripe team and many more. I recommend them all to the entrepreneurs I speak to.

I've honestly also encountered some shitty ones. There are VCs who've verbally offered me terms and then tried to back out weeks later. I won't ever work with these folks again.

One particular example of bad behaviour that I will name is Softbank (at least the London team). Like most growth-stage founders, I've pitched them for investment multiple times. They passed - no hard feelings. But it seemed like standard practice during my visits to the London office to make me wait in the lobby, often for an hour or more after the meeting was supposed to start. I heard of one founder who'd flown in from another country and was made to wait for the entire day in their lobby.

Their behaviour during pitches was worse. The lead partner took meetings barefoot, and would pick his feet incessantly. During one meeting, he lit a cigarette and smoked it in his office, windows closed. He finally put it down in his lunch plate, and poured his coffee over the cigarette to extinguish it. I didn't know if it was some weird power play, or if he just lacked any kind of manners. Looking back, I wish I had the guts to ask him to stop, or to simply get up and walk out of his office. But my company really needed the investment and I didn't want to blow my chance.

Blind reference calls are also crucial here. The founder calls that the VC offers are less likely to give you a fully rounded view of the firm. They’ll pick their winners. But, especially for portfolio companies that have failed or are doing poorly, you want to know how the VC behaved. It's easy for everyone to be founder-friendly when times are good. During a crisis, behaviours sometimes diverge....

Example questions for founders:

Tell me about a time when you were really struggling to raise money to keep the company going.

Did the VC offer to participate in the round? Or even lead the round if you couldn't find new money? Were they helpful finding new investors? Did they push for a valuation cut, or attempt to introduce onerous terms? Have they tried to sell or transfer their stake in the company before you were ready? What was their language and behaviour during the tough period? Did they roll their sleeves up and help out, or did they ghost you?

What's their behaviour during board meetings? Do they add useful insight, or just like the sound of their own voice?

What are their regular information requirements? Do they bombard your finance team with constant ad-hoc queries?

Have they ever gone above-and-beyond what you expected to put in work for the company? (I had an investor who interviewed a bunch of ex-execs from all our competitors to gather intelligence)

If you don't have the good fortune to have multiple, competing termsheets, I think it's still worth doing the reference calls - you need to know what you're about to get into.

It's really tempting to skip the reference calls and just celebrate your termsheet. Don't do this.

Legals and Diligence

Once you sign a termsheet, the lead VC will do some basic “due diligence” (this will be less onerous in seed/series A compared to later rounds). This will involve reference calls to previous employers or colleagues, and checking your company documents, employment contracts, IP assignments etc. Any other (non-lead) investors should be able to piggy-back on the lead investor's diligence, rather than doing their own.

It's worth getting your corporate paperwork in order & up-to-date in a single Google Drive folder before you start fundraising, so that you can share with investors when they ask. This speeds things up a lot.

You'll need to appoint a lawyer - you can ask other founders or angels for recommendations. Your prospective investors will often ask you to cover their legal costs (the money just gets subtracted from the investment amount). This is annoying, but seems to be standard practice. For Seed or Series A, maybe try to keep it to $15,000-$25,000.

The VC's lawyers will put together an Investment Agreement, and modify your Company's Articles of Association (or create them from scratch if they don't exist). Your lawyers will review the documents, and raise any points with you that they think are contentious or non-standard. Good VCs will make this process very simple. Shitty VCs will try to sneak in all sorts of garbage.

One term that sometimes gets left until late in the process is the option pool top-up. Ideally, this should be covered in the termsheet. It's standard for investors to require the unallocated option pool to be topped up to a level that will equal 10% (sometimes less) of the post-investment shares, but for this to happen immediately before the new investor puts money in. Essentially, existing shareholders get diluted by the top-up, but the new investor does not get diluted. Again, it's a little annoying, but seems to be market standard.

This whole process might take 2-6 weeks, depending on how efficient the VC is, and how quickly you reply with the requested information.

The investment is only final when the money hits your bank account.

Congratulations. You now need to get back to building a successful business!

Angel Investors

“Angel investors” are rich individuals who invest small(-ish) amounts of their personal money into early stage technology companies. They have often (but not always) been founders or early employees of successful startups. A small angel cheque might be £5,000 or £10,000, but some “super-angels” make investments in the millions.

People take different views on how useful angels are. I’ve seen a seed round recently consisting of 56 separate angel investors. Other founders almost never take money from angels.

People talk about several different advantages that angels can bring.

If you get a number of angel investments early in your fundraising process, they can help by making warm introductions to VCs.

If you’re a B2B company, the founders of potential customers can help with product feedback and sales.

You can sometimes get other, more general business advice from angels who’ve been operators or founders themselves, but the quality of this advice is extremely variable.

Some founders seem to collect angel investors for their “brand name” or PR value. This is mostly bullshit, unless the angel is Jay Z. Journalists honestly don’t care that I’m investing in your company.

Very active angel investors may make 50+ investments a year, so realistically it’s hard for them to be super involved in your company.

The downside of taking angel money is that managing a group of angels can be like herding cats. You will need their signature on every official corporate action for the future of your company (ie future fundraising). If one angel has decided to go on a month-long ayahuasca retreat in the Peruvian mountains, it can be very inconvenient. If you really want to include angels, I would stick to the 5 or 6 highest value people, and enforce a reasonably high minimum cheque size.

You may also come across angel syndicates - this is generally for groups of angels who want to invest less money - perhaps £1k - £5k per deal - and as such find it hard to get individual allocation. So they all club together and offer to invest £50-100k as a syndicate. This is good for the entrepreneur because you only need the signature of the syndicate lead in future, but the value-add of each of the individual investors tends to be even lower. There are exceptions.

You can either try to pitch angel investors early - before you start talking to VCs - and aim to get a handful onboard who will help to make introductions. Or you can carve out a proportion of the round for angels after you have a termsheet, and then go and select angels you think will be most valuable.

Personally, I always steered away from taking money from angel investors. They are usually not as valuable as you think. And I say this as an angel investor myself!

Crowdfunding

I was involved in raising about £35m (?) in crowdfunding at Monzo, across 3 or 4 rounds. It is probably the slowest, hardest and most expensive way to raise money.

If you’re struggling to raise VC funding, it’s almost never a good fallback option.

But it is useful, I think, for deepening the engagement you have with your early customer base or community, especially where you want to get them involved in product or brand development.

Whether it’s a Kickstarter campaign, Steam Early Access or an equity platform like Crowdcube or Seedrs, it’s a great way to set expectations that this is a prototype product and invite customers to engage with a constructive and forgiving mindset. If you are open and communicative with these early supporters, they’ll turn into your most loyal customers and vocal advocates.

I would keep it as an option and discuss it with your lead VC - perhaps reserve £1m of a Series A round for crowdfunding if you think you have a product that’s suitable; normally something consumer-facing. It usually makes less sense to crowdfund for a B2B product.

I’ll repeat this - crowdfunding is generally a very tough way to raise funding if your other options aren’t working.

Investment Advisors

You may think about paying an Investment Bank or some other kind of advisor to run your investment process. They'll offer to help you put together a pitch deck, introduce you to relevant investors and negotiate key terms.

In general, you should not do this. Especially for a Seed or Series A.

Generally, only the weaker companies need to use advisors. By using an advisor, you are signalling to investors that you are one of these weaker company.

Instead, you should be able to get useful introductions and advice on your pitch deck from your existing VC investors or angels. If you don't already have useful investors, programmes like Y Combinator can be really useful for getting in front of VCs at Demo Day.

You might reasonably consider using advisors if you're raising a $500m pre-IPO growth round. But even at this stage, many of the best companies raise without advisors.

Secondaries

A VC investment in your company is sometimes called a “Primary” investment. It involves the creation of new shares in your company, diluting all existing shareholders, and the investor pays the investment money directly to the company. You can then spend that investment growing the company to hopefully make it more valuable. That’s how investment normally works.

“Secondary Share Sales” or “secondaries” are slightly different. It’s when founders, early employees or angels sell some of their existing shares directly to new investors. It doesn’t dilute existing investors - no new shares are created - and the money goes to the person selling the shares, not to the company.

It can be useful in a few different scenarios, but it should always come after you’ve raised enough primary investment to comfortably run the company comfortably for the next 18-24 months. You should normally only do secondaries when there’s excess demand from investors for more shares in your company, and your existing shareholders don’t want to dilute any further.

The first situation in which secondaries are useful is to quietly remove an angel investor, early employee or even cofounder who’s leaving the business. Allowing someone in this position to sell some proportion (or all) of their shareholding can make tricky conversations go a lot more smoothly. There are situations where you might want to do this at Seed or Series A.

The second situation is where founders or early employees have been working for several years on the company with relatively low salaries, and the business is starting to see some real success. You want to keep these people motivated to work hard - an exit might still be 5+ years away. In such situations, it can be incredibly stressful to know that approximately 99.9% of your total net worth is tied up in the business.

VCs have a portfolio of investments, and they want each company in the portfolio to make value-maximising (rather than risk-minimising) decisions. They want to maximise the value of the portfolio as a whole, and can accept several failures. On the other hand, founders’ wealth is normally extremely concentrated, and the failure of their startup is financially catastrophic. This dynamic can lead founders to be overly cautious, which is not what other shareholders want, in general.

So, selling 5-10% of your shareholding as a founder or early employee can secure your financial position - perhaps you put a deposit on a house. This frees you up to take the decisions that you believe will maximise the expected value of the company, and benefits all shareholders. These kinds of secondaries are getting more and more common.

It‘s tricky to set hard-and-fast rules about this, and the market standard is always changing. With founder secondaries, for example, it doesn’t feel to me like this would be appropriate in a seed-stage company that’s been around for 12 months. Selling so early may suggest that the founders don’t really believe in the future of the company.

On the other hand, I recently helped a company raise only their second-ever investment round at a £100m valuation after 8 years in business. This is a great time to allow the early folks to do secondaries.

I also firmly believe in the value of secondary offerings for the wider employee base - I wrote about it back in 2017.

If you’re thinking about doing secondaries, it’s important you get a termsheet signed for the primary investment first, to make sure the company has sufficient funding! You should then carefully broach the subject with your new investor. Maybe they will buy the additional shares, or know another investor who’d take it. If not, perhaps one of the other VCs in the process might take the additional secondary allocation.

It’s normal to investors give some small discount for buying secondary shares because they generally don’t carry all the full investor protections. Eg, the new shares in the primary investment might get a 1x liquidation preference, whereas the shares being sold in the secondary are often common, with no liquidation preference. A discount of 10-20% to the primary investment price might be normal, but secondaries with zero discount are possible if the round is very heavily oversubscribed.

Standard Pre-Seed / Seed Terms

You may be able to raise a small pre-seed round on the strength of the founders plus an idea, but it's really very hard. At this earliest stage, some founders are able to raise £50-200k from friends or family, but it mainly depends on having enough rich people in your network, which really sucks. Instead, Entrepreneur First is a great programme for people without a cofounder or prototype. Being a coder, or having a technical cofounder is so important at this stage because it enables you to build your prototype and test it with users. It gets somewhat easier (only relatively easier - it's still hard) to raise money with even a minimal amount of traction. £1m at £5m valuation might be a typical pre-seed round at the moment for first-time founders in London who've not been through an accelerator. If you're a repeat founder with even moderate previous success, or you have some amount of traction, these numbers will be a lot higher - I’ve seen seed rounds of £3m on £30m in London this year. It also helps to have been an early employee at a successful startup - people from Wise, Revolut, Monzo Deliveroo etc may find it somewhat easier to raise money in London at the moment.

In SF, the hottest seed-stage companies coming out of YC might raise $5m on a $50m valuation.

A round like this usually involves giving away 10-25% of the company's equity, depending on how competitive the round gets. You can use this seed money to build out the team, improve the first version of the product and build on your initial traction.

If you're a second-time founder, it's sometimes better to raise a seed round pre-launch. If you raise post-launch, and the metrics are more sluggish than expected, you may struggle. Pre-launch, there are no metrics - investors will often get carried away imagining your huge future success. It's all based on the quality of the founders, and the strength of their vision.

If you do have explosive initial metrics, these are obviously very helpful. While I was doing YC in 2011, Codecademy launched mid-programme (after pivoting from building a travel guide) and signed up 150,000 users in their first weekend. They raised a lot of money off the back of this.

Standard terms right now might be;

1x non-participating preference shares.

4 year founder reverse vesting

Standard pro-rata rights, drag & tag along rights

Broad-based weighted average anti-dilution

(Read more about what all these terms mean in the excellent Venture Deals Book)

Do you want to do a priced Equity round vs a SAFE (with a cap)? SAFEs can be a bit faster, and let you do a rolling close (eg close each tranche of money as people say yes), whereas equity rounds need all the money to be committed before you sign binding documentation.

If you are a UK-based company, you should look whether you qualify for SEIS or EIS tax relief for investors. These schemes are extraordinarily favourable - an SEIS investment of £10,000 will only (eventually) cost the investor about £2,500 if the company fails, due to all the income tax relief. And if the company succeeds, the capital gains are normally tax-free. It’s genuinely astonishing. Please don’t just take my word - go and get professional tax advice!

There is a category of particularly bad seed investment funds in the UK that only invest in SEIS-eligible companies. As an investment strategy, this just seems foolish - as a professional seed investor, the only thing that matters is ensuring you’re in the (very few) big winners each year. You should therefore be selecting companies based on whether you think they will be one of those winners. Treat any tax relief as a secondary benefit. If you took the SEIS-only strategy, you would have missed Monzo’s seed round; we weren’t eligible because we were aiming to become a regulated bank.

Series A Terms

The market is very hot right now. £10m at £50m might be a “typical” Series A in London, but this changes extremely rapidly.

For Series A, you will need strong proof of product-market fit, rather than just an interesting idea and strong founders. You’ll want to aim for at least $1m ARR as a SaaS company, or very strong user growth as a consumer company.

Investors will have more of a focus on metrics - customer growth, revenue, evidence of stickiness (ie low churn) and strong unit economics. While the assessment will be more metrics-driven than a seed round, your product vision and mission are still very important. By the time you're doing a series B or C, this balance shifts even more towards the metrics.

As well as the standard seed terms, the lead VC at series A will almost always ask for a board seat.

They may ask founders to reset all (or a portion) of their stock vesting schedule. I would try to avoid this.

After the round

Make sure you file your new investment docs somewhere safe. You'll need them for diligence in the next round.

You should have a rough plan of how you intend to spend the money over the next 18 months. It's worth putting this into a monthly forecast spreadsheet, and then pulling together simple management accounts every month (either in a spreadsheet or Xero), compared to your budget. You should be able to see pretty quickly if you're spending too quickly (revenue is slower than predicted) or more slowly than planned (usually because hiring is taking longer than you thought).

Your investors may want to release something to the press - usually in an outlet like Techcrunch. This may be your first press appearance. It's not really worth stressing much about this. Funding announcements usually don't drive very much customer attention.

However, these articles do often drive more inbound interest from (lower tier) VCs who missed out on the round. They may offer you more money, and even an increased valuation. Generally, you should ignore these requests. If they come from a very high-quality VC, add them to your list of interesting folks for the next round.

If you get a lot of additional interest, you might consider taking a few million more investment on an uncapped convertible loan note (or SAFE). If you’re going to need to raise money again in future, this is a way of getting that future valuation today. It’s an extremely favourable way to raise money, and only happens rarely. The main danger is that you now have so much money that you over-hire and increase your burn rate too fast, without having the business to back it up. Or you could convert this excess demand into secondaries (see above).

With fundraising done, now is the time to get back to work! Your focus should be on making something people want, not impressing VCs. Hopefully you don't have to think about fundraising for at least another 12 months.

Further Reading

Org Structure and Target Revenue for SaaS Companies

Venture Deals Book

YC Guide to Raising a Series A

George Bevis’ Guide to Fundraising

With thanks to 🙏

Dan Karger

Shaun Sharkey

Karin Nielsen

Christian Hernandez Gallardo

Steffen Wulff Petersen

Eileen Burbidge

Carmelo Spano These folks corrected my errors and suggested additional content.

[tomblomfield]

Unit Economics

The old joke describes a lot of companies at the moment - "I'll sell at a loss but make it up on volume.” Pilloried in the press, startups burn through vast sums of capital before spectacularly imploding.

Let’s go back to 2012-13. The world was finally emerging from a punishing financial crisis, and low returns across most asset classes mean that a glut of capital was looking for a return. Leading tech companies were outperforming the rest of the stock market, and venture funding started to flow more freely as investors tried to find the next big thing. Loss-making companies finally had the capital to spend aggressively after a lean decade following the dot-com boom and bust.

Uber took this to an extreme, weaponising cheap capital. It would expand aggressively into new cities, pay drivers cash incentives to sign up, and simultaneously subsidise the cost to riders. Every additional ride would lose Uber more and more money. This often continued for years in a given city. But it was part of a strategy - its business improved with scale and density - even if it took hundred of millions of dollars per city.

As Uber got to scale in a city driver utilisation would increase. As a result, it could stop subsidising rides so heavily and margins would improve. In time, the city became profitable. To compete with Uber, other companies needed to raise huge war chests and go head-to-head in the same game of deep subsidies. It became an incredibly expensive war of attrition. In markets where a competitor was present, prices stayed lower for longer. Consumers got cheap travel funded by the venture capital industry. Whoever could raise the most capital could survive the longest and take the market. And Uber was great at raising capital. Their strategy largely worked in US and European markets, building a multi-billion dollar company.

A new generation of entrepreneurs in 2014-2016 saw this playbook and drew the obvious conclusion. Growth to gain market-share mattered above all else. Negative unit economics could be fixed with scale. A generation of "on-demand” startups were launched; food delivery, laundry, home-cleaning, dog-walking, child-minding, hairdressing, massage. They heavily subsidised their service to acquire new users, believing that they’d turn things around once they got enough scale or density in a given city. Investors, following the “Uber playbook”, pumped in money.

Companies raised eye-watering amounts of money on the back of growth metrics; skyrocketing weekly-active-user numbers and impressive viral co-efficients. But they had lacklustre revenues and unsustainable cost structures. It was a bloodbath - most companies failed when they couldn't improve margins and investors finally pulled the plug on ever-growing losses. Some, though, succeeded in turning their business around. Instacart - most recently valued at $4.2bn - is a shining example.

Now in 2018, what’s the lesson?

Inevitably, investors are paying serious attention to "unit economics” - how much do you earn (or lose) from each extra "unit” (normally a customer) per year? How much does it cost you to acquire the customer? What’s the payback period? What’s the customer lifetime value? Business fundamentals matter again.

Nevertheless, I think many new startups will continue to run successful negative-unit-economics strategies. I want to talk about a couple of examples where I think it makes sense.

Perhaps the business is a marketplace that needs critical mass to be effective. Think about a traditional village market. Without vendors, no customers are going to show up. But serious vendors are not going to bother pitching their stall if they aren’t sure the customers will be there. So what does the village council do? Run a massive, free funfair to attract thousands of visitors from all the nearby villages. Then the merchants are sure to pay to set up stall. Alternatively, guarantee each merchant a minimum revenue amount to pitch their stall. As most marketplace models needs some kind of critical mass, focussing on growth first makes sense.

Alternatively, companies can often dramatically reduce unit cost as they grow. Perhaps there are “economies of scale” - building an enormous factory will allow the company to produce products more cheaply than any competitor. Rather than trying to raise the money to build the factory up-front, companies will initially subsidise their product, selling below cost in order to stimulate demand and grow a massive customer base. They can then use this evidence of customer demand to raise capital to build a more efficient factory, eventually improving margin.

Or, more simply, a company may believe it can use its massive scale to renegotiate with suppliers, improving margin over time.

The advantage of these strategies is that you can figure out if there's customer demand for your product without having to raise massive up-front investment. Customer demand is almost always the biggest problem for early-stage companies - a total lack of "product-market fit".

The problem with these growth-first strategies is that they're capital intensive and very, very risky. You could simply be wrong about the savings you can achieve at scale. You might burn more cash than anticipated getting there. Perhaps a competitor also raises a lot of capital, and pushes the cost of customer acquisition even higher. Or perhaps there’s another financial crisis, and capital becomes scarce.

But here’s the dilemma - if there two companies are competing for the same consumer market, the one that gets to scale first will generally win, provided it can continue to raise capital.

If you’re going to take this approach, you’d better get really, really good at fundraising.

[tomblomfield]

When to join a startup

Something has changed in the last few years which has made an increasing number of people want to join startups. It seemed to start around the time the Social Network movie came out - perhaps it’s just a coincidence, but part of me imagines a group of MBAs sitting around watching Justin Timberlake play Sean Parker, thinking that actually a billion dollars would be pretty cool.

When choosing a startup to work at, people often overlook one of the most important factors, which is the size and stage of the company. I’d argue this is sometimes even more important than the industry or the idea itself.

Bootstrapping, aka two people in a bedroom

The startup was recently formed, and the company might not even be legally incorporated yet. There’s no funding and no-one is taking any salary. You’re two, three or four people in a bedroom living on baked beans, working all hours of the day to get a working prototype to show to customers or investors. The only people using your website or app are a couple of sympathetic friends and your mum.

Someone else tried to convince you to join a different startup a year earlier, but they had no funding and zero customers. They wanted you to work without a salary in return for 1% of equity, which sounded like a scam to you. You’re glad you picked this startup instead. You might not be getting any salary, but at least you’re joining as a co-founder with a double-digit equity stake. You jokingly talk with your cofounders about which island you’d each buy when you sell out for billions in a few years’ time.

The product vision is vague and broad, but you’re working every day to try to validate it with customers. Anything is possible. The entire direction of the company might even be changing from week to week.

Because nothing yet exists, you need to bring it to life with a combination of energy and raw self-belief. There’s little specialisation and no hierarchy; everyone does whatever needs to be done. It can be exhilarating.

It can also be exhausting at times, lasting months or years before you find customer traction or funding.

Seed-Funded

Now the company has a working prototype, a few dozen regular users and £250k of seed funding. It’s enough to pay a handful of people low salaries. Since you’re too big to fit in a bedroom, you’re renting desks at a coworking space or scrounging them off a bigger startup.

You cut a lot of corners, but seem to ship an incredible amount of code. People you don’t know personally start to use your product and it feels awesome. You’re working hard to spread the word, perhaps even starting to earn a little revenue from your first paying users.

You join at this stage for 3% equity plus whatever basic salary you need to survive. You talk about which cities you’d buy houses in when the company sells.

You might join as the first professional programmer or designer, but you’re still more-or-less on your own. When you join, your first job is to go to the Apple Store and buy yourself a laptop because no-one thought to order any equipment. There’s no “mentorship” from more experienced colleagues or even code-review, simply because the company is still too small.

“Marketing” consists of one of the founders emailing your funding announcement to TechCrunch

As an employee, you have a significant say in the direction of the company, although the business model might still shift substantially underneath you. Even if you’re not making the decisions, you hear about them immediately.

There’s still a good chance that the company fails to find “product-market fit” and goes bankrupt without raising more money. Your mum tells you that you should have stuck with your well-paying job at Oracle.

Series A

The company has raised £3m from a big-name VC and the team has grown to 10-15 people. You’ve got your own office with your logo on the door, or at least your own area in the coworking space.

The investor makes you submit quarterly cashflow reports, so you start keeping accounts for the first time. This is done by whoever has Excel installed on their computer. The company eventually hires an office manager to ease the burden of administration on the founders. They set up a payroll provider and start doing peer reviews.

You join the company to do a specific role, but you spend your first week or two figuring out what you should actually be working on. At least they remembered to buy you a laptop, a desk and a chair.

There are 3 or 4 engineers in the team, so you start to do code-review and set up a continuous integration server. You lament all the technical debt that was accrued by those idiots who arrived before you, slowing down the pace of feature development.

A new product direction for the company is decided in a meeting of the three founders; this is presented in an “all-hands” meeting of 12 employees. The company sets out a quarterly product roadmap, and you’re asked what you think should be prioritised. You pick the projects that most interest you.

You’ll certainly be able to earn more money at a big company, but the salaries are enough to live comfortably on. You get 0.5% in stock options with a salary that’s 10-30% below market rate. But you reckon it’s worth the gamble - if the company sells, you’ll be able to buy a really nice house in London. Still, it feels a long way off.

The marketing function is one full-time person who does everything from PR, paid advertising and social media. The founder no longer personally runs the company’s Twitter account. Your company regularly appears in the “ones to watch” articles in tech press.

You’ve got thousands of paying customers, and you occasionally see people in public using your app, which feels fantastic. Your mum isn’t really sure what your company does, but she’s happy enough because you’re being paid a real salary.

Series B

The company is now 2-3 years old and has just raised £10-20m. It’s using that money to grow the team, increasing headcount to 60 people.

The founders got tired of the dingy office, so they splashed out on somewhere with lots of exposed brickwork and glass walls. Everyone is sitting on Herman Miller chairs. You find these chairs online and see they cost £1000 each.

There are 3 or 4 people in finance and HR roles, and you’re presented with a company handbook when you join. You have a couple of days’ training, but you mostly figure it out along the way.

Marketing now has three digital advertising people, and people specialising in PR, content and community management. You’ve got millions of paying customers in several countries, and your company is regularly featured in the business pages of the press.

Engineering has been split into two or three separate teams, and they’re trying recruit graduating college students to fill the hiring pipeline for next year.

You join in a very well-defined role, after the team manager recruited you. You meet founders during your interview, but they don’t always remember your name now you work here. The CEO sees a management coach every fortnight.

A new product direction is debated at a board meeting, and senior management is informed by the CEO. Management let their teams know that changes are imminent. Most people are focussed on “repeatable processes” and scaling up.

The company doesn’t seem to release new features very often, but the app is used by some of of your mum’s friends, which makes her very proud.

Your salary is in line with what other companies are paying, and you get 0.05% stock options. You’ve already figured out which house you’d put a deposit on when the company sells. A sale seems inevitable at some stage.

Series C

You’re joining a unicorn! After 5 years, the company has raised £100m at a £1bn valuation. There are some strange terms in the deal structure that you’ve never seen before, but the company’s HR department tells you that’s just “legal stuff”.

When you join, you’re granted £50,000 of options, which you work out is one two-hundredth of a percent, or 0.005% of the company. Friends in other startups tell you to check what the investor’s liquidation preference is, but no-one at the company can seem tell you. They’re all too busy trying to guess when the IPO is going to be announced. You figure that any kind of payout is a nice bonus. The salary is pretty decent anyway.

You join in the company’s newly opened Dublin office, part of a new drive by the company to internationalise. You’ve joined as one of 6 new Sales Associates focussing on European enterprise sales. There’s 4 week intensive induction training programme before you’re allowed to talk to any customers.

The new office feels empty at first, but you’re surprised how quickly it fills up with new staff. You ask where the marketing department sit, but you’re told they’re in a different office.

You see the CEO on the cover of Forbes, but you’ve never actually met him.

Your mum is already using the app, although it’s starting to look a bit dated compared to some of the newer startups that are in TechCrunch.

Business Insider reports that the company has fired the new VP of Product and is pursuing a new production direction. She had only arrived from Twitter 6 months earlier. An internal memo from HR a couple of days says that the company’s doing some minor internal restructuring.

You see consultants in the meeting rooms, but you don’t know what they’re doing.

A month later, you gather for a televised all-hands meeting, broadcast from the company’s HQ. The CEO delivers a short speech announcing that the company’s been acquired by Oracle, explaining how it will accelerate the company’s ability to deliver on its vision. He thanks everyone for being part of the company’s incredible journey. People in the audience are crying.

HR follows up explaining that as part of the acquisition, some departments will be downsized. You’re told that your stock options are “underwater”. When you Google this, you  find out that they’re worthless. You’ve got some friends in engineering who are being given Oracle stock as a “retention package”, but that doesn’t apply to anyone in sales. You wonder why you ever joined a startup in the first place.

Discuss this post on Hacker News

[tomblomfield]

Five Unbreakable Rules for Startups

I’ve been involved with 4 startups over the last 10 years or so, 3 as a co-founder. I’m a follower of Paul Graham and the YC camp of startup wisdom. There’s now a great deal of literature laying out the unbreakable rules for startups. Despite studying this literature, I’ve managed to break each of these rules, in some cases more than once. In every case, I have come to regret it. 

1. Choose your cofounders carefully

If your startup is successful, you’ll spend the majority of your waking time with these people for the next 5 years. Invest the right amount of time getting to know each other. Ideally, you’ll have worked with these people for a few years at another company before you do your own thing. 

Your relationship will be like a marriage, but even more intense.

Three co-founders feels like the right number. Try to find the most driven, effective people you know and convince them to join you. Unless there’s a really good reason, equity splits should be equal. If you don’t think your cofounders as effective or valuable as you, why are you starting a company with them? 

2. Written agreements from the start

An agreement doesn’t have to be complex, or necessarily involve lawyers. There are plenty of open-source co-founder agreements published by law firms. But you need to agree: 

a) Any money invested, either as equity or debt b) Equity split c) Salaries, included any deferred compensation 

In the simplest case, the agreement will be “no money invested, equal equity splits, zero salary”. But as soon as bills need paying, things get trickier. An investor friend recently told me that he makes a rule of telling founders, “I won’t ask you to trust me”. All deals go into writing immediately. 

3. All stock must be on a vesting schedule

Vesting means that stock is earned over the lifetime of a person’s involvement at a company. A standard vesting schedule is “4 year vesting with a 1 year cliff”. This means, if I have 48 shares in a company, 12 of those become irrevocably mine (i.e. “vest”) on the first anniversary of my joining the company. The remaining 36 shares vest monthly over the remaining 3 years - 1 share per month. 

If I leave (or I’m fired) after 3 years, I walk away with 36 shares. The remaining 12 shares are taken back by the company. 

Vesting is a good thing for everyone. It ties people’s incentives to the long-term success of the company. I’ve heard founders even talking about 6 or 8 year vesting sometimes. 

If your co-founder says “just trust me”, see above. 4. Keep company money separate

When your company needs to pay bills and you’ve not raised outside investment yet, be very clear who’s paying and under what terms. Is the money going to be repaid? When? 

As soon as you can, establish a separate company bank account. All cofounders ideally put the same amount of cash in, and bills get paid out from that account. Simple. 

If you’re putting in money as a stop-gap before an investment round and expect the money to be repaid, put this in writing. It should appear in your company’s balance sheet as a liability - “Director Loan”. You’ll also need to let investors know if you expect to use their investment to pay back loans. 5. When you go out to raise investment, don’t over-optimise for valuation.

PG stood up one Tuesday evening at Y Combinator with a memorable lesson. YC companies are competitive about everything. In each new batch, founders are told not to compete over who can raise at the highest valuation. And every batch, some founders ignore this advice. Airbnb, we were told, raised their seed round of $600k on a valuation of something like $3.5m - certainly nothing like the uncapped convertible notes we sometimes see at the moment. And the Airbnb founders are just fine with how they’re doing. 

You should spend a little time figuring out what price the market will offer. Choose the investors you think you could work with for next 5-10 years. Don’t spend time shopping the deal around to increase your valuation. Also, don’t pick crappy investors just because they offer a higher valuation. 

These rules are not negotiable!

If you break them, you will end up in trouble.

[tomblomfield]

Getting Shit Done

I was recently talking to a handful of successful startups founders about issues they were facing as they scaled up their companies. Unanimously, hiring and retaining people who "get shit done" seemed to be their biggest problem. I’ve been thinking about this for the last few days, because it’s a deceptively simple idea.  

It’s deceptively simple because people have a very strong cognitive bias - practically everyone thinks they "get shit done”, much like everyone thinks they are an above-average driver. 

Empirically, most people do not get shit done. 

So what does "getting shit done” look like? How can you define it?

The closest I’ve come is someone who, when confronted with a problem, will fix it with a surprisingly good solution in a surprisingly short amount of time. They have an ability to produce an astonishingly high quantity and quality of work. It’s someone I am confident giving my hardest, ugliest problems to, knowing that they’ll solve it better than I could. And when they present the solution, you’ll see they found a bunch of other problems along the way and fixed them too.

These are the kind of people you should try to start companies with. If you’re already running a startup, they are your most valuable assets. Give them more equity than your board is comfortable with, and try to get them to stick around as long as possible.   

In Paul Graham’s formulation, they are “relentlessly resourceful”. Somehow, they just seem to defeat any problem. There are many different strategies. You can plough through an obstacle with brute force applied in just the right place. Or you can avoid the obstacle by redefining the problem, changing the rules of the game to suit yourself. Perhaps simply refusing to give up, and working harder and longer than anyone would consider reasonable. And sometimes doing things that look a little crazy from the outside.

The opposite is uncomfortably common. There are many people who will talk about problems, strategise different solutions, seek input and group consensus, but never actually accomplish anything. When things don’t happen, they always have a list of reasons why it’s not their fault. In a startup, this person needs weeding out as quickly as possible because they’re dead weight.

Once a company is running, it can gain a momentum all of its own. This seems especially true for big companies with a stable customer-base and market share. Some large companies have such momentum that a large proportion of the employees could simply not come to work and the thing would keep going all by itself. Big companies seem to train managers to be “interrupt-driven”, rather than proactive. So if you’re hiring from big companies, watch out for this. 

Consistently “getting shit done" takes a huge amount of energy and initiative, but it seems energising for the right kind of person, rather than exhausting. It is a particularly important skill in the early days, because the natural state of a startup is inertia and, ultimately, failure. At first, your company has zero velocity, so you need to apply an incredible amount of time and energy to overcome this inertia and get the thing moving.  Nothing happens unless you make it happen.

My favourite example is the story of Instacart’s early launch with Trader Joe’s. Instacart is a grocery delivery service and partners with some of the biggest retailers in the world. But when they were starting out, they wanted all of the inventory of Trader Joe’s listed on their site, along with the price and photo for each item. A normal approach would have been to negotiate a business development deal, which would have taken many months, killing momentum. Instead, the founders figured out that they could probably purchase one of every single item in the store, and working for 48 hours straight, photograph it all in a studio that was empty over a weekend. In my book, that is getting shit done. 

[tomblomfield]

Apple is propping up a fundamentally broken payments industry

Apple’s latest announcement on payments has sparked some interesting debate but also a fair share of breathless pronouncements on a “revolution" in mobile payments.

To be clear - Apple Pay is a step forward in terms of end user experience - but it simply entrenches a fundamentally broken card payment network and layers on even more cost.

Apple have long been masters of user experience - and Apple Pay does makes significant strides forward in that area. The point-of-sale experience is good, but not much better than contactless cards that have been common in Europe for years. The real leap forwards is in-app payments - new apps installed on an iPhone will have access to payment details without the user having to type in card details for every new purchase. Instead, customers will be prompted to scan a fingerprint, and the payment will be processed - that’s a pretty big leap forward in terms of experience.

There’s been speculation that this new payment mechanism might lead to the virtualization of credit cards. But what does that really mean? Apple is not killing the credit card. They’re killing the little piece of plastic that gets sent in the mail. Again, a big user experience improvement, but a trivial improvement at the payments level - payments are still going across the card networks. Fundamentally, having to switch out a card to access a different credit product seems wrong-headed.

All this talk of "frictionless credit cards” presupposes that cards and card networks are necessary in the first place. Perhaps a more interesting question is "frictionless credit”.

To understand how this might work, we need to break down a payment transaction to see where credit fits in:

A customer presents a card to merchant for payment, perhaps entering a PIN in a terminal.

The terminal sends transaction details up a line from the merchant to a payment processor.

The processor forwards transaction details to the card company’s network.

The card company routes transaction details to card issuer (the customer’s bank, or an independent financing company) for authorization. Is there credit available? Ie, is customer within agreed balance or overdraft limits?

Issuer approves transaction and sends confirmation back through same channels.

The customer gets their item from the shop and leaves.

The “credit” in credit card is not related to the plastic card, or even the card network. It’s simply debt financing that’s offered by a financial institution at the other end of a series of pipes. Visa & co provide those pipes, but charge a pretty heft fee for doing so. Thanks to the existing 4-party system, merchants are paying around 2-3% of every transaction as a tax levied by those incumbents, who add little value in return. Apple now makes that a 5-party system, adding extra cost in exchange for a slick user experience.

With Apple Pay, instead of a user inserting a card and entering a pin, they’d present their iPhone and touch their thumb to a fingerprint reader. Their iPhone passes up credit card details via the card processor (or, more precisely, it passes up a token that allows the card networks to access card details from Apple’s servers a little way down the line), and the process continues as normal. The metaphor of Apple Pay as a simple “wallet” works well - it simply provides a mechanism for storing your cards, and presenting them to merchants when you want to pay. They aren’t actually processing any payments themselves., unlike PayPal or Google Wallet.

Apple Pay entrenches a fundamentally broken card payment network, and layers on even more cost. Apple has struck deals with Payment Networks and Issuing banks, and as part of those deals, it is taking a cut of the fee. It’s now another mouth to feed.

What we should be aiming at is frictionless payment over a different series of pipes - the public internet, and existing inter-bank electronic clearing systems. If Banks opened up their platforms to allow multiple credit providers, we’d have competition to offer consumers credit financing on competitive terms. Whether you need an overdraft, a fixed-term loan or individual-item financing, you should get the best rate available in the market. The idea of having to switch payment card to get access to the best rates is crazy.

By decoupling the issue of “credit” is from "payment network”, we expose the card networks for the rent-seeking oligopoly they are.

Discuss this post on Hacker News

[tomblomfield]

Customer churn can kill your startup

Startups are about growth, and of all the different possible metrics, startups often focus on user growth - if people aren't using your new product or service in greater and greater numbers, it's a good sign that you're not on the right track. And, as long as your business-model is solid, user growth is a leading indicator of revenue and profit growth.

But there's another key metric that can be the making of your company, or the death of it - churn, or the proportion of existing customers who become ex-customers during a period of time (generally a year).

In the early days, it's very hard to measure your churn because you simply haven't been around long enough. The early revenue growth curves for high- and low-churn companies may look identical. 

In fact, high-churn businesses often have exceptionally impressive growth numbers in their first months or years because they've found some viral loop, the crack cocaine of startup-land, which provides an explosive catalyst for new-user acquisition.

However, problems often start to appear after the first year or so - occasional weak months look exceptionally bad, since your business model relies on new customers in the top of the funnel to replace those flooding out. And even if you manage to keep finding new people to push into the top of your funnel for several years, you will eventually churn through your entire addressable market.

Then your business implodes.

The prime examples are Zynga and Groupon - both of which have been catastrophically failing over the last year or two.

Conversely, low-churn businesses often have relatively modest initial user-acquisition growth curves. Often, the nature of low-churn businesses (in particular, high switching costs) makes it incredibly hard to gain your first few users before you've established credibility. However, these same hurdles present considerable long-term advantages, and the occasional slow month in terms of user-acquisition still increases monthly revenue. Once you've built up a loyal customer base, it becomes an extremely attractive business model - costs are often fixed & up-front, and the marginal cost to serve each customer every month is minimal.

When talking to startups, my favourite graph to look at is their revenue by monthly cohort. That is, splitting each months' revenue by the month in which the users originally signed up to the service.

In a low-churn business, the graph looks like a layer-cake, with each new month of users adding a layer of revenue on the top of the business.

The thin cohorts at the bottom of the graph are the loyal users who signed up at the start, and who are still paying for your service 18 months later. The orange tip in the top-right are the users who just signed up, and have only contributed to revenue in month 18.

In the best low-churn businesses, the revenue provided by each cohort can actually grow over time - each cohort gets "fatter" - if you can successfully up-sell new services.

In a high-churn business, the cohorts decay alarmingly quickly, and once new-user acquisition starts to slow, the business implodes.

If you simply looked at the top-line of the graph (total monthly revenue), without considering the cohorts, you'd think the high-churn business was doing much better until at least month 13-14. But one-and-a-half years in, it's clear that the low-churn business is on a path to success, while the high-churn business needs to execute a substantial pivot to avoid failure.

Indicators of Churn

So what are the characteristics of high- and low-churn businesses, and what techniques can you use to minimise churn?

High Switching Costs - if it's slow, painful & costly to switch providers, you will experience very low customer churn. This is clearly the case with retail banks, email providers and recurring payment processors. I still bank with the same provider I chose 15 years ago, despite their crappy service and barely-functional website.

New competitors have developed clever tactics to solve this problem - developing onboarding tools to reduce switching costs, or focussing on new customers before they've committed to an incumbent provider. This is one reason Stripe focusses so hard on serving other startups, and banks target teenagers.

Sales Architecture - the way a product is priced & sold is often designed to minimise churn. Gyms & dating sites are the best examples here. People come out of the Christmas & New Year vacation period feeling unhealthy, lonely, and determined to change. One large dating site books over 70% of its annual revenue in the first quarter of the year. 

Strong Brand Loyalty / Personality - the best brands position themselves as expressions of their customers' personality.

Cigarette companies and beverage manufacturers are the best example of this - products are often indistinguishable from each other, and the switching costs are minimal. The customer can just reach for a different can on the shelf. Companies combat this by investing heavily in marketing to position their products in customers' mind as extensions of themselves.

There's an interesting phenomenon in the drinks industry where a couple of faceless mega-corps control a wide variety of incredibly powerful brands with basically indistinguishable underlying products - MillerCoors and Anheuser Busch. 

  Make Something People Love - after some fantastic comments from readers, I've added this extra point. Perhaps the most difficult, but also most effective form of customer retention is making a product or service that is dramatically superior to the competition. As Barry put it, "The switching cost is missing out on a great service." It's subtly different from brand loyalty - Google has very low churn because its search engine is so much better than the competition. It arguably doesn't have a very strong brand or "personality".

So What?

To some extent, you're stuck with the churn inherent in your industry. But you do have some level of control.

If you enter a market like payment processing, be prepared for the long-haul. You'll likely struggle to establish your credibility early-on, and finding innovative ways to acquire new customers be vital. You'll need to raise significant amounts of early capital to invest in infrastructure that will only start to pay off years later.

If you're part of an industry in which you can acquire customers incredibly cheaply and monetise them quickly, you'll generally need less early capital. You'll often reach profitability very early on, and it may feel like you're on a startup rocket-ship. But make sure you're providing sustainable, long-term value to your customers, otherwise you risk running out of fuel and crashing painfully back to earth.

Discuss this post on Hacker News

[tomblomfield]

Growth

"When eating an elephant, take one bite at a time."

- Creighton Abrams

I was chatting with an investor a year or two ago, shortly after our Series A, and the subject of revenue goals came up.

At the time, our revenue was pretty low - less than 10% of monthly costs. We estimated our business would only become viable when revenue reached a level 10 times greater than our current costs.

The implication was that we needed grow by 100 X before our business had any significance at all, and I was struggling to come up with any credible plan for getting there.

Her response was for us to simply put one foot in front of the other. Just focus on growing every month, and the rest will take care of itself.

At 15% month-over-month growth, you'd grow by 100 X in around 33 months.

At 20% month-over-month, it takes 25 months.

At 25% month-over-month, it takes 21 months.

[tomblomfield]

Startup Series Part 4: Deadlines

The question of deadlines is one of the most divisive issues in software development today. Business-people despair at developers’ inability to meet goals, while developers lament the latest unachievable deadline imposed by their pointy-haired boss.

In practice, there is often a common cause of this malaise. If your team doesn’t have an agreed scope with sufficiently granular time-estimates for each component piece of work, your project will inevitably overrun, and sometimes by an order of magnitude.

Scoping a project

The solution is to come up with a scoped deadline - a date in the future by which you will have implemented an agreed list of features or functionality. Crucially, each of the features needs an estimate of the amount of time or effort required to complete it, similar to some styles of Agile software development.

The only effective way to estimate effort is to break the project down into chunks of work that can individually be estimated. In no case should any chunk be more than 2 developer-days, and ideally they’d be around ½ a day each (4 hours). There are lots of methods for actually coming up with these numbers - Planning poker is one neat collaborative solution, or Joel Spolsky’s Evidence-Based Estimation is also interesting.

Fundamentally, developers should be the people saying how long a given chunk of work will take. Whatever system you use, it’s essential to have a relationship where developers feel like their judgment is respected and the business-side of the company trusts developers to put in a reasonable amount of effort. At the end of the day, even the best estimation techniques can’t fix a broken culture.

The alternative, an “it’s done when it’s done” attitude, is dangerously counterproductive - if there’s no pressure to hit business goals, technical decisions will tend towards feature-creep and perfectionism.

Why scoped-deadlines are useful

As far as I can see, there are 3 main benefits of scoped deadlines:

It makes you iterative - forcing everyone involved to ask “is this feature really necessary?”. You will always have more development work than time available, so choosing what to work on is a crucial skill. If you strive to keep your deadlines around 2 weeks, you will prototype very quickly, building only the features you really need. Half the time, customer feedback will change what you saw as “version 2” anyway.

Second, it prevents scope creep during the project, as you’ve locked-in the features that are going to be delivered. This is good for both developers and business-people. For the former, it encourages a  pragmatic approach to the quality-vs-speed tradeoff - personally, it helps me check the urge to refactor code when it isn’t strictly necessary. For the latter, it provides a positive response to the perennial request of “can you just implement XYZ for me?”. Sure - in the next version.

Third, it can sometimes good for motivation & productivity, for some combination of people, teams & problems. I find deadlines energising - crossing to-do items of a list, and delivering impressive new feature motivates me. It’s a very tangible way for a team to see that they’re making progress, and people love being part of success. But it’s certainly the least important of the three.

Deadlines in practice

As a project progresses, you should be regularly deploying your code - use a feature-switch to keep new work visible to only staff or small segments of your user base. This is very important because it’s a leading indicator of missed deadlines. If you’re halfway through your “sprint”, and no code has been deployed, you’re likely going to overrun. It also helps catch bugs early, and makes you consider how your code will interact with the existing codebase from the very start.

Even with this advice, you sometimes just won’t hit your deadlines. It might turn out that the version on open-source library you’re using isn’t compatible with a new tool you want to implement. Unexpected problems crop up. While I don’t think it’s a terrible thing to work a couple of late nights if your project needs to get back on track, it’s very different if the scope of the project has fundamentally changed.

Retrospectives are a good way to identify any patterns in scoping problems - if you highlight areas that consistently overran, you’ll get better at spotting them in future.

On the other hand, be quick to celebrate your successes. Releasing code from behind a feature-switch to your general user-base is a great time to gather the team and reflect on your achievements.

Discuss this post over at Hacker News

[tomblomfield]

Startup Series Part 3: You make what you measure

Merely measuring something has an uncanny tendency to improve it. If you want to make your user numbers go up, put a big piece of paper on your wall and every day plot the number of users. You'll be delighted when it goes up and disappointed when it goes down. Pretty soon you'll start noticing what makes the number go up, and you'll start to do more of that. Corollary: be careful what you measure.

- Paul Graham

Metrics are one of the most powerful and most dangerous tools at a startup’s disposal. They can help focus a team around a common goal or push you off-course for months.

Start by tracking one thing

We realised pretty early at GoCardless that we needed to track something to work out if we were improving. As we are a payments processor, the first metric we chose was our total daily transaction value - how much money was going through the system. We chose this metric because, in the very early days, total daily transaction fees (ie our revenue) was embarrassingly low, whereas our total transactions were roughly 100x higher. This worked well for a few months - we hit milestones in encouragingly quick succession, moving from £1k-a-month to £1m-a-month to £1m-a-day. We’d display the daily number on a large board in the office, and send weekly and monthly summaries to everyone in the company, with the change over the previous period. It worked well both to motivate the team and act as a Pole Star when making decisions; “which of these options will maximise our monthly transaction value?”. When we hit 10% week-on-week growth, we were happy. When we didn't, we redoubled our efforts.

Choose a proxy for long-term value

However, a year or so down the line, we realised that we’d encouraged some pretty perverse behaviour. A large minority of our transaction value was coming from a few merchants putting through very high-value transactions. Because of a quirk in our pricing model (1% capped at £2 per transaction), we were actually making relatively little revenue and assuming way more risk than we’d like on these customers. For a short time, we were actively pursuing more of these customers in order to boost transaction value. Yet, when we came to search for a solution, it was incredible how ingrained our hunt for transaction volume had become - any change we made to combat the problem would inevitably result in lower transaction values, although dramatically higher revenue - and yet, emotionally, we struggled to make the change. Once we swapped the key metric to daily transaction fees, the problem went away.

Since it sometimes seems fashionable to run companies without revenue, you need to pick the best proxy for long-term value of your company, be that profit, revenue, installs, MAU or page-views. But this raises the next problem we encountered. Even if you could track company value on a day-to-day basis (and you can if you’ve gone public), it’s not an actionable metric. This is usually a problem for B2B companies since the enterprise sales cycle can often be several months - the work you do today won’t impact revenue for some time.

Break out KPIs

One solution is to have each team within the company break down that key number into its component drivers until you get to something actionable. A really neat example is an outbound telesales team. Ultimately, you want your sales team to be closing recurring deals, which will drive revenue in a predictable fashion. But, as any sales director will tell you, if you’re not closing the deals, you need to focus on the activities you're performing. The stage before a closed deal might be some form of proposal, outlining the key SLAs you will deliver in return for committed fees. To deliver 5 closed deals this month, you might need to make 10 proposals. To make those 10 proposals, you need to attend pitch meetings with 20 companies. To get those pitch meetings, you’ll need to have spoken to 200 companies. Since only 1-in-3 cold-calls results in a conversation with a decision-maker, your telesales teams need to call 600 companies this month. Suddenly, you have some pretty actionable KPIs for your sales team. These are the numbers that you track in daily stand-ups, and measure conversion between each stage. Since they are actionable metrics, the entire process becomes an optimisation problem.

As far as possible, each part of your business should have 2 or 3 actionable metrics that they examine on a daily or weekly basis. They’re the numbers that tell you whether you’re improving or not. An example might be website up-time for the devops team, or average customer wait-time for your customer support team. Whatever numbers you choose need to be objective - if people can massage up a bad month, it undermines everyone’s faith in the metric. These metrics shouldn’t be sticks to beat people with - it’s actually incredibly motivating to work very hard and see that you’re making progress. They’re also useful to highlight strategies or areas of the business that just aren’t working out, rather than allocating personal blame.

Eric Ries spends a lot of time in the Lean Startup talking about actionable vs vanity metrics - it's well worth a read.

Implement your strategy with KPIs

The choice of KPIs is also a very powerful tool for a founder or management team to set the direction of a company. There are many different ways to reach £1m in monthly revenue - the way you set up your KPIs and associated targets will have a huge influence over the behaviour of people in your company. As a simple example, are you aiming for 10,000 customers to pay you £100 each, or 100 who'll pay £10,000 each?

When metrics go wrong

Even these actionable KPIs can produce perverse behaviour. I worked at a large national utilities supplier whose (very large) email customer service team committed to responding to 90% of emails within 24 hours. On the face of it, a great actionable metric - and the team were consistently replying to 89 or 90% of emails within the allotted time. But they’d also developed a practice of simply ignoring any email which exceed the 24-hour cutoff. Since these emails didn’t impact their targets (or their bonus), 10% of customers simply never got a response.

A final issue is that, in some areas of your business, KPIs can be really tough or even impossible to pin down. While a front-end team working on your landing pages might measure conversion to signup, a PR team running a 6-month campaign may struggle to find an objective indicator of success. You can try to count the number of articles (and the readership of each), but you’d also need to assess the relevancy of the target audience. You might try to establish a baseline of page-views and count increases or spikes, but there’s so much noise that it quickly becomes subjective. While people have tried to to pin down the value of a "like" or a "re-tweet", it's only usually relevant for consumer-facing companies. We’ve never really managed to find a solution to this problem - I’d love to hear what other companies have done.

In summary

Pick one number that’s your “Pole star” - the best proxy for long-term company value. Re-examine it periodically to see if it’s producing perverse outcomes.

Have each team break down the key metric into its component drivers or KPIs that individuals can influence. Measure team & individual performance & improvement on this basis.

Make sure the numbers are objective.

Make them visible - put the key metric on a big dashboard, and give each team a dashboard that lets them see how they’re doing. Send regular automated emails around your teams with a breakdown of their numbers.

Follow the discussion over on Hacker News

[tomblomfield]

Startup Series Part 2: Attracting great engineers

This is the second in a series of articles on the operational side of running startup - once you've found product-market fit and raised VC cash, how do you go about building a business?

The first post in this series, on the hiring process, assumes you have a sufficient number of quality applicants. Once that's true, hiring becomes a process optimisation problem - it might take a bit of effort to get right, but there aren't too many unknowns. On the other hand, attracting top-quality developers to your company in the first place is a much tougher proposition. 

In the long-term, you will attract outstanding talent if you; 

build a successful company with a strong vision

working on interesting technical challenges

with other outstanding developers

who value software development as a professional trade. 

The often-omitted final step is to tell people about it! You could have the best culture in the world, but you won't attract applicants if no-one knows about you. 

Github is one of the best in the business when it comes to attracting great talent. People like Zach Holman and Tom Preston-Warner blog profusely and tour the world talking about software development. But, underlying every article and presentation is this message; Github is an awesome place to work.

Since not every company can spend hundreds of thousands a year flying people around the world for conferences, or fit their reception area out as a replica of the Oval Office, I wanted to share a few actionable tips for the first-time founder. These shorter-term fixes will provide value disproportionate to their cost. There are also a few gotchas - common practices that do more harm than good.

Provide top-quality equipment

Dollar-for-dollar, high-quality equipment was consistently the most sought-after perk when we've surveyed developers, above a swanky office, fancy snacks, and even salary. It makes sense to invest here.

Some simple maths backs this up - depending on experience, you might pay anywhere from £30,000 to £70,000+ for a software developer in somewhere like London. Upgrading from a standard MacBook air to top-of the range model plus Thunderbolt display will cost you an additional £1,500. You'd need to achieve a 1.9% productivity gain (based on a £40k salary and a 2-year equipment lifetime) to pay back the investment. If this equipment reduces the running time of your test-suite by two minutes, you'd save about 4 days a year[1]  which, alone, is worth about 1.8% productivity boost.

[1] 4 days = 2 minutes * 5 runs a day * 225 working days per year

It then costs, conservatively, £5,000 to attract and hire a single developer. If top-quality equipment has any impact on hiring or retention, you've suddenly made a profitable investment. You also get to take lots of cool photos of your working environment and post them all over twitter and your hiring page - remember that telling people is the most important part.

  Interesting observation; while we still let people choose their equipment, we strongly encourage people to choose between the MacBook Pro and Air. We've had several people originally opt for various flavours of Linux, but they've all swapped over to Macs within 12 months. The homogeneity means that equipment will work anywhere in the office - swapping desks to work with a new project team simply means plugging into a new Thunderbolt, rather than lugging tonnes of equipment around. It also means that useful internal tools & scripts that we've developed are more likely to work out-of-the-box.

Work on awesome side-projects

We've found that having the engineering team take a couple of days off work to hack on a fun side-project can be a great recruitment tool. Not only does it increase morale and let you try out new technologies, it also provides you with great content for blogging & conference talks.

The best example is our pool-ball tracker we built at GoCardless. We mounted a webcam above our office pool table, and used OpenCV libraries to track the position of the balls. The ball coordinates were fed into a rules engine which then scored the game. It got a great reception on Hacker News and elsewhere, and resulted in an extra 9,000 unique visitors to our site on a single day. And it was awesome fun.

Other examples are our GoCardless-branded beer and Raspberry Pi projects. 

Our only failure here was a Spotify-powered office music system - we just never got around to blogging about it. As with everything on this list, it's only effective if you tell people about it.

Technical & Culture Blogging

This is the single greatest recruitment tool we've found. If you're using any kind of technology at all, or have views on development best-practices and startup culture, you should be able to write compelling content that will do well on places like Hacker News and Reddit. It's also more more repeatable and has a higher ROI than side-projects, because it doesn't require half-a-dozen people to take multiple days off work.

For example, one particularly incendiary article on ditching Responsive Web Design garnered 34,000 unique visitors on a single day. We've had several applicants explicitly mention this article during interviews, even 9 months down the line.

You can blog about pretty much anything you work on - meetings, org structure, a new javascript framework you're using. Explaining how you're different from just another BigCo is an extremely useful recruitment tool.

Often, the key to getting traction on somewhere like Hacker News is choosing a punchy title and taking a slightly more extreme position (See "Hours are Bullshit") that you might otherwise do. Interesting technical posts do well, too.

From a practical point of view, make sure you host the blog on your company's domain (SEO benefits), mention your company's name and link to your hiring page in an inoffensive way.

Open-source your tools

As a technology startup, you'll be successful if you're closer to your market & customers than your competitors, and you're able to respond more quickly to their needs. As such, giving away tools that make you more productive initially seems counter-intuitive, but it's not. Depending on your market, your competitors are likely to be slow-moving incumbents. If they're still struggling with Visual Basic .Net and SOAP APIs, releasing a new Ruby deployment tool isn't going to help them much. 

Even if that's not the case, open-sourcing useful little tools will dramatically help your recruitment processes - Github are the authors of the well-known Ruby tool Resque, for example.

At GoCardless, we've not been as good as we'd like at open-sourcing our tools, but that's changing. We've just released Hutch, a Ruby tool for RabbitMQ, and some development widgets for Dashing. Next on the list is a neat little tool written in Go that makes it simple to spin up multiple services in a local development environment.

When you open-source your tools, don't forget to tell people about it! At the very least, it's a nice thing to do for the ecosystem.

Speak at meetups & conferences

This is really an extension of the previous three points - take all the great content you've produced from your fun side-projects and open-source contributions, and package them up into neat 20-minute presentations with some interesting slides.

It's great for your engineers' personal development, and it really helps spread your name around the relevant communities. You don't need to spend a lot of money on flights around the world, either. Many cities have very vibrant user-groups which hold meetups every few weeks - there's an Angular JS group in 50 cities around the world, for example.

Encourage all of your engineers to attend - and make sure you're wearing your company t-shirts! It's a great opportunity to talk to other like-minded developers about the interesting technology you're using.

  Finally…

These are five pretty simple things you can do to increase the number of quality applicants. The most important factor is simply to get your name out into whichever community you're trying to recruit from. If you spend a couple of weeks building a cool new tool, don't forget to spend the final hour or two writing a blog post about it.

I'd love to hear about other tips people have - you can follow the discussion over at Hacker News

[tomblomfield]

Startup Series Part 1: Interviewing Engineers

There’s been a huge volume of literature written on the subject of startup methodologies and philosophies. This is a positive thing for the ecosystem - just as new software tools mean it’s simpler and cheaper to start a company, these methodologies allow first-time entrepreneurs to avoid many of the pitfalls of the past.

But I’d like to write a more practical guide - what happens once you’ve launched your MVP, iterated to a product that people actually want, and raised VC money to scale? What are the day-to-day challenges you’ll face and pitfalls you’ll encounter? Over the last 3 years at GoCardless, we’ve run into and subsequently dug ourselves out of many of these pitfalls. By making these mistakes, we’ve developed solutions that, at times, have dramatically increased our productivity.

Startup Series Part 1: Interviewing Engineers 

The hiring process at technology companies has been the subject of a great number of blog posts, often written from the perspective of disgruntled candidates. They rail against what they see as capricious and ineffective techniques. This problem will probably exist as long as interviews produce unsuccessful candidates, but it is possible to design & run a process that will annoy a very minimal number of people, whilst selecting the best of the bunch to work at your company.

Once you have a good number of capable people applying to work at your company (a much harder problem!), selecting the best of them should not be a terribly difficult problem.

Over the last 3 years, we’ve seen around a thousand CVs, conducted hundreds of interviews, reviewed several dozen coding challenges and ultimately made 15 technical hires. As a result, we identified a number pitfalls in the interviewing and selection process. Usually we did this by stumbling into them head-first.

  Define a process and stick to it

If you’re not absolutely clear on what each step of the interview process involves, and what you’re looking for at each stage, you’ll inevitably resort to weak, fluffy questions that don’t really reveal anything about candidate. If you throw a couple of your developers into an interview with no preparation, you’ve wasted 2 hours of engineering time at best. At worst, you’ve alienated the candidate and irritated your developers.

Instead, invest a little time defining what systems and processes you’ll use. Write down this process and share it with your team and candidates. You don’t need to invent this from scratch - choose someone else’s and adapt it to your needs.

Get an applicant-tracking system that stores CVs and the result of each interview (with detailed notes), so that you can compare candidates based on data. If you see a dozen developers in a week day, you’re unlikely to remember each of them by Friday.

Our process was pretty simple: CV screen, 15-minute phone screen, 2-hour coding exercise, 1 in-person interview to debrief on the coding exercise, 2 subsequent “final-round” interviews, with a mix of technical and “fit” questions.

Ultimately, the output of each stage should be “hire” or “no-hire”. Rack up enough “hire” votes from the different interviews, and you can make an informed decision. If you want, you can assign a more granular score, but it rarely yields a different outcome.

If you find yourself coming out of an interview and not being able to offer a hire/no-hire opinion, you're asking the wrong questions.

  Lack of preparation is unforgivable

Before the interview, write a list of good questions for each aspect of a developer’s skillset - with a backend developer, for example, you might want to focus on “web technology”, “databases”, “system design and architecture” and “algorithms”. If you have 2 in-person interviews, split the topics between them so that you don’t end up covering the same ground.

You can do the same thing for cultural & personality interviews, but you need to take care to avoid weak questions which either don’t reveal anything. Often, questions like “why do you want to work at a startup?” and “why do you want to work at this company?” are just an opportunity for the candidate to blow smoke up your arse. It’s a vanity exercise.

Instead, I like questions like “which parts of your previous job did you most enjoy? Which parts would you avoid in future?”. If you really probe for specific examples, it can tell you a lot about a person’s personality and motivations.

This list of questions should be shared with the company, and improved over time. I’d suggest it’s a key part of the company’s IP.

Relevant coding challenges are the best indicator of ability

In my experience, relevant, realistic coding challenges are by far the best indicator of ability. They should take roughly 2 hours, to be done in the candidate’s own time, and they should tell you:

- at a basic level, can the candidate structure a simple system?

- does the candidate write fluent, idiomatic code, in the context of whatever language is chosen?

- can the candidate select & use appropriate libraries?

- how much effort has gone into building the system?

For example, we sometimes ask people to write a client library for a real-world API or web-service in a language of their choice. I really like the exercise because there are such a range of solutions and opportunities for people to demonstrate exceptional ability and effort. There are also a number of great extension questions when you ask the candidate to talk you through the solution. How would you speed-up the client or the API? What are the different approaches to caching? How might you fetch a great number records simultaneously? If you were maintaining the API, how would you deal with very high volumes of requests? What are the various ways of dealing with API versioning?

We also tend to do some fairly lightweight algorithmic coding challenges in person - calculate row n of Pascal's triangle or implement a basic sorting algorithm, for example. It's important to provide a clear definition of the algorithm in question, allow the candidate use of a language of their choice and their own development environment, otherwise you're not testing the right things. Interestingly, the optimal solution to many of these challenges involve recursion - a technique that seems to baffle some developers.

These shorter tests tend to reveal whether people can think under pressure, communicate clearly and debug broken code in a sensible way. For example, faced with a half-working sorting algorithm, a bad candidate will start changing variables at random. A good candidate would work methodically through the problem, ideally adding debugging lines that output the values of relevant variables at each stage. It's worth noting that, while useful, these tests are not as good an indicator of on-the-job capability as the longer coding challenge. Many fantastic engineers don't excel under this kind of high-pressure situation, and actually it's not the kind of scenario they'd encounter on-the-job very often.

At the other end of the spectrum, asking someone to complete a 3 or 4-day project might be the ideal way to judge aptitude, but it just isn’t realistic in our experience.

  Practical Tips

Finally, there are a number of simple practical tips that will make your life much easier:

Wherever possible, try to bunch your interviews into blocks of time. At the most extreme, I met 8 applicants for in-person interviews in a single day. It's exhausting, but it avoids constant distraction and context-switching, and allows you compare candidates more effectively. 

Have one person in the company who is responsible for receiving & screening CVs. Do this in blocks of time, once or twice a week. Otherwise, it can get overwhelming 

Be clear what you're looking for from CV- and phone-screens. You could be wasting a lot of time. Write a checklist after you've seen a dozen or two CVs. We should have rejected way more people at this stage.

Whatever the outcome, respond to candidates quickly and constructively. It makes them feel valued, and it's simple good manners.

  Finally...

Even using this process, you’ll make bad hires. It happens, and it’s not the end of the world. Fire fast and move on. Overwhelmingly, the bad hires we made were due to poor preparation, or, at times, wilfully skipping most of this process. Hiring well is one of the most important things you can do for your company. Don’t neglect it!

  I'd love to hear your thoughts - please comment below, or follow the discussion over at Hacker News

[tomblomfield]

Advice

Starting a company is a challenging process - you're thrown into the deep-end with nothing but your wits to help you. Often, though, advice will be forthcoming. This post is about that advice, and how to spot the difference between good and bad.

Some advice is expert - your lawyer talking about your Ts & Cs, or a sysadmin giving advice on web-service redundancy. In these cases, you'd do well to trust the person's professional judgement and follow their advice.

Other advice is not.

Some people, as part of their jobs, are trained to give substantive, concrete, and often completely baseless advice. In my previous life as a Management Consultant, we'd routinely give advice like "sell these 400 under-performing stores". There is a certain reassurance in the tangible, solid nature of the advice; "Do this and you'll be fine". It absolves the recipients from spending more time thinking about the problem - the experts had provided a solution. As long as the advice wasn't demonstrably wrong, everyone was happy.

Unfortunately, early-stage companies aren't like this. If you waste 3 or 4 months misguidedly pursuing some market segment, or building a feature-set before you've determined that you're really on to something, you'll bankrupt your company.

This is why advising early-stage startups is so fraught with difficulty - experts from fields like law & accounting give substantive advice without really understanding the nuance of the market or the product. In fact, almost no-one else in the world is close enough to your customers to really understand their problems. These are the problems that you, as a startup founder, should be trying to identify & solve.

When my startup, GoCardless, was in Y Combinator, the advice we got was different. Despite having some of the best collective experience in early-stage startups on the planet, it was striking how rarely the partners would give this kind of substantive advice. Instead, they dealt in mantras & heuristics. At the time, this was incredibly frustrating - we wanted someone wise just to tell us what to do. It apparently doesn't work like that.

Instead, they presented a set of rules which appear to maximise (but not guarantee) a startup's chances of survival:

"Launch early & talk to your users" (or, more completely "Build the absolute smallest thing that can be considered a complete application and ship it" )

"Make Something People Want" 

"Don't Worry about Competitors"

"Focus 90% of your time on solving your one biggest problem"

"Don't Talk To Investors (until demo-day)"

"Be a cockroach" (or "Assume you won't get money, and if someone does offer you any, assume you'll never get any more.")

Sam Altman recently published a list of these at http://blog.samaltman.com/startup-advice

When people come to you with a problem, it's always tempting to give substantive advice. This must be even truer for the Y Combinator partners - these are people who've built & sold a number of highly successful businesses over the last 15 years. Yet, by and large, they refrain. In retrospect, I find that a really interesting phenomenon.

On the other hand, it's troubling to see accelerators, especially in Europe, touting their vast "networks of mentors". Experienced accountants give great tax advice, but dreadful startup advice. When it comes to acquiring your first 100 users, I'd stick with the mantras - "Launch early, talk to your users & make something people want."