Tableau Development and the Idea Selection Process
It seems that with every version of Tableau, major or minor, a certain amount of feature requests from the Ideas in the Community are released along with it. When 8.2 came out, we were finally able to mark one of the most popular ideas as Released -- Tableau Desktop/Public for Mac. The idea had over 400 votes, nearly 14,000 views, and was over two years old before it was released. So I decided to sit down with Thierry D’hers, our VP of Program Management, to get a better understanding of how the Tableau Development team uses these ideas and decides when and if they’re included into the product.
To start off the interview, I ask Thierry to give a brief overview of his team and what they do. He describes them as the “Feature Shepherds”—they are the faction of the Development organization that coordinates the work on features across the different teams, and though they don’t code or test, the Program Managers drive the shaping of the feature from ideation through execution to release.
So how is it that the Dev team uses the Ideas section? He starts by telling me that the future feature backlog is discussed every 6-8 weeks to review which features should be added, removed or re-prioritized. This is determined through a number of channels: the direction of the industry, the Tableau field (sales managers, consultants, support engineers, etc), direct conversations with customers, and of course, the Ideas section. However, in Thierry’s opinion the Ideas section is one of the best ways to review features for two important reasons.
The first reason is that "it gives us a sense of relative importance versus another feature."
Why is that? The natural properties that come along with ideas, such as voting or participating in a discussion, create data. This data can then be monitored for trends. For example, "we can see that something has been very important and now it’s stale. Or what was dormant is suddenly picking up in activity quickly."
It’s hard to get these types of trends when talking directly with customers because it is a one on one conversation. Though the customer may be able to highlight an issue, it is often times specific to that customer. "So it’s hard for a product team to know, if we need to solve that one big problem or do we solve a dozen little problems that have a bigger impact to more customers?"
The other reason Thierry is a big proponent of the Ideas section is that there’s a trail of conversations. "Many times people will say ‘Oh, I need that feature.’ But in truth, they don’t necessarily need that feature specifically. Instead, what they need is something else that can actually be solved elsewhere in the product or in different ways." Through the discussions below the idea, the conversation is being recorded and people can weigh in about their different needs.
I ask him to give me an example. His response? "Dynamic parameters." It’s the idea with the most votes and comments—and one that people often wonder why hasn’t been included in a release.
So why aren’t they doing it yet? "Well, because we’re still trying to get to the bottom of it. The idea and thread below it actually has four or five underlying issues. It’s not that we’re saying we don’t need to look into dynamic parameters –we’re looking into this…However, the worst thing we can do is build a feature that is called a dynamic parameter and realize we really only addressed 10% of what people were really looking for." So instead, each issue is being focused on, but what is delivered won’t necessarily be called a dynamic parameter as it might be delivered through other capabilities that address the root cause of the customers' pains. Thierry and I discuss that the Dynamic Parameter idea might never actually close out because of its sheer complexity, but it will begin to have less and less activity as the root causes are addressed one after the other, and another idea may take the lead.
This sounds fair enough, but I dig a little deeper—"setting aside dynamic parameters, how do you respond to the comment that there are still lots of votes on ideas that don’t seem to be getting addressed—it doesn’t seem like Tableau is listening to what we (the community) want and instead Tableau is adding features to the product that we never asked for?"
"That’s a fair question because there’s over a thousand ideas and we typically release 30-40 of them. And how do you pick those 30-40? Why don’t we pick the top 40? As it turns out we usually pick a few of the top 40, a few of the middle ones and a few of the lower ones…When you build a release you want to make sure you are addressing some of the current problems for your existing customers, but you also want to make sure you’re creating innovation and continuing on the path of the Tableau mission—which is to help people see and understand their data. If we had a release that was only focused on addressing customers’ problems, but was not promoting or pushing for the mission, that probably wouldn’t be a healthy thing for us to do either.
There are also times where an idea is getting a lot of votes or activity, but for which we don’t have a good design. So until we have the right and good design, we won’t do it. It doesn’t mean we’re ignoring it—because we’re not. We definitely need to find a way to close the loop and communicate this with voters."
So what can the Community do to help push the ideas that it really wants?
"Keep being active!" The more activity an idea has, the more pressure the Dev team feels to do something about it. Thierry mentioned earlier that his team looks at the trends in the Ideas activity, so if an idea seems to go dormant (and the Community thinks it’s because Tableau isn’t listening), unfortunately, their team sees it as a lack of interest in that feature. Things change and evolve, and something that seemed like a big deal two years ago, may no longer be a big deal anymore.
So continue participating! Search for ideas before you post, vote them up (or down), and add comments to give context to how the idea would be used.
After having this conversation with Thierry, it became more evident that taking on the Ideas section is a daunting task. However, by getting more involved in the process we may be able to bridge the gap. And so, one of my roles as the Tableau Community Specialist will be to help the Development team become more involved in these conversations so that users are being heard and there is an understanding between the two parties that working together will bring the best features forward.