In business, there’s the idea of a “minimum viable product” or MVP. The MVP is the least expensive (in time, money, and risk) version of a product or feature that you can put in front of potential users to test whether or not there’s a market for whatever it is you want to do. MVPs should be simple, but get the job (gauging interest) done – I know of a startup that literally just went to potential clients with static images and a way to explain their potential product, and it was enough to get early investment so they could actually make the product. MVPs tend to focus on the “golden path” as in, the features and use cases that 90% of the potential market will want to use, rather than niche cases. An MVP should be the bare essentials needed to get started. Extra features – nice to haves – can be put in a backlog of things to get at once you have your first version out the door and it gets traction. Why spend time on things that aren’t essential when you don’t even know if there’s any interest in them?

For personal projects, I’m not very worried about what people will want, as usually I’m just intrigued by an idea or technology and want to play with it. Even so, I want to create something similar to an MVP, getting my project working end-to-end with the bare minimum of extras, and THEN I start adding those nice-to-have features that are such tempting distractions. I do try to get my idea as well specced out as I can so that I don’t suddenly find something that I overlooked that leads to distraction and derails the whole thing.

For an MVP, I think in terms of MUST and SHOULD. MUST items are absolutely essential features, without which nothing works, while SHOULD items are ones that I think can wait until later. While I usually don’t implement SHOULDs right away unless they are absolutely trivial, the important part of thinking about those SHOULDs is that they can influence the way the MUSTs are carried out. I just describe things in terms of what a thing MUST do to be functional, and SHOULD do to be delightful to use or viable as a potential product.

Continuing to use Hoshi, a home automation project that will make my smart home proactive vs. reactive, as our exemplar here, I will provide an example of MUST and SHOULD descriptions.

We MUST have a centralized system that is fluent in multiple external APIs when it receives notifications of events. That system MUST have some kind of rules regarding what to do when a given event happens. To do that, we MUST have sensors that can detect events in the physical world. The sensors MUST also relay those events to the central system for processing.

The centralized system SHOULD be easy to administer. Rules SHOULD be easy for a user to create. It SHOULD be very easy to add both new types of sensors to the system. It SHOULD be very easy to add new APIs to the system.

The sensors SHOULD be small and inexpensive. The sensors SHOULD be able to be battery powered or use wall power. Users SHOULD be able to have an arbitrarily large number of sensors.

The way the sensors communicate back to the central server SHOULD be robust, easily extensible, and, to be convenient, not require extra hardware to increase range.

From all of the above, for this example, I will be digging into the MUSTs and SHOULDs around the sensors rather than everything else. In this case, the SHOULDs about the sensors will strongly influence my initial choices in the MUST section. Because the sensors SHOULD be small and inexpensive, I’m going to look at implementations that don’t rely on stupidly expensive hardware.

If I didn’t pay attention to my SHOULDs, I might say hey, I’ll buy a bunch of pre-made sensors off the shelf which would certainly do for the MUST part. However, they tend to run $30+ which isn’t inexpensive enough for my tastes. The ones that do have a lot of range tend to be more expensive and also don’t last long on battery power. So if I only considered my MUSTs and not my SHOULDs, I’d wind up with a bunch of expensive hardware that doesn’t fit in with my longer-term plans. I’ll need to look at rolling my own sensors, which in addition to being less expensive and more likely to meet my exact needs, will also be a lot of fun.

One thing to note is that I’m not going into the technical details, but in the next step I’ll show how we go from MUST and SHOULD to a functional plan.