Product launches and the virtue of being vague

Twitter recently bumped their character limit from 140 to 280. Leading up to the change, Twitter hinted that they were considering increasing the character limit, but they remained coy about anything definitive. When the update to 280 characters finally became official, they remained vague about their timeline and scope, saying only that they “are rolling the change out to all languages where cramming was an issue.”

At Zendesk events, we also talk publicly about product updates but make sure to caveat any projections with the understanding that things could change. This is not a niche trend: it’s not often that you will see public dates for new features or products. Why is that? And how can your Support team play at hinting about upcoming releases while keeping things under wraps?

We interviewed Kristen Miranda, a Product Manager for Zendesk Support, to learn more about why dates are carefully veiled and what role Support teams can play before, during, and after a product change.

Q: Why do you think stakeholders want specific dates and timelines for new releases?

A: Since teams need to prepare and plan their implementations several quarters out, they want reassurance that there are solutions for lingering issues and if there aren’t it’s important for teams to know so that they can find workarounds.

Q: What are you protecting against when you hedge about upcoming changes?

A: There is an economic term called ‘loss aversion’ which refers to how it is more painful to lose something after having gained it than having never had it at all. Since software development is agile and change happens, we want to avoid setting expectations that something will happen if it isn’t certain that it will. We want to be careful because we know that people make plans based off of what we share.

Q: Why does this result in a better Customer Experience?

A: If we only announce what is sure to happen, we are providing more accurate information. To digress for a moment, the reality is that product roadmaps are always subject to change; shifting priorities leads to resource redistribution which can delay or accelerate projections.

Moreover, even if we intend to roll out a feature, we may discover during the development or implementation process that there are technical limitations, that the solution isn’t right for the problem, or that circumstances have changed and other priorities are more pressing. We make a lot of assumptions in the development process. It is in actually doing the work that we are able to discover whether those inferences hold up or not.

If we widely circulated a detailed product roadmap before release were certain, we would be adding unnecessary noise. Customers need to know when things are coming out for sure so they can plan accordingly, so we try to give only the necessary information to save our customers time and effort.

Q: At Zendesk, we talk about being Humblident, a combination of “humble” and “confident.” How does that play into the above?

A: You need to ensure that you are always accounting for mistaken assumptions. Feature development happens in drafts, so you have to build-in being wrong; doing so is acknowledging reality. Planning for mistakes requires doing things like creating a minimally viable product, testing hypotheses, and identifying assumptions.

Q: Can secrecy be taken too far? Can you be too vague?

A: Yes. People need lead time to implement upcoming changes. For example, when we know we are going to deprecate a feature, we need to let people know as soon as possible since they may need to train agents to adopt new features or otherwise tweak existing workflows.

At Zendesk, we loop in customer success executives, account managers, agents, and other sales and support stakeholders whenever possible to ensure that they are having conversations with customers before significant change happens.

Q: What role can and do Support teams play (or not play) before, during, and after a product launch?

A: At Zendesk, we have a Product Champion (PC) program which allows agents to specialize in a product area and meet regularly with the associated Product Manager(s) to keep abreast of upcoming releases. These experts forward information to their peers, find good candidates for betas, hint to customers about upcoming solutions for outstanding issues, and route customer feedback back to Product Managers. When PCs advocate on behalf of customers, it helps us keep certain things on the roadmap which may have otherwise been removed.

They also help anticipate questions customers may have so we can address them beforehand and get on the same page about messaging. Moreover, since our Support team uses the Support Product itself, they can serve as testing subjects.

Finally, since they are working on tickets with customers, PCs can keep tabs on unintended consequences and help connect the dots if a product update goes awry. This is why it is critical to be explicit with them about what to look out for. For example, if we are rolling out a new feature that uses a shared service, we ask Advocates to look out for troubling tickets about other features that rely on that service.

Q: How can Zendesk features or tools be used to communicate changes?

A: Help Center forums, macros and triggers can all be used to announce new features, betas, or any other changes that people may have questions about. Setting these up proactively will empower users to find the information they need themselves or get routed to the right people when they have questions/feedback.

Here at Zendesk, we have a Product Feedback forum with feature requests. We will go back to associated posts after a new release to notify users when a particular feature request has been added to the Product Roadmap and also when it has been released.

Q: How do you balance transparent communication with setting expectations?

A: It’s important to hedge until you really know whether a new feature will be rolled out. You can say something is on the roadmap, but you may not want to disclose when it may be rolled out. If the customer is really eager for a feature that you know will not be added to the roadmap, you can let them know that you are focusing on the problem they want to solve.

Q: How do you keep the cat in the bag?

A: Any product roadmap documents we create internally have dates on them, are marked as ‘work in progress,’ and/or have a watermark to demonstrate that they are drafts. This signals that the projected dates are fluid and subject to change.

Which is all to say…

While it can often be taken too far, being vague about unsure outcomes often leads to a better experience for all stakeholders: it sets the expectation that plans are subject to review until they are as close to certain as possible. Keeping your Support team looped in along the way can ensure that they are your champions before, during, and after product updates and feature releases.

It is not easy to both confidently march towards outcomes and remain humble about the uncertainty around them, but it is important to try to integrate both qualities. After all, your customers and internal teams are looking for guidance and support as your product evolves. Doing what you can to guarantee they are able to successfully adapt to change and adopt new features is essential for your own company’s success as well.