Working with customer requests
In a previous post, we saw the problems when trying to work with ETA — Estimated Time of Delivery — on requests coming from the customers. In this post, I’ll present an alternative approach to customer requests.
ETA requests will not stop!
First of all, it’s nearly impossible to stop receiving requests for an ETA on features. People will always be in a hurry, trying to complete their work! Some functionality will always be missing!
When you are on the receiving end of an ETA request try to understand the bigger picture; what’s the value people want to get from the whole process? Don’t zoom in to the missing functionality, ask instead “What are you trying to achieve again?”. Often the answer to this question will trigger a different action two or three steps earlier in the process that is already in place.
If you don’t feel comfortable having this discussion, offer to connect with a colleague that can talk about the bigger picture.
Past getting the bigger picture, avoid giving an ETA! Instead offer a priority of working on that functionality, “our team can start working on this asap/after a month!”. It is imperative to figure out if a workaround is available and offer that too. This way you show that you care about your relationship with the customer.
Working on a request from the customer
When you decide to work on a customer request, include the customer early on in the process! There are countless occasions to talk to your customer about a feature they requested, here are a few:
- Before starting any work, crosscheck with the customer that their request is still valid! There are cases where an alternative has worked, or that this request is not a priority now.
- Sharing the first designs and flow for the functionality, again to validate that you are providing the right solution. Having this discussion early on you can figure out whether your team has the right focus on the most important task for your customer.
- Inviting for early testing when some functionality is developed. Sharing at this point, you get information about the usability of what you are working on.
- Sharing once the functionality is released, along with a full-fledged scenario on the customer’s use case. This way you revalidate the case with your customer and you highlight the value your team delivered.
- Follow up with the customer post-release, to see if the functionality meets their needs. In this talk, you can get meaningful insights into the next steps for the specific functionality if any. It is important to try and engage with customers post-release to secure that you delivered value!
- On some occasions, you will need to walk hand-in-hand with the customer on using the feature. This is your way to show that you personally care for your customer’s success and the value offered. A cool side-effect is that you have first-hand experience of a real usage scenario on your feature!
One more thing
ETA is a really hot topic that bites us all alike; whether on the requesting or the implementing end! Working on the alternative path shared above all get some added benefits:
- You and your development team feel the impact they are having on your customers. The feedback loop is closely knit to the development cycle and that’s a good thing!
- You and your Customer Success and Sales teams collaborate. This collaboration over a customer request is an opportunity to build empathy and share successes across teams.
- Finally, you build a healthy relationship with your customers relying on mutual respect and collaboration. Although you haven’t provided an ETA, your customers feel that you care about your actions and interactions together!
Overall, working on customer requests is a collaborative effort. The more we build the process as a win-win, the more we will all benefit!
Please share your thoughts, feedback, and more ideas on dealing with customer requests.
