As an agency, we work with a lot of different types of clients across different sectors and business domains. It’s no secret that in most software projects there are unforeseen surprises and obstacles that teams need to navigate around during the lifetime of the project. The two most common problems I see in a project revolve around communication and the lack of a defined Product Owner.
So, why do we need a Product Owner in the first place and what are the responsibilities in such a role?
In a nutshell, a Product Owner is the person responsible for making sure that the team is building the right thing at the right time and maximizing the end value of the product for its stakeholders. They are the ones who are taking the requirements and objectives from the stakeholders, then communicating and prioritizing the work to the development team. A lot more goes into these responsibilities and day-to-day activities, but this gives us a starting point to recognize why it’s such a crucial role in every software project.
Here are a few of the most common Product Owner related issues that many development teams are experiencing.
#1 Not having a Product Owner
Without a Product Owner filling the gap between the stakeholders and the development team, essentially steering the wheel of the product, it becomes extremely difficult for the team to meet the expectations and deliver something that would be considered a successful product by all parties.
Every successful project has a Product Owner, whether defined or not. This just means that if the role is not well defined someone in the team is taking on those responsibilities and trying to sometimes guess what the expected outcome should be. In a worst case scenario the development team is forced to make judgement calls about business decisions, and about things they probably don’t have enough knowledge on.
In agency life it often happens that this responsibility is pushed to the agency (for numerous understandable reasons), and in order to finish the project on time and within the budget tough decisions about priorities and features just have to be made, but it will drastically lower the chances of building something great.
#2 Multiple people acting as a Product Owner
A Product Owner should always be one person; not a team, not a committee, not a tribe. Decisions will most often happen in larger groups, but the Product Owner should be the primary voice communicating with the team. When a Product Owner’s role or responsibilities are not clearly defined or known, team starts getting conflicting messages and requirements from multiple people. Which in worst case scenarios can derail the development from its course, or at least create confusion within the team.
#3 Product Owner not available
As with everyone else Product Owners get busy too. Even if a project has a Product Owner it doesn’t necessarily mean that they have been given enough time to take care of all the responsibilities. Passive Product Owners who are not keeping up with the team, or not available for the team will typically slow down the progress. This again creates great frustrations within the team - who is typically eager to get answers fast to be able to move to the next task or feature. In many projects a Product Owner role is a full time job, but in organizations that are not used to running software projects this is sometimes not well understood.
#4 Product Owner role misunderstood
One of the common misunderstandings is that a Project Manager is considered to be a Product Owner. Even though both roles work towards the same goal to make the project succeed, these are two very different roles. At a high level Product Owners are the ones with the vision and decision making power, while a Project Manager is more about the execution.
You might be thinking - wait what? In agile software development we don’t even have a role for a Project Manager? Isn’t this some kind of ancient waterfall-ish thing? While it’s true that in Scrum the Project Manager is not a typical role, there are still times (especially in larger projects or corporations) where this kind of role might be valuable.
Conclusion
So, how do we overcome these types of problems in such a critical role in the project? As an agency we try to emphasize the importance of the role in early stages of every new customer project. We have it in our proposals and agreements as a requirement for the customer. Naturally we are not in a position to force our clients to assign a Product Owner to the project, if this role does not exist. But we can help to recognize the upsides of adding the role, and then work with our client helping them to improve their methodologies and processes for the better.
If clients don’t see the value of having a Product Owner role on their side, then it often makes it difficult for an agency to provide enough value to the client. After all, the most important responsibility of a Product Owner is to make sure that team is building the right thing, at the right time.
How do you make your clients or your organization to understand the importance of the Product Owner role? What are the challenges in finding or assigning people to Product Owner role?
