Go / Whoa / No - A Framework for Customer Requests
Some of our clients are in the business of building highly-customized enterprise software for a small base of high-value customers. These software customers produce a steady stream of product requests to make their software better.
Some are quick and easy: "Can you re-order the shipping options dropdown?"
Some are a bit more involved: "I need my invoice numbers to be prefixed by the first three characters of my customer's name"
And, some are just dumb: "Can you log me in as super-admin when I click the owl's beak in the footer logo on the home page?"
The challenge I often see is that account managers can't properly assess incoming customer requests on how much effort might be required to fulfill them. This usually requires a product person or a developer.
Instead, the account manager might take a note letting the client know, "I'll talk to our dev team and get back with you". The note is taken and then a developer is interrupted on Slack for the 12th time that day.
Maybe the developer responds in slack "should be fine", just to shake the intterupt and get back to coding. I've seen this game of telephone happen in this same ad-hoc fashion more times than I've seen Back To The Future (it's a lot!). And now, I'm proposing a better way.
Drawing inspiration from my kids' elementary education about healthy eating, I created a quick and easy-to-remember framework to add some structure to the madness. I call it "Go / Whoa / No". Here's how it works.
Go | The task is routine and a simple change. It's likely something that has been done quickly before and so we have a lot of confidence that the item is low-effort. The next step on a "Go" request is to prioritize and complete the work. |
Whoa | We are sure we can do it, but we aren't exactly sure how or if we'll need to change other parts of the system to accommodate. More research is needed before we can properly estimate the task. The next step on a "Whoa" request is to research a solution and provide an estimate before committing to the work. |
No | The request, as written, is incompatible with our software now and we foresee that it will remain incompatible taking into account vision. The next step on a "No" request is to understand more about what the client really needs and explore compatibile ways to meet the need. |
When a client asks an account manager (AM) "Can you make the software do X?", the AM records the request and tries to assign "Go, Whoa or No" to the request. If they don't know, they still record the request, but leave the "Go, Whoa, No" section blank. Before leaving the call, the <blank>s are called out and the client is informed that we'll check with our dev team to get an answer on the outstanding requests.
Now, requests can be batched and sent over to your dev team and they can fill out any missing "Go, Whoa, No"s. I like to use a simple google sheet for this, but you can use any tool you like.
Once your dev team adds their input, you can go back to the client where you'll have no trouble doing the following:
- Prioritize the "Go"s
- Decide which "Whoa"s you want to invest more research into.
- Discuss the "No"s and potential work-arounds
Sounds like a lot of work, Nick. I'm just going to keep slacking my developers.
It's more discipline, but actually leads to less work and happier customers. Let me explain.
Shorter Time to Value
Remember when the AM first wrote down the request? Some of the items were immediate "Go"s. This means the client can leave the call knowing that these "Go" items will be put into the development queue or they can select which "Go" items they'd like to have first. By forcing the AM to identify and prioritize "Go"s early, we are shortening the time-to-value (TTV).
More Developer Mindshare
Instead of slacking your developer or product manager one-off questions, you are batching your requests. Batching forces the developer to block some focused time to deeply consider your batch of requests. Sure, you won't get an 'in-the-moment' assessment, but you'll get a more accurate and thoughtful picture of what is possible for your client.
Invaluable customer insights
As a product manager who loves forcing functions, I welcome the mandate to review batches of "Go, Whoa, No"s regularly. This is a raw, early look into what customers need to run their businesses and a tremendous asset for building a strong product strategy.
"Go / Whoa /No" is just a simple framework that forces us to answer the question "Can we do this?", as soon as we possibly can but with some added rigor, discipline and the right amount of focus. Give it a try and let me know how it works out for you.