How to remain user-centered while balancing competing voices.
The definition of product management and what it entails seems to change from company to company — and, irritatingly, from person to person.
Yet, you soldier on and build products that help people achieve goals, not simply complete tasks…
How do you do it though?
For the latest in our UX expert opinions series, we asked 28 of the best product managers around how they remain user-centered while balancing these seemingly competing voices. Using their product management alchemy, several pros claim to be able to turn even streams of unsolicited feedback into useful solutions for customers.
Look out for patterns in the areas where they agree and disagree—there’s no consensus about user stories, for example. Just remember: this isn’t a list of best practices—it’s a list of best hypotheses. Enjoy!
From my experience, the only way to keep user needs at the centre of your process is to centre your process around users.
It should start and end with talking to users when possible (and it almost always is possible). Every choice the team makes should be from the perspective of serving customer needs first and business needs second. It’s too easy to drift into serving your own needs:
How can I get this project through with the least amount of stress as possible?
How can we build this with the least amount of engineering resource possible?
How can we make something we know leadership will approve?
And so on. Serving users first has to built into your process or it will get pushed out. That means support from leadership too. When that is in place, and the team has a militant focus on fulfilling users’ needs, that’s when businesses grow and magic happens.
We’re lucky because our customers are product managers, so they naturally get how product management works. But I don’t think that would change our tactics—being transparent and communicative at every step.
For starters, we’ve made our roadmap public, and encourage our customers to send feedback and questions. We make it as easy as possible for them:
While we listen to every suggestion and piece of feedback we get, we don’t instantly go build things. But we do talk through every last one and, at times, help the customer understand why we’re not prioritising their suggestion over other things (as with any company, we can’t build everything). Many companies shy away from being this open and honest, but we find it helpful in getting users onboard with our product. In turn, they end up giving even better and more useful feedback!
The straightforward answer is that you and your delivery team (yes, even the developers) need to get out there and observe your users using your product, or your competitors’ products.
You need to do this as frequently as possible—a minimum of 2 hours every 6 weeks.
Why? This is the only way you and your team are going to experience your users’ joys and frustrations first-hand. And it’s that visceral experience that will motivate your team to improve your products.
Before you protest that you do meet with customers often, let me clarify a couple of things.
Wherever possible, you should observe your users in person. You need to be able to see not just what they’re doing with the product, but how they’re reacting. Body language tells you a tremendous amount and you miss all that if all you can see is a screencast.
A passable option is to observe your users remotely with multiple cameras, showing their faces and hands as well as their screens. However, unless you have your own usability studio, this can become prohibitively complex and expensive—which would discourage you from your bare minimum of exposure to users for 2 hours every 6 weeks.
It’s cheaper and easier to go and observe your users in their usual environment, so this should always be your first option. If you don’t meet with your users regularly, you have no hope of keeping their needs at the heart of your product—so get out there!
Establish a regular practice of soliciting user feedback and setting quantifiable goals.
For example, 1 site visit every quarter or 5 user engagements (via phone interview or in person) every quarter. It’s a systematic practice that every product manager must take upon him or herself.
However, this insight can’t live in a silo.
Make sure that these insights are circulated widely and regularly across stakeholders in the organisation, including the leadership team.
As a fast-growing startup leading the account-based marketing movement, Terminus hired a product manager after there were already 200 customers with all sorts of ideas about what the company’s product should do next. Not to mention 3 inspired founders with nothing but ambition!
The company already had a regular cadence for absorbing customer feedback from the customer success team, and talking to customers directly at marketing events. We were moving so fast that we were validating ideas on the most expensive basis possible—using fully developed, working software.
The product team now invests in design workshops and extensive customer conversations before building significant new features, to ensure customer needs are baked in from the beginning. The increase in confidence all round is nothing short of remarkable, and it’s fueling the next phase of growth at Terminus!
The best way to keep customers at the center of your product management process is to co-create with them.
Engage your customers on a weekly basis to generate insights and evaluate solutions.
For great examples of how this is done, check out Tom Chi’s talk from Mind the Product or the Nordstrom Idea Lab’s case study on building a sunglass app.
For me, it’s about making sure everyone working in our business gets out and talks to customers.
We have to walk in their shoes and understand their problems. If we are all responsible for getting out there and listening to what they tell us, we can’t help but have them at the fore of all we do. It’s important that your business values this time and allows for it as part of your working hours—it can’t be seen as a luxury.
Tying what we hear into all elements of the work we do is key to making sure we do the right things for customers. Working closely with marketing teams to craft robust and living personas is so important.
In government, we don’t have any ‘UX’ roles because we think it is everyone’s responsibility to create a good user experience.
We have user researchers, interaction designers and content designers—all working with product managers and service designers to create user-focused public services.
I’ve never worked anywhere that is so determined to keep user needs at the centre of the process. It helps that we have the support of the Government Digital Service (GDS)—point 1 of the Service Standard is to ‘understand user needs’.
It’s important to embed user researchers into your team, and they should be doing regular, contextual research with real users of your product.
The most effective way to create good products or services is to make sure your delivery team has regular exposure to users. Take your team with you—let teammates see real people using the thing they’re building. It’s the best way to build better things.
User-centricity as part of the product management process can only occur if the company, as a whole, has a user-centered culture.
Otherwise, it becomes an uphill battle. Product Managers can influence this cultural change in two ways:
The first part is aligning impressions, within various groups, about who the user is and which types of pain the company is working to solve. Having well-defined personas for all users (and involving all stakeholders in the persona-creation process) can be a great tool for driving this alignment.
The second part is consistency of process. Personas are only valuable if they are used consistently to make product decisions. The same is true for user research, prototyping, validation, etc. These activities can’t be a one-off. They need to be ingrained in your process and bought into by other teams. Today, we don’t hesitate to plan for DevOps or QA activities, so why should user-centered activities be any different?
Product managers can influence the adoption of techniques like dual track agile to ensure the process always accounts for user-based activities.
One simple user-centred design (UCD) technique I created several years ago keeps my team and I focussed on what’s important for the user.
I ask the team, at the beginning of the project, to define in the user’s words what success means. Together, we create a success statement for each persona. This simple method establishes a strong user-centered foundation at the start of a project and carries through easily to reviews.
This one statement takes the team out of feature-and-benefits land and focuses them on how the product helps the user. It also weeds out any jargon or supposition, which creeps into a lot of user discussions.
During discovery, we assess the validity of this statement with real users, and ask what information or actions they’d need to achieve success. I take this one success statement to each review on an ongoing basis—for designs and builds. I ask the team, can a user achieve this stated success from here? It becomes obvious which pieces of information and actions are necessary—and which are extraneous.
I also like to assign a key metric to that success statement, so at launch I can track whether or not I’m helping the user achieve success.
I come from a user research background, so I believe there is only one way to keep user needs at the center of our product—talking to our customers all the time.
I do this in a few ways:
These methods might not work for everyone, but the point is that talking to users should be approached from multiple angles. It’s not just about usability testing or phone calls. The key is to talk to customers in multiple contexts about multiple aspects of the product. If you do that, you are able to go beyond feedback on a specific feature, to a place where user needs permeate every part of the development cycle.
Build your roadmap around your users’ needs
Focus on the problems or unmet needs of your users in your roadmap, not the solutions that you might create. That way you always have a touchpoint to come back to—regardless of the solution you’re working on—and everyone is focused on asking, ‘Does it solve this problem or meet this need?’ Instead of, ‘Did we create what we said we would?’
Connect your users’ needs directly to business outcomes or goals
We all have objectives or goals we need to achieve to help our companies or products grow—so try to connect your users’ needs back to these. Generally, execs don’t respond well to vague promises of returns, so try to be as specific as possible. You can even use a formula to keep a consistent assessment of these needs, which can help explain your prioritisation of certain issues.
Value / Effort = Priority
Value: estimated contribution to deﬁned goals
Effort: is the investment you make to generate value in return
It’s easy, for example, to explain the importance of making your product easier to use when you have a user retention or annual renewal goal. Puzzled or frustrated customers don’t renew!
Listen to your customers and ask why a lot. Keep communication channels open with your customers and deep dive into their requests.
Over 80% of our company’s employees deal directly with customers on a daily basis. That means that almost everyone here has good insight into customer needs. We provide an internal channel where the whole team can provide feedback on our product.
To avoid this turning into a backlog of superficial suggestions, we ask questions that help product managers understand why a certain situation is a problem for the customer, its impact and what’s currently being done to solve these problems. The product managers then need to reply to the feedback and provide an overview of how we’re planning to tackle each problem that has been reported.
We also set up lunches with sales and customer success teams so they can tell us why they think we lose customers and whether our main competitors are changing. It’s amazing how much you can learn from a simple conversation.
Another good source of feedback is customer support. Periodically, I try to understand the main product gaps, usability failures and problems with product performance. We’ve recently prioritised improvements in the product based on this type of analysis, which included quantity of tickets created and their full resolution time. As a result, we had a 38% reduction in the quantity of tickets created for our features.
For me, the most important thing though is to talk to your users—I often do Skype calls to listen to what they have to say. And remember you need to understand why something is being asked for—look for the root cause of their problems.
While it’s important to keep users at the center of the process, it’s just as important (if not more so) to focus on buyers.
In many B2B situations, there are personas who will be involved in the buying process but never actually use the product. Even when users are involved in the buying process, they usually value different things when evaluating a product for purchase to when they’re using it. If you just focus on users and don’t understand the buyer personas and needs, you’ll likely never get people to purchase the product. You won’t even have a chance to get people using it.
I’ll also focus on 3 crucial elements that I don’t see happening in many B2B organisations:
I realised that user stories are prescriptive and assume what users want to do, instead of users’ underlying needs, motivations, desires and fears.
In other words, user stories don’t bring out why users want to do whatever they’re attempting to do.
Personas are great, as they put the user right in the middle of your product. After many years of using personas, however, I realised this was a futile exercise. No one referred back to the persona, nor did it help anyone understand why the persona was doing something in the context of a user story.
Ever since I came across Clay Christensen and the “Jobs To Be Done” (JTBD) framework, I’ve been using and recommending job stories instead of user stories. The reason is pretty straightforward—job stories focus on the context and motivation.
As a B2B organisation, Huddle gets lots of feature requests and feedback from the admin users who work the closest with our customer success teams. It can be difficult to get insights directly from the end users.
We’ve found that sending out Net Promoter Score surveys, to a randomised significant sample, gets us an overall pulse of how we are doing. But it’s hard to correlate changes in score with product changes. Instead, what I find the most useful is spotting patterns in the free text question, How could we improve? If a topic keeps getting mentioned by a sizeable percentage of respondents, it gets investigated. We then have calls with the respondents to ask the famous 5 whys, until we get to the root cause of the problem. We also use those relationships with end users to build a list of people who are happy to be contacted in the future, to test the prototypes designed to solve that problem.
Reaching out to end users directly, in a B2B environment, requires lots of internal communication, so we let account managers know when we have been on a call with an end user from their account. This way, they are always aware of all touch points with their account.
You don’t. You strive but you’re always at least slightly off-centre.
You try to amplify user research findings by properly prioritising and communicating them to all teams and stakeholders. You try to budget for instrumentation that gives you solid user behavior data. You include internal stakeholders in customer support and user research work. You drag your UX personas into meetings. You hold listening tours. You innovate and steal many ways of listening to, learning from, and understanding your users.
Legitimate forces always seek to displace your users from decisions. Engineers paying off technical debt. Regulators enforcing public policy. Suppliers mandating changes to how your service interacts with them. Marketers seeking compliance with identity standards. Management making promises to investors. Sales demanding ‘just one feature to close the big sale’. In B2B, corporate buyers may want different things than their users need. Even improvements to your own product management process rob attention and resources from your users.
The hardest part is keeping users in your heart every day. Distractions and stakeholder pressure keep pulling and pushing you to other concerns. So you need a personal touchstone—a mantra, a habit, a reminder to return your focus to your users each day. You also need colleagues to share your resolve and help each other hold that focus on users.
Because user-centricity only happens when you insist and persist.
Here are three tips from my book The Lean Product Playbook to help ensure you keep customer needs at the center of your product management process.
In my opinion it’s all about user behaviour and feedback throughout the product life-cycle.
Keep in mind not only the pain points that you’re solving for users, but also the long-term impact your solutions have on the product. While building a product, it’s good to keep the discovery handy:
Ask: what are the needs of my (target) users and why?
Try to figure out which user is doing what and for how long
Study the user’s behaviour and which patterns emerge over time
Don’t focus on all the users the same way
Don’t make assumptions about users and their needs
As you build, take a step back to find out whether a product actually fulfills a user need and is it worth building
Interview your users and make listening the absolute key
Set a challenge that every single core action should be achievable within 3 clicks
Ask: are the designs solving for performance and stability?
Focus on whether a product or feature really meets your user’s need, whether the users will pay for your solution, and (more importantly) whether the users will spread the word about the product.
An emerging user need describes an outcome a user desires in a certain situation.
When a product can help users progress towards a desired outcome, it increases its own value and user happiness significantly.
Uncover users’ needs and make them transparent to the whole product development team, and stakeholders or clients. You can create empathy for these user needs using research insights posters, coherent narratives and job stories (under the Jobs To Be Done framework).
As one of the UK’s leading news publishers, we have to build products for our customers and editorial colleagues across the country.
Workflows can vary from person to person, and between regional offices. We often see people taking the shortest path, but there are also those who take the long way round to completing a task.
When we identify a problem—or a perceived problem—we observe the process(es) and talk through them with the editorial users. We also have to consider how different teams, with different needs complete tasks. Talking to a good sample of people is crucial.
We share designs and product updates with stakeholders on a regular basis, including those from others areas of the business. This ensures that a solution is not causing new issues elsewhere. This is a huge risk in a large company such as ours.
When the updated product or feature is ready, we like to test with a sample of users to see if it has the desired effect—or if further iteration is needed before a full release. This gives various teams the opportunity to engage with us in the product team. It allows them to be part of the development process—to create solutions to the problems they and their colleagues (countrywide) are having.
Unless you’re building a product for display, you need a product that will actually be available for sale—and, more importantly, that someone will want to buy. Your goal is to solve a user problem the way they want it to be solved.
If the user isn’t at the core of your product, your product will fail. Developing user personas is a great way to understand how a user interacts with a potential solution to their problem. Bringing in users—better yet, go to their workplace to observe and talk—helps you see how they work.
The user needs to be at the center of your go-to-market planning and launch. You should have buyer personas to help you understand the core goals, attitudes and behaviors of your buyers. Once you understand buyers’ motivations, you can mirror that by developing a positioning that holds their attention. Once you understand the buyer’s journey, the launch strategies are easier to develop and execute. Once you know the buyer—the user—you can reach them directly.
It’s not rocket science, but it’s simply not about you and your product. This is hard for some product managers to hear. But building around, and for, the user is mutually beneficial—you get a product sold and the user gets a problem solved.
If you put users at the heart of your organisation, they’ll also be at the centre of your product management process.
I work on products in the UK government and we’ve hard-coded users into the development of all our digital services. Our Digital Service Standard tells us to understand user needs, and our design principles tell us to start with user needs. We always begin with a discovery phase in which we uncover our users and their needs. We are then periodically assessed against the quality of our user insights, to make sure that users are at the centre of our services.
If your organisation genuinely trusts and values its users, it makes it easier for product managers to be the voice of the user.
In digital product management, it can be hard to remember that your customer is not just a collection of data points but a person seeking an experience.
The data captured on-site can only tell you what the customer did or didn’t do, not their intent. Deeply immersing yourself in the product experience is important, but your learnings will always be skewed by what you know. Speaking regularly and directly to your customers has to be a priority for everyone in your organisation. Everything you build needs to be something that your customers have asked for—directly or indirectly.
Technical teams speak regularly about their technical debt. I think it’s important for product managers to speak up about their customer debt. That is, customers left unsatisfied due to half-finished features which were built because we could (e.g. the line was set up for it), not because we should.
And if you ever needed a reason to turn laser-like focus onto your customers and their needs, hopefully this sums it up for you:
“Sustainable growth is characterised by one simple rule: new customers come from the actions of past customers.”
- Eric Ries
Marketing gurus constantly remind us to talk to your customers. They’re almost right. Sales people talk to customers. Support people talk to customers. Product managers should listen to customers. After all, you don’t learn much while you’re talking.
In the Under10 product management model, learning is at the core of effective product management. Product managers (or whatever their title may be) should be the experts on personas and their problems.
To stay up to date, product managers should hold themselves accountable with a personal quota for customer engagements every month. Whether on the phone, via video chat, or face to face, strive for at least 5 customer interactions every month. You’ll be amazed how often yesterday’s conversations inform today’s decisions.
Without market data, a product manager is just another person with an opinion.
I walk through each step of this product management process in my upcoming book, Turn Ideas Into Products.
Talk daily to users. If that’s not possible, talk weekly with users. Try to connect with them in-person, by grabbing a coffee or something.
You know, users are people too :). Leave your ego at the door and connect with them, heart-to-heart.
Learn about their struggles, their pain points, their desires and what makes them tick. If you do that, you’ll get a lot of insights and ideas on how to improve your product. If you approach a user while focussing on what you want to get done, you’ll have a hard time connecting and exploring. People tend to feel when they’re talking to a douchebag. You’re feeling it too.
At the end of the day, don’t forget you’re not the CPPO—Chief People Pleaser Officer. You’re there to help people and build things that make sense for you as a business. You want to develop a feature that solves a problem for 1,000,000 people, not build 1,000,000 features so you can make 1,000,000 people happy. The latter is impossible and stupid. Just get on with your childhood complexes, dude—we’ve had enough of it.
People + Business = LOVE.
As a product manager, you often have to balance your business’ needs with your users’ needs. You’re accountable to your boss, to your stakeholders and ultimately your users.
I try to stick to 2 maxims:
Get to know your user
Never stop testing
For the first, empathising with your users, and understanding their motivations and behaviors, is a way to always keep their needs at the center of the product. You should ensure you’re always doing some sort of user testing.
Are you trying to improve some aspect of engagement on your site? Before sinking more resources than necessary, try to test it out. This will help when you need to show ROI to your colleagues and justify future upgrades to your product.
It tends to be a balance between three key components: Empathy, Testing and Continuous Research.
Amazon’s Jeff Bezos is famous for making sure the conference table always includes an empty chair and letting attendees know that it’s occupied by the ‘the most important person in the room’ – the customer.
Developing empathy and awareness for your target users is a conerstone of a successful product management strategy; it’s key to make sure that you and your team understand your customer’s POV, their needs and why they’re using your product or service. Keeping personas in sight, building empathy maps and – why not – keeping an empty chair are some ways of doing that.
Empathy is essential, but so is testing. You should be testing often, at every stage of your design process. When you get real users trying out your interactionsm (and that could be as early as testing a paper prototype or sketches linked together) you literally peek into their world. It makes it easier to visualize the things you should be focusing on.
Lastly, user research should be continious – you don’t check it off a todo list. You should be always talking to your users, conducting interviews, surveys, continously refining your personas, testing (and more, but this is probably enough to paint the picture) at least on a weekly basis. If you do that, your (and your team’s) awareness of what actually matters to your users will grow naturally.