I recently had an extended conversation with Tom Conrad, Chief Technology Officer & Executive Vice President of Product at Pandora, the Internet radio pioneer. Tom was a user interface designer for Mac OS at Apple, held posts at Pets.com and Documentum, and was the Technical Director for the You Don’t Know Jack line of video games before joining the founding team at Pandora. Our talk was so rich in content and ideas that I decided to parse it out into a couple of posts.

My interest in chatting with Tom was not in the “so you’re doing agile development” vein; rather, I’m interested in innovative companies that have migrated from agile development to agile strategy, and Pandora is a prime example of this wave of management philosophy. As many organizations have discovered, agile development can help add flexibility and responsiveness to their development cycle, but these improvements only go so far when the rest of the organization has not evolved to a more agile approach.

Tom began our conversation by poking a hole in one of the foundation ideas of the IT revolution of the past few decades: the suggestion that the rapid changes we’ve seen have been due mostly to rapid technological advance. He said:

If you’d asked me during the first 12 years of my career, what were the biggest innovations, I wouldn’t have said laptops, or the Internet, I definitely would have said that the massive changes in the way that we write software was the single most disruptive thing I’d seen to that point.

This is, in my view, an important insight; as critical as new hardware, software, and connectivity technologies have been to the IT revolution, none of these developments have been as meaningful as the migration to more iterative, collaborative, and change-friendly development techniques. I’m in vehement agreement with Tom on this point; these new development approaches have enabled the rapid, responsive release of products that solve customer and consumer problems, and that have facilitated the evolutionary release cycle we’ve all become accustomed to, with new iPads and iPhones, new versions of cloud-based software, and new generations of digital cameras and microprocessors every few months. While many of these new capabilities are delivered in hardware, they’re based on software, and iterative, incremental evolution focused on the needs of the marketplace has been the real enabling technology of the revolution.

Tom next reminded me of the restrictions of the “bad old days,” even at a company seen as the poster-child of innovation:

At Apple we couldn’t change a single byte without a year-long certification and release cycle. When I was there, that cycle was, pragmatically speaking, closer to two or three years. We did a little better than the automotive industry,  in terms of innovating and getting to market quickly, but not much.

Tom and I chatted a bit about how these agile ideas have manifested at Pandora. He started by describing how traditional, multi-year strategic planning would handicap an innovative company like Pandora:

Mobile systems, new advertising technologies, are all changing at a tremendous pace; we know more about the opportunities there today than we did 90 days ago. 90 days from now the world will be further fleshed out. It’s important for us to react to new information. If the iPhone SDK becomes available, and 90 days later the apps store opens, if you’re in a multi-year cycle, obviously you’ve risked missing an opportunity to react to critical new information.

Tom has defined in a brief comment the challenges that today’s innovative companies face that Westinghouse or Proctor & Gamble, for example, may not have faced 20 years ago. While innovation and new products have always been an element of strategy for leading companies, the marketplace was significantly more stable and the product cycle much more deliberate and long-term than it is now. Maytag may have had to release new features and functions in its household appliances, but it was unlikely that entire new markets and platforms for their products were opening up and mutating month-by-month.

Tom went on to describe how these new conditions influenced Pandora’s innovation cycle:

Everything we do here has been based on a 90 to 120 day calendar. I can tell you, based on the marketplace reaction to our products, where we might be 90 or 120 days out, but for each month beyond that it gets foggier and foggier. What that allowed us to do is be reactive to new opportunities as they come along. This planning philosophy informs how we perform all the way to the CEO level, and we have great support for this approach from the CEO.

I asked Tom how the strategic planning process at Pandora diverged from the traditional, annual, all-hands session that often ended up with a 100 item project list of initiatives that never got prioritized or acted upon because it was so large and overwhelming.

For six of the years since we’ve launched, from 2005 to 2011, we used an agile version of the old-school, facilitated off-site approach. Every 90 to 120 days, we’d build a list of new opportunities presented to the business. This was a product-management facilitated process, with the advertising team bringing in ad opportunities that had come along, and the product teams speaking with the voice of the consumer. We’d generate a list of maybe 60 different product ideas. There’d be a single PowerPoint slide for each opportunity with a few bullet points fleshing it out. The only requirement for getting on the list was that there was some stakeholder somewhere in the business that thought we’d be foolish not to pursue that idea in the next 90 days. Then we passed the list to the engineers who articulated the resources required to deliver, but certainly nothing like a full specification. Then we’d bring all the executives together, I’d hang all the sixty or so ideas on the wall, and I’d give a walkthrough, describe who supported them and what revenue might be tied to them. We’d hand out little sticky notes, and everyone would get the same number of votes, and the CEO, myself, every exec would walk around and vote for the ideas they supported. There’d be some horse-trading and some reconfiguration of some ideas, and at the end we’d have about 10 to 15 ideas that were fully supported and the rest with a few votes here and there. So at the end of the process we’d hand off 10 or 15 initiatives to the engineering team and let them run with them for 90 days, and at the end of that time we’d go through the process again.

I think that Tom’s description of the original Pandora planning process is instructive for a few reasons.  Firstly, it’s more agile and iterative than most corporate planning processes I’ve experienced, and is a great fit with an agile software development approach. The number of projects generated by the process is small enough so that they can be tried and either accepted or rejected based on real-world engineering or market results, rather than on politics and positional jockeying. The cycle is quick enough to frequently consider new developments in the marketplace or the technology. The realities of resource constraints are built in to the process, since under-resourced projects are bound to fail, and so will bubble up to the vision of the executive team at the next session.

Yet, as agile and responsive as this approach is, especially when compared to the traditionally strategic planning techniques employed at more traditional firms, Pandora’s management team felt it needed to evolve to become even more responsive and agile. We’ll hear from Tom about the new approaches Pandora employs, and the challenges of agile planning, in our next post.