What Marketing Requirements Look Like

  1. Posted on August 24, 2009 11:12:AM by Earl Beede to Practicing Earl
  2. Technique, problem space, solution space, requirements, marketing

I recently went with trepidation into a class with Pragmatic Marketing called “Requirements that Work”, part of their Practical Product Management series. Marketing professionals have been my foil for bad requirements for years and here I was, ready to hear from the experts themselves how marketing, and not engineering, should be making all the decisions about the software.

I admit, I expected Pragmatic Marketing to recommend to marketers that marketers write requirements like technical people write requirements and to continue to blur the distinction between requirements and design. So I was a little surprised and pleased when Pragmatic Marketing made the line between requirements and design sharper and more clear than I have seen in ages.

In fact, they strongly suggest that marketing people avoid writing requirements using the traditional, “The system shall…” format that has been taught to technical people for years. So what did Pragmatic Marketing recommend? They stated that a requirement is composed of three parts: a persona, a problem statement, and a use scenario.

A persona is an instantiation of a demographic. By giving the demographic/stakeholder-class/user-group a set of personal details, the marketer is able to give a face to a problem that needs to be solved by their product. It seems that relating to a person (even a fact-based fictitious one) improves the analysis and communication of a requirement.

One great insight for Pragmatic Marketing (great because I have said a similar thing for years) is that any given release of the product can typical delight only one persona and try not to make the rest of the personas (i.e. customers) upset. When you try to make all the customers/personas happy, it makes critical tradeoffs difficult, if not impossible, and usually results in a poor marketing message.

The problem statement is a brief or partial sentence that gets at the heart of a problem facing a persona. Tom Gilb would use the term “gist” for the same type of thing. Some examples from the class include: “Collecting customer inputs”, “New laptops come with Vista”, and “Where is the best picture?”.

The problem statement isn’t a requirement in the sense of “you must do this” but an issue or opportunity that is out there that the market has spoken about. Part of prioritizing the requirement is to collect market evidence—the number of times that the marketer has seen the problem/opportunity in the market.

The third bit is the use scenario. This is a sentence or two that puts the problem in a context often encountered by the persona. An example in the class: the problem, “Where is the best picture?” is followed by the use scenario, “Sally takes hundred of photos every month and doesn’t have time to catalog them individually. She wants to find photos taken this year that include her whole family for a greeting card.”

Notice that the problem statement is only the essence (or gist) of the overall use scenario. Also note that we have no idea how to solve it or even if it can be solved. It is clearly a statement of the problem faced by the persona. The use scenario may be a somewhat generalized issue to the market, but it is specific in relation to the persona.

We might be tempted to write that use scenario as a series of “system shall” requirements

  • The system shall automatically categorize photographs
  • The system shall provide a search facility to select photographs by category
  • The system shall rank photos within a category based on photographic characteristics (e.g. lighting, subject to field ratio, smiles, etc.)

However, in doing so, we have started to make some solution choices, even if we didn’t mean to. We seem to imply we need a category-based scheme. Why couldn’t we use some other approach to solve her problem like face recognition without a category? Why use a search? Couldn’t we have the system present its choice of best photograph? Pattern recognition from previous choices? The point is, we have a bit of design creeping in there.

But that brings us back to a really fundamental question: What is a requirement? Is it a statement of the problem (what vs. how) or something—anything—that is “required” of you by somebody else. I choose the former (see my second blog entry called Space Cadet), others choose the latter. At least at this point, I have the marketing experts on my side.

Post a Comment:


Earl Beede

Earl Beede, CSDP is a Senior Fellow at Construx Software, where he designs and leads seminars and provides consulting services on early project-lifecycle practices, estimation, requirements, quality assurance, contract management, and software methodologies.

With more than 20 years experience as a quality assurance representative, systems analyst, process architect, and manager, Earl has designed and written software development processes for companies across a wide variety of industries. Prior to joining Construx, he held quality assurance and systems analyst positions at organizations that include the Department of Defense, Boeing Computer Services and Verizon Wireless.

Earl has a Bachelor's degree from the University of Washington. He is a member of the IEEE Computer Society and a past coordinator of the Seattle Area SPIN (Software Process Improvement Network).


Contact Earl