Building for yourself
As a young entrepreneur, one common piece of advice you hear is to “build a product that solves a problem you have yourself.” Scratch your own itch, they tell you.
And that advice is logical and pretty well reasoned. If you are solving a problem you have yourself, then you will be intimately familiar with the nuances of that problem and should be able to create a great solution. If it’s your own pain, you’ll attack it with passion and perseverance.
Totally makes sense.
Up until now, however, I’ve opted for the alternative approach. Not to solve a problem for myself, but to try to identify a problem that a lot of people/companies have. Look for a big problem with a big potential market.
But recently, my team released a product that originated as my own problem. The product is called Sherlock — we call it a user engagement scoring application. It allows SaaS businesses to quickly create a scoring model to measure engagement with their product — giving an engagement score to every one of their users and accounts.
It’s a great product…but the point here is that it solves a problem I’ve struggled with every since I started building SaaS software. It has always driven me CRAZY that there wasn’t an easy way to find my most engaged users and accounts. That I could never tell if my product engagement was going up or going down. Or figure out which segments or activities were driving engagement. Product Engagement was/is the metric that drove the entire business…but I just couldn’t get a hold of it.
Eight years ago I tried to hack it with Google Analytics. After weeks of soul crushing attempts, we gave up (and never used Google Analytics again, by the way).
I’ve tried building my own macros on top of spreadsheets of data pulled from a general analytics tool. Hours of late night work on this one. Thinking back makes me shiver.
Most recently, I’ve hacked it with a complicated periodic SQL query of data in a makeshift warehouse. But it was never quite right — an expensive query that required engineering each time and impossible to manipulate. Somewhat helpful, but ultimately unruly.
Eventually…I just said fuck it and dedicated time with the team to build it. We released an MVP about 18 months ago and just recently released a rebuilt version after many, many months of de-prioritizing any iteration. The new product is really good and something of which I’m very proud (the team that built it did an amazing job).
So…how’s it feel, scratching my own itch?
Honestly? Yeah — it feels really, really good. I can now personally attest that scratching your own itch feels great. Every day I use Sherlock, I am filled with satisfaction. I haven’t loved a product that I’ve built more than this one. It makes me wish I listened to this advice sooner :)
And then the dark side creeps in.
With every ounce of satisfaction that comes from scratching this itch comes and equal (if not greater) sense of doom.
A sense of doom rooted in the greatest risk of building for yourself….a market of 1.
When you solve a personal problem, by definition, you are not attacking a universal problem. Instead you are solving a small problem and hoping that it proves to be universal.
You’re not building a better mouse trap. You’re not going after a well-established pain — one that is ripe for a variety of solutions. You are focusing on a single frayed thread on your own sweater sleeve that, really, only you can see. The only real problem you’re solving is your own emotional imbalance that this pain creates.
The fear is that building for yourself is nothing more than person therapy (the expensive kind, at that).
At least that’s the fear.
So…how does it turn out?
Well…of course, I don’t know yet. It may work out very well. This problem may turn out to be greater than just a frayed thread on my sweater. It may turn out that every SaaS business has this pain (even though they may not have realized it).
Or it may turn out that I’m the only one that gives a fuck.
Time will tell. Either way, I’m glad that I attempted this approach. Either way…we’ll learn a bunch.