From time to time I like to take a few minutes and jot some things down outside of the core browserless business. As much as there is to write about product itself, the other side of the equation (actually running it) is just as interesting to me. I've done this before on our post about running an independent business, and it's a topic I'm rather interested in -- especially now that it's gotten a lot of attention. Quite frankly, I think the nature of how most developers work over the next few years will change quite drastically given the breadth and depth of how software is built, but that's a topic for another post! Today, I wanted to take a look at the darker side of running a business, mostly the small things that will absolutely kill it. My intent here is to shed light on symptoms so you can course-correct before they become and out of control problem (ala Agent Smith from the Matrix). Hopefully you'll find something new, or perhaps said in a way that helps it "sink" in more.
I should warn you that this writing is mostly geared towards newcomers who are interested in going the "indie-hacker" route, and while some of the advice can be applied practically to any business, some of the suggestions given might not line up with where you're at in the lifecycle. So take everything with a grain of salt, and here we go.
Being involved in something you aren't obsessed with
It's quite hard to put my finger on it exactly what it is that you'll need to make a product succeed. Some call it passion, others call it "skin in the game," but I feel that it has more in common with obsession than anything else. I think a good personification of this, that we're all familiar with even though he's somewhat polarizing, is Elon Musk. Musk can be characterized as passionate, determined, and driven; but I see his involvement in his companies as obsession. Probably to an unhealthy level. But, by most accounts, his companies are still innovating and forcing their respective competitors to innovate as well. I doubt that Tesla would be where it is today if it hadn't had someone obsessed with it behind the wheel (pun intended).
While it's an extreme example the spirit behind it is true: you can't get something past the break point without pushing like mad. Staying up all night mad. Mad enough that you email folks who hated your product to find out more why and wish them luck on their endeavors. So mad that you still push through even when the big competitors could eat you up in a moment. For browserless, specifically, there were multiple times like this. When GCP announced they can run puppeteer/headless-chrome without any work involved it felt like the writing was on the wall for me. If I hadn't been as emotionally invested in the business I can say (with pretty good certainty) that I would have given up after that event. Looking back now, we didn't lose but a single user when this announcement took place, just for some perspective.
Now the the appropriate response to this is that you'll burn out with this kind of mentality. Maybe. My observations have been that if you are forcing yourself to put in the time, and not looking forward to it, then there's bigger issues at stake. To be clear, I'm not evangelizing a work-always work ethic, but there's going to be times where you'll have to push through and be obsessed with doing so. Otherwise, like a fire struggling to stay lit, it will fade out.
Now, what can you do if you're in this scenario? There's really only two options: quit or pivot. Keep your code, strategy plans, and network alive but dust off your shoes and move on. You're going to be miserable, your users will most certainly be, and you're not living up to your hypothetical potential. Take what you can and get out or use what's there and pivot into something that better aligns with who you are as a person. You're doing no one any favors by continuing the charade.
Meeting the needs of every user
As a life-long people pleaser, the topic of saying "no" has always been a personal challenge for me. Largely by the fact that I interpreted the advice in the wrong way. You don't want to say just "no" to someone, but give reasonable workarounds and evidence as to why. This is a tougher topic to stomach as the characteristics around why you'd deny someone are unique for every situation, so an example is prudent here.
In browserless we've long had a feature request to launch a browser, run some work through it, and then keep it open after the underlying connection (HTTP or socket) is terminated. While something that was doable, and likely easily implemented, it faced numerous challenges that made me feel at odds. How would these browsers be "reaped"? How would re-connecting work? What would we do if there's too many left running? So, instead of implementing it quickly and carrying that burden for a long time, I told folks that the engine wasn't well setup for it at this time but would be something we'd work towards. In the mean time, I offered potential workarounds for their specific use-cases, even if it meant not using browserless, which was difficult. Over time we were able to slightly alter core parts of the engine to accommodate this feature. Any time we made some deeper change I had this feature in the back of my mind, and when all the parts were there we made it so. The system itself still maintains the same stability as it did before, but is now more flexible in meeting these more exotic use cases. In retrospect, had I implemented this with quick haste, I would have destabilized the hosted service for others and baked a half-finished product for the users that were asking for it. In my opinion it's better to have no users then users who despise you.
The other side of all this is treating your users as best as you can. At the end of the day, I'm really aiming for fans, and I think the term "users" feels cold and disingenuous. These are people who have put a time (and monetary) investment into what you're doing, and being there for them is critical. They'll let you know what works, what doesn't, and what can be improved -- and you should absolutely listen to that.
What should you do if your product is all over the place? Honestly, survey your highest-consumption users and build more towards them. Try not to invest too deeply into the edge-cases you've built -- but by all means keep some of it there as it likely found a way there for a reason. This might mean a gentle pivot, or really just a re-alignment, to better serve the core use-case. Going forward, learn to hold off on features and use-cases until you feel it's ready.
Not learning the skill of listening
Without a doubt, the best skill I feel I've learned in my lifetime is listening. When you actually open your ears to what your fans are saying about you then things start to become a lot more clearer. This helps in so many dimensions: reaffirmation, critical feedback, compliments and so much more. The moment you stop lending your ear is the moment that the beautiful feedback loop ends, and the program halts.
The hardest dimension about listening, from what I've found, is the wide amount of ways folks will communicate to you. Some love to write short cryptic emails, others will want to call you and visually see your face and body. Cultural influence as well as upbringing have a lot to do with this, and even knowing who you're talking to (and where they came from) can go a long ways to establishing sympathy and listening more proactively. Imitation is the most sincerest form of flattery, and responding to folks in the same tone/medium goes a long way to building great relationships -- which is what we're aiming to do!
Listening, in combination with honesty and sympathy, might be the most powerful synergy out there. When properly utilized it's a skill that forges strong bonds, fans of your service, and potentially relationships that will outlast any product out there. So how can you get better at it? For me it was repeating back what was said, but in the way my mind understood it. This gives the person talking a chance to address differences in perception, whilst at the same time cueing them into how things work inside your head. If they, like you, are good active listeners then they might even adjust (slightly) how they communicate with you to better get across what's going on. The last thing I'll recommend is seeing it from their perspective. What would you do if you had to work in some clunky old system, but were trying to use this new cool thing? How might you overcome that obstacle (or what kind of support would you need)? Part of being a good listener is filling in the gaps for people who aren't good communicators. They're likely in the thick of a problem that's hard to overcome (hence why they're using your service), and so their ability to see the whole picture is compromised. If you can, for a moment, capture a glimpse of what they're seeing while holding the whole picture of possibilities, you can unlock a lot of potential that might have been absent up until now.
You're not selling a pain-killer
One of the comments I've received about browserless that stands out to this day was "Your product is a real pain-killer." This jumped out at me as, I distinctly recall creating browserless to try and kill a long-held pain of mine: managing headless work streams (both from a development and maintainability perspective). Most people will put up with minor inconveniences, depending, but in order for them to actually pay for something you'll actually need to solve a real pain. It can be an inconvenience pain, a security pain, or a recurring pain; but it has to be painful.
Even innovators creating something new are really just putting a new spin on prior pains. I think social networking is just making it easier to stay connected to friends and co-workers. Everything they've done, and are doing, has already been achieved elsewhere, but it had been painful or extremely difficult. Wanted to see photos of your friends? You certainly could prior to social networks, but it required you to visit them and see their photo books or pictures on the wall. Even hardware companies are really just a spin on making things less painful! Smartphones are a great example of this: nearly everything you can do on smartphone could have been done prior, it just required a lot more upfront work. Convenience and luxury are the things that people will spend money on.
Is your project not solving a pain? It probably is, but just not something painful enough to separate people from their money. Money is a form of value, and so is time, and if the ratio is off then people will spend time rather than money. Not all of them, because to certain audiences out there money has less value then you'd perceive, but time is in short supply. So if you are solving a problem, and not getting users, then you're probably solving the wrong problem for the users that would spend money on it. This discussion leads itself into broader topics like audiences and where to find users, however if you don't solve a painful problem for someone it doesn't matter who your audience is and how much money they have.
Free accounts
Before we get too far into this topic I want to clarify that, at a certain scale of business, free accounts make a lot of sense. But if you're going the self-funded indie-hacker route, then they mostly do not. Free accounts get people into your product, which might serve a purpose for building awareness, but they also bring an incredible amount of risk with them. Not only do you widen your security vector, but you also end up paying for these users in some form or another. Either at the data-retention level, the legal/compliance level, or the time level. It's the latter of these that I want to talk more about.
Though free users can absolutely be an ingredient into a well run business, lots of them (and I mean a lot) can significantly drag your products release velocity. More users mean more use-cases, which means a bigger product. A bigger product, really a bigger anything, is fundamentally harder to move in both nature and in software. It's harder to pivot with lots of users on-board, and it's much harder to innovate effectively. They also require a higher head-count in terms of support, and many more layers of communication due the variety of communication preferences. It also has the likelihood of pushing you beyond what you can handle initially.
This seems to fly in the face of most companies and businesses out there, that have free accounts. How come I offer this advice? Well, quite simply to stay in the game you'll need to grow many shortcomings you both know and don't know yet. If your product gains adoption quickly, you risk losing it all if you can't handle the pressure of it. If you have security issues due to adoption, eventually no one will use your product. If you can't respond to the needs of your users, news will spread like a disease amongst your potential fans. Simply put: you'll want to scale both your skills and size of the business at the same cadence ideally.
What can you do instead? Offer a free trial that's extremely limited in scope, but gives folks a taste of what's possible. browserless doesn't even offer that, we simply have a demo account that interested folks can check out to see if it meets there needs. If it doesn't, then there's no loss in time or money. Do we lose prospective users? Sure, but I'm ok with that at this point since we're meeting the needs of our current user-base and I feel I'm growing at roughly the same speed the business is. Timing here is key.
Closing thoughts
After giving some significant time to this topic, it really all boils down a few forces: loss of time, money or motivation. Most products will eventually find users, either due to changes in the ecosystem or maturity of the product, but you have to stay motivated enough to weather through that. Loss of money is a tough one, especially if you're financed, as you can't really force more folks out of their money without showing some sort of result. Finally; time is the hardest one to weigh, gauge and measure. I can only put a finger on time constraints when the symptoms start showing up in odd places. User sending reminder emails, TODO lists growing longer, or folks leaving the platform altogether. Any one of these is threat enough to put an end to what you're doing.
In all of this one thing has become resoundingly clear: I now know why most people are ok with working for somebody else. It takes the right kind of obsession to make a business succeed, and it's probably a neighboring condition to insanity. You have to believe that, without a doubt, what you're doing can make a difference to someone else. There'll be a lot of negative pressure that it won't, but nearly every great innovation in the past was met (almost always) with overwhelming criticism. The best breakthroughs are the ones that didn't listen and kept on their journey.
Thoughts/questions? I'm always interested in hearing them! Send me an email joel at browserless dot io!