Product Management Versus Development: One Bag and a Carry-On
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 management is often the greatest ally developers can have, there is some inherent tension between the two. Product management usually wants as many features in a product as possible, while developers and UX designers typically don’t want to be held accountable for fulfilling unrealistic expectations of what we can accomplish in a single product release. Figure 1 illustrates this conflict.
In my current role, I do a lot of negotiating back and forth between product management, 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 summarized my observations using the metaphor of a couple packing to go on vacation.
Product management 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. They have an extensive list of things to pack—and frequently change or add 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 dress shoes for going out to dinner.”
The other, development, is thinking about getting there and 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. Every accomplished packer knows the code: One does not simply throw a pair of flip-flops into a packed bag.
So to sum up, 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 the tension between the two? I, for one, don’t think we should. I think the essence of design is to resolve tensions, not eliminate them. Some classic UX design tensions include convention versus innovation and control versus freedom. In these cases, the conflicting poles are not binary choices of this or that; rather, they are like the opposite ends of a 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-management perspective and the value it brings. Remember that the trip to the airport and 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. 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 can’t enjoy being there if you can’t find your way to get there.
Some Practical Techniques
Here are two simple techniques that help me to manage this productive tension between me and product management. 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 you begin. 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. 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 quality assurance. When you inevitably start throwing things away, you won’t want to have invested a lot of value into what you now must discard. I think one of the greatest values that 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 halfway there would provide no additional value. In short, you need to apply a sort of quantum theory to feature sets, such as “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 focus groups. Overwhelmingly, the most common technique was to save one’s bills until payday, then sit down and stack them in a priority order such as 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.
Looking for the latest in product and data science? Get our articles, webinars and podcasts.