Shannon Cunningham

Good ,Better, Best:  How Innovative Teams Work to Deliver Fast and Get it Right

Blog Post created by Shannon Cunningham Employee on Dec 16, 2015

I’ve worked for tech companies since the 90’s and I can tell you two very important lessons I have learned are:

  1. It doesn’t always have to look pretty to work
  2. It has to work

During the earlier client/server days software was built to last, not necessarily, pretty or speedy, but products were consistently effective.  It also took 18 months to gather requirements, another 18 months to build and test the thing and absolutely no changes.  None.

 

Today 18 months means 4 to 5 product release cycles and connected products and services coming at you faster than Adele can sell another download of “Hello”. We don’t have time to lament over everything but we do focus on one key factor: It has to work!

 

In an industry where speed rules, you can’t not deliver innovation quickly.  Waiting to launch a product or service until it’s perfect is the one of the worst things you can do.  (Putting out something that doesn’t work is #1, if you were wondering.)

 

How do we do this? My team follows a Good, Better, Best rule. When developing training either for a custom engagement or for the masses, we start our process very much like any project team with requirements gathering, user impact, change models, etc. Then after all of this is complete we look at the list with our customers (internal and external) and ask them to rank their requests through Good, Better, Best.    The natural response is everything is needed but when you start talking about timelines, budget and impact to business, the necessities start to bubble up to the top.  If you wait for the entire program to be complete before you release anything, you could risk everything.

 

How to rank Good, Better, Best:

kano model.jpg

 

Good: We cannot use this product without it.

Better: We would be more effective and produce fewer errors if we had this.

Best: Wouldn’t it be awesome if…

 

 

If you have ever worked in the Kano Model, this visual might resonate with you.

 

 

 

 

The challenge with many projects is requests often focus on the 'delighters' and less on the minimum requirements. Think of like buying a new smart phone. You have to consider:

  • Users & Environments
  • Usage needs
  • Features
  • Budget
  • Timing

In some cases yesterday’s ‘delighters’ are today’s ‘must be’ features. Prioritizing what you need vs. what you want can help laser in on what is important.

For someone like me, a case for my smart phone would be considered a ‘delighter’, while a good camera and social media postings are ‘must be’ features.

 

However, if you have are making decisions based on a field service technician as the user, a phone will get broken within the first week. A sturdy, weatherproof case is a ‘must be’, for this user as well as a quality phone.  The social media services may be considered a “delighter”.

 

This exercise allows you to get to Good.  To move onto Better and ultimately Best is about timing.

 

Create a plan to complete, test, and implement Good, and then add your plans to incorporate the rest. In some cases you may find your needs change over time based on what is available to you. Remember your smart phone? How many features are you finding on your Best list that are still important to you?

 

Whatever you are creating, producing or growing, it’s always a helpful to have a Good, Better, Best plan.  Just remember you are never done innovating; you’re just done with this phase.

Outcomes