Chapter 19: Ignore the Competition

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

Seth Godin

I’m going to be really honest — this topic is a tough sell. You’ll either believe it or you won’t, but I’m going to give it a shot. The short version is that 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 own vision and executing on it.

It can be easy to fixate on the competition. You may think to yourself, “We need feature X because company Y offers it” or “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 this assumption that everyone else knows exactly what they’re doing. But I’m going to let you in on a dirty secret — no one knows what they’re doing. Some might have a clearer picture, but everyone is constantly learning and adjusting.

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.

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. And if you try to mix in a dozen other 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 almost 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 some 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 actually 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 actually 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 really correlate to what most bug trackers were doing. Bug trackers were highly configurable, flexible, and powerful — and if you were to be building complex so ware for airplanes, nuclear missiles, or operating systems, you’d need that flexibility — but there were also countless teams out there that were building fairly basic web sites with popular content management platforms. They didn’t need twenty fields to classify bugs — they just needed something that worked.

Since building Sifter, I’ve only fleetingly paid attention to our competitors. Even then, I only keep up with them so that I can remain knowledgeable enough to help guide people to other products that may be a better fit for them. We have no shortage of features or ideas on our roadmap. We struggle every day to choose how to apply our time. The last thing we need is bunch of what everybody else is doing.

Any time that I hear about a feature that a competitor has some- thing that we don’t, I’m thrilled. The way I see it, the more differences there are between bug trackers, the better o our 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, priori- ties, and preferences. I’d much rather they be happy with someone else’s application than watch them to try to shoehorn Sifter to meet their needs.

If there are customers paying you money today, and they’re asking for specific improvements, their requests should be in front of any ideas you might derive from competitors. People who use your application and are willing to give you money and to 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.

Related Reading

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

Continue to Chapter 20: Creating Interest


This is a chapter from the first edition of Starting + Sustaining, a book about bootstrapping a successful hosted web application business. The second edition, a massive update, will be out in Spring of 2017. You can subscribe here to be notified when it launches.