What to answer when Product Owner/Manager says "this feature [requested by users] needs a lot of time to develop, so we'll never do it"?

Question

More precisely: I work in a company that doesn't have any design culture. Some people tend to think a little more in a user-centered way but not the important ones. The Product Manager only cares about the development time, the CEO only cares about business strategy against competitors, and in the end we are never able to put the expected features (asked for by users) above the stategic & market oriented features (defined by CEO/PM).

Let's take an example: a few months ago it was reported to me that users want to see immediately when a message is read or unread. The proposed solution was: "we have to display in bold the name of the message in the list, and when you read it it turns back to regular, but just for you". But then the Lead Developer said that would need a lot of time to do, because we don't actually know when a message have been read and by whom. Since then, the Product Manager has just delayed the feature, again and again, saying that the impact was too low as compared with the time needed to do it. Ultimately, it even became: "we'll probably never do it at all".

So, as a UX designer, how am I supposed to defend users when these people are taking decisions and just look at me like what I'm saying is useless?

Answer 1

tl;dr

Present user needs in the context of business outcomes.
If that doesn't work, it's time to find a new job before this one melts down.

---

Align user needs with business outcomes

Based on your description, it sounds like

• You've done a good job of expressing the user's desire for the enhancement.
• The rest of the organization has done a good job of expressing business outcomes.

Given the two in isolation, the business outcome will always win. Especially in an organization that hasn't kept up with the current state product design practices.

Keep the proper structure of product strategy in mind:

Product Vision ➝ Initiatives ➝ Epics ➝ Stories ➝ Tasks

The vision and resulting initiatives will drive everything downstream. If you can't impact things at that level, you'll fail.

Healthy product development roles

In a typical, healthy software organization:
The UX designer would focus on user needs and discovering opportunities in that domain.
The Executive team would focus on market and financial needs and define targets in that domain.
The Product Manager would be responsible for marrying the two, communicating the opportunity to leadership, and prioritizing the backlog accordingly.

In your case, the Product Manager either doesn't have the ability to understand how user and business come together or there's undue pressure to simply accept the Exec team's orders without modification. That's a very bad situation that will lead to failure.

Filling the gap

Before you throw in the towel, try to do the Product Manager's job. Reframe your priorities based on how they'll change your position in the market and provide real returns. Compare the current features to user expectations and how user frustration or lack of usability will cost your users, drive product abandonment, and negatively impact MRR (monthly recurring revenue).

Product decision making framework

I don't remember where I found this, but I've been using it for years and it's an incredibly helpful way to get everyone to understand priorities ...

If you can get the product strategy correctly defined (which may be difficult in your case), the revenue calculation is your next biggest deciding factor. That's hard to estimate and it will certainly be a team effort. You might have to do the legwork to do market research, talk with other department heads (Sales and Ops come to mind), and chat with actual decision makers on the client end. It may not be your job, but it's good experience in the end and it may just save your company's product from impending doom.

Sidebar on the state of your software

If your product doesn't "know actually when a message have been read and by who" and will require "a lot of time to do" I'd venture a guess that it's ready to be rewritten. There's also a good chance you need a new engineering team, or at least a new leader to make that evaluation. Those are tough calls to make, but I've seen a lot of products fail because they were afraid to accept that reality.

Does the Kano model apply?

SPavel references the Kano model's view on satisfaction gains across the three basic feature types: basic, performer, and exciter/delighter. Kano tells us latter two will give you the biggest satisfaction gains, which is often true. Your organization is (knowingly or not) applying this theory. However, the Kano model assumes you already have the minimum requirements in place and your product provides the necessary features of basic usability and function. Application of the Kano model to defend avoiding the basics is gross misunderstanding.

IOW, Kano applies, but not like your organization thinks it does.

Reality check 💔 😬

I think that's all great stuff and it would be smart of you to make the effort. On the other hand, it's incredibly optimistic to think the organization is going to be transformed when you show them the light.

