What Organizations Get Wrong With User-Centricity
Some concepts represent a flash of counterintuitive brilliance and others are obvious when you say them out loud. User-centricity involves listening to the people who use your product or service and incorporating their pain points, needs and desires into your plans. That definitely sounds obvious, yet most organizations don’t do it.
Often, organizations believe they understand the problem domain well enough without speaking to users. They can save time on thorny conversations and focus on delivering features. Anyone who’s been frustrated with apps for tasks such as food delivery, booking travel or submitting expenses has encountered the result of this.
It’s not that the apps don’t work; it’s just that the set of users whose needs are satisfied by the software is limited to only those who are like the people developing it.
However, reaching outside your bubble to incorporate the needs of users can lead to another mistake, which is what we’ll deal with today.
User-Centricity Is Vital
Whether you are making a physical product, developing a software product or designing a service, the concept of user-centered design is likely to be familiar. The term is 50 years old and was popularized by Donald Norman, whose 1988 book “The Design of Everyday Things” was a bestseller.
User-centricity describes the degree to which you use conversations with users to build a deep understanding of their domain. This allows you to incorporate users’ needs and desires into your development roadmap.
A user-centric team:
- Understands what users want to accomplish
- Evaluates success according to the value they provide to users
- Continuously discovers opportunities by talking to users
- Updates their plans based on what they learn
You might use an informal process, such as unstructured interviews and hands-on usability tests, to gather feedback, or you may use a more structured technique, such as user-centered design. There are even methods more tailored to modern software delivery, like continuous discovery. The crucial first step is having conversations with real users.
DORA’s Accelerate State of DevOps report found that software teams that develop with a focus on users have higher job satisfaction and lower burnout. The report also found that user-centric organizations perform 40% above those who believe they know better than their customers.
Crucially, if you listen to your users, you’re more likely to identify areas of improvement that would be invisible if your roadmap was driven only by the opinions of those in your organization.
User-centricity allows you to develop fewer features that have a bigger impact on user value and satisfaction rates.
Have Regular User Conversations
Many teams collect feedback through in-product widgets or email surveys. Tracking sentiment over time with a net promoter score can be useful, but it doesn’t help you better understand users. To obtain high-value knowledge of their problems and desires, you need to talk to them, ideally with some structure to the conversation.
It’s important to have some structure to avoid wasting the user’s time and to make sure the way you collect feedback doesn’t bias responses. As Teresa Torres explains in the book “Continuous Discovery Habits,” asking someone, “How do you decide which hotel room to book?” invites too much imagination, as people tend to provide an answer based on their ideal self-image. Asking instead “Tell me about the last time you booked a hotel room” grounds the answer in lived experience and gets more realistic answers.
Once you build the habit of talking to users often, you can begin to understand them. This puts you in a better position to identify opportunities to delight them by solving pain points and meeting their needs.
This leads us to the most common trip hazard of user feedback: treating everything you hear as a new feature request.
Don’t Treat Feedback as Features
Whenever you speak to users, you’ll get feature ideas. Either the user will ask directly for a feature, or they’ll describe an opportunity that will give you an idea for a feature. Turning feedback directly into features causes problems and will ruin your software product.
During your conversations, if a user describes a feature they want, you can uncover the underlying opportunity by asking them what having that feature would mean to them or what problem it would solve. You’re not on the hunt for feature ideas, as these don’t help you learn about your users. What you want to discover is the underlying needs driving each request.
The output of feedback is a shared and deep understanding of your users, not a wish list.
All the feedback should be streamed to the team so everyone gains a deeper understanding of the users. That means translating the conversation into a useful summary, not sharing call recordings or transcripts. The goal is to maximize the learning from these conversations.
The feedback can be aggregated and mapped so you have something that connects the feedback across many users into actionable roadmap experiments. With these, you can iterate on what you learn and test the assumptions that you make when deciding how you’ll respond to opportunities.
If the result of every conversation is adding requests to a backlog, you’ll quickly be overwhelmed. You’ll also be adding features that may get little use. When a feature is too specific to a single user’s needs, it will suffer low adoption rates.
Saying yes to a request from one user can add complexity for all the other users who must ignore menu options or interface elements that don’t apply to them, so declining an opportunity is sometimes the right answer if it means your product is easier to understand and use.
Your job isn’t to respond to every opportunity that emerges from a user-centric approach but instead to identify where opportunities align with your own goals for the software you create.
How To Enable ‘No’
Whenever adoption is a factor in a software product, the temptation is to win every single deal and get as many people using the software as possible. Most developers have experienced this as a stream of demands from a sales team that promises customers whatever they need in return for a signature on a contract.
When your only source of feedback is from other teams with customer contact, you lose the ability to uncover the underlying opportunities. You can only develop a deep understanding of users by talking to them directly. This also lets you control the narrative about the conversation’s outcome, which is to better understand their needs rather than collecting a list of requirements.
Great software products are opinionated. People aren’t just buying a software product; they are also buying into your expertise in the problem domain. This is why people buy monitoring tools instead of streaming information into a database. The opinions about storage formats, data retention, outlier detection, alerting methods and visualization are a valuable part of the product.
That doesn’t mean your customers must abide by all your opinions. You can create escape hatches that let them tailor aspects of your software to their context, where their needs differ from those of other organizations and industries. Escape hatches are a better solution to these unusually specific cases than adding niche features, so thinking about how people can tailor their use of your product can be a major factor in enabling a “no” to a niche opportunity.
Listen, Understand and Innovate
User-centricity isn’t about giving users whatever they demand. It’s about building a deep understanding of their challenges, pain points, needs and desires. This pool of knowledge, not individual requests, inspires new feature ideas.
This lets you innovate in areas with big impact and create features users will find highly valuable.
