The Bootstrapped Founder - Bootstrapped Founder #37: Make It Stick

Dear founder,

It won’t take long before customers start asking for one particular kind of feature: integrating into other tools that they use all the time. They have adopted your product into their routine and their workflow, only to notice that something is missing. Some steps need to be taken to get your product to seamlessly join into the range of other tools your customers use to solve their problems.

You are looking for product–workflow fit. While it’s great to be able to use your product as a standalone solution to their problem, your customers will value it much higher if it comes with two kinds of integrations: input integration and output integration. To provide a basic level of both, build your product to accept and return data in commonly used data formats (such as the eternally requested CSV format). If the workflow requires interactions with cloud services, you will find that most of them provide easily used and well-documented APIs.

Input Integrations

Find out the shape of your customers’ data at the outset of their problem.

Let's say your audience is plumbers who need help requisitioning new inventory of their pipefitting supplies. Do they already have an inventory management system that has an API? Are they maybe using an Excel sheet or a Google spreadsheet? Do they have such a system at all, or do they "go and check" regularly?

Whatever it is, you will need to allow your customers to use the system they already have in place. Forcing them to adopt another system just because your product only works with that is a surefire way to build a tool that your prospective customers won't even try.

Every kind of additional input format you support will open your product to more potential customers. This requires research and expert knowledge of the field you're operating in. Of course, at some point, the fraction of customers will be tiny, a niche within the niche, and their potential revenue will be lower than what it costs you to build and maintain an integration. That, too, requires insight into your market.

Whenever you work with data imports, here are a few basic ideas:

• Integrate the industry-standard format. Many industries have developed common interchange data formats over time, and they usually are specified in great detail. This is an easy choice if you want to support the biggest number of customers.

• Integrate comma-separated values. This is the lingua franca of data. Almost every software tool eventually understands and produces comma-separated values, the CSV format.

• Integrate Excel files and Google sheets. Often, that's the highest stage that your prospects will reach with their self-invented and self-organized systems. These are the systems you intend to replace, so make it easy to migrate the existing data into your product.

• Integrate JSON and/or XML. When there are already existing services and APIs in your space, make your product compatible with their outputs. Remember, your product exists in a landscape of other services, and fitting into your customers' workflow is the way to adoption.

Output Integration

What is true for your customers' workflow before they use your product is also true for when you've solved their critical problem successfully: they need to continue with other steps. Allowing their data to be easily utilized right after using your service will significantly increase your customer retention and turn your product from a nice-to-have into a must-have.

When you look into which data formats your customers expect, look into both the immediate steps that follow and the final outcome of your customers' task. If you can supply data in a shape that allows for both to be maximally valuable, you're helping twice. If you can enrich your customers' data with something they can use later down the road, your product delivers value even when they're done using it.

When you're exploring what shape your result data should have, here are a few thoughts:

• Produce the industry-standard format. As with the input data, this will give you access to the largest group of prospective customers. It will also make sure that other tools that eventually integrate with your solution implement this format, further normalizing the industry standard.

• Allow for CSV data export. Your customers may not need it all the time, but this data format is surprisingly relevant for retention. It's commonly used when your customers want to experiment with what using your data with another tool would be like. If you allow them to do this easily, it can further consolidate your product as an essential part of completing tasks.

• Produce machine-readable data like JSON. A service that can be accessed by humans and machines is twice as valuable as one that can only be used by people. Allow your more technical customers to use your product in a programmatical way, and the impact of your solution will increase significantly. After all, the types of solutions that other businesses can create by integrating your service as one of many are thousand-fold and extraordinary!

• Facilitate reporting. Whatever problem your service solves, it's likely that someone has to report what they have been doing and how well they've done it. For that, make it easy for your customers to export their transactional data, like how often and how much they have used your service. This is also a selling point when you're trying to convince managers and team leads to purchase your product. That way, the problem solves your customers' critical problems as well as allowing their managers to measure their performance—a win-win-win situation.

Integrating Beyond Data Formats

Input and output integrations cover the basic data workflow that your customers have. For deeper integrations, you can build extensions that integrate other SaaS or standalone software products that make up parts of the daily operations of your customers.

