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.

Thierry and his team

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.

Ideas Activity Dashboard used by the Dev team

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?"

Thierry pauses.

"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.


Interesting Tracy. Thanks for this. I had completely given up on the Idea section, because it didn't seem to make a difference. I have already created and/or voted up most of the Ideas that cause me pain. So now what? It sounds like what you're saying is to keep an Idea from looking 'dormant' to the Dev team I have to continually promote it, chatter about it. OK, if that's the message, I'll pick my top 10 pain points and keep badgering everyone to vote for them. Cheers, Shawn

I echo Shawn's comments. I, too, had given up on the Ideas. It's good that there's executive support of Ideas and they are given attention by the dev. team -- which underscores my previous Idea of increasing the dev. team headcount....

" 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? Thierry pauses...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."

This is what I've been saying, improved communication is so needed!

One of the most interesting articles I've ever read in this blog. I was also fascinated about myself because I think, I don't normally read lots of postings about the internal structure and organization of commercial vendors from which I use one or more products. This shows that your “Idea Selection Process” is still a thrilling concept.

After reading for me two important things remain:

The first thing is that you never know the status on the idea – did Tableau read it, is it in discussion, do they need more info, did they chosen it …. You definitely need more transparency – because there are a lot of voluntary contributors that invest a hugh amount of time into creating, clarifying and discussing ideas. This should be quite of value for Tableau. And they will stop if there is no response. We know from agile project management that communicating with stakeholders is the key.

The second thing is that from my point of view you should go the incremental way instead hunting for a perfect solution in the first step. Even if this only helps some of the people, you will get some feedback and can improve the feature to satisfy even more customers. A perfect example for me was the R integration – a great step in the right direction, but of course for me things are missing or can be improved (“Raw SQL” like functions that operate on row level, debugging functionality, import/export features, …). Else the idea may end up in an endless discussion mode.

Too bad we can't Like replies to blog posts. +1 for both these comments.

Thanks for the response about the ideas section. I'd like to offer some (constructive) criticism.

The current organization and presentation of the ideas section has become close to unusable given the large volume. I think its a very valuable part of the Tableau website, and it's helpful to review them, make suggestions, see other people's ideas and workarounds. But at this point, the current organization makes that process very tedious and time consuming.

We can see ideas grouped by the date they were originally entered or by the name of the person who made the original suggestion. That is not terribly relevant.

Please consider a more thematic arrangement -- perhaps expanding on the work by kettan and others to organize ideas.

Try to make it easy for someone who has a problem with some area, say actions or filters or dashboard layout, to find related ideas grouped logically and then read the content. Maybe more people would revise similar ideas instead of entering duplicates, or suggest useful workarounds. Searching for keywords or text is hit or miss. Some ideas fit in multiple categories.

I'd really like to browse idea categories in an exploratory way, much like you can expand topic areas quickly in the knowledge base.

So the most effective approach might involve a moderator who can add tags, reorganize categories, maybe mark potential duplicates.

Alex, I agree with all you've said. The good news is the Johan (one of our Communities MVPs) has taken on the herculean task of organizing the ideas section:

He did it as an example of how it could be better organized, hoping Tableau would take the 'hint' and pick up where he left off. The bad news is I'm fairly certain that Johan is now done with this, and has moved on to other things. So if Tableau doesn't pickup the ball, I suspect all his hard work will slowly age and become useless.



Tableau Ideas Team -- please take Shawn's "hint" above. Johan's work is really helpful, but hard to trip across. Instead the idea home page presents a relatively random list of the ideas have been entered or edited recently.

This is a great post, with one caveat. The notion that an idea going "dormant" means that it shouldn't be implemented seems to be poor logic.

I'm going to use one of my own ideas to demonstrate this, the idea of Chaining Parameters ( This idea may go dormant simply because there are not many uses for the idea. The uses are very important and have huge user impacts, but specifically speaking in terms of the number of uses, that number is very low. The two situations I present are really the majority of uses for this idea, but they are absolutely necessary.

This means that activity will inevitably stop on the idea. Even if people want a solution, they may not search "Ideas" for the problem, they will only search forums. I didn't even know about the Ideas section until about 2 months after my team started to use Tableau. Should my team just assign a person to log on an add a useless comment once a day to keep it at the top of the "recent" list and to generate activity? This seems like a poor model and one where the development team is asking for spam comments. Ideas should be evaluated on their merit, not how active they are.

First, thanks for this blog post. It is good to know more about the internal approach/thought process and it is very well-intentioned.

