In the tech industry, the "tell me a story" approach to product requirements – personas, user stories, use cases, visualizations, etc. –  has made a bigger impact than many people may realize. Not only has this new type of content resolved many problems that existed with requirements, but it has led to a brand new way of looking at requirements. By thinking of requirements as stories, it's easier to figure out what kinds of requirements we need, and why we need them.

A tale of two mini-series
The fundamental question when writing any kind of story is, "What are you trying to convey?" I was thinking of exactly that question while I was watching the HBO mini-series The Pacific. I probably wasn't the only person to expect The Pacific to be the same kind of story as Band Of Brothers, just transplanted from the European to the Pacific theater of operations. I was wrong.

As it turns out, the new series has a very different kind of story to tell. Band Of Brothers depicted the experience of combat, in (literally) gory detail. While The Pacific does have more than enough battle scenes, it also tries to show military life beyond the battlefield. For example, one episode focused on the painful romantic choices that young people stationed in faraway lands have to make. Another episode depicted something rarely seen in war movies, the psychiatric casualties of war. Far more than Band Of Brothers, The Pacific shows more of the atrocious things that young men under brutal, terrifying conditions are capable of doing.

Agile adoption requires a change in values, not just a change in process. That's the message of the Agile Manifesto, and everything we've learned in the year since the Manifesto's publication has only expanded and emphasized it. We might not have all the specifics on how that relationship works (for example, does an "Agile culture" automatically dictate Agile practices?), but the correlation is definitely there.

In technology companies, these values are critically important, since technology does not just improve the business, it is the business. Agile changes how teams develop and deliver technology. In a technology company, delivery includes practically everyone outside the development team—marketing, sales, support, consulting, partners, you name it. Beyond the janitorial staff, it's hard to think of someone who won't be effected when a tech company goes Agile.

Consequently, product managers and product marketers, sitting on the border between the development team and everyone else, are simultaneously the agents and targets of Agile transformation. For example, when monolithic releases crumble into many smaller iterations, people throughout the rest of the company have obvious questions, such as,  When can I tell a customer to expect the enhancement they've wanted for the last two years? When is the next time we're going to have to do sales training? When will we have delivered enough new value to merit a product launch? PMs facing this situation will have to make adjustments to their own work, such as building and communicating the product roadmap.

Last Saturday, at the Silicon Valley Product Camp, I was part of a panel on PM metrics. Any topic that's at the same time important and unsettled keeps you thinking long after the panel, so not surprisingly, almost a week later, I'm still chewing on it. Here's an observation I'll make today, after further pondering:

You know when you're doing well as a PM when someone yells at you for getting a persona, user story, use case, or task analysis wrong.

Understanding the world from the standpoint of the individual buyer or user is one of the primary responsibility of PM. According to some schools of thought, it's the core responsibility, especially since no one else in a technology company is responsible for collecting, analyzing, and distributing these deep customer insights. (There are other core responsibilities, too, related to the company's business and the technology itself.)

That information may look academic, but it should be immediately pertinent in very important ways. Understanding the way in which people in a variety of roles assess, purchase, and adopt technology is critical for making smart decisions about everything from product design to the product roadmap, from crafting messaging to choosing marketing channels. Unless you live in a Soviet-style command economy, in which manufacturing 3,000 left shoes is a problem for the consumer, not the producer, customer insights need to inform both strategic and tactical decisions.

I swore that I was not going to say anything further. I really, really tried, but I'm going to have to throw away the little plastic medal that says, "Two Weeks And No Buzz." Here's a must-read quote that a colleague forwarded to me:

So why exactly did Google Buzz launch with some key social features missing? Jackson said that while Google employees were testing out the product internally, they never had much desire to mute any of their coworkers, and that their email contact list closely matched the people they wanted to follow on Buzz. Obviously, that wasn’t true for most people once the product was released outside of the Googleplex. Which is why Google is considering pre-releasing new Buzz features to a few thousand opt-in users long before they’re rolled out to the public.

The short version: "It worked for us inside the firewall, so we never thought it'd have a problem outside the firewall." Of course, an enterprise collaboration tool is a wholly different kind of solution than a social networking tool, so the requirements for the former do not completely cover the latter.