Product Team Mistakes, Part 1: Communicating Company & User Needs — Users Know

Understanding the Business

One of the biggest complaints was fascinating, because I heard it from both PMs and designers. Designers complained that PMs were bad at understanding and describing the business case for features they were requesting, while several PMs complained that designers didn’t understand the company’s business.

Whatever you think about splitting up roles within a product team, most people agree that understanding and explaining the business side of a product is more the PM’s job than the designer’s. If they don’t understand the business or if they’re not sharing it in a way that helps everyone know what is being built, that’s a pretty serious problem. Still, let’s not let designers off the hook here. Everybody making changes to the product should understand the business needs, but it sounds like there are quite a few folks out there who don’t.

Designers cited “vanity metrics” and “death through optimization” as examples of PMs who misused metrics or didn’t understand the business well. Instead of focusing on important KPIs that would reflect a better user experience or an improvement in things like revenue or retention, some PMs looked at numbers that didn’t mean much, like “time on site” or “total registered users.” Others spend a huge amount of time focusing on eking out tiny improvements with tweaks to things like button color or text, instead of making larger changes that might have a significant impact on usability or usefulness.

Several designers also said that their PMs only seemed to have a very high level understanding of the product and didn’t have any real ideas about how to improve anything important. Designers felt that PMs should have a deep understanding of the business model and how changes to the product contributed to improving the bottom line and customer experience. Unfortunately, in many cases, PMs either didn’t have a firm grasp on the economics of the product or they couldn’t explain it in a way that designers understood.

I’m not putting all the blame on the PM here. There were also PMs who complained that designers or researchers with whom they worked were actively hostile to learning about money. When the PMs tried to get designers to understand that their work had to improve metrics, some designers insisted that design was somehow different, and they were exempt from understanding the business model.

Solutions vs Problems

Another frequent complaint was that PMs weren’t sharing user needs or problems with the team. In fact, in some cases, they were actively interfering with designers contacting users to learn this themselves, but I’ll explain more about that in a future blog post.

So if PMs weren’t clearly articulating business needs or user problems, what were they doing? Demanding specific solutions, in most cases. Designers claimed that PMs would frequently come to them with a “solution” and simply ask the designer to “make it pretty” or in some cases “make it work.”

In general, designers wanted PMs to share the goals of the user and the specific problem that needed to be solved. Instead the PMs would come up with a solution and deliver it as a specific feature request without explaining how the feature would help the users succeed.

Even when the PMs did write problems statements, they would sometimes write them in the form of a solution. For example, “The user can’t place their order using SMS,” or “The user can’t use the advanced search tools to filter results by relevancy,” rather than explaining the context of the user and the user goals that weren’t being achieved.

The problem with this approach is that it devalues the potential contribution of designers in a very specific way. It limits designers to mostly visual decisions, which is fine if you’re dealing with a designer who is only concerned with things like typography, color, and whitespace. But it’s a terrible waste of designers who have experience and training in things like information architecture, systems thinking, or research synthesis.

Many user experience and product designers are used to coming up with creative solutions to user needs. They would much prefer being given a problem and asked to solve it rather than being given a feature and asked to draw it.

Why does this happen?

None of this is particularly unusual. In my experience working with teams, I’ve seen quite a few PMs who think their job is either to:

• Come up with all the features and solve all the problems themselves, OR
• Come up with a high level idea and then leave all the pesky details (like how it works and what metrics it will improve and how it might help users) to somebody else

The biggest culprits for all of these behaviors are the following (all of which probably deserve blog posts of their own, but who’s got that kind of time??):

• The CEO/Stakeholders really want a specific feature
• The designers on the team are largely visual designers and aren’t used to being asked to come up with feature ideas
• PMs don’t have access to customer research and/or metrics (I know! It’s terrible.)
• Sales says they need a key feature to be competitive with a big customer (VERY common in B2B)
• Somebody falls in love with an idea or solution instead of starting from the business and user needs
• PMs believe their job is to simply gather requirements from various stakeholders and then prioritize the list (to be fair, in some orgs, this is literally the PM’s job — although it rarely results in a good product)

How do you fix it?

If you’re a PM reading this, you might think, “Oh, this doesn’t apply to me!” And you may very well be right! This was not a huge statistically significant survey of all types of teams. This was random whining on the Internet. But let’s just say there was no shortage of that whining, and there were some extremely strong patterns to be found, many of which I’ve seen in my own experience working with teams.

The best way to find out if your team (not just the designers!) really understands the business is to ask them to explain it to you, preferably in a friendly, non-confrontational way. If they don’t get it, try not to automatically blame them or assume designers don’t care. Take a look at what you’re doing to make sure that everybody on the team understands the “why” behind everything you build.

Also, make sure that you take a look at when you’re bringing designers into the planning process. Do you wait until you have a really good idea of the feature and how the feature will work before “handing things over to” design? Stop it! Bring design in at the point where you’ve figured out the business need and the general user problems and have your UX designers help figure out the right features.

Of course, handing over nothing more than a single sentence or short paragraph can be just as bad. Saying “we need better search!” isn’t strategy! It isn’t high level thinking! It isn’t even particularly helpful!

Instead, try framing what you need as a user and business problem. “Our data are showing that a lot of users are searching for x or y and then abandoning the product. Some initial research suggests that they may get really frustrated because they’re having a hard time understanding the results. What are some things we could do to fix this for them and help them get what they’re looking for.”

And designers don’t get a pass on any of this either. If you refuse to understand the business needs or feel like getting insights from customers is somebody else’s problem, you’re not going to make very good decisions.

If PMs come to you with a fully formed feature, try asking about the needs behind it. Maybe something like, “This looks really interesting. Can you tell me what sort of impact you expect this to have on the business? How about the user need? What is this solving for them?” If you don’t understand the answer (or if the PM doesn’t have one), hopefully you can work together to understand why the PM wanted the feature in the first place.

Whether you’re a PM or a designer or anybody else working within a company to build something for humans, it’s critical that you understand why everybody is making the decisions they’re making. When we all understand what the company needs and what the users need, we can all make better decisions. If you’re interested in some exercises for working better as a team, you should check out Build Better Products.

Originally published at https://www.usersknow.com on September 13, 2019.