As a product manager and usability expert, I work with both marketing and R&D teams to deliver a product that meets users’ needs and expectations and provides value.
Our approach is to build a product with a strong base that offers most of the expected capacities considered important for our particular domain. Then we bake in the capability for customers to build what they need to adapt to their specific context.
The approach probably sounds familiar to many of you.
It's at this stage that the questions arise: What is in the base? What do we need to include to let users customize?
Users have a say. We need to listen.
Like many products, our platform is somewhat generic, used by hundreds of users in many different contexts: business verticals, with a wide variety of goals and differing levels of technical skills. How can it be possible to listen to so many voices?
A Clamor of Voices
Chances are people from different teams across your company — sales, marketing, customer support, consultants, partnership representatives — talk to users. They all know something about how different users get value from your product and “what they say they need.”
But of course this clamor of voices can be inconsistent, contradictory and focused on “what I think I most want now,” even if a workaround is available, or if bigger issues arose a few months before.
Bringing Order From Chaos: The Usability Approach
As my background is usability, I have extended some usability concepts and methods to the field of product ownership.
In the field of usability, it is accepted practice to put five to eight users from each “persona” into live test scenarios and watch their experience while using the product. This catches roughly 80 percent of a product’s usability issues.
We think this can also be true for larger customers’ needs. Let’s apply the methods, and let the next releases prove us right. Below is a process we use which you can apply to your product.
The usability approach to building good product from the voice of the customer is:
- Get to know your customers.
- Identify product requirements.
- Prioritize according to users’ voices.
- Take it back to the users.
- Test internally.
Get to Know Your Customers
Talking to customers through periodic surveys over the phone helps identify and categorize their projects and teams into common types, similar to the “personas” for individual users in the field of usability. You learn about user teams — how they are structured, what skills they comprise, the technical environment and tools they use, and the projects and goals they use your software for.
Have all user-facing teams in the company become involved in the process of creating “issue tickets” about the product from what they hear. Users’ company name appear on the ticket.
At this point we recommend you analyze requests for information from results of usability testing, and “loss reasons” — that is, why some customers have given up on the product, or why some prospects have not chosen it. When you analyze all the information you have, you will often see clear trends that can drive development.
Product marketing now proposes a short list of new and improved features and asks the representatives of the various user-facing teams to prioritize according to their specialized knowledge. R&D takes that list and analyzes development feasibility, given current constraints.
After negotiation between needs and feasibility, you'll have a prioritization of what is doable now, and later.
Take It to the Users
Once you know what you will work on, you can invite five to eight companies to participate with design through a co-conception charter.
Use the product internally throughout feature development. Go “through the looking-glass” and become your own users. So much useful perspective arises from just flipping a point of view from “creator” to “user."
Validating usability needs actual users.
This means that, throughout the development and implementation of new features, the team needs to regularly demo what they have done to gather feedback, and to run quick usability testing, where five to eight “users through the looking glass” (consultants and pre-sales engineers) actually take the mouse to discover and experiment. Sometimes listening to a “voice” isn’t enough — you need to see how they are using the product to fully understand the real requirement.
When the scope and quality are good enough, it’s time to involve those five to eight companies in wider testing sessions, on their own use cases. Bugs, usability improvements, and more about the scope will arise while there is still time to fix at least some of them.
Release and Repeat
You can’t include everything — no one can produce a product that does everything for everyone. But by listening to your customers and by combining this immediate and practical demand with market analysis and innovation, it's possible to provide a product that provides ongoing value for customers.