ETAs for Features

A lesson I seem to have to relearn every year: Don’t give ETAs for features. No upside; easy to blow and lose trust.
— Patrick McKenzie (@patio11) January 22, 2013

Back in 2007-2008, while my more technical co-founders were building the product, I spent my time meeting with potential customers. When I would get requests for features, it was easy to say, “Sure, we’ll get that feature in.”  “When?”  “In just a few <insert random time frame pulled out of thin air>!”

And I had all intention to get it done for those customers.

The problem was two-fold:  1) In those on-the-fly conversations, there was no way to get a realistic ETA from my engineering team, and 2) Even if I could have spoken with them, none of us really knew how difficult building GPU libraries was going to be. All of our ETAs would have been off.

Over the course of time, we developed a more rigorous approach to product management. We categorize features and rank them. Customer requests affect the ranking.

So rather than talk about ETAs, we talk about our roadmap and about where their particular feature fits on the roadmap. We assure them that their feedback will be incorporated into the roadmap and will correspondingly bump up the priority of that particular feature.

We’ve also developed a great engineering approach to quickly delivering bug fixes and new features to key customers (which I’ll discuss in a later post).

How do you approach giving ETAs for features? What do you do to both satisfy customers while also maintaining the integrity of your processes?