Since moving to Calgary, we’ve organized an annual ski trip with my in-laws. We usually head somewhere driving distance from Alberta, so often Inner BC: Fernie, Golden, Revelstoke, and Red Mountain (Rossland) have all been destinations. This year we went back to Fernie, and it was our first time taking a ~weeklong road trip with Henry. With Frankie (the dog), Henry (the baby), and all the ski gear, we pretty close to maxed out our vehicle (Tiguan) for space. Now, for years, my in-laws have been joking that at some point we’ll need to buy a Suburban. And for years, I thought that was a joke. But I think it’s become a bit more serious.
I hate the suburban. It’s a stupid looking car. It’s humungous. It’s expensive. It looks like a bus. But clearly, it’s very practical if you are hauling a lot of stuff and a lot of humans. The nature of these conversations about getting a suburban is tied to a very specific event: an annual ski road trip. An annual road trip to ski is probably the most space-consuming trip we make as a family all year. At no other time do I need to fill my car with that much stuff. In fact, 95% of the time we use the car, it’s more than sufficient for space. I have been left thinking; do you purchase an oversized vehicle to satisfy 5% of your usage? I think the answer is no. Generally, you should design your life around the majority of use cases and solve for the exceptions as outliers (e.g., perhaps we rent a suburban once a year?).
One principle I value when it comes to creating a new product or policy is to design for the majority. A habit I picked up from working in an investing role is to attempt and identify uncommon outcomes; identifying uncommon but potentially significant outcomes was a valued skill. That mindset – naturally considering hypothetical scenarios – has sometimes made it hard to balance my desire to design for the majority when designing new HR policies (do we create the overhead to satisfy a rare but possible need?) or providing feedback on software development (do we solve for that uncommon, but very painful use case a client has?).
I’m still working through my opinion on this, but where I’m circling is to start by designing for the majority, yet consider the potential frequency of uncommon events and the severity of their outcomes to determine when an exception is needed.