MattJackRob

Below is an email I sent to an early stage startup asking for my thoughts on investment; specifically, should they raise money, and if so, how much; I thought it might be interesting for others so I’m sharing it here:

Hi X,

No probs. The key to any successful business is having a great product. Great products beget users & investment, not the other way round.

Raising investment is the biggest possible distraction to starting/running a business. Unless you’ve got real traction i.e., impressive growth numbers (50%+ month-on-month) then I wouldn’t try to raise money: A) It will be really hard, and probably end up being a waste of time; B) You don’t yet know if it’s worth you committing the next 18 months of your life to the project.

If/when you raise money you should raise enough for 18 months runway. No-one worth taking money from will give you more, and given you’ll have to start raising 3-6 months before your money is due to run out, raising less means you’ll be back raising again in 6 months which is not recommended.

I hope that helps. Best of luck!

Matt

I think that one of the best things we’ve done as a startup is to take a “Valley” approach. From the start we’ve tried to adopt the best practices (sorry to slip back into consultese) from the startup world: Lean Startup Methodology, Agile Development, Customer Development. Sound familiar?

I hope so, because they all make a huge amount of sense. The only problem is that in that last paragraph, “tried”, is the operative word. We knew we should be building our MVP; that we should be iterating quickly; that we should be metric driven; and that we should implement customer development. Eric Ries told us so. So did Steve Blank. And they made it sound so obvious. Which it is. But they also made it sound so easy. Which it really isn’t.

We failed miserably to build our MVP (see “Why you should not be building a Minimum First Version”), we’re still not as metric driven as we’d like to be (I talk about testing for things in “Fail fast, learn quick” that I arguably still don’t know the answer to), and our efforts at customer development have been arrested at best.

And that brings me to the nub of this post: it’s all very well reading about all of these brilliant methodologies, but it’s something else entirely to implement them. And you know what? That’s alright.

The point of knowing this stuff is not to stop you from making mistakes in the first place. You have to make your own mistakes. The point is that it’s only by exposing yourself to the smartest people and the best practices that you’ll realise they’re mistakes.

So go for it, “Roll the dice”, and see what happens.

Tech startups have inherent iterative potential: you can be one thing one day (say a Group payments company), and something completely different the next (for example an alternative Payments network). A school of thought has sprung up around this called Lean Startup Methodology. One of the key principles is that you should focus on building a Minimum Viable Product. The main reason is so that you don’t spend too long building out the first version before you realise you should be building something completely different.

This has become pretty widely accepted and almost every early-stage startup I speak to tells me that they’re focused on building their MVP. However, a trend that’s started to emerge is that what many of these guys think is their MVP is actually a Minimum First Version. On first thought it might seem like a piece of sophistry to try and distinguish between the two but I think there’s an important nuance.

As soon as you start thinking about Minimum First Version you start thinking about your Final Version, and therefore what a stripped down version of that might look like. That is often radically different to your MVP.

To give an example we started out in the Group Payments space. We wanted to build a tool that would make it easy for people to collect money from lots of people. The end product at its core would be a site where they could set-up groups, issue bills and reminders, and see a summary of information. We couldn’t handle payments ourselves yet, so we thought our MVP/Minimum First Version (we treated them synonymously) would be an ugly version of that which used the PayPal API, and had only this core functionality. To be fair, we built it in three weeks. But because it was still quite a substantial product we then had to iterate and improve the product over a number of months to get everything to work as it was supposed to, to get a fair reflection of what users thought of it.

We learnt that there was a kernel of the product people found really useful, and that larger groups and businesses found it really useful, but did we really have to spend 4 or 5 months finding that out?

No. Last week we realized what our MVP was and built it in a day: a bit.ly type link generator for payments: you say how much you want and what for, and we generate a link. I then thought back to the original list of people we were trying to help and it would have solved the core problem for all of them.

That was our Minimum Viable Product. We should have built it in a couple of days, shipped it, and then focused all our resources on getting people to use it and seeing what worked and what didn’t. Instead we had a much more complicated product, which needed months of work to get the various bits to work, before we could have those same conversations properly, and learn exactly the same thing.

Now when I think of the number of startups I know who have spent upwards of a year just to build their first product, I really worry if they’ll ever even find out what that kernel is for them, and even if they do, if they’ll have the time to iterate on that sufficiently to get to product-market fit.

So here’s my question to you: Are you building a Minimum Viable Product or a Minimum First Version? Or, more concretely, what’s the equivalent of our link generator for your business?

If you’re going to fail, which as a first-time (or for that matter, any amount of times) entrepreneur, you will in many ways and many times, then fail fast. You only get so long as a start-up until the money runs out or your personal circumstances change, and realistically have time for 2 failed “traditional” businesses in your lifetime. If you can test your assumptions quicker by getting an MVP out there or testing demand in some way, you can reduce the time it takes to know whether you’re on to something and increase the number of chances you will get to more like 4-6.

In order to be able to fail a test, you need to know what you’re testing for. To that end, you should always know what the 1 or 2 key hypotheses you’re testing are and have some way of tracking them. Generally the first 5 will be something like: Target users have X problem; Target users want problem X solved; My solution helps solve X for these users; I can distribute to/find users through Y channel; Users will pay ¬£Z for it. Once you’ve established what these are, you can quickly devise ways to test to see if they are true, and if they’re not, work out if fails can be turned into passes, or if one represents an insurmountable obstacle to your businesses success.

