Effectiveness is the goal, efficiency will only get you part of the way! As a Product Owner, how do I ensure the success of a team? During my journey as a Product Owner for many teams. I have battled the dilemma of focussing on increasing output (efficiency) or outcome (effectiveness). Here is my story…
Efficient Teams
In the early days of my product management career, I began as a Product Owner in the Engineering department. Prior to my first assignment, I was the Scrum Master for the same team and had to coach and improve the team's performance.
I had the luxury of starting with a clean slate. I learned all the theories of backlog management, user stories, and refinement. My experience in Software Development helped me create an efficient team. The skills I gained helped me improve the performance of 8 teams. I will give a brief description of some of the best practices as a Product Owner.
Backlog Management — Keep the backlog as clean as it needs to be.
- Define the length of your backlog. Ask how often priorities change? What is the release cadence?
- Close any stale stories that are older than the length of your backlog. If it is important, then someone will reopen it or will request it again. Don’t do this with bugs since you would like to know all the bugs in the system.
- Group any tickets into categories. I use Bugs, Tech Debt, Improvements, and Epics. They become easier to filter, manage, etc.
- When planning a sprint you can use the categories to help create a great iteration. For example, for each sprint I would plan 2 bugs, 2 improvements, focus on the top priority feature, and give the team a day per sprint on their tech debt.
User Stories — Clear stories or tasks teams can deliver.
- 3 Cs for user stories. Card, Conversation, Confirmation to keep the story short, create conversations to discuss the solutions, and a definition of when it is truly done.
- Use of templates to keep issues consistent across the backlog. For example, As a …, In order to …, I want … for user stories or for bugs 1. Steps to Reproduce: 2. Actual Result: 3. Expected Result:
- Use of INVEST to ensure smooth delivery of stories. Independent stories, where the specifications are Negotiable, that brings Value, that can be Estimated, Small, and be Tested. This improves the flow of stories across your sprint/kanban board.
Refinement — Reduce surprises and time need to understand the feature.
For every story a team should have discussed it three times before they begin working on it:
- Kick-Off your features. This is the chance to introduce a new feature, show a prototype, begin Q&A of what you want to achieve.
- Estimations and Story Splitting. Ensure teams can estimate stories and split until they are small enough. Split by Persona, Workflow, Simple/Complex, Experiment/Real, Acceptance Criteria, etc.
- Explore the happy paths and unhappy paths. This is really getting to your test criteria. Many teams underestimate stories because we never discuss what can go wrong.
When I follow all these practices I immediately see an improvement in how much is delivered. However, this is all focussed on Output.
Effective Teams
After a couple of years in a more tactical role, I had the pleasure to work with great Product Managers with a lot of experience working on market-leading products. My biggest realization is that being efficient is not enough to be successful. If we look at the delivery of software as a water pipeline, I helped teams improve the capacity and the flow of the water to our customers. What if that pipeline contains sewage? Then I have the potential to kill a product quickly.
I had to evolve from a tactical Product Owner into a product leader. Someone who understands the market, product, and customers and can be the “Scale of Justice” and make decisions based on the information you have at that moment. To make a team effective I followed 3 rules:
- Ask why?
- Provide Context.
- Be Strategical!
Ask Why?
I first became aware of the secret weapon for Product Management when I was 5. Every child is naturally inquisitive and is slowly learning how the world works. As a Product Manager, I am the child and everyone else is the world we are trying to understand. The people we interview are like our parents, the answer they provide may not make sense, so I continue to ask why until I truly understand the root cause of their problems or the needs of our customers. This will help me become an expert on the problem.
What is a sign that we haven’t asked why enough times? List all the use cases for a specific problem/solution a team will deliver if the list is endless then we have not asked why enough. For each use case, keep asking why (to the users) until you find a root cause. You may be surprised that what they asked for is what they want not what they need. Also, you may realize that many of the use cases in fact come from the root cause use case.
Provide Context
Understanding the problem is a start. However, if you are delivering a single user story that is an increment of a feature, will your team understand the whole context of the feature? I have partnered with some smart people who are experts in UX. Combining techniques from Product Management and User Experience you can help to provide enough context for a development team to deliver seamlessly.
- A problem definition
- Personas for the Product
- User Journey of your Personas with experience
- User Interviews to support the problem
- Prototype/Designs with user validations
- Business Goal/Scope/Key Use Cases/High-Level Requirements
To be successful here, it is best to be open and be transparent. Keeping knowledge is power, but sharing this knowledge within your company will give power to the development team. In addition, you are helping all departments such as Engineering, UX, Product Marketing, Support, Sales, etc.
Be Strategical!
The final step to becoming effective is to start to think strategically. At the beginning of my journey, I focussed on the day to day tasks and in the delivery of user stories. When I join a company, I will always seek the business strategy, product vision, product strategy, how each opportunity we pursue will help the business, why, and how a feature will help our customers and also the challenges we face as a product company. This is in fact my toughest challenge because I came from a technical background. Three key points to learn about when becoming more strategical:
Scale the Product Owner Role
Now the real dilemma! I have worked in both a split PO/PM role and as a “Full Stack” Product Owner. How do I deal with Output vs. Outcome?
The issue with PM/PO is:
- As a PO, I had no context, I didn’t know why the priorities are set. I had no authority to change priorities if the development teams had concerns. I became a messenger. I could only focus on efficiency.
- As a PM, I couldn’t motivate a team to solve problems. I was too far from the team to influence the execution of the features. I was also an outsider to the team. I could be effective, but the PO can lose the context in translation.
In a “Full Stack” Product Owner/Product Manager role I saw the following advantages:
- I saw ideas become reality at close proximity.
- I was a part of the team when discovering and executing product opportunities.
- I had the influencing power to build features that are needed and make adjustments with early feedback.
The only issue was the balance of output and outcome. How can we ensure success as a Product Owner? I have come to realize that I am no longer a Product Owner as described in Scrum, I have in fact evolved into a Product Manager. Also, I believe that Product Ownership is a responsibility that is shared by my team. I do this by:
- Being accountable for the context and outcome of the development team. We strive for great products or to quickly detect when we fail.
- Delegate to the experts. I consider my team as a cross-functional team made of developers, QA, UX, and myself. I rely on each discipline to bring something to the table when understanding the problem, discovering a solution, and building the solution.
- Empowerment of Product Ownership responsibilities to the team. Teach the team how Product Ownership works. Empower team members to manage their backlog. Executing a product backlog becomes a responsibility of the team with the Product Manager driving the team and looking ahead to create a successful team.
