Ted Wasserman on Tableau’s product development approach

Ted and Lee and Lauren at NYNJ TUG at TCC 2014 Seattle

Ted Wasserman (Tableau-Product Manager), Lee Feinberg (President-DecisionViz), Lauren Rogers (Tableau-User Groups)

At Tableau Conference 14 #data14, we held a special user group event, starring Ted Wasserman.  Ted is a product manager and shared how the company selects features to develop and how they use agile development…

Ted Wasserman: Take the collective wisdom of all of you guys – you’re all in different companies, different industries, trying to analyze data in different ways. How do you take the common scenarios, the common pain point, the common everything, sort of bubble that up into something that’s useful, that we can take and really understand what’s hot, what’s going on, where are the problems, what are our customers doing. We could have 50 individual conversations and we would get 50 individual different answers, and that makes the problem difficult.

And it’s a hard job. Being a product manager is a really rewarding job; I love it. But at the end of the day, it’s difficult, because you only have limited time and resources, and you have to make sure what you ultimately choose for the product roadmap is something that’s going to appeal to a broad base of customers. You do it in a way that makes it delightful and useful for them.

Lee Feinberg: We all definitely get the notion that there’s so much to go through and figure out what goes into each release, and even how each of those pieces work. Can you give us an idea – what’s it like to actually go through making that decision? Is it you who does it? Is there a little team that talks about it that gets to finally say, “This is what we’re doing, this is how it’s going to work”? What’s it like in that room when you’re really making the choice?

Ted Wasserman: Yeah, it’s interesting, and it just varies. Like I said, we have major themes that drive what we’re working on, and within each pillar or bucket we have individual teams that are working on it. So we have a team working on our mobile app, we have a team working on our enterprise capabilities. Within each team, we keep a long list of things we’d love to do. That list gets populated with user feedback from all the sources that I just talked about.

Come release time, everybody gets together. We have input from the sales team, from the development leadership, and thought leadership team, and executive team. “Here are the top things, out of this whole list of things we could be doing, here are the top things that we think we need to do sooner rather than later.” Because eventually you’ll get to all of them, or the list just keeps going.

But “Here’s what it looks like right now. Here’s why. Here are the patterns we’re seeing across the different regions, in different countries.” The people in Japan maybe have different needs than some of you here. So we take all that feedback, and we end up – you go through an exercise and say, “We only have this many resources, this many people hours. We know how long each of these is going to take.” So based on that, we optimize, and here’s the list.

It goes through multiple people, multiple thought leaders at the company, and at the end of the day, that’s where the decision gets made.

And it’s fluid. Because we’re in an agile model, we’re not necessarily locked into doing something. So if something really important came up, we have flexibility in our schedule to change things, to alter the order. But from a high level perspective, we sort of know – even if you take a quarter of that long list of things, we at least know what the first quarter looks like. We always have an idea of what are the top things we would need to work on.

Lee Feinberg: You’re being a very good straight man, because the next question was about agile. You made a comment, and it really just caught my attention. You said you’re moving to a way that you’re going to be more agile. Can you tell us a little bit about what that means, what the change is?

And also, can you tell us maybe how some of what you’re learning about changing how you do your work could translate to how the people here do their work, actually building – we have our list of ideas that we get that we want to build our dashboards or change them and so forth, so how can we take some of what you know how to do and apply it to our work?

Ted Wasserman: That’s a good question. Really, if you’ve been in software development – I’m not sure what your backgrounds are, but agile is a new methodology or more modern methodology for developing software. You used to go through this more serial – they call it a waterfall process, where you spend a lot of time debating the requirements upfront and all the designs, and then you implement it. Then you test it and you give it to customers to use, and then it goes into production magically.

But what ends up happening in that old model is that you get feedback much too late in the game. It’s much more costlier to make changes later in the game. So what really agile does is it changes the way that process works and makes it a lot more dynamic. Rather than going through all those serial steps of requirements and design prototypes and build – it’s just much more fluid.

So what that means is you have looser requirements upfront, but you want to make sure the high level description of the scenarios are really the right ones. It means you value quick prototyping and so on, and getting immediate feedback, rather than waiting too late in the cycle. So that’s why I mentioned our alphas have already started Version 9, even though we’re not shipping the product till next year.

In the past, alphas would be really close to the beta programs. We’re starting a lot earlier now to make sure we get very early feedback.

The other change that’s part of that is the focus on quality. So even within these different development groups, like I said, if you think about it, you always want to be at a point where you can ship code in in a quality way and on schedule with the best set of features.

So whatever you build early has to be quality, it has to be validated, tested, so that you have the ability and you don’t carry problems or issues down the road with you as you do further development.

I think those are the two big things, is earlier customer interaction, so getting involved, making sure that the right customers are involved in that earlier interaction is important.

It’s finding those early adopter customers to give you feedback on the areas that you’re actively working on is something we’re really trying hard to do. So working with the user groups to identify who those potential customers might be, are they the right fit for the alpha, do they have the bandwidth to do it, do they have the extra servers to install, like an early Version 9 alpha build, and do they have cycles to give us the quality feedback.

That’s really important to us, because we put a lot of effort in. In the alpha and beta programs, you’re dealing directly with the development team; you’re not going through the traditional technical support channel. So we want to make sure we have a lot of engaged customers and users giving feedback.