Product Requirements: Using a Written or Visual Framework [MindTheProduct]

There’s a lot of variation in how companies document product requirements. Some are moving away from detailed, written product requirements documents (PRDs), while others are using shorter write-ups, user stories, or jobs-to-be-done formats.

Some product teams are moving away from written PRDs to visual artifacts like mockups and prototypes. It’s a change in approach that’s driven by demands for more agility and greater velocity from the time a problem is identified to the time that a product is released.  

As firms move faster and pivot more, perhaps it’s time to reconsider how best to capture product requirements.

In my time as a product manager and consultant I’ve used different written and visual methods to capture product requirements, and I think of the options to capture product requirements as a 2×2 matrix: in addition to visual and written forms, some methods detail user/market problems and others define specific solutions that should be implemented.

Figure 1: FRAMEWORK OF METHODS TO CAPTURE AND DEFINE PRODUCT FEATURES

Different written and visual methods can be used to detail problems that target user experience as pain points. A separate set of both written and visual techniques can be used to define solutions that should be implemented in software to address the pain points.

Focus on Core Problems

Recently it has become more common to move from only “defining solutions” to also “detailing problems”. This, I think, is a better way to begin to understand a user or market need and its associated pain points. Eric Ries, in his post “What is customer development?“, comments: “We know some products succeed and others fail, but the reasons are complex and unpredictable. We’re easily convinced by the argument that all we need to do is ‘build it and they will come.’ And when they don’t come, well, we just try, try, again. What’s wrong with this picture?” Well, by simply “building it”, the product managers have probably failed to focus on core problems, and instead jumped straight to prescribing a solution.

In fact, both scoping the problems and using this learning to detail solutions are necessary steps. They become more effective when used together. Following Ries’ point, defining a solution is the response to the customer development activity: it becomes much clearer once the market landscape and pain points are well understood.

Written Methods

Some product teams will use written methods across both the problem identification and solution definition steps, while others will use visual methods. Personally, I get positive results from detailed written requirements. And venture capitalists Ben Horowitz and David Weiden in “Good Product Manager. Bad Product Manager” say that: “Written communication to engineering is superior [to verbal communication] because it is more consistent across an entire product team, it is more lasting, it raises accountability.“  

Another endorsement for written requirements comes from Ben Yoskovitz, in “The Specification is Dead; Long Live the Specification.” He says: “I like to write. I find it’s a great way of recording structured and unstructured thought. Documents are useful for organizing and reorganizing thoughts as well. So I tend to start any new product requirement work with a specification.“

In general, good writing is good thinking. It confirms that a robust research process took place and drives discussion across the organization during product development.

Visual Methods

There has been a move away from written requirements to more visual artifacts as demand for intuitive user interfaces has increased.  Developers may be more comfortable knowing exactly what the finished product should “look” like, especially if the company views its design and user interface as a differentiator.  

Prototypes can be more compelling during internal progress reviews, user feedback sessions, or meetings to gain executive support for new initiatives because they are much closer to the finished product than written descriptions. With a clickable prototype, an internal review board can see just how the finished product will look AND function.

Occasionally, however, a visual-centric approach opens the door to scope creep and the inclusion of low-value features, or it may lead the product to pivot away from the key pain point in the name of good design. This is because it can be easier to design new features visually than to implement them in the product, when front- and back-end software must be written.

Bear in mind that written requirements also can serve to define the scope, what is in and what is out plus acceptance criteria, more effectively than visuals.

Use Both Methods

There’s not need to choose between visual and written methods: both are useful. I have found that, after writing a draft set of requirements, working with a designer on initial visual concepts can help to identify gaps and refine the written work.

I have often started to write requirements after some user interviews and other research, leaving gaps in my draft that I annotate with comments such as “discuss various  visual options with <designer name>” and  general comments on what a user would expect to see given the use case.  

There are many good posts on how to write all different kinds of specs, but this recent post  includes great examples.

Figure 2: FRAMEWORK OF VARIOUS METHODS WITH DESCRIPTIONS OF EACH OPTION

The same matrix of methods of product requirements, with key techniques and descriptions.

 

Choosing the Right Method

The decision on the most suitable method depends on the type of product developed (hardware vs. software; consumer vs. enterprise), the industry served, and the internal resources available (a lean engineering team without much industry experience may ask for details in written form, or prototypes rather than mockups).

In some cases, detailing just the problems will be enough for a development team to build compelling and effective features within the product. For example, a product manager may write a dozen user stories or a variety of jobs-to-be-done, and with an order of priority, this may be all that engineers need. This is particularly true if the engineering team has domain expertise or has worked on a product for a long time and the features are extensions to what is already available. 

The graphic below shows some of the advantages and disadvantages of written and visual methods to capture problems and detail solutions. 

FIGURE 3: ADVANTAGES AND DISADVANTAGES OF THE DIFFERENT METHODS

 

Any product organization looking at new methods to capture product requirements should think about their advantages and disadvantages in terms of their business and goals.

Is the product launching in a new market, or is it a an extension of functionality to existing users?

Using visual artifacts to detail problems in a new market may help shed light on the individual parts of complex tasks, and enable the product team to identify core pain points. Visual artifacts also make for good presentation material for user feedback sessions and reviews.

For clients familiar with the product, written artifacts may be enough. They may be less interested in “what it will look like” since they are comfortable with the current product.

Another consideration is the overall size of the development effort – new features require a different approach from a new application or new suite of applications.

Finally, when managing role-based products that require significant interaction between different users, visuals (showing the various user views plus the flow chart of interaction) may be the best way to ensure that all scenarios are accounted for and to convey the desired functionality and flow to technical teams.

 

Product Requirements in B2B Software Markets

In a B2B software market, where I’ve been a product manager, you need to go beyond just detailing user and market problems, and provide detailed definitions of the products and features to be built (both visually and with text).

I commonly follow the “hybrid spec ticket” format. As I begin working with design/UX and engineering teams after drafting a hybrid spec ticket, many answers to their questions – like what market drivers have created this problem, key terms and definitions  – are added into the ticket. The energy and building management market I work in is complex, and these supplementary details need to be documented and available to developers and designers throughout the process. I imagine that other B2B markets also need to document complex market characteristics, and the hybrid spec ticket format is a good option for this.

I focus on clarifying and summarizing a few core issues when specifying product features: First, I summarize the pain point and why it is a pain point. Energy managers have trouble tracking peak demand in buildings. Peak demand is a difficult metric to track because there may be no systems in place to measure in real time, no method to help the user understand when they might set a new demand threshold, and no alerting capability to tell them when it may happen and what to do about it. It’s also difficult to convert energy units into dollars. I’ve written about this specific feature in product requirements, including how users address the issue today and why the current state is less than ideal.

In summary, there are many ways to define and specify new products. The above methods can be used together, and in concert may lead to more clarity on what is to be built and a better understanding of the current state of a market. The decisions on which methods to use, written or visual, focused on documenting problems or defining solutions, should be determined by each given organization, based on what fits the business best.

 

The post Product Requirements: Using a Written or Visual Framework appeared first on MindTheProduct.

Source: MindTheProduct http://ift.tt/2q9cEPC