Second, we really need to do better than assuming ideas are dormant if comments and voting slow down on the idea. With the development lead time for ideas that do get worked often being at least 6-9 months out in a best case, it is easy for users that live the pain daily to become less engaged. As others have rightly pointed out, your "lead users" (those that share Ideas) are going to lose interest if there is not an increased level of back-and-forth dialogue. Today, it seems to be primarily one-way communication, meaning external users talking indirectly to internal Tableau employees. The utility of the Ideas concept ought to increase by orders of magnitude if there were increased communication from the product development team on a more regular basis.

I've always wondered if it's too hard to create a lab environment with a number of beta features that users can test? There are several examples out there where users are invited to a secluded and fully tracked sandbox. Product developers (Tableau in this case) could hugely benefit from understanding user behaviour from real experimentation data. This is not to say Tableau needs to make 1,000 ideas available for testing, but let users test a minimum viable version of more concepts before committing hours of refined dev work and then releasing new features.

Dynamic Parameters was first suggested as an idea in March 2012. There must be over a hundred comments explaining the issue, with details and suggestions. Tableau's feedback to date is that they are still looking to understand the underlying requirement and problems... it seems to me the Company focus is on the 'sexy' features that have a marketing impact, such as Story telling. The Ideas page is touted as way for end users to influence the direction in which Tableau takes this product, but this is becoming increasingly difficult to believe.

Really, dynamic parameters is that difficult of a concept to implement? Yes, some people may want "extra" features of dynamic parameters, but the very, very basic feature is, when you connect a parameter to its source field, the parameter updates when its source is updated! How simple is that?

It doesn't take a rocket scientist to figure out that this is what 99% of Tableau users want.

I also agree 100% with the two comments immediately above mine. An easy majority (estimated 70 - 95%) of the demand for dynamic parameters will fit into a single use case. The remaining four possible interpretations of the term are edge cases. And it is not difficult to discern where the bulk of the ask is situated:

Folks need for parameters to drive multiple, independent data sources. And they need for those parameter values to update dynamically when new data arrives.

That's it. It's that simple. It's been there, untouched, for three years. And that you've focused on flashier features to sell more licenses is evident. The complex job Tableau performs is difficult, and the leaps & bounds forward in version 9 are amazing on all fronts: from performance to functionality.

Yet this spin to explain why dynamic parameters has been hitherto ignored is insufficient. As soon as the DP idea has been split apart into its five interpretations, and as soon as the dominant ask is squarely identified, then let us all hope and pray for a fast-track implementation.


Although dynamic parameters sounds like a simple feature to add, it is more complicated than you would think at first glance -- as the developers made clear at the last conference. The main issue is that currently parameters are independent of all data sources, which is precisely why they are so useful for say filtering across data sources.

To get the list of parameter values from a data source then requires tying parameters to particular data sources which breaks the current design and changes dependencies throughout the computation pipeline. You have to answer all kinds of questions about how to handle cases where where the data source is unavailable etc.

Not saying I don't want the ability to populate the list of possible parameter values from a query, I do. Just that I don't think Tableau has deferred this feature thoughtlessly or simply because of a desire to emphasize the flashier features only.

The good news is: absolutely _everything Tableau does_ is more complicated than it would appear at first glance. By & large, that is precisely the reason why people embrace it.

Tracy's interview with Thierry makes it clear: the program managers also have a difficult job (not only the engineers). More than anything, their focus is prioritization. And, in every walk of life, it is never possible to make everyone happy.

If anything, I hope to convey that: Tableau 9 is awesome (the engineers have not been asleep at the wheel). Dynamic parameters are difficult (yet very achievable). And the current approach to split the idea & pursue what the majority wants is great.

So what then is insufficient? Simply that this elephant has been in the room for a long time now & the outward process to address it has only just begun. Lesson learned: do what you're doing. Just do it earlier for the elephants. This will avoid stigmas like dynamic parameters from creeping to become a controversy.


Thank you everyone for speaking up here. Sean Boon, on the Tableau program management team, knows and understand this area very well. Chris and the development leadership team have been thinking about it for the last three years. Had it been simple and straightforward, we would have done it already. We want to address it incrementally by starting to address root cause scenarios one at a time. It is not a one-feature-fix-all-scenarios type of things. Taking the survey will help Sean, Amy and the developers figure out which scenario to take on first based on the scope, impact, complexity and how to design it right…
Don’t give up on the Idea forum please. We need you. We are not perfect at closing back the communication channels, we know, we are trying to get better at it too. Your voting, idea suggestions and scenario descriptions in these ideas post are super important and valuable to us. Thank you all for being vocal with us. Thierry

i love to the group and i want to part of who will help me? i love you all.

i love the group and i want to part of who will help me? i love you all.

Abonnieren Sie unser Blog