Choosing Change.

Something I find particularly difficult to deal with sometimes is how to handle all the suggestions, ideas and requests we receive from our end users. I am not talking about feedback regarding functionality that we are currently working on and where we specifically asked for feedback and user input. I am talking about all of those little things that users would really really like us to change or add to the application – particularly those that may not necessarily be a good idea.

Of course, users always have a specific reason in mind why they want the system to do something. However, not always are these requests really born from necessity. Especially in our case, where our application is replacing another system that many of our users have been working with for years, in some cases even decades. It’s no surprise really, that a not-insignificant number of enhancement requests could be simplified into one user story:

“As an experienced user, I want the system to handle this process the way my old system did, so that I do not need to change.”

Like I said, nobody is at all surprised that we receive requests like that, however somehow we haven’t yet figured out the best way to deal with them. Yes, we do have an extensive team of trainers, support staff and even a specific change management department, but requests such as these seem to bypass those teams entirely and in the end, tend to end up as enhancement requests in our product backlog.

For us product owners, this makes the process of prioritizing and grooming the backlog that much more difficult, because not only do we need to evaluate, prioritize and write user stories for all the very valid and great suggestions we receive from our users, we now also need to figure out what to do with the undesirable ones, who frankly just clog up our queue.

I do believe that the product team is responsible for choosing change – but we are probably not the right team to manage its undesirable cousins and the users who request them…

Better late than Never.

I’ll admit it, I was so busy and stuck in getting some system testing done, I completely forgot it was Tuesday and therefore “blog-day”. Shame on me!

So, this post is a little late, but nonetheless I hope you find it interesting:

Are we solving the right problem? by Mike Cottmeyer

Don’t Get Emotional.

One of my least favorite tasks as a product owner is having to prioritize the backlog and stack rank stories to make sure we develop the right things at the right time. In principle, I don’t have a problem prioritizing items, what I do find rather frustrating is how emotional and subjective prioritization often is.

I myself am a huge fan of logic and formulas and empirical research (geek alert!) to reach a conclusion as to which items are important, rather than just going with my gut. Having said that, sometimes it is necessary to go above and beyond what the data says, because there is a specific item that triggers a lot of emotion – negative or positive – from the overall user community, that warrants an increased priority.

On my project, we have a lot of those very vocal, very passionate users, that are sometimes rather difficult to temporarily drown out, so the product team can objectively assess and prioritize enhancements to our application. Furthermore, a lot of us product owners, myself included, have worked in the field as a user at one point in our careers and therefore still have some emotional ties to what is was like being a user. On top of that, we have spent a lot of time and effort to foster a culture of actively soliciting user feedback and enhancements requests, which makes it very difficult and rather uncomfortable to say no to requests, even though sometimes we probably should.

With all of this emotional baggage, a product owner’s judgement can easily be clouded – not deliberately, but subconsciously. Even more reason to develop a clear-cut, fact-based system to rank and prioritize stories and features based on their attributes. But which attributes are the right ones to look at? Do they all carry the same importance? Do we rank technology over user experience or vice versa? If the system crashes, because we overload it with data and logic, that is obviously very bad. But at the same time, we also cannot ignore the user emotions and aggravations. Instead, we need to find a way to quantify the user reactions to be able to compare and contrast them other measurable aspects of the product. Only then can we determine whether a screaming user is just having a bad day or it is a clear indication that something is very very wrong…

I don’t have all the answers yet, but one thing I am certain of: if you want to improve the prioritization of your backlog, be objective and don’t get emotional!