Skip to content


My FounderLY interview

Matthew from FounderLY wondered what it would have been like to watch raw video footage of Steve Jobs, Bill Gates, and other tech founders during their formative years. So he’s been going around interviewing young startup founders, for posterity and for other founders’ inspiration. A pretty interesting effort.

A few weeks ago he asked whether he could interview me for the site. Although it would be rather presumptious to put myself in the category of potential future Steve Jobses, I agreed.

So here you go – a tidily scripted set of questions from Matthew, and some chaotically unscripted stream-of-consciousness replies from me. The video comes in two parts, about 22 minutes in total, and a transcript is below.

Martin Kleppmann interview, part 1 from FounderLY on Vimeo

Martin Kleppmann interview, part 2 from FounderLY on Vimeo

Transcript

Matthew Wise: Hi this is Matthew Wise with FounderLY.com. We empower entrepreneurs to have a voice and share their story with the world, enabling others to learn about building products and starting companies.

I’m really excited today because I’m here with Martin Kleppmann, founder of Rapportive. Rapportive shows you everything about your contacts inside your email box, enabling you to see who people are and where they are based, so that you can connect and collaborate over shared interests. So, Martin, we’d love you to give our audience a brief bio.

Martin: Sure. I’m originally from Germany, which explains my weird accent, and then I went to the UK for several years to study computer science. That was in Cambridge. After that, I started a startup; it was called Go Test It, we made a tool for automated cross-browser testing of websites. That was pretty cool, and it was acquired a few years ago. After that, I was looking around for something new to do, and together with two friends we started Rapportive.

What we do now is to pull photos, job details from LinkedIn, recent tweets and all of this stuff into Gmail, and show it right there.

Matthew: What makes Rapportive unique, who is it for and why are you so passionate about it?

Martin: It’s really for people who do a lot of email, particularly emailing with people who you don’t really know well. If you only ever email with ten different people, then you wouldn’t need it — but most of us, particularly startup founders, are constantly dealing with investors, outside advisors, users emailing us, potential customers, potential partners, people on emailing lists… all of these people, we vaguely know who they are, but not really. And actually, it is really important that you build this personal contact with them, and get to know them personally.

Previously, when people got an email from someone, they would go and search Google, try to find their Twitter account, try to find them on LinkedIn, and this just takes a lot of time. And we’ve just automated all of that. The idea is that now, you can actually respond to people personally and build up that personal connection. It’s little things: even just being able to see the photo of someone in your email… firstly, that’s a deep visceral connection: you connect much more with them than if you’re just looking at a wall of text; and also, if you meet them in real life, well, you’re much more likely to be able to recognise them. I think that makes your email a better place; it’s really excellent.

Matthew: What are some of the technology and market trends that currently exist, and how do you see things developing in the future in your space?

Martin: I’m not sure about the big trends. There are a lot of things, but they are all very subtle things. For example, people caring a lot about user experience, and we take that really seriously. We put ridiculous amounts of effort into making sure that stuff works really nicely.

Other things that are happening: we are having to deal with more and more people, and people expect that you don’t just get an automated stock reply, but that people actually engage with you personally. That’s the future, I think. We’ve already got that in one-to-one communication between individuals, but the big trend is that companies as a whole are starting to be more personal with the outside. They are no longer this corporate brand, this cold, anonymous thing, but you actually expect to be able to see the people behind that brand, and be able to engage with them directly and build a relationship. And those relationships are what matter, because… if you’re just competing on price, your customers can just go somewhere else, but if you can build up a relationship with your customers, that’s really really powerful.

We think that’s what we are enabling, by giving you this social substrate for your communications.

Matthew: Can you tell us what inspired you to start Rapportive? Was there an “aha” moment, or did market research lead you to the opportunity? What’s the story behind it?

Martin: It really came from something we wanted ourselves. I think everyone says this! In my previous startup (and my cofounders also had a previous startup), we were all trying to do a lot of engaging with people personally, getting out there, learning a lot from people, really understanding where they were coming from. And that was so much effort! I’d keep lists of people in a custom database or in spreadsheets or in CRM systems like Highrise, and I’d have to keep them up to date by hand. I’d make a lot of notes about people, even just for myself, just so that I could remember when I came back to them six months later: what interactions I’d had with them, what we’d talked about.

But I then found that all of this information would go stale: for example, I had entered someone’s job details and then they’d change job… and I’m not going to go and re-enter all of this stuff! It’s already out there on the web — really, software should just do this stuff automatically; there’s no reason why I should have to type this in again.

And then, also, why should I have to always change over to another browser tab in order to search for something, and have five tabs open with different searches for stuff? It’s just ridiculous, this stuff should be in the tool which I use all the time anyway, which is email.

And so, those are the two premises we started with. We wanted something which keeps itself up-to-date automatically from all the data which is already out there; you shouldn’t have to re-enter anything. And secondly, it should be in the workflow of the tool you already use, which, for most of us is primarily email. And on that premise we said: what can we build? Oh, well, let’s just stick something on the side of Gmail, see how it works. And people loved it.

Matthew: Excellent! Who is your cofounder, how did you meet, what qualities were you looking for in a cofounder, and how did you know they’d be a good fit?

Martin: I have two cofounders, Rahul and Sam; there are three of us. They are both really excellent people. I had known them for a while before starting: we were together in an office space, a kind of co-working space in Cambridge, UK. They were working on their previous startup, and I was working on my previous startup; we worked together a bit, we had lunch together every day, and just ended up talking about a lot of things.

We found that partly we thought the same in a lot of ways, and partly we also had different but nicely complementary ways of thinking. We had a shared culture but often different perspectives, which helped us to together find the best way of doing stuff. And that’s really the basis on which we work. I think we have a very strong sense of a culture and making sure we work together very well, so we are constantly getting better at what we do.

Matthew: From idea to product launch, how long did it take, and when did you actually launch?

