Building a Small, Boring Product

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. Small in scope, managed by a single person.

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.

As I’ve ruminated on the idea of SBPs for the last few months, I’ve come up with a few projects that I think might be good candidates to try and build. After sifting through a few of the ideas, I’ve settled on my first SBP - a web app targeting gymnastics coaches. I don’t have a name for it yet, but here’s a rundown of the problem I think exists and my solution.

The Problem

My wife coaches gymnastics. We have four children who are in gymnastics. I’ve spent countless hours sitting in gyms across the state for almost a decade watching the hustle and bustle of competition. In other words - I am neck-deep in the gymnastics world.

One of the things I repeatedly see coaches at competition doing is working with printed spreadsheets or using the pre-printed score sheets to track their team’s scores. Once the competition is done, there is no easy way outside of spreadsheets to see or analyze this data historically without a lot of effort. Not only that, but keeping track of all the papers and passing around spreadsheets between coaches is very cumbersome and chaotic.

The SBP Idea/Solution

My solution is simple - a centralized, web-based application that allows coaches to manage scores for all of their gymnasts.

There are a handful of mobile apps that primarily target parents, but I have not seen many (if any) that are built specifically with the coaches in mind.

Coaches have a slightly different goal when logging and looking at scores for their team. They want to be able to see trends, analyze scores, make notes, and track a gymnasts progress over the course of their career.

Of course, there is much more that goes into analyzing a gymnast’s progress than just tracking their scores, but having a central location to manage it all would make the process much easier. Once you have a central repository to store the data, several other possibilities begin to open up.

But…it all starts with the simple function of centrally tracking scores.

As a coach, a product like this would provide a number of benefits:

  • A Single/Centralized Source of Truth - no more storing piles of score sheets or emailing around different versions of spreadsheets between coaches. Everything is located in a single web app. If you need a spreadsheet, you can export the data to CSV or Excel as needed. But, you always have a centralized archive as your single source of truth. This also allows you to track your team’s progress over the course of multiple seasons.

  • Cloud Based - accessible from anywhere that an internet connection is available. It would be mobile friendly so coaches could access the information from their phones or tablets (which I see a lot of coaches using at competitions).

  • Data is Automatically Backed Up - We all know how frustrating it is when your computer crashes or you overwrite a file accidentally. Data is safely backed up on a routine basis to ensure that if a disaster happens, you could retrieve the information again.

  • Scalable Pricing Model - One thing I’ve learned sitting through tons of gym meets is that there are all shapes and sizes of gyms. From smaller gyms that only have one or two competitors all the way to larger gyms that bring dozens and dozens gymnasts. I don’t want the product to leave out smaller gyms just because they have fewer people and can’t afford the costs. Therefore, the cost structure should scale to fit the customer’s needs. No setup fees and a generous free-tier would allow smaller gyms the opportunity to have the same access to functionality as larger gyms. Pricing would be based on the number of gymnasts that were being managed (or something like that). Additionally, billing would be month-to-month, which would allow coaches to “pause” usage as needed.

Building a system that allows coaches to record scores for their gymnasts fits the idea of building a slow, boring product. The idea is not complicated. It’s basically what we call in the software world a CRUD application (Create, Read, Update, Delete). Nothing fancy.

But it would be helpful. At the least, it would be helpful to the gyms that our family runs around with.

Proof-of-Concept and the Path Forward

I’ve built a small proof-of-concept app that is a mock-up of the primary user interfaces. It’s not a full MVP yet because I don’t have it hooked up to a backend database. But the app works well enough that I’ve been able to get some feedback from my wife and I am a few steps away from feeling comfortable enough to show a few other people.

It’s a good start and it only took me about a week to put together. Some of the features I plan on building out in later releases include:

  • Include Men’s Scoring - right now this is focused on women’s teams and scoring. That’s where the initial need is in my circle, but I fully understand that there is a men’s side that will need to be built out as well. So, that will be the first priority after I get the initial MVP done.

  • Coaches Dashboard - a single page that aggregates some of the key stats for a team such as average scores, highest scores on events, trending, etc.

  • Notes - functions that allow the user to enter notes to accompany scores. This is helpful when you want to mark out what things you notice potentially contributed to the score received (i.e did the gymnast fall on the beam, were they piked, etc.). I think a running list of notes would be helpful at the gymnast level as well. Being able to note what each gymnast needs to work on before the next meet…stuff like that.

  • Printable Blank Score Sheets - for coaches who prefer to record scores at the meet on paper, I would like to build in a button that they can push and generate a nice templated score sheet based on the roster of gymnasts that are competing for a particular meet.

I’ve got a few other ideas for the product, but honestly, if I can get the core pieces in place, plus a few of these extra functions, I think it will be leaps and bounds better than most existing systems of record keeping that are in place now.

So, over the next few months, I plan to finish out the MVP and get something stood up in production for people to start pushing around on. I also plan to write about the process as a way to share some of the design and technical decisions that go into making a small product like this. In other words, I’m gonna try to build this thing in public. Maybe I’ll call it “The SBP Diaries” or something.

Maybe it will go somewhere, maybe it won’t. The process of building the product is what will be fun. Even if it only serves the handful of people in my immediate circle, I will have considered the project a success. And if this one doesn’t pan out, I’m sure there will be lessons learned along the way and I also have a few more ideas to kick around.

If you are a gym owner or gymnastics coach and you would like to know more about the project, feel free to email me for more details.