For most organisations, providing an engaging, and user-first online experience isn’t a nice-to-have, it’s essential. Understanding the service you provide, and understanding how to make that a good experience online, are not the same thing. That’s what a Digital Product Owner is for. Keep in mind the way this role works can vary massively from organisation to organisation depending on team make up and Agile maturity of the organisation.
In some organisations, a digital product owner might have a close-equivalent, these can be called digital delivery leads, technical product owner, digital product managers, product owners or something else. If an organisation isn’t digitally-native, there might be non-digital product owners and product managers too. The core responsibility of this woman or man is to own the online experience of your organisation, or a slice of it.
As a digital product owner, I work at all layers of the software development lifecycle.
At the first stage of the lifecycle my job is to understand the true business problem we’re trying to fix. I do this using Design Thinking and Human Centred Design. The basic principle of HCD is proactively and intentionally understanding how the people experiencing this problem behave and act in real-life. Leading a team to develop something that works for them and you is easy. But chances are, that’s not who you’re building for. There are toolkits full of frameworks which can be used at this stage but some of my favourites are opportunity canvases paired with assumption mapping and a whole lot of 5 Whys.
Now we understand the problem, we can start high-level epic planning and story-mapping. This is where we break down the solution into user experiences, technical features needed to deliver that experience, and technical tasks needed to build that technical feature.
Development takes more time and money to complete than many organisations realise. So the next step is applying the Lean Startup MVP thinking to find “the smallest thing you can build that lets you quickly make it around the build/measure/learn loop”. This is usually done using some form of desirability, feasibility and viability matrix. Ie. is this something our users want enough for us to justify prioritising it over other things they want? (Desirability). Is it technically doable? (Feasability). And is it financially smart, ie. is there a return on the investment we’re making by building this? (Viability).
From here we need to define requirements for the technical tasks stemming from those user stories. This means stakeholder engagement, and working with the developers to write stories and acceptance criteria that make sense to them.
1. Digital Product Owners know how to resource the mahi
Depending on how complicated and deep the tech-stack is, it can be a job itself just finding those people and creating opportunities for them to do the work needed. The more moving parts to a solution, the more opportunities there are for something to go wrong. In that sense, a Digital Product Owner can often be working in a similar way to a Project Manger.
A digital product owner doesn’t need to know how each of those layers of the stack work, but they should know who and how to ask.
A good digital product owner should have a kete of soft-skills which make this very human side of software development able to worked through.
2. Digital Product Owners understand user behaviour
One of my product mentors once told me the secret power of a Digital Product Owner is their deep and true understanding of how customers interact with their product online. If I have nothing else when it comes to a new piece of work, that’s where I’ll start. Development is expensive and it’s not only a waste of time building something that isn’t going to be used, it’s a waste of money.
Understanding those customers and having the insights on hand is not where the responsibility of a Digital Product Owner ends. It’s up to us to share that understanding and insight with the business, or the owners of the problem. Depending on the set up of your organisation, this might actually be the Digital Product Owner, but for most of my work, there’s been a business owner who has ultimate accountability and responsibility for the product itself. It’s my job to work with them to ensure the online experience delivers on the overall goals of the product.
Customer research and persona building are fun and important foundational building blocks of understanding our customers. There are dozens of frameworks and approaches to this, from guerrilla testing, A/B testing, user workshops, focus groups, online surveys, to process maps and analytics, different workplaces and problems/opportunities call for different tools.
3. Digital Product Owners are the touchpoint for stakeholders at all levels
In my experience, if you’ve identified and understood the right problem to be solved, or opportunity to be addressed, you’re building the right thing, and every level of the business is going to be interested and invested in your progress. This means Digital Product Owner stakeholder engagement goes across every layer of the business. So adaptive communication skills are a must.
Digital product ownership means communicating with the business to refine what they need, keeping them informed around progress, and leading conversations about evidence-based prioritisation. It means communicating with the development team they work within to refine technical stories, articulate the vision and lead the day-to-day development team rituals and practices.
Example of team feedback loop
4. Digital Product Owners help keep the development team focused and fed
In an organisation where digitalisation is the goal, developers and development teams can become pawns in management’s fight for resource. Digital Product Owners keep the noise away from the teams, so they can focus on what has been agreed to as priority.
From stand-up to end-of-day, a Digital Product Owner is responsible for making sure the development has the right work to focus on, and has the mental capacity to focus on that work, and the psychological safety to speak up when that’s not true.
While the process of managing workflow looks different depending on what tools are used, the intent is always the same: Clarity, capability, and motivation.
Clarity: the team should know what they need to work on (ie. the backlog is regularly groomed and up to date. If sprint planning is done using evidence based capacity planning (ie. we know roughly how much work we can pull in this sprint, and that work is all there ready to go, this should be true.
Capabilty: the team should have the ability to do the work that needs to be done. If they don’t, and you can’t build capability in the team to do so, eg. there are no Android developers in the team, and nobody is going to learn how to do that within a sprint, then that user story should be outsourced.
Motivation: the team should understand the vision, mission, and sprint goal, and be motivated to make their contribution towards those outcomes.
I’m lucky to have had a long career in leadership so am able to apply these learnings and disciplines to my work as a Digital Product Owner.
In terms of tools, I’ve used JIRA for years as well as Trello and GitHub. They all have advantages and disadvantages depending on the environment they’re being used within. These tools are used to track the progress of the team towards the next roadmap goal. It’s not about keeping to a deadline, because estimating how long new-arena development is going to take is similar to estimating how long it will take to answer a 100 question maths quiz. The cone of uncertainty starts very wide!
Keeping track of the day-to-day user story progress, refining the technical requirements needed, while still moving the team towards a longer horizon vision or roadmap is a skill unto itself.
5. Digital Product Owners measure team outcomes
It’s a very complicated process to bring something to life from ideation to delivery. OKRs or objectives and key results are one way of tracking progress towards that outcome. A Digital Product Owner is accountable for leading the setting of team OKRs, though this should be done as a collective with the team playing an equally important part as the Digital Product Owner. The Digital Product Owner is accountable for the team meeting those OKRs, but should also create a culture where the team as a collective takes that accountability on.