While you're trying to change the world, also start looking for a new job. Changing jobs is often hard, unpleasant, and rarely solves all your problems. But it's not smart to keep sailing on a sinking boat either (read Joseph Conrad's Youth sometime).

Answer 2

In terms of satisfaction, return on "expected features" is very low

Consider this from the PM's point of view - you want to tie up a large amount of engineering time to create a feature that does not make money. All it does is increase usability by some amount - important in principle, but the business outcomes are questionable according to the Kano model.

Chances are that your software is somewhere in the bottom-right quadrant along that green line. It's usable, but not award-winning, NN Group-level usable. This is good enough for the people in charge, and they want to move further along the red line instead because that's how they can make money to pay all your salaries.

Users are only one of your stakeholders

It's a mistake to think that your only responsibility is to the user. It's one of your responsibilities - and you may be the only person in the company with this responsibility - but if you don't learn how to work with all your stakeholders, all features you suggest will be doomed to languish on your hard drive.

For your internal stakeholders, it's not worth it to devote engineering time to marking messages unread...by itself. But there could be a lot of value in knowing which user has read which message. Analytics are a big one. User segmentation is another. If you pitch the engineering effort as "so we can track our users" (huge benefit to the company) instead of "so our users can see what they've read" (dubious benefit to the company) then the bean-counters will look much more kindly upon you.

Answer 3

While this is probably a losing battle and nothing you do will change the outcome, I think you should consider having a conversation with your PM and ask what are the scope of your responsibilities and his/her expectations regarding your work. Obviously, all in a very respectful way and explaining that your question is to optimize the time of the company and not do things that may not be necessary.

That way, s/he will be forced to give you a concrete answer. If s/he tells you that your responsibility is to generate the best possible user experience, then you can document what you want to do, explaining the pros and cons of your decision, and how this change will result in an improvement of the experience of those users. It is very important that you consider your company's competition: if the competition does not do it, you can "sell" it as an exclusive and differential feature.

Now, the user case that you mention seems pretty trivial and in fact it is default in almost any application of messages, so either there is a lack of data in your description, or the problem is another. And unfortunately, if the problem is interpersonal relationships, egos or jealousy, I doubt very much that you can do anything.

In short

Document everything and do your best to explain the cost-benefit differential, talk to your PM, set the scope of your responsibilities. You really can't do much more than this, but this is the least you should do.

Answer 4

I feel the pain, I really do, but in the real world there are many many things that affect the decisions made. Some you can affect, some you can't.

There are two things that can help.

1. Talk to your colleagues and build relationships. Understand why the decisions are made the way they are. Accept that the lead developer is right about the length of time to implement, but ask her/him if to explain why (I mean really, meaningfully why) so that you can also be better informed around related or similar features. Accept that the PM is making a call on this feature given all the information they have to hand, but find out what that information consists of. Not with a defensive posturing, but seeking to understand the decision process so that you can work with that process effectively for both of you.

2. Generate evidence. The impact of a feature may have been marked arbitrarily as low, or low for the effort, but what evidence do you have for the contrary. Don't think of it as trying to prove anyone right, just as a presentation of evidence. How many users are asking for the feature. What impact is it having on using the product? How are users venting their frustration? In what context are users asking for this feature. How much time are users wasting looking at already read messages. What impact is it having on the perception of the business or the brand? What are the benefits of this feature other than pleasing these particular users? If you truly believe in this feature (on behalf of your users), you need to collect robust evidence and sell it on. Remember to research that evidence back to credible reliable sources.

In the end you have to choose your battles, but if you're finding every conversation indeed feels like a battle, then you have to consider whether you're in the right place.

--

There is another way for this sort of thing - get the decision makers to use the product themselves. If there really is an unprioritized weak point in the system that is frustrating users, then having the decision makers themselves get frustrated with it might soon get its priority raised!

Answer 5

In such a case, you can increase the value of the feature, by using synergies.

The requested feature is highlighting unread messages, which would be trivial, if you had a way to know which messages are unread. You don't, that's why the feature is expensive.

Is there another feature that benefits from knowing which messages are read by whom and when? Say, internal analytics? Targeted ads? Spam/Bot detection? Debugging?