Many SaaS products can be integrated programmatically, usually using OAuth or API-key-based credentials. Either way, they can provide a number of interesting opportunities. The most basic integrations enable you to access some subset of your customers' data stored on another SaaS service, either temporarily or until the access is revoked. More advanced integrations will make things like data synchronization, manipulation, and reporting a highly automatable and time-saving endeavor—all of which are highly valued as additional side-effects of a tool that solves your customers' critical problem.

Think about how you can enable other businesses to integrate with your product as well. How would offering a programmatic interface enable other services to provide additional benefits to their customers? How could a service at another part of your customers' workflow benefit from a direct integration? Could that remove superfluous steps like data conversion or export/import? If you can provide a means for developers to integrate your product into theirs, you amplify the reach into your audience by overlapping it with theirs.

On the user-experience side of your customers, consider supplying browser extensions. Often, a little button or link placed into another website can make all the difference. This was the first integration we built at FeedbackPanda. We added a little panda face, already our logo at the time, into the online classrooms by having our customers install a Chrome browser extension. Clicking that button would open a new tab, transmit a bit of information about the classroom to an endpoint on our site, and our frontend would automatically import that information into a form. This was very simple, but it saved our customers a few dozen clicks and a few seconds of typing every time they needed to create a new record. It wasn't very hard to convince people that this was valuable: a 10-second video was all we needed.

Browser extensions are easy to create and deploy, as browser vendors have established browser extension stores that allow for automatic deployments and updates. Building an extension is straightforward, as there is a lot of good documentation available.

A word of warning about browser integrations into third-party websites and services. At FeedbackPanda, we integrated into a lot of online schools' web portals. Those businesses changed their products a lot and without notifying anyone in advance. Since we never partnered with them, there was no way for us to ever learn about this before it happened. Any changes to the data that our extension needed to work would break it, and we would have to release a fixed version. Consequentially, we had to implement continuous automated tests and alarm systems that would tell us immediately when such a change happened so that we could react quickly. As the browser extension stores can take a few hours to distribute an updated version, being quick to deploy a fix is essential to have as few customers as possible impacted by such issues.

If the browser environment has certain limitations that prevent you from fully solving your customers' problems (such as blocking notifications or native filesystem access), you can build and offer dedicated desktop or mobile applications. Only do this if it's required to use your product efficiently. Building, maintaining, and deploying installable applications is a herculean effort compared to a SaaS product. All of a sudden, you have three different codebases and have to support different versions of different operating systems, all with their own update schedules and idiosyncrasies. If you can, restrict your product to a SaaS solution as long as you don't have the resources to build a standalone application.

To make your product easier to integrate with other programs, provide a machine-accessible interface such as a REST API or any other way to automatically ingest data, using a commonly used and trusted authentication method. This also allows you to monetize your product at scale: by offering pricing based on API usage, you can create new subscription tiers that are much more interesting to your more technical users.

The Risks of Integrations

There is a risk of relying too much on these kinds of integrations, which is platform dependence. If integrating with another tool is the only way your product is usable, then any change to that product will be something you have to deal with immediately. If they adjust their product, you will need to make sure your product still integrates. If their business fails, all the customers you gained through that integration may not need your product anymore.

Whenever possible, aim to integrate with multiple competing solutions. Do you integrate with MailChimp? Offer integrations into EmailOctopus, GetResponse, and ConvertKit as well. Should one of these providers go away, you can even help your users migrate to another one that you support.

Be very conscious that whenever you integrate into a service or another service integrates into your product, both services become a slightly more interesting target for a cyberattack. There is value in customer information, both the personally identifiable information of your customers and the business data they keep with you. Be extremely cautious of making any such information easily retrievable through automated means. Always imagine the worst way an integration could be exploited, and protect your customers and their data with a level of attention that borders on paranoia.

Make sure you're legally allowed to integrate with the services and sites you choose. Although web-scraping content has been declared legal in many jurisdictions, not every business appreciates automated integrations into their products or data. Be ready to ask for permission and study the Terms & Conditions of the service with which you interface.

When you allow for integrations into your service, keep a close eye on the performance impact they have on your infrastructure. While you have complete control over your own software, the interactions caused by third-party products cannot be easily influenced. If a service is hammering your backend with hundreds of thousands of requests per second due to a misconfiguration, you need to be able to maintain a stable system. Be prepared to cut off access to your service for specific consumers, and build a resilient infrastructure that can deal with heavy spikes of traffic. You don't know how easily the delicate interconnectivity of services can be upset by a simple programming error somewhere in one of the systems.

