Requirements - Discover, not Gather!

Over the years, I have found that I always have an internal screech when someone uses the term “requirements gathering”. The term itself makes it seem like the requirements are lying there, and the Product Manager just has to grab them and pop ‘em in a document. If we were creating custom solutions, the phrase might be more accurate – all of the users would be identifiable, and we could truly gather requirements from them. We’d still need to design the product in ways the user couldn’t even imagine, but with a limited and fully identified group of users the job would be pretty straight-forward.

The requirements beast changes its face when we’re building commercial solutions. We define a market segment, to help narrow the field of potential users. Then, we have to find potentials in that market segment, and watch them in their environment. We need to interview them, to really get to know their situations. And, we need to find ways to sample the segment at large, to find out how pervasive problems really are across the segment.

Each potential we visit may use slightly different ways of expressing their problems. The adjacent systems may vary from one location to another. Some problems only occur in parts of the market segment, and the problems sometimes seem to vary greatly.

Product Managers must study all of this information, and somehow discern which problems are most important. We have to narrow our field of vision from “all possible requirements” down to sets of problems that, when solved, will incent people to spend money. Only then can we actually document the requirement (Every [frequency], [persona] has [problem].) and clearly guide our teams to build a product that’s worth our time and energy.

To build awesome commercial solutions that people want to buy, we can’t just GATHER requirements – we have to study the market, and analyze their problems. Requirements aren’t gathered, they are DISCOVERED through our analysis of market evidence. Then, they are written with the right context to improve communication to our teams, helping our teams build outstanding solutions that resonate in the market.

What do you call the process of discovering requirements?

Is Cherry-Picking Bad?

The long Memorial Day weekend was nice, and the weather is finally decent in Wisconsin. The grass is growing faster than I can mow it, and the birds are thick. Last week, the woodcocks were peenting most of the night, and the owl calls have begun. The oaks are finally leafed out, and the wild geraniums are blooming everywhere. All this means that I am distracted, as you can probably tell by the lack of posts this past week! It’s not that I’m not working – it’s just that I haven’t had a really high concentration level. This week, it’s back to business – the birds are tuned out and I am catching up on my reading.

Last week, I found myself cherry-picking from my to do list. I finished quite a few things…light-weight items that didn’t require a lot of concentration. I travel a lot, and find it most beneficial to do these low-concentration tasks for my first few days back in the office. My mind needs to rest and re-acclimate before I can focus.

I can organize my workload appropriately, so that I can cherry-pick the easier stuff when my mind isn’t prepared to focus. I can get away with that for a week or so, max. After that, I have to go back to high-concentration items, because the light-weight tasks are done for now and the meatier items need to be addressed.

One of the best parts of my job is that I get to talk with a lot of Product Managers. One common complaint is that their agile development team is cherry-picking items during the sprint. We turn over requirements, and development creates a sprint from the highest priority group. Our developers are often optimistic about schedules. During the sprint, some things don’t get done. I often hear a suspicion in these teams – suspicion that the development team works on the items that seem most fun, and don’t make it to the “other” items. That’s like if I cherry-pick from my to do list, and never quite make it to the higher-concentration items.

This behavior during an individual sprint does not bother me. In fact, I don’t really care how the development team’s work is organized – as long as they are addressing requirements in descending priority order. I understand that sometimes, we overestimate capacity and don’t complete everything that was planned for the sprint. All I ask is that the next sprint begins with the leftover tasks, so that they continue working in descending priority order.

Our teams should finish ALL the items planned for one sprint, before moving on to the next group of requirements. If we’ve done our jobs as product managers, the current iteration includes the highest priority requirements. If the team gets to the end of the sprint and they haven’t finished all the work, the next sprint should begin with the leftover items. Cherry picking is OK for a little while, but eventually we have to go back and finish the stuff we skipped. It’s a good rule for personal organization, and it’s crucial when developing commercial software in an agile world.

Fighting Internal Gravity

It’s an interesting dilemma – our development team pulls us in, often because they don’t have the information (target user personas and their problems) they need to proceed. And in order to get the information they need, we have to leave the building. The internal momentum in this situation is strong...the development team needs to keep working, and it's really hard to write requirements when we haven't been in the market. So we try to write some, but they're not very good and consequently the team has lots of questions. This creates a strong gravitational pull, and it can be hard to break it and find the time to research the market.

Start somewhere! Pick a half-day, and go see a customer. Read an industry publication you’re not familiar with. When you go to the annual sales meeting, stay an extra day, and visit a customer you’ve never met before.

After all, getting into the market and orienting ourselves toward its needs is of ultimate importance. As my colleague and friend, Steve Johnson, says, “failure is likely when delivering products without market knowledge.”**

The future of our products and our companies is in our hands, so it’s essential to find the time to get out into the market.

How do you find opportunities to get into the market? What have you learned about fighting internal gravity?

**Steve Johnson’s eBook, The Strategic Role of Product Management, is now available. I truly enjoy Steve’s comments and perspectives – in addition to being absolutely hilarious, he is a bright and experienced professional with a deep knowledge of technology and product management. Many technology companies struggle to define roles and relationships between departments. This eBook can be a handy reference to begin discussing and resolving questions of ownership and purpose for Product Managers.

When They Really Know Me

