The catch when working with ETA for feature delivery
In this post, we’ll see some problems when working with an ETA — Estimated Time of Arrival.
The semantics
“The ETA for what we are currently working on will be in July”, said no developer, tech lead, or Product manager ever! Usually, a developer or Product Manager will say something like “We expect to release what we’re currently developing in July”.
The ETA term is mentioned from the customer, the end-user side. Usually, a customer has specific work to complete that feels closely related to a missing feature. Saying feels in italics, as people requesting a feature are in a state of emergency and think about dat(sic) missing piece on the workflow they already work on! There is no time to evaluate if that piece is actually what they need!
People receiving an ETA request are either people from the Customer Support/Success team (CS) or people from the Sales team. The request comes in any of the forms shared below:
- “I can’t complete task X, because feature Y is missing. Do you have an ETA for feature Y?”
- “Feature Y is a deal-breaker for us and you seem to be missing it. Do you have an ETA for having feature Y?”
- “It seems that I’m blocked by feature Y that is missing. Do you have an ETA? This way I can share with my team whether we’re staying with you or switching to a competitor that has feature Y”
Sharing the request and coming up with an ETA
Your company’s representatives — either from the CS or the Sales team — that receive such a request will forward it to your Development and Product teams for an evaluation or estimation.
For the sake of this post, we’ll skip the evaluation/estimation part. I’m sure you all know tools that can help teams to get that estimation and analysis. In this post, we will focus instead on the tricky catches following the estimation. The scenario is, that your teams analyzed feature Y and provided an ETA date!
The vague “we’re working on this”
As the estimate is set and the development team focuses on building the feature, the requester finally gets back the useful ETA! This is where the problems start.
With an ETA at hand, the requesters will:
- Inform the affected parties on their side by adding some slack on the ETA date, “Hey we’ll have to wait until ETA date++ to complete our task”
- Plan any work up to the problematic point following the workflow they already know.
- Make some assumptions on how the requested feature will work and maybe do some prep-work for any tasks following the missing point that the new feature will cover, e.g. “since I’ll be getting back Y when the feature is delivered, I can apply this transformation to Y so that my next task can consume it easier!”
Respectively, the development team will:
- Start a deeper analysis of how the requested feature will work
- Figure out how that feature will live in the existing functionalities
- Start the implementation
The points above make total sense. Each step alone has a minor effect on the ETA, yet when combined the effect on the ETA date is multiplied. Below we’ll analyze the tricky catches each point hides, as well as one more hidden catch unrelated to the ETA delivery date.
Tumbling down the rabbit hole
In the following paragraphs, we’ll check each point separately and highlight as bold the possible catches. An analysis of these points will follow in the next section. You can easily skip this section explaining the “how” and jump directly to the “what”, the consequences.
Let’s start our journey from the development team’s side and the deeper analysis of the request. To build a solid solution, the team will check the competition for similar functionalities. Additionally, the team will speak with other customers to maximize the value offered. As more input pours in, the solution will get more generic. That’s good news for the overall value delivered but, there is a chance that the feature requires more time to build — thus missing the ETA shared. An additional catch is that the more generic functionality is not exactly what the requester asked for.
Past analysis, the development team checks how to connect the new feature to the existing functionality. Checking the specifics, there might be architectural decisions of the existing platform requiring special handling or a different shortcut in the implementation. Such a shortcut could mean more convoluted code and thus extra care in development or a different direction altogether. Essentially the feature requires more time to build. A different direction in the implementation could mean that more compromises are needed, thus the functionality is not exactly what the requester asked for.
Finally, when the development team gets their hands dirty in code more issues might arise. Going past development, when the quality assurance team starts testing more issues might arise. The results are the same as above, leading either to a more complex implementation or more compromises.
On the requesters’ side, things are a bit more blurry and ideal at the phase prior to reaching the ETA date. Based on the provided ETA, the requester will proceed into peripheral actions or block any processes waiting for the resolution. In both scenarios, the requesters rely on big assumptions that fit their workflow perfectly. Also, the requesters will communicate a solution internally to their teams building expectations for a resolution. The requesters have placed credibility to themselves and your team upfront and central.
ETA date is closing: Facing the truth
As we’ve seen above, there are three emerging themes:
- Credibility to requesters and your team is upfront and central. With an ETA date provided, you and the requester’s company have set a beacon to report to. Getting closer to that date without a delivery you — as well as the requester — report for progress. Since the ETA is set before any work is done though, there is a big chance your credibility to be hurt.
- The feature requires more time to build. This point alone renders obsolete any ETA date set. Combining a missing ETA date with the credibility issue described above, you risk your relationship with the customer.
- The feature is not exactly what the requester asked for. This is the hidden and bigger catch of them all! There are countless occasions that your team delivered in time the feature requested, but the requester had something else in mind! The most common scenario in mind goes like “Yeah, feature Y is what I asked for, but without Z functionality we cannot use it”. In this case, your team worked on something that doesn’t provide value to the customer.
With all those moving parts it’s really hard to hit the nail on the head with a requested ETA.
Story for closure
Do you know where else we use the term ETA? At the airport, for airplane routes.
Now imagine your dream trip to the Caribbean or Bora-Boras! You booked both airplane and hotel tickets six months ago and are now standing on check-in! You see on the announcement board that your flight has a two hours delay, due to airplane maintenance. Yet this delay will impact your transit flight, you might arrive half a day later at your destination!
Now you’re on board the plane and try to order some champagne that you had imagined, only to find that red wine is the only option — slight bummer. Your transit flight has two more hours of delay, so you wait. Finally, you arrive at your hotel but you have to settle for another room — as you’ve arrived one day later. Heading to the beach you see incoming clouds, as the monsoon came earlier this year. That’s when you realize, that all you wanted was to relax by the sand, which you could find on a two hours drive from your home.
In an upcoming post, I’ll be sharing alternative ways to work on requested features. In the meantime, I would appreciate any feedback and suggestions you might have!
