TL;DR: Avoiding worthless hodgepodges of complexity is why product managers need the ability & courage to reply with an ROI-driven ‘No.’
As a software product manager, I need to be able to say no to complexity.
I love the above Scott Adams offering in the banner image from February 25, 2013 where Dilbert is quoted saying:
“I added all of the product features that each of you demanded. Now our product is a worthless hodgepodge of complexity …”
As someone who listens to many stakeholders, I am in no shortage of feature requests of which many are good, but not all are profitable.
Complexity is one of those areas that are rarely profitable in software development. One the ways I ferret out feature request with a low return on investment (ROI) is to determine its complexity; both in terms of implementation and user adoption.
Put another way — and with apologies to Albert Einstein — if you can’t sell the value of a feature to a six-year-old, then it’s very unlikely that you’re going to successfully develop it as a team, let alone convince individuals and/or enterprises buy into it.
So how do you deliver an ROI-driven ‘No’ in response complexity? Good question, glad you asked.
I suppose I could get off cheap by simply insisting one preach the gospel of Bill Wake’s INVEST mnemonic to their clients, but such acts of hyper-scrumdamentalism rarely resonate with stakeholders.
Instead, I think I’d rather reach-back to a 2011 blog post by Cindy Alvarez titled “You Need to Make ‘Wanting’ No Longer Free” to formulate my somewhat lean-esque hypothesis:
- We believe stakeholders contribute complex feature requests because it costs them little more than time to so.
- If we can help them understand the considerable costs and trade-offs in the feature’s implementation and use, then they will be more willing to accept ‘No’ as an answer.
- We’ll know we’re right if our current and prospective client doesn’t complain upstream, doesn’t fire us, does agree to work with us to simplify the complex process, and/or does continue to pay us for the product sans said complex feature.
Now if I had to guess, some of you are about to leave a comment that the solution is merely whittling down complex epics into stories, and then refining bloated stories into little bitty stories.
Not that this isn’t a wise tactic (because small batches work), but as a strategic approach, I might first want work with stakeholders, UX, and other domain experts to see if the requested complexity can’t be distilled into a far less convoluted set of patterns and practices that users are more likely to adopt and enjoy.
Failing that, I would suggest saying ‘No’ by helping the stakeholder understand:
- the cost of delivering the hodgepodge of complexity;
- other requests that won’t get done while developing the hodgepodge of complexity; and
- any research indicating a potential lack of adoption of the worthless hodgepodge of complexity.
At least that’s my theory, and I’m sticking with it until the data says otherwise.