Building a Slow, Boring Product: 7/16/2021

View Email Version

The technology world is flooded with people who are looking to be the next Steve Jobs, Bill Gates, or [Insert your favorite tech m/billionaire here]. Often, when founders start new companies, they have dreams of big money via the development of some world-changing product. They cling to the “make a dent in the universe” phraseology, which automatically sets up a massive mountain to climb both in terms of the pressure to come up with an idea big enough to “make a dent,” and in the inevitable step of luring investors to buy into your idea by giving you lots of cash to make a go of it…at which point they are going to demand break-neck growth in order to ensure their investments pay off in a reasonable amount of time (Whew, that was a nice run-on sentence).

Alternatively, I’ve been thinking a lot about what it looks like to build a small, boring product - what I’ll refer to as a SBP.

When I say “small” I mean something you could build and manage alone. Something that could be built quickly. Something that would (hopefully) never outgrow what you alone could handle.

When I say “boring” I mean a product that isn’t sexy. It’s functionality isn’t world-changing, rather it gives a nice solution to a small market and is something that “just works.” Something that will never be the next Facebook, Google, etc. And most importantly - something that only does one thing, but does it very well. No bells and whistles, but yet it solves a real problem.

This is easier said than done.

When it comes to building a technical solution, simplicity is often hard to pull off. Scope creep is a perpetual menace of the Solutions Architect trying to curb the desire for building more and more functionality into a product.

Assuming that one can be content with the idea of building a SBP, there are numerous benefits for this approach:

Less Risk - SBPs usually do not require a lot of investment. The scope is small enough that the time involved and the initial capital needed is minor compared to a larger enterprise offering. SBP projects are more suitable to a bootstrapping mentality.

Shorter path to MVP - the time it takes to go from an idea to a minimum viable product (MVP) is usually shorter. Because SBPs are usually focused on solving a very focused problem, the amount of effort it takes to build or implement the initial solution is less. This allows the builder to get to market quicker and begin the process of receiving customer feedback.

Slow, Iterative Growth - slow and steady wins the race, right? Keeping things small and boring gives you the time and the space to really think about new features (if you even want to add any). You can think about the edge cases. Rather than continually racing to build as many features into the product as you can, you can ensure that you are building the right features.

I’m almost finished with the current book that I’m working on, which means I’ll soon need another project. As I’ve ruminated on the idea of SBPs for the last few months, I thought it might be fun to run to turn my attention toward building a SBP and share the experience with readers of this newsletter each week. I’ve come up with a project that I think might be a good candidate to try and build. So, stay tuned for more information about the project.

Field Notes from the week:

Each week I include a list of my favorite articles, podcasts, videos, tweets, books, people, etc. that caught my curiosity. I hope you find something below that you can enjoy as well.