Martin: It was pretty quick actually: from first UI mockups to launch it was less than two months. We weren’t actually intending to launch: we had just put up this little website. We were applying for Y Combinator at the time and we also had some other people who were interested, so we wanted to show some potential investors what we were doing. Put up a little website; it wasn’t protected, but just at unknown URL.

And then somehow the press got hold of this, and within a day we found ourselves with 10,000 users on our hands, because it just went wild through all of the blogs. That was a totally crazy experience: we had thought, “well, we’ve built this little thing, let’s give it to 10 people and see how it works”, and suddenly we have this massive load of people coming in. And we were working, working very hard, firstly trying to keep the servers up, but fortunately they held up quite nicely. Then also responding to all of the tweets, responding to all of the emails that were coming in. There was lots and lots of stuff happening very quickly; at that point we knew that we were on to something pretty exciting.

Matthew: And then you formally launched when?

Martin: We considered that our launch after the fact; we then said, “Well, OK, I guess we’ve launched now. Oh well, we’ve launched.” And then since then we’ve, at times, launched new features but that original bit of press we regard as our real launch.

Matthew: Are there any unique metrics or social proof about Rapportive that you’d like to share with our audience?

Martin: I think the thing I find most exciting: we always have a Twitter search going on — we have a big screen in the office, showing what people are saying about Rapportive on Twitter — and there’s just this constant stream of people loving it. I’m really humbled all of the time I see this. Every hour there’s stuff coming in from people saying things like, “This product has changed our life.”

And that’s just amazing: when people will actually go out of their way to say something like that, and we’re not even particularly prompting them. So yeah, we have hundreds of thousands of users at the moment, but the important thing is really how much people care about it.

Matthew: We know founders face unique challenges when they start a company. What was the hardest part about launching or starting Rapportive, and how did you overcome this obstacle?

Martin: So we had a bit of a frustrating phase over the last summer. We were working very, very hard and there was lots going on, but our product was making very little visible progress, because we were spending all of our time firefighting, scaling our database because we had so much stuff coming in that we had to do a lot of work to re-architect it. We were doing a lot of groundwork for features which are just coming out now, but in technical groundwork there are months of work which is just invisible. We were moving country because we were all coming from the UK, moving to San Francisco, and we were fighting with US immigration. We were also spending a lot of time on support — which is good, it’s really valuable, because we learn a lot about the problems that people have, but again it’s very time consuming.

So, with all of those things, it’s all useful stuff; there’s nothing really wasteful there. But on the other hand, our product wasn’t making progress, and people were starting to ask, “Well, you’ve been around for six months now, nine months now, and you’ve not really released any exciting new features. What’s going on?” And we were just saying, “Yeah, we’re trying to get to it, we’re doing what we can!”

And then I was so happy when, towards the end of 2010, we got over this big hump of stuff, and now we’re putting out features again and there is much more visible progress. So that was a fairly hard phase to go through, but I’m really glad we got over it. In the end you just have to work through it. You just have to not give up, just keep on going, keep on going, even if it’s getting tough.

Matthew: Since you’ve been in operation, what have you learned about your business and your users that you didn’t realize before you launched?

Martin: When we first launched I was a bit cautious. I was wondering: “are people going to be really freaked out by seeing how much information is actually publicly available about them on the web?” You know, when you think about it rationally, it’s obvious: you can just search for someone on Google, and for most people you’ll actually get a pretty good idea of who this person is just by looking at the search results. And we’ve just taken away a step by automating a lot of that search, making it more convenient by putting it in email.

And so I was expecting that there’d be a lot of people who would go, “Oh my God, no, privacy is dead!” But we tried to manage that very carefully: whenever anyone was concerned, we listen to them and respond to any concerns very quickly, and explain what we’re doing, why we’re doing it and why we think it’s absolutely fine. We are all very privacy conscious and we make that very clear as well. We don’t mess around with people’s private data; we only show information which people actually want to be public.

And that is something I found surprising: just how quickly we can defuse any situation. If anyone was upset we’d just talk to them quietly, patiently, and explain what’s going on. If there was any problem, fix it quickly — and all the problems suddenly go away. And that’s really encouraging, because it means that we seem to actually be doing the right thing: pushing the envelope a bit. But yes, it works.

Matthew: What is it that you make look easy? What skill or talent comes easy or intuitively to you, and what has been difficult and how do you manage that?

Martin: I’d say: what we, as a team, are particularly good at is product design. Making something which is very neat, stays out of your way, but is still powerful; which does exactly the stuff you need, not more, not less; and just behaves the way people expect it to behave, without running into a weird corner where you don’t know what to do.

And that is actually really hard to achieve. The amount of time we spend on optimizing the workflows for different users, depending on which starting state they’re coming from, which screens they have to go through and exactly what button we can show in which place, exactly what copy we use, what words we use to describe things, then taking them through the flow… and then, to the user, all it looks like is: “oh, I clicked a button, a pop-up appeared, I clicked another button and it worked.”

That’s something we really enjoy: making that look easy, but a lot of work goes into it. In the end people just appreciate it as a product which is really nicely designed, which just works and which gives them a kind of warm, fuzzy feeling.

Matthew: What’s the most important lesson you’ve learned since launching Rapportive?

Martin: The most important lesson? I’ve not really graded them in a particular priority.

I’d say, off the top of my head: caring about user experience and caring about users was something we thought from the start was really important — and that has really been validated. People appreciate us for having a product which just works nicely, and which has the little details thought out.

People appreciate that we get back to them quickly, that we’re always very friendly when responding to them, that we’re trying to be personal where we can.

Matthew: Martin, what bit of advice do you wish you would have known before starting Rapportive?

Martin: I think what’s really interesting is that in a startup everything is magnified. If you have any issue early on, that will just continue, continue, get bigger and bigger, so if you have any issue early on then make sure you fix it early on. I think we’ve generally done a pretty good job of that. But it’s worth doing that really consciously.

