If you're still baffled, flummoxed, or concerned about Facebook's now-infamous privacy policies, here's a handy chart from The New York Times. (Thanks, Madiha, for the pointer.) While the diagram retains a neutral tone, it's hard to read the phrase 50 settings with over 170 options without having a "What the hell?!?" moment.
In defense of Facebook, they're no worse than many technology companies that devise confusing UIs, full of knobs and dials that users don't understand or use. These companies are still to blame for creating the circumstances in which a confusing UI is hard to avoid, so they're not completely blameless.
An apology to future generations
Here's where we venture into the idiosyncratic sub-culture of the tech industry, which is hard to understand if you've never been part of it. In spite of having big development budgets, a staff of seasoned professionals, and months to build a useful product, tech companies repeatedly build software that begs the question, "Daddy, why is your product so hard to use?" (Even weirder: usability is often inversely proportional to the price.)
A lot of my recent research – about SaaS/PaaS, Agile tools, requirements tools, and innovating with your channel – share a common conclusion: successful technology vendors see integration as more than just a necessary evil. Here's why.
Business problems drive technology adoption You can see this principle in action in the requirements tools market, which in the last decade has grown larger and more complex. Teams use these tools to address more than one type of requirements-related challenge, so it's easy to see why the tools themselves are now as diverse as as Micro Focus (née Borland) Calibre, Atlassian JIRA, Ravenflow RAVEN, and VersionOne's Ideas Management module. If your problem is, "People don't like using our product," you might look at a visualization tool like iRise to shorten the feedback loop, leading to better design decisions. If, instead, your problem is, "We don't have a good business justification for what we build," you might look at IBM Rational DOORS to evaluate the pros and cons of alternative scenarios for what goes into the next release.
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.
While there might not be a single correct formula for fitting product management into an Agile setting, there's one inescapable rule: Prepare to have your PM skills put to the test.
Recently, I was speaking with Barry Paquet of Quantum Whisper, a small firm that has a tool designed to help PMs with these Agile-related challenges. To the right, you'll see one of the slides from Barry's presentation. The message is pretty self-evident: if your company is going to take the "voice of the customer" part of Agile seriously, PM must keep a lot of plates spinning. Feedback loops in Agile development don't run themselves—someone has to be on top of the collection, analysis, validation, communication, and review. With Agile, these activities are happening nearly constantly.
While any PM who has a passion for building good products should welcome this change, it also can be a little scary. In my own research and advisory work on Agile adoption in tech industry companies, I've heard some PMs express no small anxiety about this new model. In part, they're worried that the company might not support or even understand this process fully. However, they also experience some dark nights of the soul about whether the have the skills and experiences needed to play that sort of role. Here are a few common concerns:
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.
One of the great things about researching Agile is, given the scope of both its applicability and effects, you'll never run out of interesting topics. Agile product management, Agile used outside development, contract details in Agile projects, Agile channel management, the effect of Agile on requirements—researchers like myself and Dave West, writing about Agile directly, will have plenty to do for years to come. So, too, will others, like Mary Gerush, exploring the effects of Agile on requirements and other aspects of development.
As Agile goes mainstream, video game developers like Bioware have taken the Agile plunge. This corner of the technology market is very interesting because of the high level of challenge. In some cases, video game developers face extreme versions of common problems, such as an unforgiving standard of product quality. (Ship a crappy product, and your dreams of making obscene wealth will be replaced with the nightmare of watching your game vanish from retail channels.) Other challenges are unique to the video game industry, such as managing all the creative talent—artists, musicians, and actors—critical to product success. (But heck, if you get to meet John Cleese, Claudia Black, or Gary Oldman, the work can't be all bad.)
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.
In product marketing, you always want to sound like the smartest person in the room. However, you shouldn't prove it with marketing messages that only you fully understand.
At last, someone who can understand my brilliance
Colleague Mary Gerush and I are working on a market segmentation for requirements tools. It's a great excuse to get into a lot of very interesting conversations about some very deep topics. The requirements market is in transition, from an era of heavy-weight tools designed to address information management challenges, to something very different. (You'll have to stay tuned to find out what the new market looks like.) We're starting from scratch, with no particular attachment to the traditional terms and concepts for describing what these tools are supposed to do.
That's the entree into the very interesting conversations. Vendors in this space, whatever it is, are very smart people who think about the shape of the requirements market all day long. Not surprisingly, their opinions about the market, which are reflected in their marketing messages, are very smart, too. In fact, in a couple of occasions, I wonder if they were being a little too smart.
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.
Until now, geolocation has been one of those quaint, semi-useful buzzwords: '... now with geolocation!!!' Twitter, Buzz and Foursquare -- the main exponents of exposing your location -- might not be small, but they pale in comparison to Facebook. With the announcement that Facebook will be enabling geolocation next month, Pandora's Box has been torn open; whether you like it or not, geolocation is about to become a huge part of your life.