Tips and Tricks for the beginner Product Owner
Embrace failing fast!
Product Owner @riskmanagement
Most people are afraid to fail. Shame is at the core of the fear of failure, psychologists say (see Dr. Brené Brown @TED). The problem with fearing failure, though, is that it does nothing but help you fail.
In our western culture, shame is a driver to get others to do things. By using shame and guilt as tools, we do not only burden us with an emotional baggage that is wearing us down emotionally, but we also create a lot of dysfunctions as we hide mistakes in order not to be blamed.
Transparency and courage are values shared by most of the agile approaches, Scrum in particular, the opposite of shame and guilt. We can choose to try to live our lives on our own terms: either by trying, failing and learning or by remaining in the swamp of shame and guilt and not improving. When you feel guilty and ashamed, you behave accordingly. Your mind will keep thinking about what happened and will not allow you to change anything as this would mean acceptance of the failure.
If all went well the first time we tried, we would never ever get any better. As we strive for perfection, we should embrace failures as they give us the chance to grow. Inspection and adaptation require reflection on things that could have gone better. From my experience, once people accept that they basically constantly „fail“ in the way of retrospectively not having chosen the best approach for what they wanted to achieve, they harness the incredible power of creativity and courage and gain the intrinsic motivation to do better at every future step (see Drive).
Shame is a tricky concept and a very useless one too. It has been rooted deeply in our society for maybe longer than a millennium, and that is by far too long a time. As eastern (buddhist and hindi) cultures show us, there is no need for that concept. So stop seeing yourself as a bad person because you did something wrong. Consider yourself lucky that you were given the opportunity to change your future behavior.
So accept that you could have done better, every second of your life, If you had had your current knowledge. You did the best you could, and given the situation at hand, that‘s all you could have done anyway. Wouldn’t it be awesome if we recognized a few of these „failure moments“? Wouldn’t they be an evidence that we have learned something and we can harness the power of learning to improve?
Throwing the concept of guilt and shame overboard is the first step in the direction of good agile risk management. We know that all of us could have done better constantly. So after we accept that fact, we can think about ways to make the biggest mistakes transparent.
So why should we embrace to fail fast? When diving into a new project, I am often confronted with a situation where the management fixed the time and release date, the scope of what should be released and also the quality in terms of SLAs. The first question that I ask under such conditions is: „When do you want to know how badly you are going to fail?“
While the question might be a bit confrontational, the discussion thereafter is awakening most of the time. If the „iron triangle“ (scope, time and quality) is fixed, than it is better to know as fast as possible if the plan is off or not, so that we can react and soften the damage.
As a manager, the worst thing that can happen are surprises for which expectations management is key. Agile methods are the best tool I know to get the most trustable and fast results. Worse than having bad results is having bad results late.
From my practice as a Product Owner, you need a tool to manage releases, not only Sprints. So what I do is to set up a release map and give the developers some overview about the planned high level requirements. In return, I ask them to give me a rough relative estimation about the effort of each of those requirements. Once the first requirements get broken down to little pieces, and the little pieces get estimated, I start knowing more and can do recalculations. With every completed Sprint, I gain knowledge about the progress and even in very large projects, it does not take long to get a good idea about: when it will be finished, or if we need to tighten the scope. This helps significantly when dealing with multiple stakeholders. Particularly, conversations tend to get way more concrete when I am approached to enlarge the scope. It is easier and faster to forecast the impact of any given change.
So embrace failing fast and don’t fear to be ashamed! Every failure is a new learning opportunity if you accept it as such. Once it is there, you cannot change it anyway, but you have the chance to make the best out of it—learn something from it.