I was recently asked what to do when a stakeholder or client asks for a feature or user story that either doesn’t make sense or is based on flawed logic or on a lack of technology or domain knowledge. Sometimes stakeholders’ pet projects, wacky ideas and whims and fancies can be the nemesis of a product owner and her team. They waste valuable time and resources and in some cases they can affect team morale, as the team feels that they are on a fruitless errand.
I have two solutions to this problem: Nip it in the bud or meet them halfway.
Sometimes the best defense is a strong defense.
Yes, I wrote it that way intentionally. You can avoid some suggestions before they take root by preparing your defence in advance with clear short term goals. When someone proposes a feature or user story, bring their suggestion up in the next workshop and ask how it supports or fits that goal. If it doesn’t fit, it gets put it on the backlog under “not now.”
If your team is currently focused on delivering new features, I recommend posting or publishing a user story map that shows the stories and their priority. Jeff Patton’s book
on the subject should be required reading for any product owner. It’s vital that the team and stakeholders organize the user stories into Minimal Viable Product Experiment (or the walking skeleton as some refer to it
), Minimal Viable Product, and “Wows,” or a similar priority scheme. This provides a good starting point for a conversation about the suggestion and where it fits in the vision.
If your team isn’t focused on new features, I recommend doing impact mapping on a regular basis. Gojko Adzic has written a lot on the practice
. In a nutshell, you work with your team and stakeholders to identify a small number of behaviours or business areas that you want to impact and make these your Sprint or Release goals. Keep your goals measurable and achievable, like “reduce the number of people who drop out of registration by 30%” or “increase profit margin on bulk advertising sales.” And most importantly, involve your stakeholders in defining those goals. All user stories are then prioritized based on those goals.
If defining clear goals doesn’t deflect the idea, my second strategy is to attempt to kill it with metrics. I look for a way to break the idea into pieces, and the first piece will be something as simple as possible we can do to investigate the “potential” of the opportunity. We could create a link that simply tracks how many people click on it, or we could create a dummy version of the interface changes and have internal people test it. Online usability testing services can avoid a lot of bad suggestions.
The second piece to this strategy is to define how we’ll evaluate whether the suggestion is having the expected results, both the suggester’s expectations and my own perhaps less optimistic ones. This may not prevent the bad suggestion from happening, but it may provide you with a reason to reverse a well-meaning change that had the opposite of the intended effect.
One last word: remember that being a product owner requires having an open mind. Sometimes the crazy ideas actually work. For example, how many of us thought 10 years ago that we would all be publicly posting videos of our cats? Listen closely, ask questions, and try to understand the suggester’s enthusiasm. Sometimes the hardest job of the product owner is to sell a good idea to a skeptical team…