We were sitting at the dinner table when I received an email from our error tracking tool. I quickly glanced at my phone, got up, and went into the office. There, I dove right into the error and reached out to the customer who was affected.
They had problems scrolling in a menu that was located one of our settings dialogs.
I got up from the family dinner table for a harmless scrolling glitch.
This level of attention to detail is not healthy when you’re running a bootstrapped business. There are things you have to deal with, for sure. And then there are settings dialog scrolling problems.
I have since learned to find a healthy balance between dealing with problems when they occur and deferring them into the future.
You don’t need to be obsessed with being perfect for running a successful bootstrapped business.
I will share rules of thumb about how to determine response urgency, how much effort to put into a feature before releasing it, and how to keep aligned with your long-term plans in the face of constant interruptions in your day-to-day operations.
For many overwhelmed founders, the problem lies in thinking that every error has the same importance. It often feels that way because whenever something happens, there is a potential for it to be disastrous. It’s human nature to expect the unexpected, and unless you train yourself to have a positive outlook on these events, your animal brain will default to the worst-case scenario.
The Perfectionist’s Trap #1: Errors
In reality, errors and problems are rankable, and some of them are small enough to be safely ignored. Creating a mental model to quickly and accurately sort errors into well-defined categories will allow you to train your brain to assess incoming reports without obsessing over what may or may not happen.
A sound system for this is the Eisenhower Matrix, the famous cartesian plane with four quadrants along the axes of “Important/Not Important” and “Urgent/Not Urgent.” If you can place an incoming error report anywhere else than the “Important & Urgent” quadrant, you can deal with it another time. You don’t have to drop everything else right away.
In general, Prioritization Frameworks will help here. They are often used for feature development or business goals, but any triage operation such as error categorization benefits from them as well.
The result of using a framework like this will be immediately apparent: not all errors are equal. The most crucial difference between errors is that some are root causes, and others are consequences. Prioritizing the root causes over the resulting cascade of errors will allow you to solve problems with maximum impact. Those will be harder to fix, but that extra effort will save you a lot of time down the line.
On the opposing end of the priority list, you will find a few small, irrelevant bugs. Reframe your thinking so that “having a few unresolved bugs is fine as long as you get to them eventually.” The perfectionist in you will want to get to bug inbox zero, to a state of tabula rasa. That’s a fool’s errand, as new problems appear all the time in business. You will be chasing bugs instead of creating value for a business. Trying to “solve it all” will lead to paralysis.
Nobody but yourself expects your product to be perfect. Your customers are well aware that you’re building something, and that it takes a few iterations to get things right. They’ll be grateful for making their lives more comfortable with what you already provide. They might complain about things that annoy them, but they are not your worst critic; you are. Understand that all of your expectations of perfection are coming from inside yourself.
I found it helpful to envision where the baseline was before our customers started using our tool. Every feature we provided would catapult their capabilities way north of that baseline. Just providing a service slightly better than the baseline would be enough. Everything else is extra and not expected.
Another way of handling errors efficiently is tackling the most critical errors first instead of the most recent ones. Recency is often confused with urgency, but they are rarely connected. Going after the important and impactful errors first will add the most value to your product over time.
The Perfectionist’s Trap #2: Technical Debt
Another problem lies in thinking that technical debt has to be avoided at all costs. Particularly if you’re a technical founder who has been around the block a few times, you will know how tech debt can pile up into an unmaintainable heap of convoluted code and components.
But that usually takes a long time. And it only really matters if the business survives long enough to see it happen.
If you try to prevent technical debt at all costs, you will release later and less often, reducing potential value creation. That value usually translates into revenue that can eventually be employed to deal with tech debt down the line.
If you try to prevent technical debt at all costs, you will tend to over-engineer your product. That, ironically, creates more technical debt in other places, as your perspective on “good and clean code” as a founder might be very different from the perspective of a future developer who has to extend and maintain your product.
As a bootstrapper, you don’t take on outside funding on purpose. Technical debt is the one kind of debt you will always have to take on as a bootstrapped founder. And unlike VC money, no one will dictate the course of your business when you take it on.
Deal with technical debt eventually. Set aside a week or two to assess and fix the most dangerous occurrences. Don’t let it impede you from providing value to your customers.
Reframing Opportunity: Customer Expectations vs. Your Own
If you obsess about solving every single error immediately and building a system that is free from technical debt, you have an alignment problem. Your expectations of product quality are disconnected from your customer’s expectations.
Reframe your thinking about what customers expect. Here are a few assumptions to internalize whenever your obsessive brain rears its ugly head.
Assumption: Value is Transparent, Code is Opaque
Customers only see one side of your product. They see the interface that is meant for them to use. Their perception of the product is informed exclusively by the value they derive from using that interface. They don’t see code, and they don’t understand the complex underpinnings of your deployment automation. All they have to work with is the user interface of your service.
Your customers expect your product to continuously deliver the value they have come to expect from it during their time using it. If their productivity is not severely limited, they will not care. Code quality, non-critical performance issues, all this matters little to someone who needs to get a job done. Small bugs are mostly ignored as long as they don’t limit the core functionality of your product.
Align your expectations with your customers. Everything that threatens value delivery should be a priority. Everything else is by far less critical.
Assumption: People Find Fault with Themselves Before They Blame You
When we run into a problem as users of technology, a funny thing happens. We are conditioned by years of interacting with technology to assume that, as a user, we are at fault for not using it correctly. We think that we have misinterpreted the interface and that we should know better.
Your customers will often think they’re at fault. They will try to deal with an issue a few times, and either give up if it’s not essential or reach out only after many attempts if it’s important enough.
That gives you time. If you fix the right things quickly, your customers will never know that it was a problem on your end, to begin with.
Sometimes, customers need to learn how to use the tool correctly. Your interface is likely complex in some parts, and that confusion can only be alleviated by showing your customers how to use it correctly. After all, most SaaS products become expert tools at some point, and only in rare cases can services retain a level of simplicity and ease-of-use that makes instructional documentation unnecessary.
However, documentation is still useful for the edge cases of using your product and for customers that deviate from the expected level of technical skill and literacy. Aim at creating clear documentation that is multi-modal (images, video, and text) and is on the level of your customers.
Your customers expect that they will be able to help themselves. They expect problems to be solvable by thumbing through the manual or reaching out to some sort of customer support. For critical issues, they expect them to be solved quickly.
Align your expectations with your customers. Instead of building a perfect product, build out processes that allow you to fix critical errors quickly while keeping your customers informed. Document your product so that customers can help themselves if your product is complex enough to warrant such instructional material. It’s easier to write proper documentation than to engineer the world’s most usable product.
Assumption: Only Noticeable Improvements will be Evangelized
Happy customers whisper to their peers about your product. Unhappy customers will shout. That’s why your focus should be on making most, if not all, of your customers happy enough to evangelize your product to their colleagues and friends.
Here’s the thing: your customers will only talk about things they can see. You rolled out a new feature that shaves off twenty minutes off a daily task they need to complete? You can be sure they’ll talk about that. Did you roll out a version upgrade on your database that speeds up all queries by 2.7%? While your customers might notice slightly faster-loading pages, they won’t rave about that. You optimized your Docker images to use less RAM on your production system, allowing you to spin up two more instances? Crickets.
Your customers expect a beneficial change to be noticeable. They will notice everything that makes the service perceivably better, and they will applaud you when you fix important bugs quickly. Small edge cases and micro-optimizations won’t register with your customers, particularly if they’re not technical enough.
Align your expectations with your customers by prioritizing interface bugs and feature rollouts over small optimizations. This is not to say that you should never do these things, of course. Schedule a week every month to deal with the invisible things in the background. But always focus on what the customer experiences. That is what they will talk about. If you can reliably deliver here, they will rave about your company, because most businesses don’t focus on that.
Assumption: There are No Trophies
Remember, there are no trophies in business. Well, there may be awards, but to the reality of your business, they don’t matter. You started the business to live a better life by providing value to customers, not to win trophies.
Don’t obsess about doing it perfectly, obsess about providing value and making a difference as much as you can. By focussing your efforts on solving the critical problems of your audience, you will stay clear of dealing with things that don’t have an impact on the value you provide.
If you’re looking for trophies, search for customer testimonials. Collect screenshots of every occasion where a customer shares their delight with your product. That should be more than enough motivation to stop obsessing about your product and start focussing on empowering your customers so much that they just have to shout it from the rooftops.
At FeedbackPanda, I struggled with this obsessive behavior a lot. I felt that the product was an extension of myself, and as I held myself to high standards, so did I hold the product.
In reframing my expectations, I learned to see the product for what it truly was: a means to empower and enable other people. It matters very little what I think about the code or the configuration when the customer only ever needs a good enough solution to their problem.
The moment I scrapped my unrealistic goal of a perfect piece of software and instead focussed on building something that elevated as many people as possible from their current status quo, I found it much easier to prioritize, defer, and ignore the little things.
In aligning my expectations with those of our customers, I freed myself from obsession and learned how to help other people help themselves.
I hope this article helps you accomplish the very same thing.
