This is a chapter from the book Starting & Sustaining which is a system to help you build and launch a web app with less pain and fewer mistakes. The entire book is free to read on the web.

You can also buy the book and additional resources which includes the digital version of the book, the audiobook, a playbook, and hundreds of dollars of discounts.

Ignore the competition

There are lots of good reasons to abandon a project. Having a little competition is not one of them.

Seth Godin
Competition
August 9, 2010

This next topic is a tough sell, and it may make you a bit uncomfortable. You’ll either believe it or you won’t, but I’m going to give it a shot. The short version is: your competitors should be the least of your concerns. It’s tempting to think about what everyone else is doing, but at this point in the game, nothing is more important than clearly understanding your customers’ needs and executing your vision to meet those needs.

It’s incredibly rare that a business is killed by the competition. Most businesses end up killing themselves through a combination of factors. Lack of focus is a big one. Poor financial management or customer support are a couple more. You’re much more likely to wreck your own business long before your competitors outdo you.

Avoid thinking of business as a zero-sum game. In most markets, there’s plenty of room for competition. People have a variety of needs, and there’s no way that one solution is going to make everyone in the market happy. It just doesn’t work that way. Your product doesn’t have to pull customers from competitors. It can focus instead on opening new corners of a market and bring new customers into the fold.

It can be easy to fixate on the competition. You may think to yourself, “We need feature X because company Y offers it.” (This only matters if all of your customers are telling you that.) Or you might say, “This new product just launched–we need to hurry up and launch.” (You do need to hurry up and launch, but that has nothing to do with your competitors.) Underneath all this is the assumption that everyone else knows exactly what they’re doing. But I’m going to let you in on a secret–no one knows what they’re doing. Some might have a clearer picture, but everyone is constantly learning and adjusting as they go, just like you are.

Moreover, there’s no company or team in the world that’s right all the time. It’s a waste of your time to worry about what your competitors are doing if you don’t have complete knowledge of why they’re doing it. Apple, Facebook, Google, and Microsoft are all failing regularly. Even they don’t have all of the answers all of the time.

It’s difficult enough to focus and prioritize among your internal activities, but it’s a complete nightmare to worry about what a dozen other competitors are doing. At best it’s a distraction, and at worst it’s completely misleading. If you try to mix together a dozen competing visions, you’ll simply be lost at sea–your messaging will be blurred, and you won’t have a strong appeal to any specific audience. If you think it’s hard to appeal to one audience, try appealing to a dozen.

People often ask me why I chose to create a bug and issue tracker when there were already dozens of issue trackers out there. The short answer is that I simply couldn’t stop thinking about bug tracking. For years, whenever I’d fly somewhere, I’d invariably spend that time sketching and exploring ideas around bug tracking–for whatever reason, I was hooked. Keep in mind, all of this sketching was long before I ever thought that I’d do anything real with it; I was simply curious and passionate.

Bug tracking isn’t the most lucrative market, but for me it was perfect. I had spent years doing consulting, and I had never seen a non-technical person adopt bug tracking without significant arm-twisting. Even then, they only participated grudgingly. More often than not, they’d never log in to track bugs–they’d just go back to emailing the developers or project manager. Communication broke down, and the bug tracker would become a ghost town.

On top of that, most bug and issue tracking tools had countless configuration options. We would have meetings about meetings about meetings about workflows and custom fields, but all it did was make a mess of things. The workflow didn’t work, and the custom fields either went unused or got in the way. Between configuring the tools and trying to get non-technical folks to use them, bug tracking had always been a tedious part of the job. Looking back, it feels like we spent more time tinkering with those tools than we did using them.

Those experiences laid the groundwork for all my beliefs about bug tracking. I wanted to create something with minimal configuration that wasn’t too intimidating or overwhelming for non-technical people. At the time, that approach didn’t correlate with what most bug trackers were doing. Bug trackers were highly configurable, flexible, and powerful–and if you were building complex software for airplanes, nuclear missiles, or operating systems, you’d need that flexibility–but there were also countless teams out there building fairly basic websites with popular content management platforms. They didn’t need twenty fields to classify bugs–they just needed something that worked.

When building Sifter, I only paid fleeting attention to our competitors. Even then, I only kept up with them so I could remain knowledgeable enough to help guide people to other products that might have been a better fit for them. We had no shortage of features or ideas on our roadmap. We struggled every day to choose how to apply our time. The last thing we needed was a bunch of what everybody else was doing.

Any time I heard a competitor had something Sifter didn’t, I was thrilled. The way I see it, the more differences there are between bug trackers, the better off Sifter customers are, and the easier it is for people to find the tool that’s right for them. People are different, and they have different needs, priorities, and preferences. I’d much rather they were happy with someone else’s application than watch them try to shoehorn Sifter into meeting their needs.

If there are customers paying you money today, and they’re asking for specific improvements, their requests should come before any ideas you might derive from competitors. People who use your application and are willing to give you money and provide feedback are your best source for new ideas. Whether they realize it or not, they chose your product because it was a better fit for them than anything else. They can’t prioritize your work for you, but they–not your competitors–should be your source of inspiration.

Remember, even the largest companies in the world started somewhere. And the successful companies didn’t get there purely by knocking off the competition’s products. They got there by following their own path. Don’t distract yourself focusing on the competition in the early days. Your only concern with competitors should be ensuring that you’re not turning into a second-rate copy of some other company. Do your own thing. Carve out a niche, and own that niche.

Play by your own rules. Josh Williams, cofounder of Gowalla, talks about competing against Foursquare and how it affected their long-term vision.

Support Starting & Sustaining

This chapter is just one piece of a much bigger puzzle. Starting & Sustaining is a complete system to help you build and launch a web application with less pain and fewer mistakes.

The Package

An illustration of the checklist, book, and spreadsheet.

The Audiobook

An illustration of Starting & Sustaining on a mobile device audio player.

The Book

An illustration of Starting & Sustaining on an iPad.
An illustration of an envelope with a wax seal.

Once-a-month emails Focused emails on SaaS topics like email, security, onboarding, pricing, and more.