Thursday, May 2, 2013

The Power of "I Don't Care"

A few years back, one of the best Product Owners I've worked with taught me the three most important words in his vocabulary.  "I don't care."

Seems a little crazy, right?  Shouldn't the Product Owner always care?  Why am I spinning this like it's a good thing?

Let me paint the picture.  I was the lead analyst working on an Agile pilot program for a large financial company.  The project focus was on improving their mathematical modelling tools.  The Product Owner I was working with wouldn't recognize that job title - he was one of the key users of the tools we were developing, and had taken on the job of being both our "go to" subject matter expert and the keeper of prioritization for his requests and the requests from other users.

As part of the Agile pilot, we were building user stories.  We'd established the basic "As a...I want....So that..." story sentences.  We'd put together some acceptance criteria for each.  We'd moved into sketching out some additional details of the "top of the list" user stories we'd be developing soon.  I had some questions laid out of a "should it work like this, or more like that?"  And as we were talking about them, he looked at me and said, "Look, Mike, I don't care."

What do you mean you don't care?  He told me (wildly paraphrased): "We've already talked about what I care about.  You understand what the goal.  You understand the acceptance criteria.  I appreciate you asking, but for a lot of these details, I don't feel strongly.  Solve my problem however makes sense the team and I'll be happy."

So we ran quickly through my list of questions, marked most of them "don't care," talked through the few that he had an opinion on, and we were off and running for development.

Why do I think this is so significant?

For me this was a great reminder that "if you ask the question, most people will feel obliged to provide an answer."  If you ask your customer/user/product owner "what font do you want us to use for the pop-up help text?" most will give you an answer.  Because you asked, and expected an answer.  This is human nature.  "I don't care" is an out-of-the-box choice most of the time.

And it's an important choice to have available.  Because a Product Owner telling you they don't care about a detail isn't telling you they don't care about the product.  Or that they're unhelpful.  They're telling you they TRUST you.  They trust the team to make a good choice.  They're giving the team permission to solve the Product Owner's business problem as well as they can, without introducing constraints that aren't important to them.  They're telling us to focus on the things they DO care about. 

The takeaway here shouldn't be that we stop asking our product owners questions.  Simply assuming the Product Owner won't care and not talking with them is a great way to make them feel they're not listened to.  What we need to do instead is set the expectation that they're ALLOWED to tell us they don't care.  That the fact that we asked the question does NOT obligate them to decide the answer.

A big piece of this is expectation setting.  Make sure before you start talking through details with your Product Owners (and Stakeholders and SME's and Users) that they're aware that it's OK to tell us they don't feel strongly.  Remind them they'll have the opportunity (in desk checks and demos) to review what we're building, so not every decision has to be made up front.  Give them permission to say "I don't care."

Another piece to think about is framing.  "Hey, Jane, should the text be left-aligned or centered?" demands a binary decision.  "Hey, Jane, we're brainstorming on the display of the pop-up help text.  Is there anything we need to talk about?  Or would you rather just see a mock when we think we've got it?" asks the Product Owner to first think about what's important to them, and invites them to provide detail they care about.

A final piece to think about is having awareness about who ought to be involved in certain decisions.  There are certain decisions that the product owner legitimately needs to be involved in.  There are other decisions the team needs to make that might not.  "Should our web services return XML or JSON?" is a decision a team might be faced with.  If your project is an architectural re-design moving to SOA, and your Product Owner is the Chief Architect, then you should probably pull them into that decision.  If you're building an e-commerce site and the Product Owner is the Head of Retail, maybe not.  Again, it is human nature to try to answer a question if the question is put to you.

"I don't care" are three powerful words.  I hope I've helped you hear them more often.  

Edit: Embarrassing typos.  Thanks, Bill!


No comments:

Post a Comment