Starting a Company, Part 1: Turning a Project into a Business

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.

Project or Business?

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.

On Perfection

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.

Be paid not admired

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.

Developing a business

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.

Advertisements

Ruby on Rails: lessons learned

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.

Uploads

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.

User and Logins

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.

Permissions

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.

Templating

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.

Metrics

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.

Asynchronous Tasks

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.