As a Product Owner you can get overwhelmed by all the requests coming from different directions, all being urgent and super important.
I cannot help you in an ultimate way how to handle this situation, but I can give some advice what worked in my former and current places.
Follow the strategy
If you did everything right, you have all the guiding principles from the Product Management Onion. You should have a company vision and mission statement, followed by the strategy. You should have your own products’ vision and mission, product strategy. You should have a roadmap, a Product Goal. You should know the target group and the main problems you aim to fix. The purpose of all of these is to provide coherence and help you decide what to focus on and when to say no. If you are doing right, these provide a well targeted unified product which will naturally drive how to prioritise.
Although there can be still a lot of important independent requests from all your big and important customers, all being urgent and super important. So here follows a few examples for those.
Don’t ask “is it needed?”, ask “which one” instead
In my experience, people tend to think of their (or their customer’s) request in separation. The way they think is “do we need to do it or not?”. But if you have an overview of the Product Backlog, you know that it is probably filled with stuff you need to do. No one argues that they are useful. It can help if you explain “We have 100 things in the backlog, all useful. In every Sprint we can implement 3 of them. If you would have to chose which 3 we start with, which ones would you chose?”
Also if you have planned something and a new request comes up, someone pushing it, you should ask them “we should do it instead of which one?”. They often realise that doing the new thing would hurt another, more important goal.
Ask the right questions
If someone approaches you with a request, ask specific questions. Avoid questions where the answer is based on opinion or subjective experience. Some of my examples:
- Is it your idea, or does it come from a customer? If a customer, who and when? Can you send me their written request or meeting notes?
- What happens if we don’t do it? – this is my favourite. Often customers ask for a feature and it makes support/sales frustrated. But then it often turns out it’s just an idea and they will continue their licences even if they don’t get it. We usually concentrate on the benefits of doing something, but it can give a lot of insights if you turn the question around.
- When will it happen? – “what is the deadline” is not specific enough, because they will say “as soon as possible” or “by yesterday”. Instead refer to the previous question, and The Terrible Thing which happens if we don’t do it. Ask the theoretical question: if we never do it, when will The Terrible Thing happen? When will the customer cancel the contract? When will we lose a deal? When will the competition cut in front of us? Etc.
- How does it fit to our strategy / goals / roadmap / values / principles? – it’s a common mistake at small companies that an overall goal, direction, strategy is missing or not talked about enough. You should have your high- and mid-level guiding principles and – while you always have to do ad-hoc stuff – prioritise those which help you to go forward on that journey.
Lean on facts
Something being important or urgent is subjective. If different sales people work with different customers, it can highly depend on their personality how much they push the requests or how they interpret the things they hear from the customer.
Instead, talk about hard facts with them. With one of my teams I introduced this categorisation:
- Required by law – lawful obligation or data security breach, no question we have to do this
- Churn threat – if we don’t do this, a client will leave us (makes sense in B2B companies)
- Direct business value – if we do it, someone will directly pay for it
- Indirect business value – if we do it, it opens up new markets, or enables us to do something with direct business value
- Popular request – requested as a pattern by many customers, and comes back from time to time
- Request – single request from a customer (again, B2B, not end-user). Can be more customers, but you cannot say it’s a pattern or popular. Requester can be internal, like saving significant amount of time of someone at your company.
- Internal idea – an idea coming from inside your company which would make the system better
This can help you to decide which ones to start with. For example customer-facing employees can be really stressed if they constantly have to deal with upset people because of a missing feature. But if no one has ever left you because of a missing feature, and you will not get new customers because of making it, it might still worth to develop something else, which does and leave the frustrating issue to later.
Some principles which are good to follow:
- Don’t make it to an algorithm – these are roughly in a decreasing priority order, but this should not be a definitive process, only input for the discussion. You still need to use your common sense, but it’s much easier if you answer those questions.
- Only documented data matters – if one of the sales people is really convinced that a customer will end contract if you don’t deliver a feature, it is still maximum a Request until there is written proof from them saying they will do. Or a developer can be really convinced, supported with examples that we need to do a feature, it is just an opinion of one person until we get real customer feedback about it.
- Be as specific as you can – if something is a customer request, list all customers by name who requested it. Attach emails if possible. If someone is willing to pay for something, how much and when? How do you prove it? If they threaten to leave us, when does it happen if we never do it? Never accept “lot of our customers are asking for it” as a list or “yesterday” and “as soon as possible” as deadlines.
- Don’t make these sound as importance – I made a mistake to call Required by law as No brainer in the beginning. Turned out people started to categorise things as no brainers, because they tough it was important. The point here: this is not prifority, this is categorisation based on objective facts. Naming and eventual icons/colours should not suggest an order or priority between these categories.
Summary
You should have high level principles to guide your product development, like a strategic goal, Product Goal, some product vision and identity, target audience, yearly goal, etc. But often you need to deal with a lot of independent requests. You should always prioritise based on the exact situation, but there are things which can give you invaluable input on thinking, and these always have to depend on objective data. I cannot give you the definitive tool for that, but asking the right questions, capturing the right facts and categorise your stories can help a lot and change the way you think about what’s important.