What not to work on

Drew Bredvick, software-as-a-service

Knowing what not to work on is as hard as knowing what you should work on.

Tim Ferriss has a (somewhat outdated) list written back in 2007.

“Not-to-do” lists are often more effective than to-do lists for upgrading performance.

Allison Rimm wrote about this in an article in Harvard Business Review.

She maintains three lists of tasks:

  1. are important, non-time-sensitive
  2. need to be completed today
  3. aren’t worth the time

Any item that’s on list number three Allison intentionally skips.

“Not-to-do” list for building products

Most individual builders have rules about products they won’t build. Some have rules about avoiding products with long sales cycles, others have rules about avoiding business-to-consumer (B2C) products.

Below are a few points from makers about what not to build.

1. Don’t build an appetizer

Justin Jackson of TransistorFM argues that you should try to be “the main thing” or “the entree”.

the main thing


Most people order the entree when they go out to dinner and it’s often where restaurants make most of their profit.

In the product world, this translates to:

The counter-intuitive point here is that sometimes that means taking on more scope, building a bigger project, and writing more code. It’s advice that runs against most of the “start small” and “niche down” logic.

It’s all about analyzing the value chain of the market you serve:


I highly recommend reading all of Justin’s post here.


2. Don’t build for the wrong market

Sahil Lavingia took Gumroad from a weekend project to a venture-backed startup. The growth rate wasn’t enough to raise the next round. Check out his journey below:

(need to figure out how to embed tweets)



If you’re building ecommerce software: Good news - ecommerce is growing.


Making podcasting tools or services? Interest is at an all time high and continues to grow.



3. Don’t build something for other people

This one is my personal rule. Your mileage may vary. I have been working on a side project for a few months now and have been building it without being a user of the tool.

That doesn’t work for me.

Quicker Questions

Quicker Questions was fun to initially work on. I had started at a new company and the Q&A sessions were not efficient. I was very excited to fix this problem.

I fiddled with what stack and tech I was going to use for a couple of days. The problem wasn’t the tech, it was product-market-founder fit.

When considering HR software, question and presentation software is somewhat ancillary.

Generally, most of the HR software budget will be spent on payroll or recruiting.

Quicker Questions in its current state is not a useful addon to a growing market.

Sli.do, the winner in the space, has seen more and more competition recently. Google even unveiled a tool to do Q&A inside of Google Slides.

Companies change software like this infrequently, meaning growth in this market is heavily tied to the growth of new companies.



Questions for you

  1. What are you building?
  2. What should I build?
  3. What products do you refuse to build?

I’d love to hear what you think on Twitter @dbredvick or IndieHackers.

© Drew Bredvick.RSS