Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. Imagine a product team discussing new commenting functionality on their company blog.
“We should let people comment anonymously.”
“That will only attract trolls. We should require real names.”
“We should require unique names, but allow pseudonyms.”
You won’t find a shortage of debate on this topic across the Internet. But there is no right answer.
Like many product questions, it depends.
It depends on your business goals. It depends on your audience. And it depends on the problem you are solving for them.
Businesses are good at taking care of their own needs. Some are getting better at understanding the audiences they serve. But few take the time to define the problem they are solving for that audience.
But without understanding the problem you are solving, you have no idea which solution is good. – Tweet This
If your blog is for a well-connected, private community that relies on the comments to engage in civil discussion about topics that matter to them, then real names might be the most appropriate.
If instead your blog is for cancer-survivors who often share personal stories in the comments, pseudonyms may be a way for people to forge strong virtual connections without giving up their real-world privacy.
And finally, if your blog is about embarrassing personal topics that even pseudonyms won’t help people feel comfortable asking about, then maybe anonymity is your best option.
Each of these examples, represents a different problem for a unique audience.
The problem itself defines the criteria for selecting a suitable solution. – Tweet This
Get Clear on What Problem You Are Solving
Take a minute to review your backlog. What do you find there? Is it full of solutions?
Many of us start with solutions.
Our brains want closure making it hard to think about problems without jumping to solutions. – Tweet This
But it’s also why you spend more time than you’d like arguing with people about which solution is better.
As we saw in the example above, it’s hard to evaluate solutions without having a clear idea of what the problem or opportunity is.
Understanding the nature of the problem helps us to understand just how good any particular solution is.
We need to spend as much time thinking about the problem as we do thinking about solutions.
The Role of Product Management and Design
As teams specialize, responsibilities are being split between product management and user experience design.
A common division of labor is for product managers to own the problem definition and for user experience designers to own the solution.
You may be working in a similar configuration today.
Product managers prioritize and define problems or opportunities by writing user stories or job stories.
User experience designers take that problem or opportunity and design the optimal solution.
But this is too simple.
If you read those last few paragraphs again, you might notice that they sound an awful lot like waterfall approaches.
The product managers starts the work and then hands it off to a designer who completes the work.
Not only is this not how true teams work, it doesn’t lead to the best outcomes.
Problem and Solution Definition Move Together
There has been decades of research across many disciplines on how design problems are solved.
Without exception, every model (see here and here for two examples) defines a two-way feedback loop between how the problem is defined and how solutions are generated.
How we define the problem impacts the range of solutions that are available. And as we explore solutions, we further refine the definition of the problem.
You’ve probably experienced this yourself.
Suppose like in the example above you are working on a comment feature. You have an idea in your head about how it might work. But as you sketch it out on a whiteboard, you start to uncover new elements of the problem.
Maybe you hadn’t considered threads. Or maybe you aren’t quite sure how to handle avatars when users are anonymous.
As you explore a potential solution, new constraints pop in your head. The problem shifts and morphs.
With each solution you consider, you start to get a better idea of the nature of the problem.
If you split problem definition and solution generation into two different steps performed by two different people, you lose these valuable insights.
You sever the feedback loops.
The only reason why we split these activities into two steps in the first place is because we weren’t paying enough attention to defining the problem.
Do pay attention to problem definition.
But don’t stop defining the problem just because you started generating solutions. – Tweet This
Define Roles That Make Sense For Your Team
Don’t draw artificial boundaries between product management and user experience design.
I’ve done both roles. The line is hazy at best.
Product managers may have deeper expertise about the market or the business needs, but a good user experience designer also needs to understand this context.
User experience designers may have deeper expertise about how to translate users’ needs into user interface components or compelling workflows, but a good product manager needs to have some level of competency in this as well.
Do specialize. But focus more on who does what and less on who owns what.
Both the product manager and the user experience designer need to own the product. Both need to feel responsible for the final outcome.
The product manager might spend more time supporting sales calls and communicating with executives. The user experience designer might spend more time working on wireframes and iterating on mockups.
But they both need to understand the problem they are solving and have input into what the final solution is.
And they both need to be engaged as the problem morphs and evolves as they explore different solutions.
Stop Relying on Authority to Make Decisions
Where most teams run into problems is deciding who gets to make which decisions.
Product managers and user experience designers often collide when they disagree about a workflow, a user need, or a release date.
Too quickly, teams rely on authority to win these battles.
The product manager in a rush to make a release deadline ignores the designer’s concern that the new feature doesn’t match the style guide.
The designer refuses to adjust a call-to-action that isn’t consistent with the product messaging over concerns that the product messaging isn’t clear enough.
You’ve probably experienced similar battles.
But relying on authority to win these battles doesn’t take advantage of the knowledge and expertise on your team. – Tweet This
In an ideal world, the product manager and the user experience designer should agree. You won’t always be able to get there. But you should try.
The key is in the trying.
Rather than arguing over two outcomes where only one party is happy, both should work together to identify a third outcome that satisfies both parties.
How might we meet the criteria of the style guide and still make the release deadline?
How might we change the call-to-action so that it is both clear and consistent with the product messaging?
Both the product manager and the user experience designer should be expanding the options rather than arguing for the choice that only meets their own needs.
Do the Work Required to Collaborate
The only way to generate options that satisfy both parties is for each person to do the work to understand what their own problem is.
It’s easy to dislike something. It’s much harder to know why you dislike something. – Tweet This
But you can’t satisfy a need without understanding what the need is.
A savvy reader might realize that we’ve come full circle.
We started with understanding a user problem. As you explore and evaluate solutions, you need to match the solution with the current problem definition to understand whether or not it satisfies the users’ need.
If you encounter conflict amongst your team along the way, each of you needs to do the work to understand the nature of the problem you are experiencing so that you might together find solutions that satisfy each of your needs.
This process is iterative. The more that you can view your teammates as users that also need to be satisfied with the solution, the more likely you’ll find a solution that meets the team’s needs.
Don’t Wait For Conflict to Arise
In the heat of conflict it can be hard to collaborate. Take the time now to define how you will handle such conflicts before they arise.
Here are some questions to consider with your team:
- How will you ensure that your team spends as much time defining the problem as they do generating solutions?
- How can you ensure that the product manager and the user experience designer are engaged in both defining the problem and generating solutions?
- How will you divide up the necessary tasks in such a way that doesn’t sever the feedback loops between defining the problem and generating the solutions?
- Do each of you commit to doing the work required to collaborate – working to understand the nature of your own problem when conflict arises?
- How might you remind each other to consider new options rather than arguing over options that don’t satisfy the team’s needs?
Capture your answers in your team charter and make sure you revisit it on a regular basis.
This article is part of a series on building shared responsibility for product delivery across the product development team. You can find the previous articles here. To get notified of future articles, subscribe to the Product Talk mailing list.
This is great and I find it how all backlog grooming sessions should be run. It’s the feedback loop between those clarifying the business problem and those designing to solution to address the needs.
Great article. Too little time is typically devoted to problem definition and as a result it often leads to arguments about the solution as you pointed out. I appreciate your insights just wish they were more readily shared with teams outside product mgmt. This ties into my belief that roadmaps should be problem focused instead of solution focused. Any advice on how to change mindsets?
Hi Aimee, Changing mindsets is always challenging. I try to shift the conversation from features and deliverables to outcomes. As a result, I recommend using goal-based roadmaps rather than feature-based roadmaps. See: Drop Feature-Based Roadmaps. Of course, you have to deliver on outcomes consistently to earn the right to stop talking about features and deliverables, which isn’t always easy. But I’d rather be held accountable to delivering outcomes than a series of features that don’t have an impact.
RE: software in particular, solutions are a combination of business challenge, UI elements, FE engineering, data model, and server-side engineering. EVERY solution consists of all of these elements. A solution team needs to understand all of these elements to develop an optimal solution. That doesn’t mean that you specifically need a data architect on the team, but you do need someone who understands how the data model will work (and maybe access to a data architect for consulation). A single person may have enough knowledge to create a solution for a given challenge (although that’s exceedingly rare in our age of specialization).
This applies in other industries as well. Creating an optimal design for a mechanical device requires knowledge about the problem set/desired outcomes, user scenarios, materials, structural engineering, manufacturing, etc.
In terms of problem definition and getting away from feature backlogs, these are generally well understood challenges. “New Products Management” (Crawford and Di Benedetto), although at times a bit textbook-y, provides a good outline.
The biggest challenge is often operating as a team. No ego about who “owns” what. The team owns the problem set. The team owns the solution set. The team succeeds or fails together. This is especially difficult in matrixed organizations, where line management runs through function rather than through cross-functional product/project teams.
Of course teams don’t function optimally on consensus (that’s not a bad thing, neither do democratic systems, which operate on majority). Opinions of skilled experts on the team need to be considered, but ultimately the buck must stop somewhere. On product teams this is typically with the PM. The question is are you an ego-less PM leader who’s focused on value creation (i.e. the purpose of your team), and helping the team stay focused?
Hi Kevin,
Thanks for your thoughtful comment. I agree with almost all of it. My only point of contention is that I don’t think the buck can stop only with the product manager. This is exactly what I think leads to the product manager having too much power on the team. The buck needs to stop with the cross-functional team – the product manager, the UXer, the data analyst, the tech lead. As you say, everyone’s expertise is needed and as a result, I argue the team needs to be responsible.
We like to pick one person to be responsible as it we believe it is simpler. But simpler is not always better. In this case, we should be optimizing for team performance and that means team responsibility.
Great post! Great minds think alike…
http://www.mindtheproduct.com/2011/11/focus-on-the-problem-not-the-solution/
http://www.mindtheproduct.com/2015/04/product-management-team-sport/
A desired outcome is a business need (e.g. increase engagement, reduce churn, etc.). An opportunity is a customer need, pain point, or desire.