Some believe that scant customer complaint data is evidence that existing development processes are working and shouldn’t be challenged. In other words, “we got this.” But reactive product development thinking is like going all-in on a single hand in Vegas, when losing means everyone at the table goes home broke. And this House deals loaded decks.
Planning to spend the next rainy weekend in the garage overhauling the front end of my Triumph, I recently bought a few aftermarket goodies from a small French custom parts shop specializing in European motorcycles. One of the parts I bought was an aluminum bracket for relocating something called a “Rectifier/Regulator” (R/R) unit from its factory-installed position on the front forks to a less conspicuous location tucked neatly between the engine and the radiator.
However, there’s a potentially serious trade-off to consider with the new location: the R/R unit would be less exposed to natural airflow around the bike (which helps cool the unit) and would be extremely close to other significant heat sources like the engine. The R/R unit already runs hot by design, as one of its functions is to help dissipate excess power from the bike by radiating heat. Technical jargon aside, R/R units need adequate airflow to avoid overheating and nuking a bike’s electrical system (best-case scenario) or bursting into flames (worst-case scenario, obviously).
I didn’t think about product design or quality issues when ordering the bracket (I assume they do their homework), but the more I did think about it the more I wanted to ask a simple yet burning question:
How do you get away with relocating the R/R unit to such a cozy, hot new space without causing unit meltdowns?
Over the next day or so I became obsessed with the question, thinking that maybe they’d somehow capitalized on the bike’s own unique aerodynamic properties, or that they’d resurrected the arcane practice of alchemy to forge an innovative new heat-dissipating metal, or maybe even that they’d used an ancient incantation to cast anti-overheating protection spells over the part. Whatever the case, I was certain the shop’s engineers would be eager to school me in their methods and put my mind at ease.
The answer that I received was far more practical, honest and, well, typical than I expected:
“No one ever came back to us with this problem, and we also mount it on each of our bikes. It is safe and doesn’t overheat.”
That’s it? What the literal fuck? I guess I should have seen it coming, or at least anticipated the possibility of it. Instead, I was really just dumbfounded. And a bit intrigued by how easily I’d slipped into the unconscious trap of making some ridiculous assumptions before buying the part. Also, the irony of it all wasn’t lost on me.
automatic assumptions: engaged
Because this unique, shiny part with lots of cool selfies from various flattering perspectives lived on a ruggedly cool, technically slick website (and also because I’ve had plenty of good experiences with this shop in the past), I automatically assumed a few things that I really had no business assuming.
- First, I assumed there was a good reason for the part to even exist; the presence of an otherwise insurmountable problem compelled this product into being, a classic example of the market meeting the demands of customers desperate for radical innovation.
- I assumed the shop’s engineers had considered various competing design and relocation options, with decisions ultimately riding on a thoughtful balance of performance, practicality and safety.
- I assumed that they engineered and tested numerous prototypes…exhaustively…under extreme conditions and in extreme environments.
- I assumed that if any problems did exist, the shop would have heard about them by now from customers (because they’d probably sold lots of these parts already, and customers always call manufacturers to provide useful product feedback).
I can’t speak to the first assumption (which I still firmly hold), but assumptions 2 and 3 were dispassionately debunked by the shop itself. That leaves no.4, an assumption that the shop (and probably most product developers) shared with me: namely, the idea that early adopters serve (albeit unwittingly and thanklessly) as initial product testers, putting the product through its real-world paces and reporting back on its epic successes and failures one way or another. But can that be right? I don’t mean from an ethical standpoint, although…yeah, that too. Rather, is the assumption itself even remotely true?