My world is gray. I often find that black-or-white/right-or-wrong answers with no gradations – those can get you in trouble. That particularly rings true in my world of product development. So many times, a slight shift in the technology winds or consumer trends or fiscal justifications will have sweeping effects on your nicely shined-up “golden egg of a product idea”, and suddenly that shiny golden egg is tarnished or is showing stress cracks. I hate it when that happens.
Speaking in absolutes is an oft-debated topic when it comes to management theories, philosophical arguments, personal relationships, etc. because that can get you in trouble. Those absolute statements in product requirements can have the same effect. They look great on paper: decisive, concrete, sure-footed, and easy for the engineering folks to immediately comprehend and attack with voraciousness. Then the harsh cold reality sets in: things change, and everyone is looking to assign blame as to why the specifications didn’t require the appropriate degree of flexibility in the design to “roll with the punches.”
Agile design principles are specifically geared to address this problem. Splice things up into small, definable chunks that can be more easily implemented, and the pieces come together bit-by-bit. If changes are required and a previously decided upon approach is destined for failure, then fail quick, pivot fast, and adjust your sails to the direction called for by the new breezes that blow.
The spin-phrase du jour: “Absolutely!”
Part and parcel to that agile approach is an environment that accepts and expects agility. That environment is sometimes tough to come by. A few years ago, I had a CEO who liked definitive, conclusive answers. The topic was not important. He simply favored decisiveness and clear-cut answers when it came to business decisions. A black and white opinion kind of guy. As a result, the subordinates learned to adapt and deliver sound bites that met those expectations. Perhaps it was a favorite “phrase-du-jour” in that particular decade of American business culture, and our staff simply followed the trend – or perhaps we were a microcosm all to ourselves – but the standing response by our Sales personnel to any question was always preceded by a single, emphatic, lead-in phrase: “Absolutely!” The rest of the response – regardless of the topic – was then enveloped by an air of concreteness and positivity that got the desired nod of encouragement from the CEO.
So, imagine the trouble the Product and Engineering folks (myself included) ran into when trying to paint the correct picture in a 3-year product roadmap exercise. Many a time I found myself falling into the trap of using the “spin phrase du jour” as the lead-in to one of my product pitches. “Absolutely! We can make those shiny green widgets in 6 months,” while simultaneously trying to cover the scope, schedule, cost, quality, risk, and resource assumptions in sufficient detail to keep the project alive, but not blow past the inherent (and obvious to most) unknowns and gray-area decisions we faced along the path.
“It Depends …”
I stumbled upon some like-minded musings and concerns with respect to product decisions and the associated tools selections that are the cause for so many “religion and politics” style heated debates that permeate many organizations. In a blog entry on mindtheproduct.com Martin Eriksson calls it out in a simple descriptive phrase: It Depends. It depends on context, it depends on balance, and there is a spectrum of gray when it comes to product development tools, processes and approaches that must be considered for successful product deployments.
When facing clients or internal executives/peers on the topic of product futures, it is always best to know your audience and adapt to the recipient’s hot buttons. Simultaneously, my experience and advice says: retain acute awareness of the gray tone that often envelopes your product crystal ball when it comes to features/trends/market nuances/technology changes, and retain an air of agility over absolutes in the planning and implementation process.