Today I’m excited to share that I’m kicking off a new side project. With any new project it’s important to understand what you’re trying to achieve before you begin, and so my first step will be to define project objectives.

My old physics professor used to tell us that while most people learn from their own mistakes, the wise manage to learn from others’ mistakes instead. It may be telling, but I do tend to learn best by building things myself. With this new project I’m looking to growth by acquiring specific experiences while creating.

I specifically want to work through the process of independently and iteratively building and marketing a software service that people will actually use. Even if it’s only a small niche of people, I want the responsibility of operating and improving it. This scenario would be fertile ground for experimenting with my CI/CD and project management practices.

These objectives can be articulated in the following short list:

- Create a software service that people actually use
- Experiment with new processes and technologies

This is a workable starting point. Perhaps the biggest benefit we receive from clearly stating our objectives is the ability to filter future decisions through them. It’s easier to make tradeoffs when priorities are visible and understood.

But at this point, the project is still very vague. What kind of service will I create? Who will be its target audience? How can I be confident that anyone will use it?

A common point of failure in software projects is the unvalidated assumption that a product will sell. It’s easy for software engineers in particular to understate the importance of validating business ideas. In Rob Walling’s book Start Small, Stay Small: A Developer’s Guide to Launching a Startup, the author argues that “…the single most important factor to a product’s success is not the founders, not the marketing effort, and certainly not the product. It’s whether there’s a group of people willing to pay for it.” While my initial goal is to acquire users rather than paying customers, the principle stands as they will still be spending their time.

A good starting point would be to build a service catering to a niche group of people that I am also a part of, and so am more likely to understand well. Even better if I already have access to an affordable channel for communicating with that group.

It so happens that I am already heavily invested in a pair of niche gaming communities where I’ve already built an audience. One of these is the solo tabletop roleplaying community surrounding Word Mill Game’s Mythic Game Master Emulator, and the other is the community surrounding RuneScape, a classic massively multiplayer online roleplaying game. I maintain a YouTube channel with an audience of more than 1000 subscribers who mostly watch either tabletop roleplaying games or retro fantasy roleplaying games. This is an immediately accessible market that might be willing to spend their time testing out a game being tailored for them.

RuneScape is interesting in that it has had regular content updates since it was initially launched as a service in 2001. RuneScape is still serving fresh content to a large community of paying customers. I’ve invested quite a bit of time into RuneScape (you can find me on the high scores here), and I’m well aware of the influence that the game has had on my belief in tight iterative development cycles. RuneScape started out life as a small project that grew over time into the iconic franchise it represents today. There’s an awesome documentary about it on YouTube if you’re interested in a dose of early 2000s nostalgia.

All of this points me towards creating a live game as a service and marketing it to my YouTube audience. While the gaming industry is incredibly competitive, I may have a chance at building a small user base if I can tailor a game to my niche and make it available for free. I may even grow a following if I can provide regular updates about my progress. To state this confidently, however, is to do exactly what I’ve already warned against doing: making unvalidated assumptions.

One of the easiest ways to quickly validate assumptions would be to build and market prototypes. In the book A Playful Production Process by Richard Lemarchand and Amy Hennig of Naughty Dog, the authors advise game designers to rapidly iterate on playtested prototypes to validate what resonates with an audience. The book describes each prototype as an experiment meant to answer specific questions. I love the similarities between their proposed approach to game design and the iterative development processes I’ve been using for years in the aerospace industry.

The key here is to not get hung up thinking that a prototype is representative of the game that you’re building. It’s nearly certain that some ideas will connect more effectively than others, meaning that many ideas will be left on the cutting room floor. I would want to produce minimalist prototypes to minimize the amount of time and energy I invest into less impactful ideas. At the same time, well-received prototypes would validate ideas and move the game closer to actually being played.

And so here I have a potential market, a channel for communicating with them, an idea for a live service, and a plan for validating that idea. My highest priority will be to validate these assumptions as quickly as I can. This will allow me to either de-risk the idea and move forward, or to realize quickly that a user base isn’t materializing. I’m ready now for my favorite pre-project ritual: the pre-mortem. I’ll break it down in the next update.