Certain things are really hard, but you need to get good at them. For example, communicating and sharing intuitions, that’s a topic that I’ve been thinking about a lot. We find that, since we’re three cofounders, we often have similar ideas about things, but and then often find that they differ in subtle ways. Really what we want to do is to combine our three intuitions into one, so that together, we have a really good broad and also deep insight into what people want. That requires that you find ways of explaining to the others not just what you think, but why you think it.

And that’s really hard to learn, and we’ve gradually been getting better at that. As you go about things, just be conscious of the fact that it’s going to take a lot of effort and time, even just to learn to speak the same language. You think you all speak English, but then you find, of course, that you make up your own words to describe the domain you’re working in. A lot of things are just completely non-obvious.

You get a lot of conflicting advice from outside mentors. We have a lot of really good investors, advisors, mentors, and often they say completely contradictory things — and that’s fine. You just need to learn to absorb those things into your own intuition, and within the team work out how you can share those intuitions. Then you can have a coherent vision, all together, for what you’re going to build, why it’s important, how you’re going to go forward.

Matthew: What bit of advice would you like to share with our audience about launching a startup? If you have to distill it, what are the key elements?

Martin: One thing, which worked in our favor but is not necessarily particularly replicable: if your product works well for journalists, then journalists will write about it quite a lot. We didn’t realize this initially, but it happened to be the fact that, Rapportive works really well for people who deal with a lot of incoming weird stuff from lots of people they don’t know, and need to assess very quickly whether the sources are reliable. And, well, that’s pretty much what journalists do.

It was also the case that when we started Rapportive, a lot of the data we had about people was not particularly great, but bloggers tend to be the kind of people who are very present on social media, so we had really great data for them! And that worked in our favor. Since then we’ve got a lot better at data for everyone else, and now we’ve got a pretty high coverage rate for everyone. But for that initial launch, just working well for reporters and bloggers was pretty good.

But of course, you can’t choose your startup based on the fact that it’s going to be useful for bloggers, so that’s not very useful advice.

There are lots of different schools of thought for launching and they all kind of make sense. There’s the “launch small and make sure that you’re continuously learning” school, and that makes a lot of sense. And then there’s also the school which observes that, if you can get a lot of very quick press that generates a lot of excitement and a lot of buzz, that’s also valuable. In the end, with these things there’s never a right answer; you just have to take in all of the bits of advice you hear and create your personal conglomerate of what makes sense.

Matthew: Before we close, I would love for you to give our audience your vision of Rapportive and how you hope it will change the world.

Martin: We’ve got a lot of really exciting things coming. I don’t want to talk about them in too much detail, but to give a rough outline:

I think, firstly, the inbox is a really, really interesting place, because that’s where all of your communications come together. Email is the primary one we use at the moment; I don’t know, maybe it’ll be Facebook mail within two years’ time, but that doesn’t really matter, that’s beside the point.

The point is that people are really, really opinionated about which tool they want to use, and getting people to change tool is really, really hard. So we’re building Rapportive in the philosophy that we don’t people to change behavior; we just want people to continue doing what they’re doing already, and just make it better.

Just add those little magic touches, add little things which either save you time, or which take something which was previously laborious (and required switching to other browser tabs and required re-entering of data), and make all of that go away. Just make it be there, and make common tasks feel natural.

That’s the philosophy with which we’re going about things, and that seems to be working pretty well.

Matthew: Excellent. Well, Martin, it’s been a pleasure having you as a guest on FounderLY. We’re rooting for your success at Rapportive. For those in our audience who’d like to learn more you can visit their website at www.rapportive.com and register to become a user and join their community. This is Matthew Wise with FounderLY. Thanks so much, Martin.

Martin: Thank you, Matthew.

What's so special about Y Combinator?

Since we joined Y Combinator’s Summer 2010 funding cycle, I keep getting asked how much value we got from it, and whether I would do it again.

tl;dr The short answer: we got a huge amount of value during the three-month main programme, and we are continuing to benefit all the time from being part of YC. And yes, I would do it again without a moment’s doubt.

The long answer deserves a bit more explanation.

On the surface, it seems like the Y Combinator formula is “money and mentoring for equity”. That seems like a simple enough formula, and clones around the world are rushing to replicate it. Unfortunately I think they mostly miss the point, because there is so much more to YC which the others lack.

When we applied to YC, we had already launched and didn’t really need the $20k they were offering (investors had started contacting us from the day that Rapportive first hit the press). Looking at the other startups who joined YC at the same time of us, most of them got profitable or secured substantial angel/VC funding at good valuations soon afterwards. So although the money is nice, it’s probably not the main attraction.

As to mentoring, press and investor contacts… as an entrepreneur, you’re probably already quite good at getting attention and feedback from relevant people, using your personal network. How much more value could you get?

Network and knowledge

