Stop communicating your ETA’s

Key to Product Management and Development

There is no looking back on the fact that we need to heed to customer requests and deliver their wish list items sooner than later, of course after validating with the product-roadmap fit. Every product company, I am sure, will get swamped by such requests and here are some facts from my own experience.

About 20-25% of all support tickets we receive from customers are feature requests. Almost 80% of all these requests are must-have or should-have features, the absence of which somehow pulls them down in productivity.

Most of such requests, especially from your strategic customers, come with urgency and a demand for timeline. But remember, never guarantee an ETA to your customer. It just is not possible to keep up to it most of the time.

Software development is not a blind-fold repeatable process

When you sit down to estimate a timeline for development of a feature, you would come up with a list of to-do items, foresee-able to your knowledge and based on your experience. But it is only during the development phase that you identify the exactness of missing pieces. Unless something is tried and tested ahead of time, it remains unpredictable until the day of its completion. This is precisely why many organizations call their development team as Research and Development team. No invention is done with a fixed date in mind or no research scholar promises to deliver a path breaking product within a timeframe.

Should we scrap all the estimations going forward?

Not really! Being a Product Manager I am more concerned about capitalizing the time-bound market potential and the above development approach definitely does not work to my favor, as you would have thought. However, we do expect to predict things to some extent and to accomplish that here is what we do:

1. Be clear and particular about the use-case than the means of achieving it.
2. Never jump 1000 miles ahead at once. Figure out the first meaningful milestone with a modest use-case. Some of you could relate this with an MVP approach.
3. When you sit down for an estimation exercise, try to include members (developers + designers) who have done something similar before, or at least have done considerable amount of research on the topic.
4. Give enough time for members to understand and think through the requirements before estimating them. We usually give a 10 day window for developers and designers to understand the features, think about the implementation process, do enough research on elements required, before the estimation party.
5. Evaluate the risk, well in advance, by listing down the dependencies, unknowns, resources required etc. (the usual project management stuff)
6. Think about how the feature will impact other depending functions and workflows inside the product. This generally takes half of the total development time.
7. Let developers and designers understand the goals clearly so they can take some amount of independent decisions over the course of their involvement.

All the above elements would help you in minimizing the risk of overshooting the timelines, yet, in most cases you would have to negotiate internally on ETA’s for functionalities or functionalities for ETA’s.

Be ready to allocate at least 20% more time or resources than you have estimated, to get things done with perfection and accuracy.

For all the above risks and reasons you never can promise an ETA for features and hence, try to be prompt and proactive at your communication with customers.

Don’t hesitate to say ‘No’, when you are not comfortable saying ‘Yes’, when it comes to timelines.

If you found this post helpful you might want to follow me on twitter where I tweet about Startups and Product Strategy