Mistakes are inevitable. As a product owner, you need to be decisive and use all the knowledge and resources at your disposal. In the end though, you sometimes need to just be a daredevil and make decisions with incomplete information so the team can build something. With that comes a 100% possibility that you will eventually decide on a course that is…less than ideal. This really is ok because the purpose of a sprint is to produce features of value but also to learn something, and you actually learn a lot from being wrong!
Let me give you a couple of examples…
Sometimes you will be right
In a recent project to produce a pretty cutting edge visual tool for portfolio analysis, I
took a chance on an idea where we would overlay different universes of securities that can help our investment group find new ideas for their portfolios. Prior to seeing this overlay idea, our stakeholders didn’t think they would be very interested in it (and sadly this led us to prioritize it to the end of the project). Once we gave them a demo, however, they lit up and as we summed up the new list of priorities (with the overlay now at the top) our key sponsor said, “You know when I walked in here today those were not my priorities, but now that I have seen it, yeah, I think this is the most important next step.” So I learned if you can demonstrate vision and correctly anticipate the needs of a user group, risks can pay off big. That project will now continue very fruitfully and may end up helping many more investment professionals as we expand it.
(Note: This is very different than simply building some new widget because it is possible — we married the possible with the desirable to find a really great idea. It is all about the users needs.)
I was proud to be a part of that effort but it doesn’t always go so well…
Sometimes you will be flat wrong
On another project about a year ago, I wrote a story for a system 
that tracks company earnings and changed the logic for how we calculate fiscal year ends. My decision ended up causing confusion with those entering the earnings numbers and ultimately we had to change the logic back to the original way. I made that decision with incomplete knowledge and the thing I learned was to make sure I always have an active, engaged stakeholder group on every agile project.
In the cases where I was wrong, I have had to deal with some user frustration, but I believe this is entirely worth it if the benefit is that I can make real decisions as a PO and keep the iterative process rolling. It also helps greatly to have the support of upper management as our company was historically averse to any significant level of risk.
Risk is part of the job
Taking a leap may result in a mistake and our job as product owners is to take that risk responsibly and learn from it so we hopefully make fewer mistakes as time goes on. Remember that these small mistakes are far better than completely blowing a project as is possible without iterative development. Review your work every two weeks with your stakeholders and developers, and figure out what’s good and what should change. The end result will be a better product.
Mitigate what you can
Of course being decisive and learning during each sprint can be augmented by good story prep, usability testing, direct observation of your users as they work, and interviewing those users (though this last one is likely less useful than the others).
One of the things I really enjoy about being a product owner is the ability to just try something. Often you don’t know if something will work until you see it, so don’t be afraid to explore those possibilities along with the stories that are more predictable. You might just add a hell of a lot of value.
As always, love to hear if you think this makes sense in your organization (or not) and what experiences you have had with being a daredevil (who, after all, was that blind superhero guy who did a lot of leaping).
Addendum: I was at the AgilePalooza conference today in Los Angeles and David Hussman was giving the keynote. He said many noteworthy things (checkout #agilepalooza on twitter for others’ thoughts), but the point that caught my attention was about Malcolm Gladwell’s book Blink (this is a really good read, btw). The main tenet of the book was that people usually make better decisions when they make a decision quickly rather than gather all available data, analyze, and THEN decide. This complements what I was saying in this post — I think you as a PO must always be trying to understand your stakeholders, your current technology and see emerging trends better but when it comes down to a single decision…just make a choice, it’ll probably be the right one. Either way, inspect, adapt, and move on.
explain…when we first started our transition to agile, our product owners were told they were supposed to write the stories, define the acceptance criteria, and prioritize that with stakeholders. Then they needed to communicate that to the team and continue explaining things as they worked through their development. But what about all the Business Systems Analysts (BSAs/BAs)? They used to do a lot of that (though perhaps in a bit less directive way).