The things that are really special about Y Combinator, in my opinion, are less frequently talked about:

  • There is a genuine, strong sense of camaraderie and mutual support amongst YC alumni. Many organisations claim to have strong alumni networks, but I have often found these claims to be empty words: often, the only participants in these networks are those who want to take, not those who want to give, because those who have something to give feel their time is wasted. It is hard to maintain a high standard in a network, and YC’s is the only example I have seen where the high standard is consistently upheld. Even the most busy founders of the most successful startups are genuinely supportive, and will spend surprisingly large amounts of time to answer questions, give practical advice, make introductions and recommendations, etc. They are real friends, not just utilitarian business contacts. This culture is truly remarkable.

  • It sounds trite, but the YC partners are all really great people. They are exceptionally bright and talented, outspoken, honest, straight-to-the-point and totally bullshit-free – hardly anyone else I know even comes near in terms of these qualities. They have lots of time for their companies (surprisingly, given the number of companies they’ve funded), and I have only ever seen them do things that are good for founders. It seems altruistic, but Paul Graham maintains that it’s simply the best business strategy for YC.

  • Between them, the YC partners have seen it all. They’ve seen big exits and small exits, profitable companies and train-wrecks, fast growth and slow growth, dream teams and founder disputes, and all manner of great ideas and screw-ups. Startups are unpredictable; you never know what surprises lie around the next corner. When we talk to YC, no matter whether we have good news or bad news, chances are that they’ve seen the situation before, and their pattern-matching will enable them to make good predictions.

  • The YC team know everybody who’s worth knowing in the startup scene, and everyone respects them. This makes them ideally placed for introducing you to the kind of people you want to meet. Demo Day is one aspect of this, a maximum-efficiency batch process for introducing startups and investors to each other, but YC also make individual introductions all the time. They also know who is worth talking to, who is actively investing, and which people are just fishing for information.

  • If there is a change in the startup ecosystem, YC are amongst the first to see it — because they have insight into a uniquely high proportion of startup deals, and they work actively to spot patterns and learn from them. As a YC startup, you get to hear about these changes first, something that you can use to your advantage.

  • If you are new to Silicon Valley, like we were, YC is a fantastic way to get yourself established and find your feet. They are welcoming to outsiders, and you can bootstrap your valley network from those who already know their way around. You can celebrate with them when things go well, and to get encouragement from them in hard times. You couldn’t ask for a better group of people to hang out with.

  • Because YC has a proven track record of funding great companies, being accepted to YC carries a strong signalling effect, making it more likely for others to believe that you are doing something interesting by default.

Being part of the best

A lot of the points above are remarkable, but not intrinsically unique to Y Combinator; what’s particularly special about YC is that it is simply number one. Being number one is very different from being number two or any number below.

One friend from our YC batch remarked at Demo Day: “This room contains the future of the IT industry.” He was right. Since many of the world’s best startups go through YC, they collectively form a force which has the power and drive to shape the entire industry for many years to come. That’s not because there is any centralised agenda; it’s more comparable to being a graduate from one of the top universities in the world.

Ever wonder why so many leading figures in business, science and politics are graduates of Harvard, Yale, Cambridge, Oxford, MIT or Stanford? I don’t think their teaching is really that much better than any other university, or than reading the textbooks by yourself. But you do get two valuable things from a top university:

  1. a signalling effect: other people can see that a reputable organisation thinks that at one point in your life (when you took your exams), you were reasonably motivated and not entirely stupid;
  2. you build a network of talented people.

I think we are seeing something similar with YC. The fact that YC has brought forth a number of successful startups is merely a correlation; by itself it doesn’t say anything about cause and effect. But when people see a correlation, it has a signalling effect nevertheless. (The reputation of a good university is also mostly due to the observed correlation between its graduates and their later success.)

Startups are risky and full of unknowns, and you as startup founder are in the business of convincing everyone that you are going to be the big, successful one. You need all the positive signals you can get.

But is it worth the cost?

Y Combinator takes 2–10% of your company’s equity. How do you figure out whether the value you get from YC is worth the cost? If you are wondering whether to apply for YC, this is probably the question you’re trying to answer.

Firstly, note this: dilution makes an incremental difference to your outcome: if you sell 5% of the company to an investor, you reduce your pay-out by 5% if you sell the company. However, whether you have or don’t have an investor can make a huge difference. Say you give 5% of the company to…

  • someone who later makes that one critical introduction that leads to the deal which saves your company.
  • someone who helps you negotiate with your acquirer and doubles the value of your exit.
  • someone who encourages you to make a particular pivot, which turns out to unlock a billion-dollar market.
  • someone who prevents you from making a stupid mistake that would have set you back by 12 months.

Whether any of these scenarios will actually happen is unknown in advance, but my point is: probability of success tends to move in discontinuous jumps. An extra per cent of equity may make absolutely no difference at all to your success, or it may turn out to make the difference between epic fail and massive win. A bit of equity may buy you an “unfair advantage”, or it may be a complete waste.

You need to figure out which investors might make the big difference, and which probably won’t. Your job as founder is to figure out how to play your cards such as to maximise the chances of massive win. Dilution changes incrementally, but probability of success is much more variable. Therefore, if you can figure out a way of substantially increasing your chances of success (putting yourself on the good side of some of those discontinuities), the equity cost is secondary. It’s not irrelevant, but as long as it’s in the right ballpark, it’s ok.

Of course you should be prudent to whom you give equity, but I would argue that if someone can give you “unfair advantages”, it’s well worth bringing them on board and not worrying too much about the cost.[1]

So, does Y Combinator give you that big advantage which has a disproportionately large positive impact on your chances of success?

I’d say yes. If you don’t need any of the benefits mentioned above, maybe not… but honestly, I’d be very surprised if your network and your group of advisors is already so perfect that you wouldn’t benefit from YC. Whether you’ve already launched or not makes very little difference.

YC is a package consisting of a variety of good things. In principle you may be able to assemble yourself a similar package from component parts — e.g. using AngelList for your investor intros, asking around to find suitable advisors, and spending lots of time networking and taking speculative meetings. But somehow that feels to me like buying individual CPUs and RAM and rack-mount cases to assemble your servers, when you could just spend 10 minutes to buy computing resources from Heroku, EC2 or Rackspace. It might make sense for some people, but for most of us, the time saving and assured quality you get from a good pre-built package is well worth a bit of extra cost. (That doesn’t mean you can’t use component parts as well – for example, we used AngelList to fill up our seed round.)

I hope you find this useful when deciding whether to apply to YC. :)


[1] In my opinion, the main reason to be careful with distribution of equity is not because dilution reduces the size of your payout, but rather because you should avoid odd-looking things on your cap table. Later investors will see weird things on the cap table during due diligence, may assume that you are irresponsible in the way you run the business, and pull out of the deal. That's something you can avoid by keeping your capital structure nice and clean. But honestly, no investor in the world could possibly object to seeing YC on your cap table, because they know perfectly well how much value YC brings. So that concern is irrelevant here.

