I hate the unnecessary inclusion of versus in titles and headings, because it often implies an adversarial relationship where one does not—or at least should not—exist. But, while product managers are often the greatest allies UX professionals can have, in spite of the many positive aspects of our relationships with them, there is some inherent tension between us. They usually want as many features in a product as possible, while UX professionals and developers typically do not want to be held accountable for fulfilling unrealistic expectations of what we can accomplish in a single product release.
Champion Advertisement
Continue Reading…
Figure 1 illustrates this conflict.
Figure 1—Product Management versus Development
In my current role, I do a lot of negotiating back and forth between product managers, their stakeholders, and my product development team trying to refine a set of requirements for a given product release or a roadmap of releases. This reminds me of a study I did back in my doctoral days, when I observed the differences between Product Management and Development during a particular product’s development cycle. I had summarized my observations using the metaphor of a couple packing to go on vacation.
One is thinking about being there and has an extensive list of things to pack—and frequently changes or adds things to the list up to the last minute. “Certainly, we’ll need flip flops for the beach, but we might go hiking on trails, so we should bring our tennis shoes, too. Oh, and let’s bring some dressy shoes for going out to dinner.”
The other is thinking about getting there, so is focusing on getting everything into one bag and a carry-on. Every time the former makes a change, the latter sighs deeply and unpacks everything, making room to add the new item. In some cases, this forces a swap with something already packed. Figure 2 articulates what every accomplished packer knows.
Figure 2—The Packer’s Code
So, according to the metaphor of packing, the product manager is the visionary, the one who imagines how great it will be when we get there and identifies all the things we’ll need to make it an enjoyable experience. The developer plays the role of the packer, the one who must fit all of that stuff into the constraints of reality.
Resolving the Tension
The obvious question is: how does one eliminate this tension? I, for one, don’t think we should. I think the essence of design is to resolve tensions, not eliminate them. In the past, I have written about some classic UX design tensions like convention versus innovation and control versus freedom. (See my UXmatters column “UX Dimensions of Conflict.”) In these cases, the conflicting poles are not binary choices of this or that; rather they are like the opposite ends of a radio’s speaker balance knob. More of this gives you less of that. The designer’s question is: “What is the correct blend, given the problem I am trying to solve?”
So, from the developer’s point of view, the first step is to recognize the validity of the product manager’s perspective and the value it brings. Remember that the trip to the airport, then to the vacation resort takes just a few hours. After that, you’ll be at the resort for an entire week. The benefits of packing lightly start to fade as you go horseback riding in flip flops. Similarly, the appeal of an efficient set of requirements that you can easily meet within the time and technology constraints can quickly wane, as a thin set of features struggles to succeed in a competitive marketplace. And in spite of your best intentions to expand upon the current release in the next one, the newest bright and shiny thing may have emerged, so it is likely that the thin release will have to sustain your business presence in that marketplace, because there may be no reinforcements on the way.
The second step, from the developer’s point of view, is to recognize the validity of his or her perspective and recognize the value of constraint. There’s no need to be apologetic or shy about this. As the old project management chestnut says, “Better is the enemy of done.” Your vacation ceases to be any fun at all if the airline doesn’t allow your luggage onto the plane. You cannot enjoy being there if you cannot find your way to getting there.
Some Practical Techniques
Next, I’ll describe two simple techniques that help me to manage this productive tension between me and my product managers. One consists of making all of the hard requirements decisions before making any development investment; the other describes a useful yardstick with which to make such decisions.
Negotiation Through Artifacts
Every good packer knows the secret to packing is to stage everything before packing anything. For example, if I am packing a suitcase, I lay out all of the clothes on the bed first. Similarly, if I am packing my car, I put all the luggage and stuff we need to take with us on the driveway first. Then I can make better decisions about what should go where and when I should put it there.
As a UX designer, I do the equivalent of staging when I create scenarios and wireframes, essentially laying out and agreeing on the user experience before we start investing significant development time and resources. (See my article “Usable, Saleable, Buildable: The Role of UX in Defining Requirements.” The fight over what is in and what is out is a good fight; a fight that needs to happen. It’s just not a fight you want to have when the product is already in the middle of QA. Because, when you inevitably start throwing things away, you won’t want to have invested lots of value into what you now must discard. I think one of the greatest values User Experience brings to the table is our ability to moderate these fights and negotiations by leveraging artifacts in which we’ve made little development investment.
Minimum Viable Product
Eric Reis, a Silicon Valley entrepreneur, popularized the concept of a minimum viable product, and agile developers have adopted this approach as a way of deflating large sets of requirements into manageable, independent chunks of development work. Essentially, an agile team asks, “What is the least amount of functionality our product has to have before users would find themselves compelled to buy the product?” This establishes the minimal target—the point below which you would have wasted all of your time and effort, because you would have nothing to show for it that anyone would buy. For example, NotePad or a similar text editor probably represents the minimum viable product for a word processor. If you couldn’t do at least that, you’d have nothing to take to market. Or stated in the converse, if you could do at least that, you’d have something someone would buy.
The nice thing about the concept of a minimum viable product is that everyone on a product team can pretty easily agree on the feature set that it represents. Establishing this baseline clears the landscape for the stickier rounds of negotiations, when you go through similar iterations of finding the next group of features that represent the next most important level of viability. For example, a next logical step for NotePad would be to introduce more sophisticated text formatting and allow Rich Text Format (RTF) output. Adding features that got you just half way there would provide no additional value. In short, you need to apply a sort of quantum theory to feature sets—as in, “Anything that doesn’t jump a gap that’s this big brings no value at all.”
When does this stop? When you run out of allocated development resources.
I once worked for an online bill payment company that wanted to design a financial planning application. To do this, we wanted to know how people went about paying their bills, so we did some focus groups. Overwhelmingly, the most common technique was to save one’s bills until payday, then sit down and stack them in priority order—for example, rent, car payment, and so on. Participants then started paying bills from the top of the stack and continued writing checks until they ran out of either bills or money.
That’s pretty much how we decide what goes into a release, too. If we’ve run out of resources, but Product Management thinks there are essential features that are still on the table, they must reduce the requirements for other projects.
The end result of all this is that we have a reliable release roadmap in which Product Management and Sales have confidence—because the packers keep the visionaries honest—and we have releases that offer true customer value—because the visionaries make sure the most valuable things get packed into a release. At the heart of this are the UX artifacts—like scenarios and wireframes—that facilitate productive discussions without a lot of development investment.
In his role as User Experience Architect for IBM Security, Mike’s professional focus is on designing usable user interfaces that accommodate the user as learner. Previously, as User Assistance Architect at IBM, Mike identified tools, methods, and standards for integrating the content and delivery of user assistance, including documentation, Help, elearning, and training. He was formerly Lead UX Designer for CheckFree Corporation, where he instituted their User Experience Research and Design Center. Mike has a PhD in Instructional Technology from the University of Georgia and a Masters in Technical and Professional Communication from Southern Polytechnic State University. He is a Fellow with the Society for Technical Communication and a Certified Performance Technologist through the International Society for Performance Improvement. Read More
