*Head Desk* a Postscript

This post is an addendum to the *Head Desk* Post from a month ago.

Earlier this week I had the opportunity to volunteer for a Girls Get IT event in Atlanta.  It promotes junior high school and high school girls getting involved in STEM related fields.  We went on a tour of Chamberlain College of Nursing.  This visit was awesome - I think I was more excited then the kids - I don't think I realized how much technology there was in Healthcare education.  

During the tour, there was a computer that allowed the nursing student to simulate the requesting of medicine pills for the patient.  She entered the drug name and the quantity needed.  As part of that process, the software had intelligence built in that detected drugs of similar names.  So if she requested Mombiely (yes, I made that up) - it would say did you mean Mombiely or Mobiely?  The risk of administering the wrong drug can be fatal.  This software is checking for the typical mistakes a person might make when requesting specific medication.   It was a timely experience after what had happened with my bank website.

Regression

Nope- I’m not talking about the testing term regression.  Yesterday was one of those days I took a step backwards (it's possible the month of August was one big regression).  One of the most basic rules you learn in Improv is to “yes and”.  There are no “no buts…” 

I’ve been taking Level 2 of Improv for the past several weeks. For the most part it’s taking what we learned in Level 1 and building upon those lessons.  It’s still scary…still fun…still 2 hours a week that I don’t think about anything but be in the moment. 

Last night I made a basic mistake in several scenes.  Instead of ‘yes anding’ my scene partner I sort of ‘no butted’.  If your partner tells you that you’re a cheerleader on a field, you shouldn’t tell her that she’s mistaken and that you flunked out of cheerleading.  Improv is about building on one another – I should have taken her statement as fact and brought it to the next level.  I need to remember to yes and…yes I’m a cheerleader on a field; I’m on a golf course cheering on miniature golfers at the park and got this cut on my forehead because I was too close to the windmill. Building on your partner allows the scene to grow and become interesting. Negating your partner can take it to a stand still.

It was a good mistake to make, because I’m able to learn from it.  Not only did I do this in Improv class, I think lately I’ve been making the same mistake in work too.

We’re in the middle of our 2014 planning.  We’ve established our strategic initiatives and goals; we’re in the process of mapping out how we’re going to get there (realizing that the path could will change during the course of the year).  This is the time of year that I hear the most from a variety of internal constituencies on the best ways to get there. J  It’s awesome to have this level of engagement from the folks you work with.  It also starts to get draining.  I realized tonight that I’ve been saying “no but” more then I should be on some of the ideas that have been funneling through. 

As product managers we know it’s about investing in the right ideas that create the greatest value that aligns to our markets.  We don’t have time to investigate all of them, but we need to make sure we’re listening so that we understand which ones to pursue.  To do that, we need to be open to all ideas and approach them as if they could be a reality so we’re able to determine their true potential. I’m taking a step back and remembering to “yes and” more in my day job.

If you read this post and are thinking "yep, got it, I'm good".  I thought the same thing. Try saying "yes and" to things for an entire week - this will be a good test to ensure you're there.  If you're reading this post thinking it won't work for me because I've got too much on my plate and I've got the experience to tell good ideas from ones that won't work - you are essentially saying "no but" - just try yes and for a week...what harm could that be?

*Head Desk*: A Lesson in Humility

Two week ago I received an email from my bank that my checking account fell below my low balance threshold.  “Low balance” was defined by me. I set it up to get notified when something unexpected was happening with my bank account.  This email meant something unexpected happened.  I logged in to discover that I had a negative balance.  I’ve been balancing my checkbook before the Internet existed...I have an accounting degree…this should not be happening to me. 

I reviewed the transactions and immediately saw the problem.  The bill I paid to a department store was 100x bigger then it should have been.  Apparently I didn’t type in the decimal.  *Head Desk*  I called the bank (yelled representative many times at the automated phone system) and found the money was already in flight and there was nothing I can do about it. 

I’m still unwinding this, but I put my product management hat on and started thinking about usability.  My bill for this department store is delivered to my bank and the bank knows the amount due to the biller.  The bill pay system not only allowed me to overpay without a warning but also allowed me to overpay by exactly 100x the bill amount.  On the flip side there is a confirmation page when you pay a bill that I apparently didn’t review.  But seriously – who looks at that any more – I see confirmation pages so many times that I don’t review them – I simply click submit.

The right answer is to have greater intelligence around these types of transactions.  If I pay my water bill two times within a day of each payment and for the same amount – should it warn me?  Maybe.  Is that answer different if instead of my water bill its my mortgage payment?  Probably. But the more of these messages I receive- the more likely I am to ignore those messages too.  The product manager in me also knows it’s a trade-off – introducing this type of checking reduces value that can be delivered in other areas. 

I think the right answer is this level of error checking should be commensurate with the level of risk, confidence level that it’s a mistake and knowing that risk is going to be different based on the user persona.  As sucky as this experience has been – it would have been much worse for the 25-year-old version of me. 

In any case, this also is a good lesson in humility. I've been using computers for 75% of my life and made the most basic mistake.  While I’m not my product’s user, it is still good experience to have in the back of my head when making product decisions and building requirements.