Accounting for Computer Scientists

Every educated person really ought to have a basic understanding of accounting. Just like maths, science, programming, music, literature, history, etc., it’s one of those things which helps you make sense of the world. Although dealing with money is not much fun, it’s an unavoidable part of life, so you might as well take a few minutes to understand it.

Sadly, in my opinion, most accountants do a terrible job of explaining their work in an accessible way; it’s a field full of jargon, acronyms and weird historical legacies. Even “Bookkeeping for Dummies” makes my head spin. Surely this stuff can’t be that difficult?

(We computing people are probably guilty of the same offence of bad explanations and jargon. The problem is, once you have become intimately familiar with a field, it’s very hard to imagine how you thought about things before you understood it.)

Eventually I figured it out: basic accounting is just graph theory. The traditional ways of representing financial information hide that structure astonishingly well, but once I had figured out that it was just a graph, it suddenly all made sense.

I’m a computer scientist, and I think of stuff in graphs all the time. If only someone had explained it like that in the first place! It would have saved me so much confusion. So I want to try to fix that. If you like graphs, then by the time you reach the end of this article, you should know everything you need in order to understand the financial statements for a small company/startup (and even calculate them yourself, in a spreadsheet or programming language of your choice).

It’s really not that hard. Let’s go!

Accounts = Nodes, Transactions = Edges

Say you go to the bagel shop and buy a Super Club bagel for $5 on the company credit card. You also visit some random Silicon Valley startup and buy one of their surplus Aeron chairs, second hand, for $500 (by writing a cheque from the company account). Those are two transactions. Each transaction is an edge in our graph, and the edge is labelled with the amount.

An edge always goes from one node to another. What are those nodes? Well, you can define them as you like (although there are some conventions). For now, let’s say:

Graph representation of accounts

Let’s add some more details. You pay the $5 credit card bill from the company account. And where did the money in the company account come from in the first place? Ah, I see, you put in $5,000 of your savings to start the company. Ok, now the graph looks like this:

Graph representation of accounts

Hopefully pretty self-explanatory so far. Money flows in the direction of the arrows.

Hungry once again, you go to the taqueria and buy a Super Burrito for $8 on the credit card. Now we could create another node for the taqueria, but this is starting to get messy – we don’t really care how much money we spent on bagels vs. how much on burritos. Let’s just lump them together as “food”. Also, “Random startup” is a bit unhelpful – I’ve already forgotten what those $500 were for. Let’s call it “furniture” instead.

Graph representation of accounts

See, that’s perfectly fine. We can have nodes which represent actual bank accounts or cards, others which represent people or companies, and others again which represent abstract categories like “food” or “furniture”. Just throw it all into the same graph.

Note also that you can have several edges between the same pair of nodes. You can keep track of the individual edges, or you can simply add them up. (Using the credit card, you spent a total of $13 on food.)

Accounts have balances

Every node in this graph is an account in accountant-speak (whether or not it is held by a bank), and every account has a balance. The balance is a single number for each account, and it is determined completely by the transactions in and out of the account:

  1. At the beginning of time, the value at each node is zero.
  2. At each node, for each incoming edge, add the edge’s label to the node’s value; for each outgoing edge, subtract the edge’s label from the value.

After you’ve processed all the edges, the value at each node is that account’s balance. Our graph now looks like this:

Graph representation of accounts

Note that the account balances have two nice properties:

  1. Because every transaction appears twice – once positive and once negative – the sum of all account balances is always zero.
  2. If you partition the set of nodes into any two disjoint sets, and add up all of the balances in each set, then the sum for the one set is always the negative sum of the other set (because, after all, they have to add up to zero).

These properties are useful for sanity-checking your numbers; if they are violated, “ur doin it wrong”. (This is what accountants mean when they talk about “balancing the books”.)

Doing business

Strengthened by a bagel and a burrito, you go out and talk to some potential customers. And hey, they love your product! It has a price tag of $5,000, and you sell it to two big enterprise customers. One pays you right away (good stuff!); the other gives you $2,500 up front, but insists that before they pay the rest, you need to implement that additional feature you foolishly promised.

So you received $5,000 + $2,500 in cash from your customers, wired straight the company bank account. Let’s add that to the graph:

Graph representation of accounts

But that’s not quite right. The price was $5,000 for each customer, and now it looks like you charged two different prices. How do we represent our arrangement with customer 2?

The solution is to deconstruct the deal into two separate transactions: the sale (in which the buyer agrees to buy, but no actual money changes hands) and the payment (when the cash actually hits your bank account). We can draw it like this:

Graph representation of accounts

See what I’ve done here? I’ve just made up a new node, generically called it “sales”, and added the actual $5,000 sales as a transaction from this “sales” account to the customer accounts. Adding this extra node hasn’t changed your bank balance.

This makes sense when you think about the intuitive meaning of the balances. The balance of each customer’s account is the amount they owe you: customer 1 has fully paid up (their incoming and outgoing transactions add up to the same), so their balance is zero; customer 2 has contractually agreed to give you $5,000, but has so far only given you half of that, so their balance is $2,500.

And the balance on the sales account is the value of stuff you’ve sold. Or rather, the negative value. That looks a bit weird… but I’ll come back to that later. (BTW, if you wanted to separately track sales for different customers or different products, no problem — just add whatever nodes make sense for you. Just make sure that every transaction appears only once as an edge, otherwise you’re making stuff up!)

Finishing off the example

To round it off, let me add some more events to the story (= some more edges to the graph).

Not only have you made some sales, but now you also receive a $20,000 investment from Y Combinator — congratulations! You and your co-founder can now afford to pay yourselves a salary. You take $8,000 out of the company account.