In short, think of the institutional risks of integrating with other services. It's perfectly fine not to integrate with a service if you fear that it could cost you dearly in the future. Integrations are supposed to amplify the usefulness of your product, not bury a time-bomb beneath the foundations of your business.

Made to Stick: Fostering Extensibility

There are a few ways to make a product that sticks around. You can make it an integral part of a vital workflow, or you can make it so compelling that people will change their workflows to fit the product. A way to do both of them at the same time is to create an extensible product.

There are two main ways of extending your product: extending the interface or extending the service itself.

Interface extensions will allow your users to create, use, and manage widgets that integrate into your service and will enable them to do specific, non-generalizable tasks directly in your product. An example of this would be a widget that displays industry-specific time-series graphs drawn from your data.

Service extensions will allow your users to integrate plugins that enable them to use specific, non-generalizable functionality to manipulate the data that your product uses. An example of this would be a plugin that would pull in weather data from a public API into your supply chain management service.

If you understand your product to be a source and a target for integrations from the start, opportunities for extensibility will appear all over the place. Take the ones with the highest impact on most users and implement them first. In some cases, you can enter partnerships with the companies that sell the service with which you integrate. This allows for cross-marketing and mutual value add.

You can find this article on the blog. I also recorded a podcast episode where I go into detail how we made FeedbackPanda extensible from the beginning and what obstacles we encountered.

If you'd like to support this newsletter, please consider checking out my recently released book Zero to Sold, available on Amazon and Gumroad. If you have already read the book, I'd love to ask for a rating and a review on Amazon. That would help me out a lot.

Links I Found Interesting

Carol Chen wrote a very insightful post on why she doesn't want to be a founder. While the article mostly talks about VC-backed businesses, a lot of the risks and fears ring true for bootstrapped founders as well. The Hacker News discussion also has a lot of stories of business ventures going wrong. Why am I including this article in a newsletter for bootstrapped founders? Because you need to see the dark side of entrepreneurship to understand that, like all other things, there is good and bad in starting your own business. I've been a fan of websites like Failory that highlight the businesses that failed. I learned more from my own failures than from other people's successes, and I highly recommend looking at why you should not be a founder before choosing to be one.

When it comes to breakout successes during a disaster, the meteoric rise of Zoom during the ongoing pandemic is a very notable example. I was amazed to find out that during the 1918 pandemic, a completely different startup had a similar surge in popularity: dixie cups. Turns out we have disposable paper cups because people wanted to stop the spread of a disease. Who knew!

Bootstrapper Success Stories

Let's start with a bittersweet story. Steven Hylands of Lowdown announced this week that the team would close down the current version of Lowdown, their Slack digest tool. They targeted larger communities and businesses, and it appears that while their customers are aware of the information overload that Slack generates, it's not a painful enough problem for the organizations per se. I call that successful invalidation! That's why the next version of Lowdown will be more personal. Steven is a great guy and a founder who has been very active in the bootstrapper community. If you use Slack and think something can be done to organize information better in there, check out the private beta for the new Lowdown.

A big milestone happened for Kevin Conti this week: his side project paid for its own expenses. That's one of the first and most important steps in the stairstepping approach: first you pay for the project, then it pays for itself, and ultimately the project pays you. That's two out of three. Let's see where softwareideas.io will take Kevin! Right now, it's at $10.000 ARR. That's quite promising.

Finally, Jon Yongfook's Bannerbear, featured in this newsletter many times in the past, has reached $2000 MRR. Jon points out in the post that growing a business can feel painfully slow in the beginning, and it takes a lot of faith and perseverance. Glad to see Bannerbear doing well, two years after being started. I bet in two years time, we'll see a solid 5-figure MRR being reported. Thanks for sharing, Jon.

Thank you for reading this week's edition of The Bootstrapped Founder. If you like what I wrote about, please forward the newsletter to anyone you think would enjoy it too.

If you want to help me share my thoughts and ideas with the world, please share this episode of the newsletter on Twitter or wherever you like, or reach out on Twitter at @arvidkahl.

See you next week!

Warm Regards from Berlin,

Arvid