Day 408: Sell Solutions, Not Technology

Something I’ve been trying to get through my thick skull: People don’t pay for cool technology. They pay for solutions.

During the last 9 months of building Browserflow, I’ve been approaching it as a fun engineering and design challenge: “Can I build a robust, powerful, and flexible browser automation tool that anyone can use?”

There’s nothing wrong with this because building things for fun is perfectly fine, but this is an unnecessarily risky way to build a business. Even though I’ve read countless case studies and retrospectives about how building something without validating whether anyone wants it almost always leads to weeping and gnashing of teeth, I still went down that path because, well, I found it interesting to work on.

If I were to do it all over again, I’d focus on solving a concrete problem for someone who’s willing to pay for a solution, and then generalize that solution. In the case of Browserflow, I started with the tool and then looked for what problems it could solve. This might still work, but it’s just a lot harder to get right.

Example of people wanting solutions, not technology: I received an email from a supportive Road to Ramen reader saying that while he wasn’t interested in using Browserflow, he did want data scraped from a particular website. I whipped up a flow, left Browserflow running for a few hours, and got the data he asked for.

The result:

(Side note: When I replied to his email with the results, I saw that he had just sent a follow-up email saying that he had found someone on Fiverr to do it because he needed it done fairly quickly and wasn’t sure when I’d check my email, which is totally fair given I hadn’t replied yet and often write about how infrequently I check my digital communications. But when he saw that I had already completed the job, he paid me immediately even though it sounded like he had gotten the results he wanted already. That was extremely classy of him — thanks R!)

To be honest, I’m still a bit skeptical that Browserflow as it is today could be a successful business. It feels like being able to run flows in the cloud would make it much easier to sell as a service (“Browserflow will automatically do X for you without you having to think about it!”) compared to its current form where you have to run flows yourself. Right now, Browserflow is more like Alfred where you can have shortcuts to make things a bit faster whereas it’d be much more valuable to be like Zapier where it’s serving core business needs. But given that building Browserflow Cloud would be a massive undertaking, I’m going to try to see how far I can take Browserflow with local execution before going down that path. Onward!