If you've been in tech for any amount of time you'll know the phrase "scratch your own itch". If you're not familiar with the phrase, it's time to catch up on some essential tech reading. A google search will get you on your way.

itchy.jpg

The concept seems simple enough... 

You have a problem. This is your itch. 

It requires a solution. The scratch. 

You believe that others may have this same problem and because you've experienced their pain who better to solve it than you. This is great! You know a real world problem and you have a solution. If you build it they will come and they will bring their dollars with them. Or will they?

The truth is, having your own problem and solving it doesn't teach you anything about your potential market. 

You're weird. I'm weird. Everyone is weird. People don't think alike. People address the same problems differently. People who have the same problem as you may not be willing to pay for your solution. To them the problem may not hurt enough or they may already have a solution that gets the job done well enough.

Scratching an itch should never go beyond crafting your hypothesis.

Scratching your own itch shouldn't inform your design, code or eventual product. It's a starting point to test the water and to find out if there's a market of people with the same pain as you. 

I've made this mistake A LOT with Dpadd. I initially scratched my own itch and created a product that I wanted to see in the world.  I was motivated to build my solution and managed to find a few people who wanted the same solution. But I kept scratching. I did listen to my early users and made tweaks to my product based on feedback. But I ignored a lot of good feedback because it wasn't in line with the problems that I wanted to solve. 

And therein lies the problem - scratching my own itch put too much emphasis on what I wanted. To build a product that people will use and pay for you need to take the 'I want' out of the equation.

It's especially difficult to put aside 'I want' when it's your own product. I've worked for years as a UX/Product person and have never had an issue focusing on user needs for client projects. But when it's your own baby, it's personal. You want it to be your thing done your way.

I'm as guilty as anyone else of this. Here's something dumb I said in the press recently:

"I want to build a place (like Goodreads) where people come and discuss what they’re playing and learn about new games."

Check out the first two words: "I want". Fuck that. It's not about what I want. It's about what the users and current/future paying customers want. And, as it turns out, many of them have different problems that they want solved that aren't in line with my original itch.

A better way

In the future I'll approach this differently. Here's how:

  1. There will be an itch.
  2. That itch will inform an initial hypothesis that others have the same itch and are looking for a solution.
  3. Test the scratches (solutions) by building nothing more than landing pages. Drive traffic to those pages to find out if there's interest and build a list of real people to talk to. Read "Why only fools write code first" by my buddy Kareem Mayan
  4. With enough interest and even financial commitment you gain knowledge of a real need in the market. 
  5. Sit down and build the minimal solution.
  6. Never scratch your own itch again as it relates to this project. Real feedback from real people will help you build the solution that will result in real revenue. 

Scratch your itch to get you started. But after that, forget what "you want" and focus on building the right solution for the right market.


If you liked this post please consider up voting it on HackerNews: https://news.ycombinator.com/item?id=7252778

Comment