Product Team Mistakes, Part 2: Selecting, Estimating, and Prioritizing Features — Users Know

A little while ago, I asked a lot of designers what product managers did that annoyed them the most. For the sake of fairness, I also asked PMs the same question about designers. I thought maybe I’d get a few responses and write up a quick blog post about some of the worst offenders. I’m going to be honest here. I dramatically underestimated the number of responses I’d get.

This is the second in a series of blog posts covering some of the biggest mistakes product teams are making when it comes to collaborating and a few suggestions of how all of us might work together a little better. Read Part 1 here .

Two of the most important jobs of a PM are to prioritize and estimate features so that the team doesn’t try to work on everything at once. In many companies, this turns into a feature roadmap which probably deserves its own blog post at some point.

Unfortunately, quite a few designers were unimpressed with their PM’s prioritization and estimation skills. Their complaints fell roughly into four categories:

• Lack of understanding of the details of a product
• Being too tactical and ignoring the longer term health of the product
• Refusal to commit
• Prioritizing internal stakeholder opinions over real user needs

Lack of understanding of the details

The first category was a pretty common complaint, especially on teams where PMs mostly just collect feature requests from stakeholders or customers. Designers complained that PMs would make wildly unreasonable roadmaps of features that didn’t really work together and that took far longer to build than expected because they simply didn’t understand the features or product in enough detail to make a good decision.

This obviously caused problems, because it was the team (mostly designers, researchers, and engineers) who were on the hook for delivering badly scoped features on unreasonable timelines. But it’s not only a problem for missing deadlines. It’s also bad for figuring out which features to build next. When PMs don’t have a deep understanding of what a feature is supposed to do and a rough idea of its complexity, it’s impossible to judge whether it’s more important than all of the other options.

Designers also pointed out that these non-detail oriented PMs would give very vague direction about features, which made them impossible to design. PMs would request features from designers like “Add SMS support” or “Improve the onboarding” without giving any of the reasoning behind the request or explaining how the feature was supposed to help the user. They would then, inevitably, be upset when the designers returned something other than what was expected.

One designer explained it as, “Usually there’s a generic, high level view of what the client/stakeholder needs but there’s rarely any real understanding or brief, and when questions are asked, the PM doesn’t know and assumes the UX fairies will figure it out. PMs rarely get involved in understanding the requirements to any helpful extent.”

Being too tactical

When PMs did understand the product well, they still made prioritization decisions that upset a lot of designers. Designers complained that PMs made small tactical decisions that focused on little changes or short term wins, and that they failed to make big bets or changes that might help improve the product over the long term.

One designer explained that the PM “didn’t seem to understand that the cumulation of all those little changes meant having to do major refactors later, which they also wouldn’t budget time for.”

Interestingly, when asked what Designers did to irritate PMs, one of the biggest complaints was that designers tended to (in the estimation of the PMs) wildly overdesign things. Several PMs said that, even when asked for fairly small features, designers would return enormous, sweeping changes that would take months.

It’s hard to say whether either of these views are entirely fair. PMs are often pressured to show immediate results, which can lead to short term thinking about changes. Also, there’s always a temptation to work on the smallest stuff first, since it seems odd to delay a quick fix until a giant feature has been completed. PMs also know that they’re the ones on the hook for justifying the need for making massive changes to something, and they can be worried that they’ll get halfway into a big project and have the company priorities change. Small changes can feel a lot safer, even if it means big, critical problems don’t ever get addressed.

Designers, on the other hand, may be enticed by the idea of bigger changes that allow them more room to really make all the improvements they think are needed. On the other hand, I’ve certainly been in the situation where a seemingly easy design solution turned into something much larger than predicted because adding or moving a single small item meant that a dozen other things needed to be updated as well. It’s easy for design changes to snowball.

Wherever the fault lies — and I have some theories that fault is generally pretty well distributed in cases like this — designers and PMs seem to have an awful lot of trouble deciding how much of the product should change at once.

Refusal to commit

This next one surprised me a bit, but several designers claimed that they had worked with PMs who absolutely refused to commit to anything or write anything down, which seems…not great? One designer said that their PM wouldn’t write anything down “for fear of getting criticized” and another explained that the PM didn’t want to be seen as “committing” to any features in writing. I haven’t personally run into this, and I imagine that there’s something really off about the general culture of a company where this happens, but enough designers mentioned something similar that I think this isn’t restricted to one or two badly run places.

There’s not much to say here other than that PMs should really write things down, and if they refuse to do so for fear of getting criticized, that’s a very bad sign about the company, the PM, or both.

Prioritizing internal stakeholder opinions over real user needs

This last one is a huge problem. I’ve separated it out from a different designer complaint about PMs refusing to do external research, since that one deserves its own post, but a large number of the problems designers complained about are probably rooted in PMs prioritizing internal stakeholder requests over customer needs.

For example, a huge percentage of the time that PMs explain that we have to “build feature x” rather than “improve metric y” it’s because somebody (generally somebody higher up the food chain) is demanding a specific feature for some reason. Often there will be a huge backlog of features that “have” to be built because the PM has gone to all of the internal stakeholders and simply asked what they want.

Of course, it rarely feels like that to the PM. PMs can get tremendous pressure, especially in larger organizations, to build specific features for all sorts of reasons. Sales believes feature x will close a deal or marketing knows they need feature y because a competitor has it or the CEO saw an article in Forbes about new feature z and they are afraid of not having the hot new thing.

Unfortunately, this tends to result in a random collection of features, which rarely makes a coherent product. Designers are the ones who are stuck trying to glue everything together without destroying the user experience, which can feel like an impossible task.

How do you fix it?

There’s no one way to fix all of these problems other than working in an environment where PMs have the skill and authority to build products the correct way.

As I mentioned in the related post , I don’t blame PMs for most of these problems. They’re systemic. PMs prioritize stakeholder input over users because, in many organizations, they’ll be punished if they don’t. PMs are afraid to commit things to writing because they know that they’ll be held responsible if things go wrong. They choose short term wins over longer term bets because they need to show results right now or because they’re worried that company strategy will change (again), and they don’t want to overcommit.

The one thing that PMs do control and could improve immediately is getting a much better grasp of the details of the feature that the team is building and about to build. Obviously nobody has an encyclopedic knowledge of all the tiny interactions in every part of the product, but there’s no excuse for the amount of “high level thinking” I heard about from designers.

You can’t make good prioritization decisions without understanding a lot of the details of your product and its features. Expecting your team to accurately design or estimate anything with no more of a brief than “Add SMS” or “Improve onboarding” is product malpractice.

Fundamentally, most of this could be fixed by PMs not prioritizing features on a backlog, but instead, clearly communicating the metrics, user needs, and company goals to the team, and then working collaboratively to figure out the best options. Unfortunately, most teams don’t work like that yet, so I’d settle for PMs who understand their products, aren’t afraid to make big changes when necessary, and who listen more to user needs than to stakeholder demands.

Want some good exercises to help work better as a team? Check out my book, Build Better Products.

Originally published at https://www.usersknow.com on October 8, 2019.