There’s been a long and storied myth about the divide between designers and their business counterparts, product managers. But we think that story is a little outdated. After all, both product managers and designers are united in their mission to deliver successful products, and we think that’s something to be celebrated.
Still, many product design teams don’t quite work as closely or as collaboratively as they could be. Even now, product managers and business stakeholders tend to own the product brief and tag design teams in to execute on the brief once it’s done.
According to Ellen Butters, a Digital Service Expert at the United States Digital Service, when design teams and product managers come together early in the process, that’s when the really good work can start.
“Designers can sometimes think in a very abstract, sort of right-brained way,” says Ellen. “But then presenting your ideas and arguing your case needs to be done using the other side of things.” Enter your friendly neighborhood product manager.
Knowing how to effectively partner with her partners is something of a specialty for Ellen. She works as part of a digital task force team who are responsible for partnering with a rotating list of federal departments and agencies and works with their teams on ensuring that their digital properties are functioning optimally.
Here’s her advice on how to set the right context for any product design conversation.
Everyone benefits from shared, upfront discovery
A lot of product design processes seem to be missing a key ingredient at their very start: designers. Ellen agrees, it’s time to shift away from seeing designers as an end point to the build process, because everyone stands to do better work when they have the right context.
Ellen counts herself lucky. At the US Digital Service, teams believe in human-centered design as their central approach. Under that method, people from every discipline are at the table from the very beginning and building the product brief together. They design the brief together, agree on the measures of success, and conduct regular retrospectives to see what’s working and what isn’t. “Strategic thinking is not limited to one role.”
Some product managers may have a tendency to be laser focused on quantitative data. And that’s okay, because that’s basically their job. But in cases where the team may be leaning too heavily into the numbers, Ellen invites designers not to get dejected and, instead, use those moments as an opportunity to find their voice as user advocates.
“I think we all want to be data driven, but there are different kinds of data: the quantitative and the qualitative,” says Ellen. “I think that companies tend to short change the qualitative data, so it's partially up to designers to make the case for why that data has a lot of value for the organization.”
Want to change the roadmap? Partner with PMs to make a business case
In the early days of product design, your roadmap may see some flux as you surface more information and learn more about your users. Ellen says this is the perfect opportunity for designers to partner with product managers on building a business case around qualitative data.
“I always like to hear my PM’s perspective on what we’re actually trying to achieve and how our solution is helping the person,” she says. “PMs often have a really elegant way of framing things and that helps me with how I approach my own research and, ultimately, how I solve the problem.”
She shares an example of a time when she spotted a lot of similar anecdotal feedback from users. The thing was that what users were asking for wasn’t a simple task and would require significant resources. Still, the designers on the project felt that this particular bit of user feedback couldn’t go ignored.
What Ellen needed was to find a way to substantiate the qualitative feedback she was hearing with some quantitative data that shows the breadth of the issue. She knew that PMs likely have the data-driven mindset to help her build the business case she needed.
A few ways product designers can partner with product managers on building a business case for a new feature, improvement, or change to the roadmap include:
- Share the hypothesis behind your design recommendation (aka what problem do you think it will solve?) and define upfront how you’ll measure success.
- Do a bit of user research first to see if you can get some preliminary numbers in front of a product manager. If you’re able to show the potential percentage of users experiencing the same issue — and the impact that may have on overall product usage or satisfaction — you’re likely to get your PM on board to advocate for your recommendation.
Working well with product managers isn’t a matter of learning to speak business lingo, it’s a matter of understanding what information to prioritize when presenting ideas and solutions to them. Partnering with PMs also means they can help you see how your project or proposal fits into the bigger picture.
“What I appreciate about the PM role so much is that it’s about relentless prioritization, which is not my habit,” she says. “I tend to just see all the problems and want to solve all of them and just get creative.
Don’t forget about your engineering pals
Speaking of pivotal partnerships, Ellen shared that she often thinks closely about her relationship with her product co-builders, engineers. “I feel like when I whiteboard and sort of do early stages of design with engineering, I avoid a lot of pitfalls, because I don't want to go in a direction that is not maintainable,” she says.
Engineering perspectives are especially important during the early brief-making and usability testing phases. Ellen often invites engineers to sit in on user observation sessions. “Engineers have such good insights and an ability to synthesize the results of usability tests and interpret them in a way that maybe I wouldn't have done on my own. And I really enjoy that,” she says.
At the heart of all successful partnerships is a willingness to hear other perspectives, the humility to ask for ideas and insights from team members in other disciplines, and the curiosity to dive further into a problem before jumping to a solution.
This post is part of an ongoing series featuring snippets from Same Page — our event series that explores the design process. Explore In the Margin to see full-length recordings and more content on the design process.