For this blog post I’d like to make a change from my usual style and share a personal experience.
For the last few months I have taken on the role of Product Owner for a new product our company is developing. It is a bit of a change for the company as they have limited experience in developing their own products, most of the work is typically implementing work on behalf of clients where much of the product development is obfuscated from us.
It is also a big change for me. I have been coaching Product Ownership for a fairly long time now. I previously lead the company’s Product Ownership Chapter and I run a local Product Ownership Meet-Up event each month and I frequently teach Product Ownership and Story Writing workshops.
You might say I am becoming an expert in the theory of Product Ownership. So I could be forgiven for thinking I would find it easy. It is also not my first rodeo, I have been a Product Owner of sorts previously for both hardware and software products .
Before you criticize someone, walk a mile in their shoes. That way, you’ll be a mile from them, and you’ll have their shoes.
Jack Handey
It’ll be easy he said…
Maybe it is because I have been coaching for quite a while now, but the transition back has been far harder than I expected. I am (too) impatient to see progress, I am finding it irritating to write stories for things that I find obvious or repetitive. I found myself tempted to make unilateral decisions rather than involve the team; I wanted to get involved in technical decisions; initially I hadn’t made time to create personas; I was using expediency as a very poor excuse for not doing activities that I believe add value. (all things I used to coach against). In short I am a bad bad man, and a hypocrite too.
We did however create a pretty good Story Map and Road Map, the team got together with some subject matter experts and over a few good discussion and we developed a pretty good understanding of our road-map and high level priorities, still at a high level but with enough understanding to make prioritization decisions. We have got in the habit of writing enough stories for the next week or two and there are a good set of wireframes to enable us to start getting feedback on our designs before we commit to the code. We have found a great balance between getting knowledge value, and then delivering working value.
As the product has progressed we have maintained the Road Map turned it into a living user story map and used it for forecasting and release projections and planning, such a simple tool but so effective for enhancing communication. It’s simplicity served us well, communication became very easy internally and externally, and when when we needed to the forecast was very straight forward – and informative.
Delivery Pipeline
The aspect I am most pleased with is that one of our first priorities was setting up a delivery pipeline alongside the first stories so now every commit we are able to deploy directly to an environment reflective of our customer (no mocks) and a releasable package is created after every check-in. I cannot understate the significance of this and how this one decision has made almost every other aspect of the delivery process easier.
There are certainly things we could be doing better, but overall I am very pleased with what we have done and I am really impressed with the team, they are an exceptional team that makes my job easy. But most of all I feel I have a much better appreciation for some of the issues that Product Owners are facing and I am reminded what a challenging and important role it is in shaping a product, conversely my hope is that I have made the team’s job easier, being on hand to clarify my understanding of customer needs, making design decisions promptly and making clear the priorities. The joy of being part of a team is that we each contribute something vital to the success and we only succeed together.
I have worked to get and interpret valuable feedback from customers and stakeholders, and as ever this is a challenging task. It would be easy to pass on every request and turn it in to a story, but this is OUR product and our role is to interpret requests in the context of our vision, and the reality is that we reject more suggestions than we adopt, every person you ask has a different and often conflicting opinion of what is needed and that filtering process is challenging and daunting, I hope I have shielded the team from the frustrations that entails. But for product owners out there this filtering is one of the hardest but most important parts of the role.
Challenges
The role itself is paradoxical at times, some days it feels like there is little to do, but everyone else is busy, other days you are making decisions that will determine whether the product will be a success or not.
Early on in the process it was hard to convey credibility, I am no SME in the domain and our teams are not used to decisions being made in-house, my vision was questioned, it took a lot of will to maintain my course and build trust, I had a rocky couple of months. I controversially chose to go against some of the key stakeholders and not implement some features they wanted, I was vindicated later, but I knew this was a risk and could easily have gone the other way.
This is the hardest aspect of the job especially when you want this to be a team activity and for the team to share responsibility and credit, but the reality is that the role of the PO is to get feedback from the stakeholders and the team, and then make a decision, that decision can be lonely as there is a lot of subjectivity and rarely a consensus.
Product development is very different to project delivery it is much more fluid and we have evolved a lot over the last 6 months the product has grown and improved and now we have two releases under our belt and a happy customer it is an exciting time for us.
DevOps
I cannot overstate how happy I am with the team or how successful I feel this has gone, I feel like a minor player in such a great team – which I hope is reflective of how well we have worked together and that it means I played my role effectively – although I am pretty sure I was the bottleneck more often than I would have liked.
I will say that we got lucky with the first customer and the support of stakeholders and the team have made it very easy for me. But the one thing that has made this most successful in my mind was the decision to deploy the very first story to a production like environment – that one decision set the stage for a smooth progression and confidence with every subsequent story. I’d encourage that to be the first decision any new team makes.
I was doing a demo the other day and as I was presenting I am thinking (with a disappointing amount of surprise) “Wow – what an amazing product this is” it looks as good as any product out there. Somehow being involved in the process meant I didn’t take the time to sit back and see what we had achieved until that moment.
This is only the first major release and we have many more to come as the product evolves and customer numbers grow. Naturally there are still a few quirks to iron out.
It is my hope that I have learned a lot from this project and be able to use the experience to be a better coach, I’ll be more able to empathize and advise with Product Owners and perhaps be more confident that when challenged I can still apply some of that theory and speak with confidence when I am coaching others.
I hope you will forgive the obvious pride at being part of this team, but aside from that it has served as a reminder to me how difficult being a Product Owner is and how much software is a team sport and the whole team should take pride in the outcome, without any one of us it would not have been successful.
John Yorke 