Last updated on May 5, 2020
In our APG team (APG = Automatic Persona Generation), we have the goal of doing value-driven system development. “Value-driven” means that each feature we add or incorporate, solves a real user problem (i.e., provides real value). Since our clients are typically operating in the business domain, their problems deal with understanding their customers better. That’s the space APG operates in.
To discover real user needs, we’ve been carrying out several user studies about personas. However, there are many issues in conducting user studies. The feedback we get is not always relevant or valid.
For example, some participants might not be truly engaged or interested in the system and just participate out of duty or because they were “forced to”. Similarly, users may just brainstorm features that really they would not use but that “sound cool”.
Moreover, when compiling the feedback, we find that there are a lot of requests for new features. Say, the users want 10 new features, but we have time and resources for two and therefore need to prioritize.
Below, I’m sharing three principles we’ve developed in order to cope with these situations.
1. Who does the feeback come from? => not all people are engaged, motivated, or knowlegeable to give useful feedback. Therefore, we have to consider if a person is just “shooting ideas” or if he or she actually wants to provide useful feedback. We then prioritize the comments from the people whose feedback indicates they are taking the commenting more seriously.
2. How repetitive is the feedback? => if the request comes from many organizations and many people within an organization, it is more likely to be a real problem to solve. If it’s a rare request, the problem is probably also very rare and worthy to focus on.
3. Is the feedback traceable to a real problem the user has? => this question tries to clarify if the request if a nice-to-have or pain killer. We need to solve real problems with the system, so nice-to-haves need to be minimized. Even if many motivated people suggest a new feature, it could still be a nice-to-have if we cannot logically connect it to a real problem.
Conclusion
Nice-to-have features are like a disease; everything can be done, but only a few things are worth doing. With nice-to-have-features, the system will not have active usage. The goal of value-driven development is to develop a system that has real users that actively use it.
Therefore, focusing on distinguishing the most useful feedback from a lot of interviews, think-alouds and comments is crucial, especially for small teams and startups that are forced to focus their development efforts.