Software is not a field of dreams
I make software. I’ve been on someone’s payroll for the last 10 years to do it too. So when my job title changed from Software Engineer to CEO, I had to learn things about software that are beyond my editor. It has been about 7 months since I officially changed my day to day, and let me just say, writing code is the easy part.
For example, acquiring customers is something I’ve rarely had to think about. I’ve had to think about keeping people happy with a product, but never how to get them to agree to use it in the first place. Most software engineers are this way. I’ve had product, marketing, and sales teams to help explain the value of a feature I built with my team. We were responsible for making sure it worked, not for getting people to use it.
As a software engineer turned CEO, I feel like building another feature is the best thing I can do for the business some days. However, the reality is that FireHydrant is a fully functioning incident response tool. It may lack features people want, but that will always be the case. We solve real problems today and we have for months. But as a human being, I will always gravitate towards the thing I know I’m good at: writing code. This is a problem, though, when you’re also responsible for making sure that code gets used.
With the added responsibility of sales and marketing, I see opportunities where a prospect might benefit from a feature and I will instantly want to build it myself. I demo our solution to others and we almost always are missing something they ask if we can do. As a team we have a lightbulb moments like “Wouldn’t it be awesome if we build X!” at a bar together. These moments are valuable and shouldn’t be discounted, after all, FireHydrant has some of its best solutions to problems because of them. But you have to be careful about giving into the urge. These features are just blades of grass in the software field of dreams.
It’s incredibly difficult to avoid the software field of dreams. Building a company is not as simple as “If you build it, they will come” (Kevin Costner actually hears “he will come”). Customer’s don’t magically appear, no matter how great your solution is. If some do, it’s usually not enough to survive as a business anyways. You have to actively explain to people how your product solves a problem. Sometimes you need to explain that it’s even a problem. Said differently, the features of your software will never tell the story about why they exist in the first place.
This is a difficult place to be in when, again, I’ve rarely ever needed to explain to others how a feature solves a problem. Internally to the team it’s obvious! “Of course we have a change log! How could we not as an incident response tool!” Within the confines of the founding team, it’s easy to be Kevin Costner and think what we’re building is obvious to others.
As an early stage company, though, this can feel like a catch 22 situation. We know we need great features to acquire customers but we also know we need more customers to continue to build those great features. It’s a muscle group we’re weak in.
If something isn’t uncomfortable, you’re not getting better at it. There’s a phrase (and internet meme sensation) called “never skip leg day”. When you only do the exercises that are “easy” and ignore your legs, you end up looking ridiculous. Skipping customer acquisition is the business version of “never skip leg day”. It’s uncomfortable for me, but something I’m getting stronger and stronger at over here at FireHydrant.
I’m the founder and CEO of FireHydrant.io — A Layer 8 Router for Incident Response. I want to help anyone with anything I can. These blog posts are my attempt at doing that.
