Skip to content
Menu
DeanOnDelivery.com
  • Home
  • About Dean
  • Product Management
  • Popular
DeanOnDelivery.com

If complexity is the enemy, then ‘No’ is your best friend.

September 1, 2015May 15, 2021 by Dean Peters

TL;DR: Avoiding worthless hodgepodges of complexity is why product managers need the ability & courage to reply with an ROI-driven ‘No.’

User Story:

As a software product manager, I need to be able to say no to complexity.

Description

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.

UATs

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.

Discussion

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.

YMMV

©2023 DeanOnDelivery.com | Powered by WordPress and Superb Themes!