We are technology Product Managers. Our Developers are using agile. We are busy fighting the momentum that would draw us into the minutia of detailed planning meetings and attempt to make Designers out of unsuspecting Product Managers.

This is not always a high reward position – the organization seems to fight us every step of the way. Our teams imply that we’re letting them down, that we should be personally involved in the planning of each sprint. Even when we KNOW that we need to get out in the market, it’s difficult to fight the tide every day.

And yet – think about the last outstanding experience you had as a customer. Aren’t they always based on the fact that the company seems to know you, to intimately understand who you are and what you need to be successful?

I use Netflix. If you watch movies and want a convenient way to receive them, you should check it out. Netflix is unique among video rental companies because they send the DVD right to my house, built on the movie queue that my son and I build.

That uniqueness is what attracted me to this service. I live about 15 minutes from the nearest video rental store. I used to run out and get a DVD, and it would take close to an hour of my time (considering drive time and the selection period). Now, I’ve always got something at home if I want to watch, and it’s delivered right to my mailbox….so all I have to do is make it to the end of the driveway!

When they send the DVD, it’s in a red envelope that’s specially designed so that you can send it back in the same envelope it came in. There’s no postage to affix, so the process is really simply.

The week before last, I was getting ready for a business trip, and the only DVD in the house was Madagascar….amusing, and certainly a favorite of my son’s – but not one I wanted to take on the road with me! I wanted to send it back and get the next one in my queue, but the red envelope had mysteriously disappeared.

This was a moment of truth for Netflix. I procrastinated for a few days, because customer service is generally bad so I figured I needed to handle this when my patience was high.

Well, I finally sat down and searched online. In about 15 seconds, I had found an entry that said I could send the DVD back to the address supplied. OK, that would involve a trip to town, AND into the post office….so I found the Netflix number.

When I found it, I was surprised immediately. On the screen, they displayed the customer service number. They also displayed a reference ID for me to use, and the approximate wait time! Awesome -- before I even called, I knew how long I should plan for.

I called the number, and entered my reference ID. The wait time online was listed as 5 minutes. It was actually only about 3 minutes before an ACTUAL voice came on the line. He apparently had access to the reference ID I had entered, because he did not ask me for my account number (which I don’t know), my social security number (which I don’t want to share), or even my name. Michael knew who I was, and immediately asked what I needed today.

I began to explain that I had misplaced the red envelope. I was prepared to be blown off, as I’ve been trained by all of the overwhelmingly bad customer service we deal with every day.

What a pleasant surprise! Michael immediately understood that I did not want to go find an envelope, figure out the right postage, and go to the post office. He added a bonus DVD to my account and immediately shipped it out. That way, I could just put 2 DVDs back in the envelope when I was done watching.

He did NOT assume that I was trying to rip him off.
He did NOT tell me to find the answer online.
He did NOT make me explain the situation in depth.

As soon as he knew my issue, he understood what I needed and gave me an easy solution.

I was attracted to Netflix for the product they offer. I am staying because they are a market-driven company, a TunedIn business. I walked away feeling like they really knew my problems and situation – I didn’t want to be on the phone a long time, I just wanted a solution.

This is the reason that Product Managers must stay in the market! No one can build, support, or service our products properly unless they really understand our target buyers and users. Product Managers need to provide that context, so that our customers end up WANTING to buy more stuff from us!

A Quick Toss Over the Wall -- Never Cool

This morning, I came across an interesting post. In it, Luke Hohmann of Enthiosys writes:

"Note also that we reject the notion that product management is somehow external from the development organization. Indeed, we're shocked when we hear of product management practices that assume the product manager can simply deliver an MRD to their development team and walk away, assuming that the process used by the development team does not affect product management. If you're a practicing Agile Product Manager, you're definitely not writing an MRD and walking away. "

I’d like to go a step further, and say that any product manager who understands technology and wants to succeed (and keep their job) is not writing any sort of requirement document and walking away.

Regardless of the development methodology in use, Product Managers need to describe and prioritize requirements for the team. In your first publication of the requirement, provide relevant context to help the team understand the market’s need. Tell them who the target persona is, what problem they’re experiencing, and how frequently this situation occurs. Sit down and review it with the product team. Make yourself available for questions during this period – they’re trying to understand the requirement and may need your help in that process. If your team finds a gap in your research and asks for more information, get it for them. As you get better at writing the requirement with appropriate context, your team will have fewer questions….allowing you to spend more time in the market, finding problems that will provide future revenue opportunities.

Throwing a requirements document over the wall has never been cool – it leaves the team in the dark, grasping around trying to figure out what is truly needed. Whether your team is agile or not, provide prioritized requirements with good context. Review with your team, and ensure that they understand the true market need. Two-way communication early in the cycle will help reduce the questions your team runs into later on – so be available, and work with the team until they understand the requirement well enough to design features and organize the iterations or sprints.

Then, walk away – while the team is building this release, go back to the market and continue researching. By the time this release is done, you’ll be ready with the next set of prioritized, context-rich requirements.

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.

Let's talk about the "backlog"!

Since the backlog is the prioritized list of necessary work, it’s pretty natural for some teams to assign its maintenance to the Product Manager. At first glance, that seems to make sense….but then, we begin diving in and realize that perhaps, there is a better way.

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!