[talkgold]

1. Build for someone specific

It’s very tempting to create a product for the widest audience. “Everyone can use our product, therefore if even a tiny proportion use it, we’ll be rich!” Beware the generalised product. If your product is not built for anyone in particular, it will not be good for anyone in particular. The worst possible market for a product is “small businesses on the web”.

On the other hand, if you build something that is directly useful for even just one real human being, chances are there will be others like that user and your product will have some success
.
2. Don’t be afraid of targeting a narrow niche

Niches have numerous advantages. There’s less competition in niches, which means that your marketing dollars will go further to get you new customers. It’ll be easier to target likely buyers since there are probably already channels (blogs, magazines, trade shows) targeting that niche, that you can make use of.

Niches also tend to be very badly served in today’s world. If you look into almost any niche you will find a plethora of awful products that are just begging to be replaced by something better suited. Being able to build great products cheaply is a fairly recent development, and most pre-existing businesses have had to make do with duct-taped, poorly conceived solutions that are begging to be replaced. The smaller the niche, the lower the bar to success.

3. Solve a real problem that costs money

As DHH pointed out, the way to realistic profitability is not through gathering an outrageous number of eyeballs, but through creating a product that people are willing to pay for. The easiest way to get someone to loosen their purse strings is to convince them that using your product will pay for itself.

This can be either by enabling them to do something new to earn money or by saving them time and effort (and hence money).

Evolution
How to build it

4. Test the market with a working prototype as soon as possible

To win in this game, you need to build a great product. The problem is, no one on your team can tell you what the best product is — only your users can do that. You need a vision to get started on a product, but that vision is critically flawed in ways that you can’t see. User feedback is the most powerful force to point out those flaws, and until you have users (whether free or paying), you cannot use that force.

For this reason, it is important that you release something, anything, as embryonic as it might be, to people who can start to use it and let you know what you’re doing wrong. Listen to your users — and, to do this, give them a chance to tell you.

5. Develop iteratively

Your product is ambitious. It will solve many great problems for your users. However, if your product never gets finished, it will solve nothing. Be ambitious in your dreams, but conservative if your immediate goals. Aim for the result of each iteration to be useful in and of itself, but keep each iteration as tiny as possible.

Developing something small does not mean giving up your dreams, only delaying them. Cut every feature and every part of a feature that you can cut, but keep it on a list to work on later. If there is any way you can do it later, do so. Often, features that you thought were essential turn out to be unimportant when you have more user feedback.

6. Get things right, and be decisive in correcting the wrongs

As your product takes off (if it does), you will have less and less time to make up for earlier mistakes. As users pile on, it will become more and more difficult to make big, drastic changes. However you make your bed, that’s how you’ll sleep. As much as possible, take hard decisions early rather than letting problems fester. Don’t delay necessary change just because you’re already committed into a different direction.

7. Don’t spend the time correcting until you know what you’re aiming for

At the same time, it’s easy to end up spending all your time refactoring the codebase every time a new feature is brought in. Refactorings must be done to maintain development speed and build a scalable, clean product. However, a refactoring effort should consist of two parts: 1) figuring out what to refactor to, 2) doing it. The first part can take weeks, the second part is often a mere few days long. The first part should never be an excuse to stop work completely.

This applies to design changes too. If you realise that you need to change the direction of the product significantly, figure out your new goals for before implementing the change.

8. Don’t let your programmers design the user interface

I’m a programmer, among other things. Like many in this profession. I suck at designing UIs (though sometimes I believe I don’t). When you let programming-focused people like me build your user interface, you will get things like this.

Some people are naturally gifted at user interface design. They feel physically sick about adding a button that clutters the interface or messes up the user’s workflow. Make sure you have a gifted UI designer on your team (whether or not he or she doubles up as a different role — including programmer). It will make a world of difference when you get your first users — the difference between a lukewarm response and “Wow, it’s great! I love it!”

Virtuoso Violinist
Who to build it with

9. Make sure every member of the development team is passionate about the product

Your development team is to your product like parents are to a child. If they do not care about your product, it might turn out well anyway — but the overwhelming likelihood is it won’t. Anyone who’s not passionate about building your product should not be involved in building your product.

For this reason, it is very unlikely that outsourcing your product development will be successful. Build your product in-house, and make sure the team is fully bought into the concept and committed to make it a success. It is better to give up 50% of your equity for a great product team than to give up 5% for a poor product team. 95% of nothing is still nothing.

In yesterday’s world, this was very hard to achieve, since even a relatively simple web application required a fairly large team to implement, and the larger the team, the harder it is to remain passionate. With today’s web development technologies, it is possible for a team of 2 or 3 to build an entire business within 3-6 months, but those 2 to 3 must be passionate and dedicated.

It is very hard to make up for your team’s lack of passion through your own passion.

10. Be sickeningly elitist about your development team and sickeningly inclusive about your users

No one should be considered too stupid to use your product. For each person who you know had trouble using your product, there will be many more who had the same trouble but never told you. It’s never the user’s fault, it’s always your product’s fault for not being clear and intuitive enough.

At the same time, your development team needs to be the best. You cannot create greatness out of mediocrity. These days, elitism is regarded almost as a flaw. Actually, it is the only way to greatness. If you want to create the best product, you need the best people.

11. The best hiring strategy is to hire no one

Hiring employees is a nightmare. There are a lot of legalities to be considered, and it is a lengthy, time-consuming, and expensive process. Fortunately, you don’t need to hire employees. You need to recruit a development team to work with you, not for you.

Your development team is like the heart and lungs and brain of your business. They should be as committed and passionate as you are. For this to happen, you need to treat them as equals, not as subordinates.

You don’t need job adverts, you don’t need resumes, and you don’t need contract negotiations. What you need is to network in the right communities, whether online or offline, to recognise the people you need, and to bring them in not as employees but as partners in your vision.

12. Include at least one target user on the development team

By development team, I mean the team involved in the day-to-day or week-to-week iteration meetings. If you fail to do this, it will cost you a lot to readjust when a real user finally approaches your application and, inevitably, finds it lacking. If you’re a small startup on a tight budget, this extra cost can kill you. Survival is worth giving up equity to get a target user on your development team.

13. Ensure everyone on your development team understands the problem they’re solving

Immerse your development team in the users’ environment for a short period of time and let them see for themselves just how bad the current systems and processes are. Presumably, you have some contacts who work in the niche that you are targeting (if you don’t, then it’s probably not the right niche for you). Convince them to let one or more of your development team sit in their office and experience the pain points for themselves.

This is the opposite of embedding an end-user in the development team. Embed your development team into the end-users’ environment — at least for a time.