Pat Hanrahan,
CTO and co-founder of Tableau Software

Tableau Software CTO Pat Hanrahan brings freewheeling creativity to the staid world of interpreting data.

Seattle's Fremont neighborhood is a known haven for creative eccentrics; it is a place where the official motto is "Delibertus Quirkus" ("Freedom to be Peculiar"). It's not a place you'd expect to find a buttoned- down business software developer. True to form, the 30 employees at tiny Tableau Software earn their keep in Seattle's self-proclaimed "Center of the Universe" with high-end resumes that somehow cross Hollywood with Wall Street. Advanced-degree Stanford alums are the core of Tableau, counting CEO Christian Chabot, who arrived from Mobius Capital Ventures, and five Ph.D.s, including Director Jock Mackinlay, who is credited with coining the term "information visualization." CTO and co-founder Pat Hanrahan keeps a pair of Academy Awards on his mantle from his old job as chief architect of Pixar's RenderMan software, (since employed in Lord of the Rings, Harry Potter and many more blockbusters). Hanrahan's work at Pixar in the 1990s actually preceded his Princeton and Stanford Ph.D. degrees, where biophysics and parasitic nematodes were heavily involved. Cut to the chase and you realize that talking to Pat Hanrahan is not your usual software exec interview, as DM Review Editorial Director Jim Ericson recently found out.

DMR: How does a successful creative fellow like you wind up in business software?
Pat Hanrahan: The two great uses of graphics are for entertainment and art and for informative purposes. I figured we had done a lot of great work in entertainment, but I didn't think graphics had been used effectively to help people do their work. If you buy a new PC, it has an incredible graphics chip built in, and the only time anybody uses that technology is for playing games. Business applications are not really taking advantage of the technology. Thinking about that sort of led to Tableau, understanding how graphics convey information and support reasoning.

DMR: It still sounds a bit gimmicky for corporate technology.
PH: In movies and entertainment, graphics are designed to tell stories. That's a little different than helping people reason. But there are similarities - you have to know what problem you're trying to solve. One reason Pixar has done so well is that they don't just make grand special effects; they really know how to tell stories with the technology. When we started this research effort, we were interested in learning about how people use graphics to digest information. I worked with several psychologists, talked to a lot of graphic designers and then my friend [VP and co-founder] Chris Stolte decided to do a thesis on this topic. He and I invented a system for building informative, useful graphics. And that's what became VizQL.

DMR: I think a lot of people have heard about VizQL but don't understand what's so different about it.
PH: The model that people have used forever is to do analysis with calculators, spreadsheets or some kind of computer interface in rows and columns of text and numbers. Once you're happy with the numbers, you run a charting wizard that gives you three or four choices of templates - pie charts, line charts or bar charts - you make your choice, create your picture and off you go. In VizQL there are no charting wizards, templates or frames. When people ask how many charts our product can build, we ask them, "How many questions can you ask? How many calculations can you conceive?" What VizQL lets you do all at once is describe a picture, query the database and perform all the analytical calculations you need to create the picture you want. The engine takes you through cycles of analysis, which means that as you pose questions, you do simple things like drag new fields into the user interface. You get an answer, and then you ask another question. You almost never think you're using graphics; you're just asking questions, and the engine underneath makes it work by putting process to visual analysis. I should add that when we originally came up with this we didn't know a lot about business intelligence [BI] - Chris and I were computer scientists. Fortunately we met up with Christian Chabot, who had a lot of experience as an analyst and knew a lot about the field. He immediately understood how this technology could be incorporated into BI products, and that's when we launched Tableau.

DMR: So it's really like learning a new semantic language and iterative process of thinking.
PH: Exactly. People have studied graphics as a language, and that's our approach when we design. The key thing is to pay attention to how graphics communicate information and encode the information in the form that's most effective. You compose an expression in the interface on the fly, and when you add or subtract something, you modify the expression. In our system, we consider text tables a special case. Text tables make sense if you want to look up something in a table. If you want to look at outliers, a text table is slow and ineffective. So depending on the task you do, there's a particular way of representing the information so that the task is most efficient. It's very different than the traditional data visualization approach to the problem.

DMR: It also sounds like you could quickly get lost and go in the wrong direction if you don't know what you're doing.
PH: That's true - there is some skill required to do this. One of the things we spent a lot of time on - more at Tableau than at Stanford - was building in the rules of best practices. It's no different than building a database schema; there are best practices to follow, and any random person could do a bad job. We have spent a lot of time and energy trying to take the principles of visualization and code them as rules. Some customers have said this is like putting [legendary graphic designer] Edward Tufte in a box. He has all these rules about how to design visualization, and we've taken those and many more and tried to encode them so that users can default to choices that tend to be pretty good.

DMR: Some creative types can't wait to use a heat chart or 3-D in presentations. Is it a rule of thumb that the person making the presentation ought to prepare the graphics for it?
PH: Basic visual literacy is like other types of literacy - reading, writing and graphics. People in the Stanford writing program take on rhetoric and other disciplines, and I've seen them spending more time teaching graphics. If you're an average person writing papers and reports and giving PowerPoint presentations, you're probably spending more time crafting charts and diagrams than words. People haven't been taught how to do that. There's good writing and bad writing, good graphics and bad graphics. We all have technology to produce graphics and words. We need to train people to use appropriate graphics and use them better.

DMR: One of our columnists, Neil Raden, recently wrote about the difference between ease of use and usability, that designers are dumbing down software too much to serve older generations of workers.
PH: A common challenge of designing software is to make it do useful things but still be easy to use. There's always a trade-off, but we think ease of use is just as important as high utility. My colleague Jock Mackinlay spent 18 or 20 years at Xerox PARC, which was sort of the planetary epicenter for user interface design. Part of our mission is to expose all of these new capabilities to people because the technology is still inaccessible, on average. A lot of information is still inaccessible by traditional means. Part of the mission statement has to be to make this stuff easier to use.

DMR: Is that reflected in the user base for your products?
PH: Our hunch initially was that power users or early adopters would grab onto the product. That certainly has happened; but unlike the BI vendors that sold to IT and created a value proposition whereby the IT group would adopt and proliferate the product, our approach has largely been directed at the end user. These people come from all walks of life; we don't find many people inside organizations today that aren't interacting with data at some level some of the time. It could be a product manager at Starbucks, a securities analyst at a hedge fund or a researcher at Dow Chemical. We have many institutional researchers in academics, a lot of government agencies. All of the branches of the U.S. Armed Forces, the NSA [National Security Agency] and homeland security are all using the product at some level. We also have a lot of small and medium-sized companies who can't afford a big BI investment. To them, Excel and Tableau is their BI implementation.

DMR: I can see the standalone utility, but Tableau is the kind of product I'd expect to see embedded in bigger platforms.
PH: That's a good point, and in fact we've worked on a number of projects, some obvious and some that are not. We have a close relationship with Hyperion - they private label a version of the product under their own brand. Most people have figured that out. There are other examples; we've been approached by a lot of companies with some ideas that are good and some that are not. It is something you have to do carefully, because you want to develop a market, and we believe we're building a substantial company. The Hyperion deal came early on in our lifecycle, and though some people thought it was crazy, it has been an amazing partnership and commercially very successful for us.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access