Comment

Don't scratch your own itch (too much)

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

Comment

10 Tips for Those Who Want to Build Products on Their Own

Over the weekend I moved Dpadd out of private beta and into a public beta. I wanted to share some thoughts and tips for those who are building web products on their own. I think this can be helpful for those who are working on side projects and those who are working on their own products full time.

 

tips-img.jpg

You can do it alone

Yeah, it's not easy but I don't see any reason why one person can't design and build great web software. If you're a designer, it really doesn't take much to get started with a programming framework like Ruby on Rails. Rails has a great community of sites and tutorials that make is easy to get started.

Apart from technical knowledge, in a lot of ways, I believe it's easier to build products as one person. On your own you follow a single vision for your product (hopefully). I believe this leads to better, more focused products. You don't debate and explain yourself or get buy in from your colleagues. You know what to build and you build it.

 

You can't do it alone

Let's be honest, trying to build a large scale social network, in a framework you've used for only a few months, without any help is probably not a good idea. Why? Time. If it takes you a week to do something that would take someone else a hour, you're wasting time. When building Dpadd I occasionally traded my time with better programmers to speed up development. Just because you can do something doesn't mean you always should. If you're a designer, trade your skills with others to speed up your own project, and vice versa if you're a developer.

 

Have a group of people that you trust to bounce ideas off of

I'm very fortunate to have a handful of great product and software people in my life. These people were key to helping me get this thing off the ground and stay focused on my vision.

Even if you don't have people around you to help, reach out to who ever you can via email, Twitter, etc. I think you'd be surprised at how many people are willing to share advice when you ask. Clarity.fm is also a great resource to find "advisors".

 

Be absolutely relentless

You're going to get stuck a lot. What you do when you get stuck will be the difference between shipping and not shipping. When a problem comes up, you need to be prepared to look through 100 Google results to find the one person who had the same bug and provided a solution. Sometimes you will need to read dozens of blog posts and even whole books to understand how to build a feature. Don't stop, be relentless in your pursuit of building your product.

 

Scratch your own itch

I know this is an obvious one but it's served me so well that I need to share it. Dpadd has existed in spreadsheet form since 2006. I would literally bust open excel to record the games I play, the ones I want to play and even rate and review titles as I finish them. That's right, I'm a giant nerd. But because I had been doing this for 6 years before starting Dpadd it was easy to know what to build to solve the problem. It would have taken me much longer to find the core set of features needed to build out the first version.

As it turns out, a number of my early users were doing the exact some thing in spreadsheets and were beside themselves to have a place to more easily organize and share their gaming activity.

 

Your product, features and design should all be MVP for a very long time.

Don't worry about your product being perfect. You're one guy or gal, you are not Apple. Most people in the startup world know the famous Reid Hoffman quote: "If you are not embarrassed by the first version of your product, you’ve launched too late". Focus on solving a problem in the simplest way you can and then get it out there so you can learn, adjust and reprioritize.

 

Create a one page business model

Focus is one of the biggest advantages of working on your own but it's sometime easy to deviate from your vision. Take 20 minutes and make a one page business model with LeanCanvas. It will help you understand and remember what problems you're solving and who you are solving them for. Refer to it often when deciding what to work on next.

 

You don't need to spend much to ship a product

It's easy to be tempted to sign up for every new startup tool and service. There are services to help you monitor and manage every part of your product but you really don't need these until you're up, running and have decent traffic. Don't get distracted by anything that slows you down in your goal of shipping a product. Dpadd took about 4 months to build and then was in private beta for 7 months.  In that time, it has cost me less than $400 total.

 

Think of your users as your team

From day one I've thought of my users as part of the team. Keep communication as open as possible, ask for advice and get buy in for direction. No one knows more about the problems you're solving than the ones with the problems. Talk and LISTEN to them any time you have an opportunity to do so.

 

Have no fear

If Dpadd didn't exist tomorrow I'd still be happy. It's not because I'm not passionate about it. I am, and I want the product to succeed and grow. But I'm not afraid of failing because I've already succeeded. I've learned so much and had a great time designing, building and sharing my creation with others. In my mind, there's nothing to fear - I've already won.

 

Like this post? Please consider voting it up on HackerNews here:  https://news.ycombinator.com/item?id=6508892

You can check out Dpadd if you're interested here: http://dpadd.com

Comment