What is a Product Owner?
When people ask what I do for work and I tell them I work for an IoT software consulting company they typically say “Ah, so you’re a developer?” When I respond with, “No, I’m a Product Owner”, I usually get a blank stare. I find it’s a role that is not well understood outside of teams that work closely with a Product Owner (PO).
In short, a PO helps answer the question: what are we building and why?
Agile Development
At SpinDance we use agile development to run our projects. Agile development is built on a short-term iterative process, this is what really powers agile development and what makes it agile. By planning and delivering a testable increment (ideally working software) every two weeks, testing and feedback can happen quickly, even before features are fully complete. This allows the team to incorporate feedback or changes in priority really quickly and at much lower cost than if it came later in the project.
A Product Owner’s Role
The role of a Product Owner in Agile development could be a huge list, but it can be condensed down to a few key responsibilities.
- Decision Maker
- Historian/Futurist
- Communicator
Decision Making
A foundational principle of agile development is that of a self-organizing development team. Part of being able to self-organize is to embed decision making capacity very close to the team. This is fundamentally where the PO comes in. It gives the team very fast access to someone who can make decisions about priority and tradeoffs associated with design ro development decisions. If the development team had to engage all the stakeholders on every decision, they would never get anything built.
In agile development product decisions are made and tracked in the backlog. The PO is primarily responsible for building and maintaining a prioritized backlog of features (user stories), this drives the work of the development team and ultimately shapes what is delivered. This means working with the stakeholders to determine the priority and requirements of all necessary features. User stories represent features or actions a user may want. A fully defined user story includes acceptance criteria and a definition of done.
Historian/Futurist
It is critical that during a product development a context is always maintained, this often falls largely on the Product Owner. We almost never have a consistent set of developers on a project from start to finish. Depending on the timing and interdependence of the different development work streams or domains the teams are often changing, adding and removing developers to keep the right skill sets in place while keeping the team lean. Therefore, there is a need to maintain a history for the project. Some of this is captured in the backlog and some in documentation but some of it is held in the minds of the team. Being able to speak to why things were done (or not done) at a particular time or in a particular easy way is incredibly valuable and saves the future team from repeating mistakes.
Equally important, someone needs to keep the future vision in mind as the details of the present features are built and tested. Sometimes a future feature or requirement may impact how we choose to implement a current feature. Working through these decisions and tradeoffs is critical work and our POs work closely with the client to do it.
In our version of agile development, we also task a Lead Engineer with helping maintain the past and future context on a project. We have found that having a Lead Engineer and Product Owner partnering in this way really raise the bar on our ability to build a context for a project as development proceeds.
Communicator
It is critical in agile development that everyone on the project team stays aligned and a big part of a PO’s role is ensuring that communication is flowing. The Scrum process helps drive a lot of this. A PO owns the backlog grooming, sprint planning, and sprint review/demo ceremonies. These standard meetings help ensure that the team is communicating regularly about the product features, priority, requirements, and completed work.
At times there is almost a bit of storytelling that is required, not to try and obfuscate the challenges of the project, but rather to get a diverse set of developers, designers, engineers, stakeholders, and users to all understand the vision for a product and contribute effectively together. This is continual work as there is an ever changing, typically growing, group of people around the product as the development process plays out.
Consultant as Product Owner
At SpinDance we are in a unique position because we are consultants and partners with our clients and don’t actually own the product being developed in the long term. In a product company a Product Owner typically has final say on what is built, and the accompanying incentives and accountability. However, this is not as much the case as a consultant, we serve our clients but don’t truly own the product long term.
We work with a large spectrum of clients some of whom have been leaders in software development for decades while others are just starting down the software development path. We tailor our Product Owner role depending on the clients need. Some client teams we work with have the expertise and bandwidth to support the PO role on the project we are engaged on, in which case we can really fill a supporting PO role meaning we support the PO on the client team as they interface with our team. This reduces team overhead while maintaining consistency for our teams of developers. In other situations, the client team may not have the skillsets or capacity to fill the PO role in which case SpinDance will staff that role on the team and engage directly with the primary stakeholders on the client side.
Value of the role
Anytime you add non-developer hours, or overhead, to a project team a fair question to ask is “what value am I getting from this investment”. In the case of a PO it really comes down to speed and risk avoidance. A good PO can help clarify the vision for the product and create a plan (backlog) to get the team there. Being able to clearly define an MVP for example is highly valuable. If you can get to MVP (x) months sooner not only does that reduce the initial investment but it gets your product into the hands of users faster. This brings learning forward which brings revenue forward. This is really critical when timing or budget are real constraints, by ensuring the team is highly focused on the right things first a huge amount of cost and risk can be avoided.
One of the core principles in agile development is consistently embracing change and working to improve not only the product being delivered but also the process by which it is developed. To that end we are continually refining how our Product Owners engage with our teams and clients.
Do you have questions or want the guidance of an IoT expert? We can help. Contact us
About the Author
Daniel Luyk is a Product Owner at SpinDance with over 13 years engineering experience in manufacturing processes, design engineering and program development. He holds a degree in Civil and Environmental Engineering from Calvin University. As Product Owner, he consults and partners with our clients to ensure their products are fully integrated, contextual, and highly successful.