Requirements Gathering - Interviewing the Right People

How do we find out what someone wants when they don’t know what they want or what they can have? One of the best techniques for gathering requirements is to interview users. But which users?

Imagine aliens came to the planet and offered to solve our gasoline problem. How could we tell them what we wanted? We might say we wanted cars that run on clean renewable energy. The aliens might leave thinking “Oh well, I guess they didn’t want faster-than-light travel.”

It isn’t much different for most software users. Users don’t typically know what software can do, or don’t have the skills to synthesize software based solutions to their real problems. Users are rarely the source of innovative solutions. So how do we gather the real requirements?

We can make our user interviews much more valuable by talking to different users. We can use Geoffrey Moore’s Crossing the Chasm description of technology adoption as a basis for segmenting our users. Ken Norton proposes that we do exactly this, and combine the different perspectives to reach our conclusions.

Classifying Users

We use personas to identify different classes of users in a software system. We use those personas to drive feature prioitization and design decisions. When making design decisions, we focus on the level of competence of the users to prioritize features. When we are eliciting requirements, it is before we get to the prioritization stage, and we are still defining what the features might be.

We can use the same techniques to increase the value of our requirements elicitation efforts.

For any given role that we identify as a user of our software, we can use Geoffrey Moore’s classification to identify four distinct user archetypes (personas).

• Innovators (Influencers) - people on the bleeding edge of the technology curve.
• Early Adopters - our first customers.
• Majority - most users of our software.
• Late Adopters - people who follow the crowd.

There are pros and cons to interviewing representatives from each group. With Ken’s guidance, we can separate the wheat from the chaff and combine their inputs to drive innovative and valuable solutions. Our goal in these interviews is to understand the pain-points and market opportunities.

Innovators

• pro - Innovators can prevent tragically bad mistakes. They can also help us to identify opportunities to solve problems most people don’t realize are problems.
• con - Innovators struggle to distinguish cool from valuable. There is also a risk that they can fixate on something that is irrelevant.

Early Adopters

• pro - Early Adopters easily develop a deep understanding of our products and goals. They can tell us in advance what problems majority users will face, and provide a bit of a sanity check on the ‘problems’ that innovators suggest
• con - Early Adopters tend to be power users, and are genuinely enthused about our product ideas. They tend to gloss over the negatives and focus on the positives. They also tend to communicate in terms of features, not capabilities.

Majority

• pro - Majority users can give us the best insight into what is painful. We can use this insight to drive market requirements and solution ideas.
• con - Majority users don’t think about software, they think about how software affects them. We have to keep a focus on the problem not the solution when gathering requirements. We also have to dig deeper with why questions to understand the underlying cause of a particular problem.

Late Adopters

• pro - Late Adopters avoid change. Use them to help us identify where we need better interaction design and more documentation.
• con - Late Adopters will drive us towards “… just like product X” solutions. They will be disinterested in novel solutions until they are mainstream.

Triangulation

Ideas that survive the innovator-filter, make sense to early adopters, and solve a painful problem for the majority are the ones that we want. The late adopters won’t be using early versions of our software, so we can focus our attention on the other groups until we become the dominant solution. Then we can look to the late adopters to help us manage incremental improvements.

Thanks Ken for suggesting that we triangulate these perspectives into great ideas!

Conclusion

Even if we don’t go out in search of these archetypes, we should try and understand the people we do talk to, and put their inputs into the proper perspective.