Then you get set up with a company accountant, and they talk lots of jargon at you. For some strange reason they are obsessed with correctly accounting for your office chair; they want it to depreciate over four years, i.e. its value is gradually reduced to zero over the course of that time. Fair enough, you say (even though you couldn’t care less what your chair will be worth in four years’ time — surely by that time you’ll be the next Google or Facebook, and you’ll have other things to worry about than chairs).

The resulting graph now looks like this:

Graph representation of accounts

Note how I have represented the transactions:

  • I have lumped together your founder investment with that of Y Combinator, under the heading of “capital”. Put simply, this is money you got into the company by selling your company’s shares, rather than by selling a product or service to a customer. As usual, you can split founders and YC into separate accounts if you feel like it.

  • I’ve represented payroll (salaries) as just money straight out of the bank account. In reality it’s a bit more complicated due to taxes, healthcare, benefits, etc. but the principles stay the same. It’s just more nodes and edges in the graph.

  • I made depreciation for one year (one quarter of $500 = $125) go away from the “furniture” account. Intuitively, this means that the balance of the “furniture” account is the value that your furniture still has now. Each year, you add another $125 edge from “furniture” to “depreciation”, until after four years, the balance of “furniture” drops to zero (assuming you haven’t bought any more chairs in the meantime, in your quest for world domination).

The profit and loss statement

At this point, if you’re getting weary, I don’t blame you. But the good news: we’ve finished building our graph! Now I will show you how this graph representation maps to two standard financial statements most commonly used in managing a company: the profit and loss statement (“P&L”), and the balance sheet. This is useful, because as a startup founder you’ll sooner or later have to discuss these documents with your investors/advisors, and so you might as well learn what the hell they mean.

In order to produce these statements, I need to get out the crayons. Here is the same graph as before, with the nodes coloured in:

Graph representation of accounts

Explaining the colours (putting the accounting terminology in brackets, since you’re likely to encounter these words):

  • Green for stuff that you have (“assets”), e.g. money in the bank, or things which you bought and you could sell again, such as furniture. Also green for people/companies who owe you money (“debtors”, such as Customer 2), and people/companies to whom you owe money (“liabilities”/”creditors”, such as your upcoming credit card bill for that burrito).
  • Blue for sales of your product/service (“revenue”) and money you spent that you’re not going to get back (“expenses”/”overheads”). The office chair is green, because you could sell it again if you wanted to, but the bagel is blue, because once you’ve bought (and eaten) the bagel, that’s it – no going back.
  • Pink for money from investors (or yourself) that you got by selling shares (“capital”). (If you get a bank loan, that’s green, not pink, because you owe the bank to pay it back.)

Every one of your nodes should fall into exactly one of these categories. If not, something has gone wrong, or you have discovered some bit of the accounting world that I don’t yet know about.

With these colours set, the profit and loss statement is simply a list of all the blue nodes, and the profit or loss of the company is the sum of all of the blue nodes’ balances. The way we’ve calculated things, a negative value is a profit, and a positive value is a loss. That’s confusing, so you typically flip the sign when reporting the number (so that a profit is positive).

Written in the standard way, our P&L looks like this:

Revenue Sales $10,000
Total revenue $10,000
Expenses Payroll $8,000
Depreciation $125
Food $13
Total expenses $8,138
Total Profit/Loss $1,862 (= total revenue - total expenses)

The meaning is fairly intuitive. You sold $10,000 worth of stuff, and spent only $8,138 in the process, so you made $1,862 profit.

The profit and loss statement is calculated over a period of time (usually a month, a quarter or a year), and it’s often interesting to compare two different periods. To calculate it for a period, filter your transactions to only include those which occurred within that period, and add up the account balances for just those transactions.

One thing to watch out for: profit doesn’t say anything about your bank account. The bank account is a green node, but we’re only looking at blue nodes here. In this example, you ended up with $23,995 in the bank, even though investors put in $25,000: you made a profit, yet still have less money in the bank than you did before, because Customer 2 hasn’t yet fully paid. That’s why it’s possible for a company to be profitable but still run out of money!

The Balance Sheet

The balance sheet is a bit less intuitive than the P&L, but it’s quite a powerful document. It summarises what the company currently has and doesn’t have, and why.

Remember what I said earlier about partitioning the nodes into two disjoint sets, and their summed balances adding to zero? That’s exactly what happens on the balance sheet. We take all of the nodes in the graph; on the one side we consider all of the green nodes, and on the other side all the blue and pink nodes. The sum of all of the blue and pink nodes’ balances is minus the sum of all of the green nodes’ balances.

Now, by convention, accountants flip the sign on all of the blue and pink nodes’ balances, which means that the two sums end up being equal. And that’s why it’s called a balance sheet.

In our example, it looks like this:

Assets Bank account $23,995
Debtors $2,500
Furniture $375
Total assets $26,870
Liabilities Credit card $8
Total liabilities $8
Total assets less total liabilities $26,862
Equity Profit/Loss $1,862
Capital $25,000
Total equity $26,862

The top block (assets and liabilities) corresponds to the green nodes in the graph, whilst the bottom block contains the pink node (capital) and the sum of all of the blue nodes. We already showed all of the detail for the blue nodes on the Profit and Loss statement above; on the balance sheet we can sum them all up to a single number.

Some more sign-flipping has occurred here: I’ve written liabilities, equity and P&L with their signs flipped (which usually, but not always, has the effect of making the numbers positive). That doesn’t change anything fundamental about the graph structure, it just puts things into the conventional schema.

So how can you interpret the balance sheet? There are various things you can read from it. You can see how much money is in the bank, and how much of that money has already been promised to other people (liabilities). You can see how much of the money in the bank came from investors, vs. how much came from sales. And it shows how much money is due to come in soon, from sales that have closed but haven’t yet been fully paid.

