We used to share planned feature release dates with our customers. Here’s how that ended up hurting us…
“I feel like you guys lied to me.”
Ouch.
This one was going to be tough to explain.
Just two weeks before, a customer had emailed us. He was a new user, and was having a bit of difficulty using Groove. His business had a pretty unique need that our feature set didn’t support… yet.
But – we were working on a product update at that very moment — an enhancement to our Rich Text Editor — that would solve his problem.
I was excited to share that with him, so when I heard about his issue, I checked in with our developers about the status of the development.
We were almost finished, and right on schedule, with the release expected to be ready in a week.
So that’s what we told the customer.
Experienced product folks are shaking their heads right now, because we know what happens next.
A week later, we hit a snag in the final stages of testing and find a series of nasty bugs that render the update too unstable to release.
Because our small team has to balance that project with the everyday work of maintaining the app, supporting our customers and fixing other critical issues, the bugs take another week and half to diagnose and eliminate.
And while we kept our concerned customer — and everyone else who had requested the feature — updated, it was clear that the episode didn’t make us look very good.
In fact, he was right. Even though it wasn’t on purpose, we lied.
It wasn’t the first time something like this had happened — we should’ve known better — but having a customer call us out so directly was a big learning experience for our whole team, and we certainly haven’t let it happen again.
Why We No Longer Share Release Dates With Our Customers
This may sound obvious to some, or shady and deceptive to others, but in fact, the opposite is true.
Let me explain.
When you share a release date, and it turns out to be wrong, you lose your customers’ trust.
As product teams, we should know that unexpected issues happen quite often, and that planned release dates aren’t always accurate. While we do our best to plan our efforts well and forecast our progress accurately, things don’t always go the way we hope they do.
So if we promise a delivery date to our customers, even if we hit our milestones more often than not — which we do — just one missed goal turns us into liars.
So by not sharing release dates, we’re being more honest — the truth is, we don’t know exactly when the release will be — than the alternative.
In business, a customer’s trust is what we work hardest to gain. Once you have it, it’s easy to lose, and incredibly difficult to get back.
We’re always working to get better at hitting our development milestones, and frankly, we’ve gotten much better at it.
Still, we can’t — and won’t — risk letting down our customers by misleading them on our feature roadmap. It’s not just a development issue, but a communications one.
Takeaway: Not sharing release dates may seem dishonest, but it’s not. In our case, we know that we don’t hit our milestones 100% of the time, so we’d rather be honest about not being able to perfectly predict the future, than use our goals to make promises that we may be forced to break.
Three Steps We’ve Taken to Solve This Problem
1) No Product Announcements Until the Product Is Ready.
This is, by far, the easiest and best way to protect your business from accidentally lying to your customers.
As startups, we run into a lot of obstacles. And unfortunately, there’s often a lot of bad news.
We can’t build everything we want, and we can’t fix everything we want to fix as quickly as every customer wants us to fix it.
Some days, there’s nothing we want more than to give a frustrated customer good news; to tell them that their issue would be fixed tomorrow, or next week.
It’s tempting, but it’s simply too risky. That’s why we’ve decided to never announce new features until they’re staged and functioning well enough to release to our customers.
Takeaway: As tempting as it is, don’t announce anything until it’s ready. This one simple rule can guarantee that you’ll never lie to your customers about release dates.
2) Only Give Customers Info You Know to Be 100% True.
While we won’t give release dates, we are honest and transparent about what we’re working on.
We publish frequent development updates on our Better blog, and we do our best to communicate to customers that we’re working hard to solve their issues, even if we can’t give them a specific time that it’ll be fixed.
As an example, this is what we recently told a customer who’s running into a problem that’ll be solved by a feature currently in development:
I have no doubt that this approach costs us some customers with critical issues who are on their way out the door.
And while there’s nothing I hate more than having a customer leave — it feels like a punch in the gut, and it never, ever, ever gets easier — I’d rather lose them (and potentially have them come back when we can better solve their problem) than lose their trust and business forever.
Takeaway: Not sharing release dates doesn’t mean that you can’t — and shouldn’t — be completely honest and upfront about what your development team is working on. You should still let customers know that you’re working hard to help them.
3) Better Communications Between Development and Support.
We’ve always focused on communication. As a remote team, you have to if you want to have any hope of success.
But in this instance, there was a specific communication gap that we needed to fill to solve this problem.
On our weekly team calls, we’ve started diving deeper into the development roadmap — not just that week’s to-do’s, but how the future roadmap looks, and whether or not it’s changed from the week before — so that our whole team has a better understanding of the features we’re working on and releasing.
And Mo, our head of customer support, has become very involved in our development roadmap, spending quite a bit of time logging issues in Pivotal Tracker so that the dev team always knows where the biggest customer pain points and opportunities are. We recently shared that workflow on this blog.
Takeaway: This isn’t just a customer communication issue, but a team communication issue, too. Make sure that your developers and support team are on the same page and supporting one another to help your customers in the most thorough way they can.
How to Apply This to Your Business
If you hit your development milestones 100% of the time with zero unexpected delays, and know for a fact that you’ll continue to do so forever, then you probably don’t need this advice.
But unfortunately, for most startups and small businesses, this simply isn’t the reality.
It can be tempting to try and keep a customer happy by promising them a solution by a certain date, but don’t do it.
If you turn out to be right, the customer is pleased.
If you turn out to be wrong, you may lose their trust forever.
As obvious as it seems, it’s an issue that’ve been battling and we were finally forced to face. I’m glad we did, and I hope that our experience helps you do the same.
