Take a look at your team’s backlog. Is it features? Or, even finer-grained tasks than that?

A Product Manager’s primary responsibility is to know the market – to discover urgent, pervasive problems that people are willing to pay to have solved.

We are generally not trained or necessarily skilled in the area of design.

A good Product Manager understands that good design is an integral part of a successful offering. We are, perhaps, capable of learning how to do design – and if necessary, we will give it our best shot.

Is that the best choice for our companies?

I want to buy products that surprise me with their simplicity and power – products that make me say, “Wow!” or “This is so obvious – why didn’t anyone do this before?”

In order to develop outstanding solutions, skilled designers must be focused on the problems we need to solve for the market. The designer should understand the problems that product management has identified. They must guide the design, closely working with development to ensure feasibility.

The designer should be in charge of the translation of market requirements into features. In an agile environment, that means that the designer must work with the Product Manager to understand the market requirements and their priority –and then lead the team to turning the problems into features and sprints that make sense. This must be done in close conjunction with the project manager, to ensure that the product that comes out the backend makes sense, and provides maximum impact in the target market segment.

People buy products that were designed by expert designers, not expert product managers!

The Backlog: One Idea; Three Definitions
There are so many terms in technology. That would not be a problem if language were a perfect science. Alas, it is not. Let’s just think about “product backlog.”

The Scrum Alliance provides this definition:

“The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements”

Wikipedia says:

“The set of features that go into each sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done.”

At Control Chaos, they say:

“Product Backlog (or, backlog) consists of all features, functions, technology, bugs that will constitute the product once the work has been done in Sprints to turn this backlog into software”

So, it looks like there is general agreement that the backlog is a prioritized list of things that need to get done in order to move our product in the right direction.

And yet – there is general chaos surrounding this artifact in most agile environments. We throw around terms like “requirements,” “features,” “functions,” and “technology” so frequently that they don’t really have a clear definition anymore. One’s definitions are dictated by our experiences and education, rather than any standard description that we can rely on.

To ensure clarity on our teams, it’s helpful to examine and discuss examples rather than terms.

Mike Kohn provided a few examples in a recently published article. The article is a good read with several good points. He explains that clarity should increase on backlog items as the sprint gets closer. If we have complex items, it makes sense to take time during prior sprints to figure out the full breadth of user stories, so that when we’re ready to work on this item we’re ready to go. Furthermore, he relies on a User Experience Designer to clarify the items. Let’s take a look at his examples.

Mike’s two examples of backlog items:

• As a user I can see the current version, company website, and copyright in a "help about" dialog so that I know useful information about the product.
• As a user I can enter a check in my register so that I can track who I pay.
  

These statements are already at the feature level. It doesn’t define exactly what the screens will look like, but someone has decided that important user information will go in a screen called “help about”. Likewise, someone has taken the time to start defining the necessary tasks included in managing a checkbook.

Where do these items come from?

When a Product Manager studies the market, they discover groups of people who share common problems. When they quantitatively analyze those problems, some are proven to be urgent, pervasive problems that people are willing to pay to solve.

The Product Manager’s primary job is to discover problems with these characteristics, then describe those problems to their organization. One part of their job is to define these problems for the Marketing and Sales organizations. The other part is defining the problems for Development, in a way that allows them to build the best possible solution, a solution that resonates in the marketplace and makes our target buyers come running.

For Mike’s example, he says that they’re building a checkbook program to compete with Quicken. I’m going to set aside the problem of entering an already swamped market and attempting to compete with the big boys. Let’s instead think about the Product Manager in this organization. If they’ve studied the market, perhaps they’ve found some problems that are urgent, pervasive, and have buyers willing to pay for a solution. The Product Manager would analyze the market evidence, and eventually write requirements. These requirements state that “Every [frequency], [persona] has [problem] with [result].”

Restating the earlier example: Once or twice in a year and usually on the initial visit, Sally the Soccer Mom wants to know more about the company, including where they are located physically and how they can be reached electronically. She needs this information when she has a problem with the product, or when she decides to upgrade.

In Mike’s fictional company, another primary requirement might state “At least once a week, Sally the Soccer Mom needs to figure out her current checking balance so that she knows if she needs to transfer money into the account. Otherwise, she might bounce a check or get charged overdraft fees.”

An interaction designer could take this requirement (along with the fully defined description of the persona, Sally the Soccer Mom), and design an interface that solves the defined problem. One item would be that the user needs to enter checks she has written. That capability is necessary in order to provide a current balance and solve her real problem – she doesn’t want to bounce a check or pay overdraft fees.

How often have you already envisioned the solution before you’ve stated the problem? Begin with the problem-oriented requirement: “Every [frequency], [persona] has [problem] with [result].” Then work with a user interaction designer or business analyst to define the solution.

If you define product backlog items at the level presented in Mike’s example, you’ll need a user interaction designer to translate the requirements into the product backlog items – otherwise, the Product Manager is being asked to focus internally, when our company is much better served by our presence in the market.

Take a look at your team’s backlog. Is it features? Or, even finer-grained tasks than that?

A Product Manager’s primary responsibility is to know the market – to discover urgent, pervasive problems that people are willing to pay to have solved.

We are generally not trained or necessarily skilled in the area of design.

A good Product Manager understands that good design is an integral part of a successful offering. We are, perhaps, capable of learning how to do design – and if necessary, we will give it our best shot.

Is that the best choice for our companies?

I want to buy products that surprise me with their simplicity and power – products that make me say, “Wow!” or “This is so obvious – why didn’t anyone do this before?”

In order to develop outstanding solutions, skilled designers must be focused on the problems we need to solve for the market. The designer should understand the problems that product management has identified. They must guide the design, closely working with development to ensure feasibility.

The designer should be in charge of the translation of market requirements into features. In an agile environment, that means that the designer must work with the Product Manager to understand the market requirements and their priority –and then lead the team to turning the problems into features and sprints that make sense. This must be done in close conjunction with the project manager, to ensure that the product that comes out the back-end makes sense, and provides maximum impact in the target market segment.

People buy products that were designed by expert designers, not expert product managers!

Stacey Weber is an author, speaker, and instructor for Pragmatic Marketing. She specializes in developing and delivering market-driven technology products. An accomplished product manager who has successfully launched many products, she has used the Pragmatic Marketing Framework to help increase market focus and dramatically increase revenue. Stacey now helps other companies reap those benefits through her role at Pragmatic Marketing. Contact Stacey or read more at The Agile Product Manager blog.