The total of the balance sheet is a lower bound on the value of your company. It’s a very pessimistic figure — it assumes that your team, your technology, your brand etc. are all worth precisely nothing; if your company raises money from investors, your valuation will be much higher than the balance sheet figure, since that valuation includes the value of team, technology, brand etc in the form of a wild guess. In established companies you can find “intangible assets” on the balance sheet, but since they are very hard to value, I suspect it’s not worth bothering with unless you know what you are doing.

That’s the end of our whirlwind tour through the world of accounting. If you’re a real accountant reading this, please forgive my simplifications; if you spot any mistakes, please let me know. For everyone else, I hope this has been useful. To find out when I write something new, please follow me on Twitter or put your email address in this box:

I won't give your address to anyone else, won't send you any spam, and you can unsubscribe at any time.

Having a launched product is hard

Over the last 6 months, we have been learning what it means to support a launched product.

Some background: Rapportive launched in March 2010, and we joined Y Combinator for the Summer 2010 batch from June to August. Even though it was fantastic to have users and solid growth, it was actually a very frustrating time for us as a team.

We found the downside of having launched, namely that we ended up spending the entire 3 months of Y Combinator (and probably another month either side) doing the following:

  • Answering many, many support emails and tweets
  • Raising our seed round
  • Stopping our infrastructure from collapsing under our user growth
  • Responding to press and bloggers
  • Reading resumés and interviewing job candidates
  • Fixing gnarly bugs in production
  • Applying for visas, so that we could work in the US
  • Attending YC dinners and office hours

By contrast, the ideal world of Y Combinator involves spending 3 months:

  • Moving your product forward
  • Attending YC dinners and office hours

Although all the things we were doing were valuable — even spending so much time on support is valuable, because we learnt a lot about our users, and we turned lots of people from angry strangers into enthusiastic supporters — it was incredibly frustrating. Our product development was almost stalled for months on end. And all the while, our YC batchmates were demoing new features every week, and getting a massive high from the productive flow of developing their products at a rapid pace.

So I am perhaps a bit envious of those who could move ahead rapidly and build their product without having to worry about supporting users or keeping their database alive. On the other hand, I am of course hugely grateful for our users who use and love our product every day. I wouldn’t have it any other way.

Photo of whiteboard at YC, showing curve of The Process

Fortunately, we are not the first to experience this. At the YC office there is a whiteboard, now carrying somewhat iconic status, which reminds every single YC founder of “The Process”: once a startup has launched, the novelty will wear off, and the team will find itself in the “Trough of Sorrow”. We know what the Trough of Sorrow looks like. I have just described it. It’s not very much fun.

But here is good news: Rapportive now seems to have journeyed on to the next phase, we have made “Releases of Improvement”, and things are looking hopeful. Are we in those “Wiggles of False Hope”? Who knows. But hey, the money is in the bank, the visas are in our passports, the infrastructure has got a lot more robust, and most importantly, our product development is moving again. We have some really cool stuff coming soon. The hope is real. And we seem to have managed to avoid the “Crash of Ineptitude”.

So what have we learnt?

  • Visibly iterating and improving the product is arguably the most important thing a startup should be doing, but sadly, other stuff has an uncanny ability to distract you away from product work. Paul Graham has written about money matters and disputes being particularly bad in this regard. That is true, and I would add server firefighting, recruitment and immigration to the list.

  • In order to get back into a flow of product development, we are now deliberately shunning distractions like recruitment and fundraising. We obviously can’t ignore these things forever, but for now it’s best for the business if we stay focussed on the thing we do best: making a product that people want. (We’re keeping one distraction, namely support, because it is so important. But we are rotating support duties so that most of the team can ignore it at any given moment.)

  • Be grateful if you carry a US passport.

  • Sometimes you just have to wade through a patch of mud, and there’s no way round it. But as long as you keep your eyes forward and keep moving, you’ll get through it, and things will brighten up.

Poster: We have a strategic plan. It's called doing things.

Intuition has no transfer encoding

Intuition is really annoying sometimes.

Actually, I love intuition, because almost all my thinking is based on it. I don’t think I am very good at analysing and thinking things through logically. Often I just have a feeling about how something should be, and then sometimes I post-rationalise it.

Not everybody’s mind works this way; if yours works like this too, you will think this is completely obvious. If not, you probably know people of this type, who can just assert “I think we should do it this way” and turn out to be right in maybe 75% of cases. Intuition is never perfect, but I love it, because it often gives a “good enough” answer very quickly, or at least provides some pointers towards places where it would be worth spending a bit more time analysing.

The thing that I find so annoying about intuition is that it is very hard to communicate. Let me explain.

Intuition is built from a large number of experiences: you grow up, you go through life, you meet people, you go to places, you read stuff, you make up stuff. There is no chance you can remember all the things you ever experience in factual detail, because that would be an overwhelmingly huge amount of information. But those things are nevertheless not forgotten: each experience leaves a trace, a tiny shadow of memory, so your thinking afterwards is ever so slightly different from the way it was before.

Over the course of years, those tiny traces are aggregated, and what you get out at the end is an intuitive understanding of how the world works (or rather, how those parts of the world which you have experienced work). Think of it like very light crayon touches, in the hands of an artist, gradually forming to be a beautiful picture — except that the picture is never complete, and always evolving.

With that intuition, when you encounter a new situation, it doesn’t matter that you haven’t encountered the exact same situation before: your brain does an approximate matching of the new situation with your mental model of the world, and immediately predicts the right answer. It doesn’t even need to search through memories, because the picture of the world in your head is already the fully aggregated sum of your experiences.

(As a second step, you will typically compare your gut reaction to specific memories, to check whether the results agree. But that’s another topic.)

A tale of bitmaps and vector graphics

The way I imagine the brain stores intuition is a bit like a huge bitmap image, with lots and lots of pixels [1]. When a new piece of information comes in, the brain’s massively parallel processing structure takes the new information, combines it with the existing image, correlates, interpolates, extrapolates, and produces an answer in an instant.

