This article is part of The Preparation Stage section of 📕 Zero to Sold: How to Start, Run, and Sell a Bootstrapped Business.
Before the internet made transferring large amounts of data cheap and easy, software used to be distributed on CDs or DVDs. For any given application, there was the “Golden Master,” a final version of the software, ready to be copied millions of times.
These days are over. Every day, millions of software updates get dispatched. For many services in the bootstrapped world, customers will never notice: they’ll just refresh their browser pages, and the latest version of the application will just appear.
With updating being so easy, no product is ever finished. Even when you release what you think is a feature-complete version of your product, it will only be “done” for a while.
There is one main reason for all software being only temporary: the changing circumstances of your customers. It can manifest in many shapes, for many reasons: as entrepreneurial dissatisfaction with the status quo, a reaction to movements in the industry, the competitive landscape, the regulatory environment, or a reaction to changes in needs and your understanding of your customers.
Let’s look into all of these reasons in detail and see how being able to update your product quickly can be optimally leveraged for your bootstrapped business — and when not to change things.
Entrepreneurial Dissatisfaction
Every product is the result of a measurement made at a point in time: you validated your audience, their critical problem, and your solution. You decided on the scope of your product from that information. But that data isn’t static. It wasn’t even complete when you went through all of those validations.
In short, your analysis will always be imperfect, because you don’t have the full insight: there is no perfect vision in the ever-changing world of entrepreneurship. Your interpretation of what is needed to solve your customers’ critical problem will be incomplete, or a premise may have changed over time.
What matters is what you do about it. Your vision of the product is the touchstone of what should be in your product and what shouldn’t. If your vision changes, so should your product.
It’s a good idea to reflect on your assumptions, your analysis, and its accuracy every now and then. I recommend doing this consciously at least once a quarter, as a form of Continuous Validation of the business, the product, and alignment with your vision.
We did this in a very informal way at FeedbackPanda. Every few months, Danielle and I would sit down and talk about the feature suggestions and ideas we had come up with or received, and checked if anything among them was interesting for making the product better. We dismissed much more than we considered, and it kept the product current without being bloated. We even removed features at times.
Your product will never be finished because your audience and their problems are moving targets that you learn to see clearer the longer you work at it.
Changing Regulatory Environments
When the General Data Protection Regulation (GDPR) regulation passed into law in May 2018 in Europe, companies all over the world frantically added cookie consent banners to their websites. They started implementing data protection features into their products, because all of a sudden, there was a chance they’d be fined heavily if they didn’t change their products.
We had been careful in not collecting any potentially dangerous information with FeedbackPanda even before GDPR was announced, as I felt we should avoid having payment information or customer address information stored in our database. I trusted that services like Stripe or Auth0 were more capable of securing this kind of information than I could ever be. As a result, we didn’t have to do much, other than adding a pesky cookie consent banner to our marketing website.
In some industries, there are already extensive protocols to follow: you need to be PCI compliant when you work in payments, you need documentation for HIPAA compliance the moment you touch medical data.
Some markets are relatively unregulated when you start, but are targeted by lawmakers eventually. We witnessed this in the Chinese EdTech landscape. Our mostly North-American customers were contracting for Chinese Kid English companies. When Chinese authorities decided that Chinese children could not receive after-school tutoring after 8 pm any longer and restricted the amount of information the schools were allowed to share about the students, the Chinese Kid English companies had to change their product and business models significantly. Some companies even closed because the regulation made it impossible for them to operate at a profit.
Your product can never be finished because the legal requirements and limitations of an industry are always changing.
Changing Technology Landscape
There are domino effects that can affect your business in surprising ways. Here is another FeedbackPanda example that illustrates the insane amount of dependencies and complicated interconnected parts of the software world.
Let’s set the stage: the Chinese Kid English companies our customers worked for were using web-based teaching platforms to facilitate video-based face-to-face teaching. Our product FeedbackPanda integrated into these platforms using a browser extension.
Everything was humming along until it didn’t.
In 2017, Adobe decided to end-of-life Flash, its popular multimedia software and browser plugin. The maturity of web technologies like HTML5 and WebAssembly made it less and less appealing to support an outdated plugin, so they decided to stop supporting Flash by the end of 2020.
Consequentially, browser vendors had to react. The security implications of this decision reached far. Before the end of 2020, all major browsers would have to phase out their Flash support, as integrating software that is not receiving security updates is a giant risk for browsers, which are applications used by millions of people every single day.
So the team for Chromium, the technology behind Google Chrome, set a roadmap to phase out Flash support over several years. One particular step along the way was disabling the flash plugin by default by July 2019. After that point, the user of Chrome would have to reactivate Flash every single time they started the browser.
When this change was a few months away, the developer community started talking about it. Within the development teams of the Chinese Kid English companies, it must have made the rounds as well, as all of a sudden, these companies understood the complexity of their tech choices: the system they used for video calls was built on Flash. And if they didn’t change anything soon, their teachers could not teach reliably any longer, and would not be able to teach at all by the end of 2020 when their browser would automatically update and disable Flash support.
Now, they had a few choices. One choice was to switch to a different video call technology provider, finding one that used HTML5 video, something that would continue to be supported.
But they did something else. The schools chose to stick with their video provider. The problem now was the nature of evergreen browsers, automatically updating eventually. So they went for something that we didn’t expect: they froze their teachers’ browsers in time by having them teach through an Electron-based application. Using Electron is like shipping a web application packaged with a browser to run it. And with a package, they could stay in control of the update process, effectively freezing their teacher’s Chrome version in a pre-2020 state forever.
Problem solved for the Chinese Kid English companies. They now had to release updates both to their website and the teaching application that would load their site in that old browser version, but they were out of the danger zone.
But for FeedbackPanda, it was the opposite. By moving away from a browser-based teaching portal to the Electron-app-based solution, our browser integration would not work anymore. Within this Electron wrapper, browser extensions could not be installed anymore, which is a limitation the schools chose to accept for not having to spend millions changing their video call provider.
For us, it meant that a major integration into the workflow of our customers was at risk. The schools were actively encouraging their teachers to teach through the app, and without having ever planned to do so, I started researching ways of integrating browser extensions into standalone Electron applications.
I finally found a solution that would allow our customers to integrate the same way they already knew from their browsers into their new teaching apps. This integration involved another standalone Electron-based app that our customers would have to install and use. Hence, it wasn’t as easy as installing an extension in a browser, but it still was much better to have a few extra steps than not to use our service at all.
This kind of change can happen on a schedule as it did with Flash. It can also occur from one day to another, as it usually does when Google releases an update to its search engine algorithms and puts whole niches out of business.
Your product can never be finished because it’s embedded in a world of changing technologies.
Changing Customer Workflows
When industries adopt new and improved practices, workflows change. There are four kinds of changes in a sector that can trigger this, which can be differentiated along the two axes of “are the core activities threatened?” and “are the core assets threatened?”
First, you have the one with the lowest chance of making you change your product: progressive change. Core activities and technologies stay mostly the same over time; just minimal change happens. Think of airlines, an industry that has changed very little over the last decades. If you have a product that integrates with the systems of this industry, it will not need to be changed much over time.
Second, there is creative change. In the movie industry, technology gets improved because there is a desire to become better and create things that are new and exciting. New technology can change whole areas of the industry very quickly, and that adoption comes with a change of how things are getting done. Assets are being developed and improved, leaving the activities mostly the same.
When only core activities are threatened, we call it intermediating change. Here, the fragility of interpersonal relationships leads to changes in how things are done: look at how car dealerships used to work and how much has been changed by technology and ubiquitous information. The power dynamics of a sales relationship have flipped, and so have the processes in the industry.
The most dangerous kind of change is radical change. Here, both activities and assets are threatened, and everything can change. If you have ever seen a rotary phone, and wondered what happened to the businesses that produced those? Remember travel agencies? When people book vacations today, they rarely need to leave the house. Travel agents have to approach marketing and sales much differently today. If you have a product that helps travel agents make sales or coordinate travel plans, you will have to react to seismic shifts in your industry and provide solutions to the problems of today.
Your product is never finished because changes in the industry you serve will change the workflows of your customers, forcing you to adapt your product.
Changes in the Economic Impact of a Feature
There is also the possibility that a change to your business or product has significant side-effects that will turn something that worked well before into something harmful for your business.
The example of Baremetrics introducing a freemium plan illustrates this clearly. They made much of the functionality of the paid subscription levels available to free accounts in the hope of finding more leads and have users see the value proposition more clearly. Soon after launching the free plan, the free users started to outnumber paid users and the amount of data that Baremetrics had to process started causing performance and database issues. Customer support was doubly affected: there were all these new freemium customers to support, and the paying members needed help solving the problems caused by the performance issues.
Their churn went up, their revenue didn’t hit the expected goals, and they called it a failed experiment. But for both the freemium attempt and for turning it off eventually, they had to change their product. Ignoring the changes they had to make as they ran into scaling issues, this is product work that was not in the initial vision, but needed to be grafted on at a later stage.
If a feature of your product turns from lead magnet into a churn multiplier, you need to remove it. If a feature you previously considered to be a bad idea turns into a potential gold mine, you need to add it.
Your product will never be finished because the economic impact of certain features is dependant on the choices you make after or before implementing them.
Bugs: Correcting the Dysfunctions You Never Meant to Create
No piece of software will be error-free, because it is built by fallible beings, operated by fallible beings on complex machines, and consumed by fallible beings haphazardly operating even more sophisticated machinery. There will be glitches, and there will be errors.
While it’s every developer’s ambition to squash these things before they hit the production systems, some will sneak through, and you will have customers reach out and report them, often in a very agitated state.
I’ve learned to use this as a brand-building exercise. When people reported bugs in the FeedbackPanda interface, I would calmly thank them for the report, tell them that I was right on it, fix the bug right there and then, and immediately tell them that it was fixed right after deploying the new version of our service. At times, this took less than 30 minutes from the customer service chat until the fixed version was deployed.
This reliably resulted in amazement and, in some cases, even converted the customer from a mere user to one of our loudest evangelists. Being heard is one thing. Being listened to and making something better is another. If you can give your customers this feeling, they will feel valued, understood, and will become your allies and public defenders. Many of those customers would rush to our aid whenever we had technical trouble, telling people on social media about their experience and that they knew we would do everything in our power to restore the service. This gave us precious time to fix the problems instead of talking to customers in a variety of Facebook groups.
With every bug you fix, your product becomes better — hopefully, as long as you don’t introduce new bugs by fixing the old ones.
Three Ways to Think About Features
I see three distinct approaches to features, of which one is often overlooked: you can add them, you can change them, and you can remove them.
Most founders love to add new features, as they often equate features with the potential of generating value. Whenever new customer needs get discovered, you add a feature. When you want to start value-nurturing your customers, showing them how much they benefit from your product, you add a feature that does that. When you want to turn your product into a network-effect engine, you add a sharing feature.
Founders are also happy to change and adjust features when needed. When customer needs change, you change your features. When your business is moving up-market or down-market, you adjust your functionality.
Only the fewest entrepreneurs are happy to remove features from their products. Even when customers don’t need a particular activity anymore, the feature is left untouched. When a feature was built to solve a need that turns out not to exist, it stays in the product. Even when a feature is clearly damaging in terms of economic impact, we don’t remove it immediately.
Why is that? What makes us so hesitant to remove what we can see isn’t working? It’s the thing that makes an entrepreneur great: boundless optimism. Here, it’s just applied the wrong way and mixed with an unhealthy dose of the sunk-cost fallacy. That fallacy states that we perceive something as more valuable than it is when we have spent considerable resources in creating or attaining it. We will rather “see it through until the end” instead of counting our losses and getting rid of it.
If you have a feature that no customer uses, remove it. I did that with a very specific button in our interface that we put into the product as a means for our first few users to be able to migrate their data from before we had integrations into their online classrooms. The button in question would allow them to assign a unique ID to a record that we couldn’t detect before the integration, but would automatically assign and use when the teacher had the browser extension installed. After a few weeks, all teachers were effectively migrated. Still, it took me months to remove that button.
And when I removed it, a single user immediately complained about it being gone. In an utterly incomprehensible way, they had started using our product with their own self-designated IDs for their records, which had no impact on our system but were a means for them to add more information to their data. When we removed the option to change that information, they started complaining.
It gave us a good insight into how some people might be using our product in unexpected ways. Removing features will do this; it will unearth the hidden outliers, the users deviating from the conventional path.
If you have a feature that is damaging to the value of your business, remove it. At some point, I envisioned that we should be able to show each teacher extremely detailed statistical information about their data, right on everyone’s dashboard. But with thousands of teachers having thousands of records, the calculations involved were very resource-intensive, not unlike the Baremetrics example I’ve mentioned before. I had to cut back on displaying this information on the dashboard and moved it into a separate component that would only load and calculate data when a user requested it deliberately. Crisis averted.
Finally, if you’re building a network-effect-based product and you find that a feature discourages your users from participating in the network, remove it. This friction can severely impede the growth potential of your product. Remove all obstacles and extra steps that keep your customers from engaging in network-building activities.
While you will likely be adding and changing features more than removing them in the early stages of your business, prepare that eventually, you will need to remove features. Avoid becoming too attached. I know it hurts to remove something you spent a lot of time on. However, you’d rather have a slim and focused product than a behemoth that does a thousand things, but none of them well.
The Kind of “Finished” You Never Want to See
The only time when your software is actually finished is when it has precisely zero users and no changes to respond to: when your business has failed. That will be the day when you can stop looking at your market and your customer’s needs. Any other day is an opportunity to improve your product.
Your product will never be finished. It will need to adapt to things within and without your control. Leverage the fact that it is easier than ever to deploy a new version of your product quickly and give your customers the best experience you can provide.