The tests above are all just the baby steps that you need to make on the path to getting traction e.g., if there’s no one who has the problem, or there is but they don’t want it solved, no-one’s going to want your solution, and you don’t have a business. By splitting them out into discrete steps you can test for them in turn much more quickly than by bringing something all the way to market and finding that no-one wants it.

In the early stages, except in rare circumstances, getting traction is all you should really be worrying about. You shouldn’t be thinking about writing a business plan or raising funding, and should just be relentlessly focusing on getting traction, as everything follows from that. Trying to get a co-founder to join/raise money/get a customer with some sort of product and some level of traction, for instance, is a whole different ball game to walking in there cold with a business plan and a pocket full of dreams.

Don’t bother making a business plan until someone who matters asks you for one (NB. Most people that do, won’t). When you first have the idea, it’s worth writing a short 1 or 2 page executive summary, just to help you flesh out the concept but beyond that you’re wasting your time. A short exec summ will be much more effective for sharing your idea with people (which again, except in very limited circumstances, you should do at every opportunity) than a business plan, and will also take a lot less time to make, allowing you to focus on what really matters; building something and finding out if people want it.

In summary, your business is going to fail or succeed based on whether you can build a product (or develop a service) and find people who want it. And the crucial thing for me is that, if you can find out that you’re idea sucked in just 3 months as opposed to 2 years, you’ve got another 21 months to work out how to make it not suck, or come up with a better idea. So build something, and get it in front of users asap. I guess the central tenet underpinning all of this is that, ultimately, whoever you are, first-time entrepreneur or serial founder of successful start-ups, you’re going to fail at a whole host of things on the way to success with any new business, so at every stage you should do whatever you can to fail fast and learn quick.

P.S. Seeing as much of this is focused on what to do when you’re starting out, I wanted to give you a random tip that I wish someone had given me (or that I’d listened): whatever you do, don’t mess around with names. You still will. Whatever, at least listen to me on this: pick a domain name for which you can get the .com as messing around negotiating with domain squatters 6 months down the line or face changing your name and brand sucks. Also, if you can, try to use a real word(s) or something as short as possible; endlessly having to spell your name for people and losing traffic because people still can’t spell it also suck. Believe me on this one, no matter how clearly you enunciate, no-one’s going to know whether you’re the founder of Groupay, Group-A, or GroupPay.

I spoke before about the fact that I wouldn’t recommend doing this alone. So who should you do it with? Well it’s pretty obvious it needs to be someone you get on really well with – you’re probably going to end up seeing more of each other than you will your girlfriends or families (if not you’re probably not working hard enough).

Equally important though, in my opinion, is that you are equal partners. It’s not nice to feel like you’re carrying someone else, and I suspect it’s even worse to feel like you’re being carried. I actually think that the ideal working relationship is one where at least a little bit of each of you worries that the other person might just be better than you. That way you work your arse off to make sure that they don’t realise it.

Since I’ve started, I have learnt an absolutely unbelievable amount and would say I’m radically better at this than when I started (admittedly it’s all relative). As a result I completely understand why investors prefer to invest in second time entrepreneurs and I would say the same thing about partners. If you can find someone who’s done this before it will be hugely beneficial.

The main problem that many start-up founders have is that they are too similar, if you’re a biz dev guy, you probably hang around with biz dev guys, and vice versa for devs. The problem is that a tech start-up needs to have some combination of Development, Design and Distribution capabilities. So as a biz dev guy, how do you find a developer to join you if you don’t already know one? Just invert the roles if you’re a developer looking for a biz dev guy.

I subscribe to the Gladwell school of thought that it takes being good at something yourself to recognise that talent in others. Therefore when you’re looking for technical co-founders, if you’re not technical yourself, it doesn’t make a great deal of sense looking for a great dev guy as you won’t have a clue. Instead look for a dev with qualities you can recognise yourself e.g., business smarts, determination and a track record of following through with things. I’m also a great believer that talent attracts talent so the corollary of Gladwell’s theory is that only by finding people who share some of, and hence recognise, your talents, will you find someone willing to join you.

A second corollary is that once you know one guy who is great at something, the best way to find a second person great at it, is to ask the first. E.g., If you want to find a great dev guy, ask the best dev guy you know, who the best dev guy they know is, and then ask them, until you find someone available and interested.

If you don’t already know someone who you definitely want to work with then it’s not going to happen overnight. Unless you want to stall, it’s worth realising that you’ve only really got three options: outsource what you can’t do, learn to do it yourself or find something else you can do. If it’s at all core to your businesses value add then it’s going to have to be the second or the third.

OK, so this all sounds great in theory (I hope) but what should you practically do. If I was looking for a new technical co-founder tomorrow I would:

1) Reach out to every tech guy I know and respect, and ask them to intro me to any tech guys they know and respect.

2) I would reach out to all of these guys and try to meet up with them for a drink. I would aim to find a couple who I a) get on with; b) share some other talents that I can recognise e.g., how smart they are, how they think about business.

3) I would keep meeting up with anyone I was getting on with and start tossing around ideas until I was convinced that they were good and I liked them. I wouldn’t worry if they were available or not, as if they think you’re good enough they soon will be.

4) I would suggest we work on something small together within really clearly defined parameters e.g., Let’s work on X for 1 month and build out an MVP of Y. Unless it’s an idea that you’re really attached to I wouldn’t bother writing the agreement down (if you feel like you need to then you should probably keep looking) but I would agree what you’re each going to do, how much we will each contribute and who will get what at the end assuming we don’t continue.