I didn’t like Svbtle after all.
From now on, I’m going to continue blogging at http://writing.londonstartuptech.com/
You can follow me there.
I didn’t like Svbtle after all.
From now on, I’m going to continue blogging at http://writing.londonstartuptech.com/
You can follow me there.
The previous post in this series was about changing your thinking from a project mindset of making something that people like, to a business mindset of making a sustainable product with paying customers. This post is about working out who your customer should be.
One of the most pressing problems for any startup is making that first sale. You need a product to be able to sell something but, as I said in the last post, you don’t know what to build until you know who you’re building it for. Without customers, this looks like a vicious cycle — where do you begin when the customers are needed before you can make the product, and the product is needed in order to draw in customers?
The answer is to start with a hypothesis for both, a best guess of who your customer is and what the product they need looks like. The next post in this series is about developing products.
Once you have a hypothesis about the customer and product, you can cycle between improving your hypothesis of the product and improving your hypothesis of the customer. Only part of this process is actually recruiting the customers and actually building the product.
You read that right. More important than building the product and recruiting customers is refining your understanding of the customers and what they need from the product. The latter is how you set yourself up for long-term success.
Let’s say that we want to start a dog-sitting service. Perhaps you love dogs but don’t have one yourself and you think there’s a gap in the market for looking after other people’s dogs. Customers pay you to turn up at their house and take care of their dog when they’re unable.
Disclaimer: I’ve never owned a dog and am not much of a pet person. If this idea sounds mean to dogs, then I apologise. If you think it sounds like a ridiculous business that would never work, then you should Google for “dog sitting service” and be surprised, like I just was.
Customer hypothesis 1: My customers are any dog-owners who want to be able to send someone to care for their dog when they’re busy.
Customer hypothesis 2: My customers are middle-aged commuters with desk jobs who live near me. They constantly feel busy and love their dogs, who are always waiting for them when they get home. On nights when they have to work late, they feel very guilty about leaving the dog on his own and waiting to be fed. Existing dog-sitting services are frustrating because they will look after the dog over holidays, but won’t come to the house for an evening. They’d love a way of sending someone to care for their dogs while he can stay working at the office until 10pm.
Which is the better customer hypothesis for a startup to have?
For most people, they assume it’s number 1. It’s less specific, so there are way more potential customers, and more potential customers has to be a good thing, right? It’s also less detailed, so there’s less chance of it being wrong.
These are all terrible reasons. More potential customers makes it much harder to know where to direct your efforts at the early stage when you’re still trying to get your product going. And a hypothesis that can’t be wrong is totally pointless! The hypothesis is only useful if you can test it and find out if it’s true or not, so you can test whether you really do understand your customer.
Hypothesis 2 gives you a much clearer image of who the customer is and what their problem is that you’re solving. It’s a much stronger starting position, as it gives you a statement that can be proved or disproved. Moreover, it lets you empathise with the customer, and that’s critical to being able to solve their problems.
The reality is that most companies will start out with a slightly vaguer customer hypothesis than hypothesis 2 (“The customer is a dog-owner in my city who wants someone to look after the dog when they work late in the evenings”), but only really established companies can afford to have broad hypotheses like hypothesis 1 (“The customer is a dog-owner who wants someone to look after their dog”) because it takes a lot of resources and a strong brand to target a broad set of customers.
Once you have your customer hypothesis as a starting point, you can start improving and refining your ideas. The best way to do this is to talk to customers and to change your hypothesis to reflect what you learn. I’ve written before about creative ways to find customers. Here I’m going to talk about the right way and the wrong ways to talk to customers. There are two simple golden rules to bear in mind here.
Golden rule 1: Ask about problems don’t tell about solutions. When you’re still at an early stage, you’ll be tempted to go to prospective customers and tell them all about what you’re creating. That’s OK later on, when you have a firmer grasp on your product hypothesis, because you already understand who your customer is. But it’s a bad idea in the early days, because you’ll end up pushing the conversation towards your current hypothesis, rather than hearing how the customer describes the problem without prompting. This could be illuminating: customers will surprise you with the problems they find, the solutions they’ve tried, and the insights they have into what’s wrong with everything else on the market. Knowing these things is a big advantage in working out your customer hypothesis.
Bad: “How would you feel about a dog-sitting service that operates on evenings and weekends? You phone up to say you’re in urgent need of a sitter and we send someone round to feed your dog, walk them and stay in the house until you get home.”
Good: “What happens with your dog when you’re late home? Have you already tried any ways of fixing that problem?”
Golden rule 2: Ask for preorders not feedback. Feedback is quite vague. Kind people will respond with praise, cynical people will respond with criticism, creative people will respond with ideas for new features, most people will respond with a mixture of all three. But these don’t help you unless you can convert the feedback into a paying customer. The most valuable feedback you can receive is an answer to the questions “Can I take a preorder?”, “Why not?” and “When I’ve done that, can I come back and take a preorder?” The reason these are so valuable is because they immediately tell the other person to think about their own opinions rather than those of another hypothetical person who they think is user. And they bring the other person’s brain straight to the issue of money and value: is this product valuable enough that you’d pay for it? Getting closer to a ‘yes’ is the goal of improving your product and customer hypotheses.
For long-term success, it’s more important to understand who your customer is and what product they want than to recruit customers or build a product. This starts with a customer hypothesis and a product hypothesis. The best ways to improve your customer hypothesis are to to meet with potential customers and to find out as much as you can about their problems before telling them about your product. The strongest kind of feedback you can get is whether a customer will preorder your product, rather than simply expressing an opinion about it.
Thanks to Tom Carver for reviewing a draft of this post.
This is the first in a four-part series I’m writing on starting a company. Today’s post is about how you start turning a project into a business. The next article in this series is about how to identify your customer.
The main difference between a project and a business is that a business’s aim is to make money and a project’s aim is anything else. This has a profound impact on the idea of perfection. Perfection in a project normally means satisfying your own opinions but perfection in a business means the qualities that make your product valuable to customers. Businesses must always be trying to sell to customers in order to understand what is valuable to them, so they know what kind of perfection they should be striving for.
I remember talking to a friend of a friend about startup companies at a social occasion last year. This was an intelligent 25-ish man enrolled in a PhD programme and he told me (paraphrased): “actually, I have an online business too. In the early days of Google App Engine and before Google Drive, I made an app that lets people collaborate on a single document in real-time.”
Me: “Nice! How’s it doing?”
Him: “Great, really successful. It’s got over 10,000 users.”
Me: “Wow. So how did you make money from it?”
Him: “It wasn’t really that kind of idea, I made it free. It hasn’t cost me anything so far.”
This is a project not a business. Not just because it’s not making money, but because making money isn’t the objective (the focus in this example is on getting lots of unpaying users). Making money from your users is great for them: it funds improvements in the project which, particularly in web and smartphone apps, benefits the people who paid you in the first place.
But, as he says, it hasn’t cost him anything so why should he expect to make any money from it? I disagree with the premise here: it has cost him. It’s cost him however much time he spent making the app, testing it, improving it, sorting out the hosting, telling anyone about it, seeing how many people were using it, etc. Unless his time is utterly valueless, he’s lost a lot. That was all time that could have been spent doing literally ANYTHING else. That’s a lot to give up.
And if its really useful and valuable to any of the users, they would probably be happy to pay for it. Paying for something sets up an agreement that it will continue to exist, that problems will be fixed, that new features will be added. This is part of what people pay for when they decide to hand over their money.
That’s not to say that we should only ever do things that make money: I’m not suggesting anyone demands their friends pay them by the hour next time they go to a pub. But if you’re making something that you want other people to use, then you should try to make money from it. This will give you the incentive to keep improving what you’ve made (good for customers) and rewards you for what you’ve already put into it.
Projects don’t try to make money and businesses do. Your customers benefit from paying you.
What is perfection? Let’s say you have a web-app for sharing photos with your friends. Should you give it every possible feature? Cropping, filters, colour correction, resizing, zooming, security controls, comments on photos, ‘likes’ on photos? Or maybe it should be designed beautifully: a modern colour scheme, with flat design, beautiful typography, rounded corners, a retina-resolution logo, with animations and the fastest loading times possible.
In a project you’re mainly answering to yourself so you have the power to decide what’s important to you and then do it. If you think it needs a feature, you can create it. If you think it needs improved design, you can improve the design. But if you’ve decided that you’re doing a business, you have to answer to your users. Your opinion of the features, design, branding and marketing are all irrelevant; it’s what your users think that matters.
This is an important distinction. If a schoolchild creates something as a homework assignment, the teacher will probably give more marks for every extra feature, or every improvement in the design. The same mentality of making everything beautiful and creating every possible feature exists in projects.
With a business, all the time spent adding features that your users don’t want, or improving design that your users don’t appreciate, is wasted. You could have spent that same time on working on things that added value for your users. Remember that you can always trade your time to improve quality later, but once you’ve improved quality, you can’t trade that back for more time.
With a project, you make and design a solution then see whether other people like it. With a business, your priority is making things that are valuable to a user. As a result, the order is reversed: you should find people who have the problem your solution addresses, find out what your customers want from your solution, then make something that does that.
As Eric Ries puts it in The Lean Startup, “If we do not know who the customer is, we do not know what quality is.”
How do you know your project has been a success? Normally, because you are happy with it. Or maybe other people tell you its good. With a business, the dynamic is different: you are creating something sustainable, so it has to make money. As a result, the measure of success of your fledgling business is whether people will pay for what you’ve created.
This affects many aspects of how you improve your product. For example, when you ask a user to test a project, the critical question is “Do you like it?”, “Would you use it?” or “How would you score it from 1 to 10?” But if your aim is to create a business, the critical questions are “Will you buy it?” “How much would you pay?” and, my favourite, “Can I take a pre-order?”
If your users won’t buy, it’s important to find out why and to make sure you’re always working on things that increase value for them. Businesses should start with this in mind: projects start from things you’d like to do, businesses start from an idea that is valuable to someone and worth paying for.
This also affects how you measure your success. Think back to the 25-year-old PhD student who said his project had “over 10,000 users.” This sounds great for a project: lots of other people liked it. For a business, this is a vanity metric. It sounds impressive but the goal of a business is to make something valuable that people will pay for, and the metric of “number of users on the service” doesn’t tell us anything about that. The measure of success of a business doesn’t have to be the total amount of money made, but it should include money as a factor. Otherwise you’re measuring for a project.
A word of warning: some of the startup companies that you hear most about exist in a Silicon Valley bubble where they get explosive growth in the number of users, take some huge investment and then work on trying to make money from some of their users. These success stories are incredibly rare: the majority of companies that don’t try to earn money from their users don’t manage to find investment, don’t produce sustainable businesses and quietly fail without any media coverage. If you’re trying to develop a sustainable business, selling should be your focus from day one.
That’s all for now. Remember that, unlike projects, businesses aim to make money. That means only doing the work that your users are going to find valuable, so they can give you money, so that you can sustain your business and your innovation. The best way to do that is to make selling to customers your focus, and building the rest of the business around that.
Next in the series: identifying your customer.
Thanks to Tom Carver and Sam Jewell for reading drafts of this article.
Ruby on Rails is the most mature web framework that most new companies use for making their web-apps. While Rails decides a lot for you, there’s often a choice of which library or plugin to use to accomplish any given goal. After doing several varied Rails projects, these are the choices I always make to make my life easier. Your mileage may vary.
Use Carrierwave. You’ll see some people advocating for Paperclip or Attachment-Fu but I’ve tried all three and Carrierwave is easier to use. It works very well with storing on Amazon and makes it easy to do things like caching uploads on forms, generating expiring URLs and pre-processing uploaded images.
Use Devise. It’s very flexible, makes OpenID and automated emailing super-simple. It’ll also auto-generate views for you, so you don’t need to bother writing your own from scratch. I’ve never even thought to look for anything else, it’s that good.
Use CanCan. Once you get your head around its syntax, it’ll seem incredibly simple. One way in which it’s great is that it lets you write all of your permissions code in one place. It also includes helper functions for your controllers that’ll save you a lot of effort in getting / creating / updating objects.
If you’re on Rails 4, use Authority. It’s extremely flexible, and makes it very simple to put permissions in one file or in multiple files. Its syntax is very easy to read and it feels very natural once you’ve used it a couple of times.
Use Haml or Slim. The haml-rails gem will make any new views be generated in Haml rather than ERB. It makes most HTML much, much faster and more compact to write. Slim is nice too, so try that out, but don’t stick with ERB just because it’s the default. Trust me that you’ll be glad you changed.
Use Vanity. It has support for simple measurements, running experiments and split tests. Last time I checked, they didn’t support Rails 4, but it’s a very powerful little library, and will draw you pretty graphs too.
Use DelayedJob. Again, this library is very simple to use, and works well from pretty much any context in your code. The only hard thing about using it is working out how to make your users work with an asynchronous workflow.
I hope this list is useful to someone; these choices have become my default settings when approaching any new Rails project and knowing them would have saved me a lot of time when I was starting out.
Why your new business should get lots of users right now; some creative ways of getting them.
There are three types of people you need to consider when trying to sell your product: the User, the Customer and the Buyer.
In the case of a person who goes into a shop, decides they want a Twirl then buys it and eats it, these are all the same person. In the case of a big corporation that buys something new for their employees to use, these are probably three totally different people.
As an early-stage business, you should be starting with the user. Think about this from the points of view of the other personas: the Customer only wants to buy the product because they think it’ll be valuable to the User. And the Buyer only wants to buy the product because they think that the value it gives to the User will give a positive return on their investment. Whether you’re aiming at three-personas-in-one individuals or split-persona companies, start with the user and the customer and buyer will follow later.
To get as many users as possible, you need to put in some legwork and get creative. The following won’t apply to every business or product, so work out which ones apply to you and try them out.
Vary your approach and record the results. This is called split-testing; it gives you a way of optimising everything you do to give the results you want. The Obama campaign used split-testing to increase their sign-up rate by 41%. You don’t have to be running for president to split-test.
Get a big sign saying “Hi, I’m Hywel and if you ever <the problem your product solves> then you should definitely talk to me!”. Or even get it on a t-shirt. Wear this wherever you go and try to get every one who approaches you signed up. At the least, collect their contact details. This is even more effective if you…
Where do groups of your users gather? In cafes? The gym? On the train? On the high street? Go there. You can either let them approach you (see above), or if you’ve got the confidence, go up to them and ask if they can spare the time to try your product. If it’s valuable, then people just trying it will graduate into users, who then graduate into paying customers.
This might seem morally dubious but it works. If your site is looking a bit dead, you can fake the appearance of activity by creating virtual users that don’t exist and “seeding” the site with activity. Reddit and Paypal have both done this in the past. Users who pop by are more likely to become involved if the site has the appearance of an active community.
You might not read forums, click on links in unsolicited emails or use Twitter but some of your users almost certainly will. Find relevant forum threads and link to your product, email people who saying they’re having the problem that you solve, and tweet to users who might be interested. Don’t be shy about doing this: people who experience the problem that your product solves will be glad to see that you’re working on it.
Your family, your partner’s family, every Facebook friend you ever had and every Twitter follower are all prospective users. Contact them individually, explain why your product is great for them and get them on board.
Everyone wants the chance to win even if they’re not going to win much. Run a competition where users who sign up then advertise your product or do another desirable action get extra chances to win. Some prizes can even be free to you, e.g. featuring a winning user on your website.
Give your users something back if they help you spread the word. Connect.me let users jump the queue to activate their accounts if they tweeted a link to the site and accidentally gained 40,000 users in a week. Rewards can be less tangible than this though; products with game-like features can simply give a user extra ‘points’ for spreading the word.
A collection of technology pitfalls I’ve seen non-technical startup founders make, and how to avoid them.
Let’s kick things off with an easy one. If you want to start a company where users all sign up to use Service X but the technology for Service X isn’t going to be ready for 1 month, what do you do in the meantime?
Answer: get the users anyway. Getting users is hard for pretty much every startup in its early days, so don’t delay doing it. Keep a spreadsheet of email addresses, write down phone numbers of everyone you meet who expresses an interest in what you’re doing, post about what you’re doing in forums and get contact details from everyone who replies.
When your technology is ready to go, you have hundreds of accounts you can create from day one and avoid that standing-start empty-desert feel new sites sometimes have.
Just as a journey of a thousand miles begins with a single step and Rome wasn’t build in day, so your startup’s technology will never be finished. The danger here for non-technical co-founders is to view the technology side of your startup as a hurdle to be overcome, and postpone other activities until the technology is “finished”. The reality is that your technology is only ever “finished for now” but will need improving, updating and maintaining as you get more users or your users get more involved or your idea grows. Technology grows as your company does; don’t let the technology become an excuse for delaying (see above).
Remember that your technology can always be changed. It will never be finished, so don’t assume it will start off being perfect. In six months, your concept might have changed or you might have 100x as many users as now – so your technology just needs to be good enough, not perfect. It’s a waste of time and money to make something that works for millions of users when you only have 1 thousand today. I see a lot of startups worrying about whether they’ll be able to serve 1 million users before they’ve even got 1 thousand. Save your time, save your money: get the technology good enough for now and focus on getting to 1 thousand users before you think about getting to 1 million.
Some startup ideas are simply traps. By traps, I mean ideas that sound attractive or easy but are actually incredibly difficult to execute well.
Traps can be things that lots of people are starting right now. An example? Dating sites: there seems to be a new one every week because a lot of people think they see why existing dating sites are failing and they think they know how to fix it. Even if you build the perfect dating site (and, let’s face it, you probably haven’t), you now have the challenge of recruiting thousands of users away from all the other sites in what is already a saturated market. I suggest asking yourself where your idea came from: were you reading about another startup or talking to someone who uses an existing service? Or did you meet someone who has a problem which there just isn’t a solution for at the moment? You’re much more likely to succeed if you have access to a group of people whose problem isn’t being solved than if you’re trying to improve on flaws in existing solutions.
Dating sites are also a great example of another trap I call symbiotic markets. Symbiosis refers to living things that have evolved together and are dependent on each other for survival. Check out the Wikipedia page for some cool examples. Symbiotic markets refers to a business idea where you need two distinct groups of users to make a success of the site. E.g. eBay needs both buyers and sellers, dating sites for heterosexuals need both men and women. If eBay had no buyers, the sellers wouldn’t visit. And if the sellers don’t visit then the buyers won’t list. The danger of symbiotic markets is that you get yourself into a chicken-and-egg conundrum where it seems impossible to get one group of users without the other, and in the end neither comes. It takes double the effort to get enough users for your site to pass the tipping point in a service with symbiotic markets. If I was going to build a dating business, I’d focus on gay and lesbian people.
Trap number three: platforms. A platform is a service for other people to build on to make their own services. There are famous lucrative examples, like the Facebook’s platform for building Facebook-based apps, or even the Google and iPhone platforms. But platforms are really hard to get right. You can’t do a platform properly until you can anticipate every single facility that will be wanted by someone who builds on it. The famous platforms everyone has heard of started out by building a whole raft of apps for themselves before letting other companies try out the platform, to avoid this problem. Make several applications first THEN extract the platform from that and you stand a much better chance than if you try to build the platform first.
An obvious point but one that bears repeating. If you hire a CTO, you’re likely to be working closely with them for a long time. If you hire either a CTO or a consultant, they have the potential to either ruin your business or make it incredible.
Years ago, I joined my first startup as CTO. We were looking at changing the way clothes are recommended and bought in the fashion industry, and we had a sound business model. But it was a terrible idea for me to be their CTO; I’m not at all enthused about fashion and was very open with them about this. I should never have asked to join, and they should never have wanted to have me. I also made clear that I wanted to have nothing to do with running the business, I just wanted to be left in isolation to make their tech. This should have been another warning sign: be wary of separating the technology from any other part of the business. It’s vital for planning the business to know which parts of the technology are hard/expensive/slow, and which are easy/cheap/fast. Similarly, it’s vital for the technology side to be made with the future direction of the business in mind. The technology can always be changed but early decisions can make later changes easier or harder.
I left that startup after only a few months and take a much stronger role in the business side of startups I work with now. Last I heard, they’d secured investment and were in a London startup accelerator programme; hopefully they went on to find a CTO who was a better fit with what they were doing.
A good CTO / consultant will care about what you’re doing, and will tell you how the technology affects your business, help you plan and think of new directions and will help you make the best decisions. They’ll take half the work off your hands and help you get things done.
A bad tech-person will just do whatever you tell them, even when it’s not the right decision for the business. This will seem easier in the short term but will harm you in the long term when you’ve spent all your cash on technology you didn’t need and bad technology decisions come back to bite you.
Summary: git is better than what we had before but it’s not great. Download my pdf cheatsheet for free if you want a clear guide to using git that thinks the way you do.
Git is a modern, distributed version control system, replacing older, centralized systems like Subversion. It has emerged as the de facto answer to storing historical information about changes to files, at least among software developers.
Git is powerful and it’s a lot better than Subversion. But it’s not great. I think that statement is objectively true for three important usability reasons.
Good software helps the user to feel in control. Git doesn’t. Let’s look at a relatively simple command:
git add <files>
This is the command you use to tell git that you want to include certain files in the next batch of work you commit. Let’s look at the help-text description:
This command updates the index using the current content found in the working tree, to prepare the content staged for the next commit.
Do you fully understand what this is saying? I do, but then I’ve spent the last day writing a git cheatsheet. Using the term ‘commit’ is forgivable, as it’s totally standard in version control systems. But index? working tree? staged? These are all git-specific and go unexplained. I’ve been using git for two years and I finally learned what the index was last week, yet that understanding is required by the fifth word of the help-text for one of the most basic functions of git.
Good software lets you explore, make mistakes and undo them. Git doesn’t. Often, there is a way of undoing things, but it is so hidden and so arcane that you feel like you’re in the Da Vinci Code.
Let’s say you do an accidental git add to a file. How do you undo it? git add-undo <file>? git undo add <file>? Or maybe git undo undoes your last action? One nerd point to anyone who guessed at git reset HEAD <file>. Notice that this command doesn’t look like it has anything to do with git add or with undoing.
OK, now you’ve accidentally done git rm on a file, and it’s disappeared. How do you undo it? Pat yourself on the back if you think that git checkout <file> is an obvious solution. (Side-groan: this only counts as checking out the file if you think about how git works, not the mental model of the user).
Whoops, you’ve accidentally committed when you didn’t mean to. Git provides the very nice git commit –amend to add some other changes to the commit. But if you didn’t mean to commit at all, what do you do? 10 points from Gryffindor unless you said git reset –soft “HEAD^”. Again, notice that this command doesn’t obviously relate to the concepts of committing or undoing.
My absolute favourite example of unforgiving user interface is this: go type git checkout “HEAD^” in any git repository. This turns git into a headless chicken:
You are in ‘detached HEAD’ state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout.
If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b new_branch_name
Sorry, what? My HEAD is detached? And how do I undo that? Why have you detached my HEAD? And what does that mean? And how do I undo it? This output doesn’t help with any of those questions. If you see this, you might well want to do git checkout master to reattach your HEAD, but git doesn’t tell you that.
Good software hides the way it works so that the user can think about it in the most natural way. Git doesn’t. Let’s take git reset as our example.
If you know how git works, you’ll know that git reset is for changing where HEAD points to, and for optionally updating the index and working copy. Now forget that you know that, and think about the user’s model of what each form of git reset is for.
The last form of these is the only one that represents what you might think of as a reset, and all four are used in different situations: change what will be committed, change where your commit appears in the revision history, undo all your current changes.
To use these requires thinking in the terms of how git works internally rather than in terms of what you, the user, are doing and what you want to achieve.
An even worse example of this bad organisation is deleting a branch on a remote. Remember, to delete a local branch you do git branch -d <branch name>. So how do you delete a branch from a remote? I think the obvious way would be git branch -d <remote>/<branch name>. The actual command is git push <remote> :<branch name>. From the user’s point of view, push is a totally different operation to deleting a branch, but push is a better reflection of the internals of git, and that’s the point of view that wins out. Also, note how small a typo it would take to delete a branch (git push origin :master) instead of pushing a branch (git push origin master) .
Try my git cheatsheet. This is a single printable side of A4 that has all the key commands for using git day-to-day. This cheatsheet is unique because it is organised thematically, grouping the commands by the situation in which you’d need them. This makes it very easy to find the commands you need. Download the contextual git cheatsheet here.
Thanks to Tom Carver for pointing out the ‘git branch’ example, and to Tom Carver and Catharine Robertson for proofreading the Git Cheatsheet.