Regular Posts Tagged : ‘Requirements’
2 years, 11 months ago 0
Posted in: Post

When anyone talks about the job of product management (or program management), they tend to emphasize the importance of getting out of the office and talking with customers. You have to understand the customer and feel their pain. And, the quintessential quote one hears is “The answers aren’t found in the office.”

I’m neither foolish nor inexperienced enough to argue with that one. But, what is equally important, and what I don’t hear people talking about is the importance of spending time studying your own product in excruciating detail and becoming expert enough to be absolutely convinced you know exactly what features need to go in the next version.

Getting out of the office is only half the story…

There is no magic formula for determining the next feature you should put into your product. You need to have a product backlog, sure. And, within one of your backlog categories, it’s not hard to come up with a pretty decent prioritization and costing of those items. But—what to do next isn’t a question that calculus will answer. You need to look at a bunch of different issues:

  • The competitive landscape – what features does the competition have that you will need to match/exceed
  • Actual or assumed customer segmentation—which features are for what audience, and will that move the dial?
  • Company strategic priorities
  • Innovative ideas that can help position the product in a noteworthy fashion
  • What incremental features can be added to help current customers be more productive?
  • What features are consistent with architectural changes you need to make?
  • What features, if grouped together, help tell an easy-to-understandable story?
  • What features will generate excitement and buzz?
  • When does the release need to ship?


An MRD, or Marketing Requirements Document, is a standard (outside of Microsoft) document that lays out the strategy for a specific product release. Typically prepared by a product manager, the MRD is designed (like most PM documents) to drive team alignment and focus. Most MRDs have 3 general sections:

  • Market Opportunity: What is the business opportunity? How does the market segment, and what are the needs and peculiarities of each segment? Who are the competitors and what aretheir SWOT? What trends are driving change? The Market Opportunity section of the MRD is an evolutionary one, meaning that each subsequent version will build upon the foundation of the previous release.
  • Marketing Requirements: Marketing requirements are the specific problems that a given release is trying to solve. These problems are informed by your product backlog—but don’t come directly out of it. Typically, these problems are associated with specific audience segments (e.g. for a web authoring tool, “Help users add rich content widgets to their web pages,” would be associated with a hobbyist or prosumer customers who haven’t developed their own library of standard HTML/JS widgets). As an aid to developing Market Requirements for a
    product release, it’s critical to have a robust product backlog that’s categorized in a fashion that reflects real-world customer processes, like an affinity tree (more on that in a future post).
  • Go-to-Market Strategy and Tactics: Typically developed by Product Marketing in conjunction with Sales, the go-to-market plan lays out the promotional and marketing/advertising strategy for the release. It includes goodies like the product positioning, channel strategy, pricing strategy, key features statements, etc. This section will often contain Sales projections (which are typically “hoped for” Sales projections).

When I say—Be the MRD—it reflects my belief that the abundance of customer and market information you’ve collected will not itself point you in any particular direction (and—it rhymes). As always, data itself is just data. And, typically, two different people will look at the same data sets and come to the polar opposite conclusions. So—YOU (as PM)—need to be the tool that integrates all the disparate piece of market, customer and other information and comes up with the right direction.

From my experience, it’s not enough for you to visit customers, do research and go to trade shows. As I said earlier—you need to work with your product enough so that you Grok it and are absolutely convinced you know exactly what features need to go in the next version.

Then, you have to be flexible enough to put aside your opinions in an instant based on customer input or market evidence.

You can’t come up with the right answer unless you have a well-developed point of view (it’s one of those knowing the path, walking the path kinds of things). You can’t make an informed assessment without understanding (some of) your customer’s pain. You can’t feel it, second-hand. You’ve got to become a customer.

So, dive in and do a bunch of projects with your product, and understand firsthand what some of the problems, issues and inefficiencies are. Only then will you be capable of putting yourself in other customers’ shoes and understanding their pain. It’s the process of developing empathy.

As an example, when I was working on Photoshop 2 (when dinosaurs roamed the earth), there were hundreds of feature suggestions we had collected from customers and our own observations. Photoshop was an unusual product in that it was so general-purpose that it was used by an incredible range of different customers, from graphic designers to prepress to software developers to illustrators and so on. So, it would have been easy to peanut-butter features across a wide set of user scenarios.

We decided to focus on 2 scenarios/objectives:

  • Build bridges/synergy with other Adobe products to increase the likelihood that Photoshop customers would also buy Illustrator, and that Illustrator customers would also purchase Photoshop. This also helped distinguish us from the competition, which didn’t have equivalent leverage. For these customers, we added support for Adobe Type Manager, built the Illustrator rasterizer into Photoshop (so, line art could be incorporated into bitmap designs), and engineered a Photoshop version of the Illustrator pen tool (for creating
    precise, vector masks).
  • Attract an emerging customer segment—prepress. Prepress houses are establishments that create color separations from photos and artwork to so they can be printed. While we had recognized this group could use Photoshop, we were completely blown away by how quickly they adopted it. Existing prepress houses used Photoshop to supplement their existing Crossfield and Scitex equipment. Service bureaus used Photoshop (exclusively) to enter the color separation market. For these customers we added a CMYK editing mode (a significant “first”), and the ability to create duotone/tritone/quadtone images.


This release had the effect of increasing Photoshop revenue like a step function. The revenue ramp suddenly took a big jump, and then continued to ramp at an increasing rate. This is symptomatic of a product that suddenly appeals to new segments (or increases its appeal to existing segments).

The customer data alone couldn’t tell us this was the right strategy. There were at least a dozen different customer segments, lots of compelling and sensible customer requests, and—frankly—a paucity of high-quality research info. But, I strongly feel that my own use of Photoshop (I helped illustrate the first Photoshop poster; wrote several articles on it; edited the tutorial guide; created interface mockups, etc), played a major role in informing the decision-making process and acted as a sieve for the customer information.

Was every feature choice perfect? Probably not. But, the strategy—which informed the feature decisions—was spot-on. And the act of integrating all of the elements of the MRD (market opportunity, customer problems, go-to-market strategy) into my brain (and those of the product team—Mark, Tom, John & Russell), made it a dynamite release.