A year and a half ago when I started thinking about what my next side project would be, I couldn’t have imagined the success that it would have. While it may seem small to some people, getting anybody to believe enough in your product to give you money for it is a huge accomplishment that you should be proud of.
It’s not easy, though. It takes dedication, hard work, and some luck to get your first customer. As Lau Tzu said: “A journey of a thousand miles begins with a single step“.
Identify the Problem
Before you can build a business, you need a product. Before you build a product, you need a problem. Finding a problem that needs to be solved might be the hardest part of your journey, so take your time with it. Have you ever thought:
“I wish there was <thing> for <problem>”?
If you have, other people likely have too. This is a good place to start exploring your product ideas.
One thing that I’ve learned through my many failed products is that if you want to be successful, it helps a lot if you are solving a problem that you yourself have. Back when I was still a freelance WordPress developer I often ran into the problem of updating themes and plugins on client hosts. It was always a big pain to do, so I thought that being able to hook into the WordPress update system would make life a lot easier. Kernl was born from this problem, and it formed the core of the product.
At Kernl’s core, I wanted it to be an easy to use WordPress SaaS product. My suspicion was that people didn’t really want to run their own update infrastructure and would gladly pay for a reliable provider. Customers would only need to upload a ZIP file of their plugin or theme, and we’d handle the rest. Keeping the core product tightly scoped really helped me focus on delivering value.
Having an existing player in your problem space acts as problem validation.Tweet
While on the topic of identifying the problem, I want to take a moment to talk about the size of a market. Just because someone has already created a product that solves your problem doesn’t mean that there isn’t room for your solution too. If you can do what they do better and differentiate yourself, you’ll get customers. It’s also worth noting that having an existing player in your problem space acts as problem validation.
Start Small, Think Big But Always Finish
You often hear people talk about the “lean startup methodology” in our community. People have a tendency to pick and choose which bits of the lean startup that they follow and I’m no exception. I definitely didn’t follow it exactly, but one thing I was sure to do was distill Kernl down to the smallest possible shippable piece before I started working on it.
Getting across the finish line for any increment can be a struggle, especially if you’re doing this in your free time. One thing to remember is that it’s ok to iterate. When I shipped the first increment of Kernl, it wasn’t perfect, but it did do what I said it would: provide private plugin and theme updates. Throughout the first increment, I kept a running backlog of things that still needed to get done. It felt as though it was always growing and that wasn’t a bad thing. There are always more things to do, but keeping focused is what moves products forward.
The one time I tried to do a “big bang” release for Kernl was a failure. I tried to create an analytics product, and things just didn’t work out. I didn’t believe in the feature I was building, and it showed in my decreased dedication and motivation. After a month of work, I cut my losses and scuttled the whole thing. It was an important lesson and reminder that I shouldn’t start something if I’m not willing to finish. Unfortunately, my time isn’t free, and there are always other things requesting it.
“What color is the bikeshed?”
A year or so ago a coworker introduced me to the term “bikeshedding“. Bikeshedding is a term that was coined as a metaphor for Parkinson’s Law of Triviality. The story goes that there is a group of engineers working to build a nuclear power plant, but instead of spending their time wisely and debating reactor design they end up wasting all their time on what color the bikeshed out in front of the power plant should be.
In my day job, we throw the term “bikeshedding” around whenever we realize that we’re debating trivial topics. If the answer to the question really doesn’t matter, or any of the proposed solutions would be fine, just pick one and move on. Being decisive is incredibly important when you’re creating a SaaS product in your free time. Customers really don’t care if you use Node.js or PHP, just pick one and go for it.
Being decisive is incredibly important when you’re creating a SaaS product in your free time.Tweet
To the customer, the result is the same, and you’ve saved time so you can work on features that directly affect your customer. Whatever the case, be decisive and don’t bikeshed.
Pick Tech That Makes You Go Fast
As a developer I’m happy to discuss for hours with anyone who will listen why I picked technology A or technology B, but when you’re building a product it probably doesn’t matter. Choose a technology that you know well and get to work. If you can build fast in it, it’s almost always the right choice.
My technology choices with Kernl reflect my goals for the project. I wanted to build a successful WordPress SaaS product and maybe learn something technical in the process, so I chose to build Kernl mostly in technologies that I understood (Node.js for the backend with Angular 1 on the frontend). Neither of these technologies got in my way, and I was super productive with them.
Another thing to consider when you’re developing is technical debt. If you’re trying to move fast and deliver your first increment, it’s OK to take on technical debt. Just remember that technical debt has a way of rearing it’s ugly head what you least expect it. Expect that at some point in the future you’ll need to pay it back. During Kernl’s pre-alpha and alpha phase, I took on a ton of technical debt in the form of a manual deploy process, callback hell, bad infrastructure, and no unit or integration tests. While I was in the process of acquiring my first few customers, I was OK with it, but once they started to rely on Kernl I had to pay it back so I could provide them with the best service possible.
Marketing A WordPress SaaS
Trying to be a marketer when you’re a developer can be tough. I’m personally a very private person. I communicate well with others, but I prefer to spend time with myself or close friends/family. When you’re marketing your product, you learn to get over the uncomfortable feeling of rejection. Not everyone is going to like what you’re doing, and you just have to deal with it.
Kernl was initially marketed via a “Show Hacker News” post and a few posts on Reddit. After that, I started searching Twitter for relevant keywords and interacted with people directly. This process was super manual and labor intensive, but it worked out well enough to get a few paying customers.
Sometimes getting a product started takes a bit of luck too. Right at the time, I was launching Kernl my main competitor (WP Updates) was sold in some shady dealings to a 3rd party. Their community of users was upset by this, and even more so when their service went down and didn’t come back up for several days. Recognizing that opportunity was knocking at my door, I started tweeting at everyone who was complaining. This was hands down the best influx of customers I’ve ever received. These people needed a product they could rely on, and I was determined to make Kernl that product.
I did make some missteps along the way, though. I ran some experiments with Google Adwords, but they never seemed to convert well. After two months I stopped running the ads and decided to pursue other options. Realistically, I think the best approach to marketing Kernl is via content marketing. This can be many things, but I think having a nice blog with a lot of WordPress dev specific articles in would help drive a lot of traffic and potential customers towards Kernl.
Listen to Your Customers
One thing I’ve learned over the years is that being responsive to customers is very important. When it comes to Kernl, I’m as responsive as I possibly can be and it seems that customers generally appreciate it. I always make a point to respond to inquiries right away even if I don’t have an answer, so the customer knows that their problem has been acknowledged.
In addition to communicating quickly, I try as often as possible to provide detailed answers and explanations to Kernl’s customers. 95% of the time I’m communicating with a fellow developer, and I know that if the situation was reversed, I’d like to know more about why something happened and what is being done to fix it. Some might consider it over-communication, but I strongly feel that over-communicating is better than under-communicating.
One of the most important things I learned from talking to customers was the need for stability.
I decided to dedicate the entire beta phase of Kernl’s launch to stability and automation.Tweet
A large handful of Kernl’s initial customer base had migrated away from WP-Updates because of the downtime issues they were having, and I didn’t want them to start seeing Kernl in that light if I couldn’t keep the service up. With that in mind, I decided to dedicate the entire beta phase of Kernl’s launch to stability and automation. No new features were written in that 2-3 month period, but heavy refactoring, automated testing, and infrastructure improvements made Kernl a far better product than it had been in alpha.
Set Realistic Goals
There are a lot of ways I approached Kernl that were different from previous attempts at a SaaS product. One of the most impactful for me was setting realistic goals. I didn’t say “I want 1000 customers and $50k in revenue at the end of 3 months”. I instead set a short-term goal of “I want to be able to take my wife out to a nice dinner once a month purely with money made from Kernl”. Once that goal was reached, I set a slightly bigger goal: “Make a car payment” + my first goal.
For me, settings goals that were just out of reach were important. It gave me something that I believed was achievable to strive for. Of course, there are other larger goals that I have for Kernl (make Kernl my full-time job), but those are a long way out still. You have to have something to strive for in the short-term if you want to stay motivated.
At some point in my journey with Kernl as a WordPress SaaS product, I felt like I started to hit a wall. Maybe it was becoming harder to acquire customers, or maybe it was that I wasn’t trying hard enough, but it felt like Kernl needed something new to stay relevant. When I started to feel that way, I started to think further ahead. I asked “What’s something that I can help introduce into the WordPress ecosystem with a lot of value?” and “Can this idea expand Kernl beyond the WordPress ecosystem?”.
Kernl’s initial goal was to provide updates for private WordPress plugins and themes, but as Kernl grew I thought I could help developers modernize their deployment workflow. Since Kernl launched, I’ve added push to deploy (GitHub, BitBucket, GitLab), Slack notifications, webhook notifications and so much more. But I felt like the next feature needed to be bigger. More than a bolt-on. Something completely different.
The next big goal I have for Kernl is the loftiest I’ve set yet: Use Kernl as a platform for feature flagging. You can slowly roll out deploys to a percentage of people, individuals, or everyone without needing to do deploys. All the server and front-end work is complete at this point, so I’m slowly dogfooding the product to make sure it scales well and is extremely easy to use. I’m also targeting developers both in and outside of the WordPress ecosystem, which is going to be a fun challenge.
Having a product business means that you always need to be moving. The minute that you stop innovating is the minute that a new player comes into space and takes your customers.