Had an interesting session with a coachee this week on the topic of requirements. She’s recently been hired at a company that sells a sophisticated reporting tool and has been asked to gather requirements around goal-setting by end users (users will be able to set goals and compare the related target to “actuals” captured by the tool). This is the first time in her career that she’s had to gather requirements for a product she doesn’t know well from end users she’s not familiar with. It’s funny how an unexpected set of circumstances can make it difficult to apply our hard-won knowledge and experience.
In this post, I wanted to share some of my guidance to her. I think these principles are valid regardless of your familiarity with the product and its users.
Master the Problem
The first point of guidance I provided was encouraging her to begin her investigation by exploring the problem space — resisting the urge to think about solutions. Requirements are statements of need and reflect the problem space. Features, which are characteristics of the product, are part of the solution space. We have to resist our human urge to jump to a solution before we have understood and validated the problem.
In this case, our PM has gotten input from people in the company who work with end users. These people are acting as “proxies”. Leveraging the experience of proxies can be wise, especially from a time management perspective. I urged her to distill their input into requirement statements, e.g., user stories, prioritize them based on the value she perceives in satisfying these requirements and validating them with the proxies. She can then reformulate and reprioritize based on their feedback.
She should also validate her understanding of the problem space with some actual users! Proxies are great but are not end users. Doing this two-step validation helps ensure the solution we propose addresses our audience’s most pressing problems.
Once you’re fairly confident that you understand the problem space, it’s time to migrate to the solution space and begin gathering and validating input from proxies and users. The trick is to imagine multiple solutions and pick the one that a.) will meet the market’s requirements b.) will help you meet your business objectives. Balancing these two sets of priorities is at the crux of great product management.
By the way, I recommend starting by pushing back on the entire premise of an assignment like this. Approach the topic with the attitude that it’s probably not valuable. Very often, a tacit assumption that some area of exploration is valuable can cause us to overlook fundamental flaws as we quickly delve into details (we lose the forest for the trees).
During our conversation, I reminded her that many frameworks and methodologies emphasize quickly creating prototypes. While I’m in general agreement with the value of prototypes, we must first validate the problem space. In practice, this is harder than it seems.
Comments