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 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 not doing anybody favors by continuing the charade.
Trying to meet the needs of every single 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 just say "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-suited for it at this time, but would be something we'd work towards. In the meantime, 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 some 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; when all the parts were finally 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 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 (more on that in the next section).
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 them around, as it likely found its 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 clearer. This helps in so many dimensions: reaffirmation, critical feedback, compliments, etc. 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 want to communicate to you. Some love to write short cryptic emails; others will want to call you and physically see you. 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 way in establishing sympathy and listening more proactively. Imitation is the sincerest form of flattery, and responding to folks in the same tone or medium has a lot of value in building great relationships—which is ultimately what we're trying 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, creates instant fans of your service, and grows relationships that can potentially 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, while at the same time cueing them into how things work inside your head. If they, like you, are good active listeners, 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 hidden until now.
You're not selling a pain-killer (and you should be)
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 immediately because it aligned with browserless’ core values. 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, but in order for them to actually pay for something, you'll need to solve a real pain. It can be an inconveniencing 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. For example, I think social networking is 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 a 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.
So, ask yourself: is your project solving a pain? It likely is (that’s how you got the idea), 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 unbalanced 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.
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 down 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 to 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. Why do I offer this advice? Well, simply put: 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. 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 their 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 is key here.
After giving some significant time to this topic, it really all boils down to 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 okay 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 with overwhelming criticism. The best breakthroughs are the ones that didn't listen and kept on their journey.
Thoughts or questions? I'm always interested in hearing them! Send me an email: [email protected], or leave a comment below.