Build for Value, Not for Applause: Product Management Under Heavy Constraints

Reading Time: 5 minutes

A bootstrapped founder will have very little time to devote to building things that don’t matter. Everything you do in your bootstrapped business should have a meaningful impact on moving your company towards a state of stability and growth. Bells and whistles are the least of your concerns when you’re trying to get to profitability.

To accomplish this, focus on maximizing the value that your product is capable of producing. Three major approaches should go into any product decision: 

  • It should maximize qualitative impact: “How well does it solve the customer’s problem?” 
  • It should maximize quantitative impact: “How many customers are being helped?”
  • It should provide a minimum of usability: “How easy is it for the customer to get their work done?”

As bootstrappers, we have no time to deal with things that don’t provide value to our customers and hence our business. Let’s take a look at how you can accomplish all of these three things when you decide how to build features for your product.

Maximal Qualitative Impact

Focus on the “Hot Paths.” This is a software engineering term for the parts of your software that are running much more often than others. For a photo upload platform, that would be the part of the software the resizes photos into thumbnails. At the same time, for a social media website, it’s likely the algorithm that determines what is shown in your user’s social streams. What unites all these software components is that if you speed them up even slightly, it will result in a significant impact on the whole product.

You can also extend this concept beyond software. What are the hot paths in the workflow of your customers? Which things to they need to do over and over that your product doesn’t help with yet? Is there anything you can speed up significantly that would impact the day-to-day activities?

At FeedbackPanda, we found a simple thing that was such a hot path in the workflow of our customers. Many teachers were putting a little sign-off text at the end of the student feedback they created to let the parents of their students know about their availability in the near future. As this changed from day to day, it didn’t fit into their feedback templates, as those were meant to contain information about the curriculum, not the teacher. When we noticed that teachers were copying and pasting this little bit of text into their finished feedback, we quickly added a centralized “signature” feature, where they could add their sign-off to their generated feedback automatically, saving them a few seconds every time they used our product. Over a day, that’s a few minutes, and it quickly adds up. By adding lots of features like this, we shaved off a few hours a week just by optimizing the hot path.

Within your application, this can be applied by looking at performance. If a screen that your users use a hundred times a day loads a second faster, that’s a few minutes saved at the end of the day. If you measure which parts of your service your customer use most often, you will know where your optimization efforts will be most impactful. 

You can accomplish this on the user-experience level by using tools like Hotjar and CrazyEgg, which call themselves Behavior Analytics tools, and are mostly recording your user’s sessions. They offer heat maps and full session recordings, which are very helpful but also raise many privacy questions. If you integrate these products into your product, consider making them an opt-in choice for your customers. People usually don’t like being watched.

A less intrusive way is collecting anonymized metrics from your frontend code by counting how often a particular page or component is instantiated or used. The details will be unique to every product, but the idea is the same: find out what people use most often and make it better. Services like Amplitude, Heap, or Pendo will help with that.

Consequentially, you will avoid wasting time by ignoring the cold paths. If your users rarely use a non-critical feature, it makes no sense to optimize it, even if that is easier than speeding up another part of the product. Just make sure that the features that are rarely used but at the same time very important are working well enough, like reliably submitting a report before a deadline after weeks of working in it.

Maximal Quantitative Impact

Whenever you invest time and money into a new feature or an improvement, make sure it impacts as many customers as possible at the same time. It should provide the highest potential value to the largest number of people. Don’t focus on something that only 10% of your customers can use. You will be able to add these things at a later point when you’re swimming in resources. Notably, in the beginning, any change you make to your product and business has to be a meaningful improvement over the status quo.

Over time, you will likely add a few things that help a few people a lot. But to gain critical mass, you need to start with something that helps a lot of people at least a bit. The idea here is to turn your earliest customers into evangelists for your product, who will shout it from the rooftops. If you only build things that amaze a few of them, that’ll be fewer people to do your marketing for you. 

There will be the odd exception of a feature that is created for a small but vocal segment of your customers. Be careful not to do this too often, or your product will move too far off the path of being useful to all your customers, not just the loud ones.

Measuring quantitative impact works the same way you would measure hot paths since those measurements of a qualitative use are at least partially quantitative as well. For each feature, count and plot how many of your users actually use it over reasonable periods. Rank by most used feature, and look into potential improvements there. For new features, making sure that they will resonate with all of your customers can be checked by adding a mock button for the view/component you don’t have yet and present the curious users who click it with a popup promising to implement it. Measure how often people click on that button, and when a threshold is reached, you can consider building it.

Minimum Usability With Maximum Simplicity

When you build features, it’s not likely that you will release a fully-featured and highly polished version on your first deployment. I would even consider this a waste of time as it would take far too long and would lack any meaningful validation. For that reason, you should release features as soon as they provide the basic functionality they are supposed to allow for.

That does not mean your product should be ugly and look scrappy. A usable and clean interface is a valuable feature in itself. However, don’t go overboard with the optics. Remember that your solution has to be better than what your customers have used before using your product. It does not have to be the best possible version of itself just yet.

That said, you can make sure to have a baseline of usability by using a UI framework from the beginning. Frameworks like Bootstrap, TailwindUI, or Material Design will allow you to build all of your components, views, and pages using a coordinated and cohesive design approach. With predefined layouts and interface elements, you can be sure to have a good foundation from which to build your features. 

Whenever you can, reduce clutter and complexity. If configuration options can be removed from a view and put into a configuration dialog, move them over. If something isn’t used most of the time, having it linger in the interface might be more of a distraction than helpful. Keep your interfaces as simple as possible. 

In many cases, this will go against the express wishes of your customers. In my experience, users will always go to “just add a button for X” as a suggested solution to their immediate problems. Well, your users are not designers or product managers. All that this suggestion should do for you is to trigger some research into the underlying problem and how you can best solve it without adding complexity to your interface.

In the Survival Stage of your business, focus your efforts on creating on the features that make your service noticeably better for the majority of your users without making the product harder to use. If a feature design ticks all these boxes, go ahead and build it. If it doesn’t, stash it for now and build something else that does.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.