But what if you want to teach your intuition to someone else? You can’t tell that person all the things you ever experienced in your life, because that would be far too much, and you’ve forgotten and assimilated most of those memories anyway. But that mental bitmap is also a terrible transfer format: our mouths and hands are extremely slow communication channels, making it impossible to get the bitmap out of your brain. Imagine reading out the individual pixel values of a bitmap image over the phone. It would take hours before the other person had even the vaguest, blurriest idea of the outlines of the image. And it would take years to fill in the detail.

So… if you want to transfer that bitmap out of your brain and into someone else’s, even approximately, you have to turn that bitmap into a vector graphic.

In vector graphics, if you choose your points and curves carefully, you can communicate the general structure of a picture very succinctly. You can enable the other person to very quickly get a rough idea of your thinking. Of course it won’t have all the colourful detail until you add lots more information, but that’s ok. And once you have analysed your picture into a vector form, you have actually gained a better understanding of what it is really about, you can zoom in to see a higher resolution, and you may be able to spot patterns that you weren’t previously aware of.

Of course, the problem: turning bitmaps into vector graphics is hard. Computer Vision researchers are always thinking about better algorithms for doing it.

And to return from our image analogy to the topic of intuition: expressing intuitive knowledge in a structured form is really hard.

Vectorising intuition

As a child, when you learn your first language by imitating sounds and by being continually corrected by your parents, you are building an intuition for the way that language works. You start off with ga ga ga, and it takes years before you can speak a coherent sentence; later, as time goes on and you grow up, you get quite good at it. Because your brain stores a pre-rendered representation of the language, you can speak and understand it easily and quickly.

When an adult learns a foreign language, by contrast, the usual way of learning it is by studying grammar, vocabulary and carefully chosen texts. The rules of grammar and the structure of the syllabus are a kind of vector representation of the language, optimised for giving the learner a rough overview of the language structure and helping them construct useful sentences as quickly as possible.

It is perfectly possible for an adult to go to a foreign country with no prior knowledge of the language, and to learn to speak it without formal grammar or syllabus, in the same way as a child does. However, most adults prefer to learn a language in a systematic manner, presumably because learning in “vectorised” form allows you to be much faster in getting to the stage where you can have an interesting conversation.

No matter which way you learn the basics, it always takes years to reach native proficiency in a language; that is unavoidable, because in the end you can’t get around learning a huge amount of subtle details and building your own intuition. (Even if represented in vector form, complicated curves and shadings require a large number of points.) The difference is in the time it takes to grok the core concepts.

But here comes the important bit. When it comes to learning languages, most languages have benefitted from decades (if not centuries) of research and systematisation efforts by many intelligent people. For most languages, grammar and learning techniques are very well understood. But what if you want to communicate some intuition that only you have? Well, you have to do the vectorising yourself.

When you have built an intuition in a specific area that is not well-known — say, with regard to some arcane or new technology, or with regard to your company’s business strategy — then there is no existing grammar you can refer to. You are like a linguist, going into the Amazonian Jungle to document mysterious languages not yet known to the outside world. You have to observe the systematic parts and the exceptions, and formulate the grammar yourself.

Turning your intuitive bitmap into a vector form that you can communicate… is hard. Very hard. But you need to figure it out.

Why is this important?

Well, there’s only so far that a single person’s intuition can reach. If you want to build great things and change the world, you need much more than a single person’s brain can hold. You need both depth and breadth: fine-grained intuition in specific technical fields requiring expertise, and also a greater variety of perspectives than a single person can have experienced.

You need to combine the intuitions of several people, i.e. you have to form a team. And in order to combine your intuitions, you need to communicate and explain them. Why? Because otherwise you have no way of resolving differences, and no way of learning from each other and improving.

By default, intuition comes without a reason attached: you ‘simply know’ that the answer is X, but you don’t know why. The problem arises when your colleague ‘simply knows’ that the answer is Y, where X≠Y, and doesn’t know a reason either. (Maybe X and Y are not completely contradictory, but rather partially overlapping ideas or differences in emphasis. Different nevertheless.) At that point either one has to overrule the other (which would defeat the goal of forming a team in the first place), or you have to rationalise the intuition, untangle the pre-aggregated reasoning, and communicate it in terms which the other person can understand.

What if you could understand the structure of both X and Y, and the reasoning behind it, and thus manage to synthesise the two? That is a lot of effort, but I am increasingly thinking that figuring out how to communicate your intuition is one of the most valuable things you can do in a team. For if you can combine your mental image of the world with other people’s, you can build something much greater than each of you. Your thoughts can be superhuman, in some sense. And that, if you can figure it out, is a huge advantage you can have.

A startup is a really interesting environment to try this kind of thing, because you can be as choosy as you want about the people you work with. You can pick like-minded people, and together work towards that shared intuition. You can build a good, well-founded, shared intuition of who your customers are and what they want. And if you can attain that shared intuition, you’re well underway to success.

Footnote:

[1] I’m not sure what each individual pixel represents. In mathematical terms, a picture is a function mapping from 2D space to colour, and a bitmap approximates this function by sampling at regularly spaced values of the input. Along that line of thinking, the mind is probably a function mapping from sensory inputs and memories to explanations and actions (or something along those lines — I’m not a neuroscientist). This function can be represented as lots of individual data points (“London & lunchtime & hunger & last had Falafel 10 days ago → go to the King of Falafel”), which is bitmap-like, or in some systematic manner (“I like to eat falafel for lunch. For example, in London, the King of Falafel is good.”), which is vector-like, omitting redundant information (lunchtime and hunger are strongly correlated, so mentioning both is fairly redundant) and emphasising structure or dependencies (the King of Falafel only exists in London). However, as you can see, his only vaguely makes sense. The bitmap/vector analogy is itself an example of a piece of intuition that I’m trying to communicate to you right now.