3

Sometimes it happens that product owner says that he wants a new feature to be added to our information system and he wants it because our users want it. But the real situation is that 1 or maybe 2 users have expressed their wish to the owner and now he extends it to all users.

Because every additional functionality or change adds complexity, it should not be done on 1-2 users request if there are 10000+ users.

My question is, is there any good guideline how many of the users should be positively affected by the change, so that it "pays off". In case this situation happens, I can say for example "we need to evaluate your request and if about 20% of our users are interested we should make it".

I'm not talking about fixing bugs nor financial profitability.

  • Do you ask product owner why he wants the feature regardless of number of users? His answer will be base for your further estimations. – Serg Feb 26 at 17:48
3

Prioritizing work and features is difficult and complex. It's definitively important skill for ux-professionals to be able to distinguish between good ideas, nice-to-have and killer additions. In my experience there are no specific numbers for "pay-off". User value is often used but it is not easy to quantify (and often isn't), secondly user value is often considered for different personas and user-groups.

There are some techniques which can help: Prioritization matrices

I would recommend getting more data for each proposed change. An interesting option here is getting user feedback through different channels, for instance spectrum.chat or through interviews, testing, chat-logs or through tools such as hotjar.

Try to document why the feature was requested, why the user needs it, how much work it is, if it affects other parts and if it adds complexity that has to be maintained. Then define user value for different personas and user-groups. Lastly compare the request with other planned features and discuss user value using prioritisation matrices.

1

Not really a usability question, but I think you need to define it internally.

It is not necessarily as black and white as 25%, it could be a "how long will the implementation take vs how big is the impact."

If it is a new button that is a shortcut to something, it might take an hour to make, then maybe it doesn't need to impact more that 1%. But if it takes 3 weeks to implement, then you need a bigger impact percentage.

I wouyld say it needs to be evaluated per change request.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.