What will happen if in our IT project a Stakeholder takes a role of a Product Owner? Is it a good idea that both these roles were performed by one person?
There are many aspects that have an impact on the success or failure of an IT project. We have already analyzed why building online product in a 12-month timeline is a bad idea. We also took a closer look at the reasons standing behind project delays, and why choosing Agile can save us from long-haul projects.
Since we left the Waterfall behind and decided to drive the Scrum highway, we need to figure out how to prevent other bumps in the road. And those will happen if we don’t separate two crucial job roles in our online project. Yes, we are talking about Stakeholder and Product Owner. Today we will find out why mixing those two project positions is an utterly wrong turn.
Let’s meet our Scrum team
Regardless of whether we are a start-up or a medium-sized company we need to do some homework before starting an IT project with a software house. This involves focusing on priorities and embracing Product Design Workshop and MVP as a one & only work philosophy. As soon as we do that, we find a perfect moment to pause a bit at the Scrum specifics and introduce our Scrum team. Who is who in our IT project?
- Team of Developers – an agile software engineers squad responsible for organizing and delivering development work. They put together everything required for deploying each product growth. The heart of their working process is Sprint, an effective process resulting in releasing the product increment.
- Scrum Master – a natural born leader and a mentor who is taking care of supervising, teaching and assisting a Development Team to fully understand and follow the Scrum method. Master of ceremony responsible for achieving project goals in Sprints.
- Product Owner – a project conductor and a key player connecting business, marketing, and IT. A decision-maker holding the entire project together. Responsible for maximizing product’s worth, and most of all – making sure that a Development Team knows all the business expectations about product’s big idea and functionalities. Product Owner keeps an eye on all the features and app improvements.
Stakeholder vs Product Owner
Good! Now we need to think about our role in a project. Investing our money in building application or any other software product makes us Stakeholders by definition. We should feel confident and perfectly aware of the nature of our business, and in fact, we do – we are pretty much self-conscious. We are also familiar with our business goals perfectly. At the end of the day – who would know them more than we do?
Therefore, it might be tempting to regard ourselves as an ideal Product Owner. But would it work in a real world? Unfortunately, it wouldn’t. Why? Our business expertise is meaningful but is not enough to take control of a project’s working process.
To picture that, let’s do some analogy. Let’s compare an IT project to house building.
- Development Team → Builders. Using this comparison, we can imagine that our software engineers actually build this house. They are bricklayers, carpenters, roofers etc. They have their impact on work planning and choosing materials. They are able to organize themselves under the construction manager’s eye.
- Scrum Master → Architect. He is highly sensitive about the construction of the house. He strongly supports the construction manager and builders in the decision process and work performance in each stage of the construction. He makes sure everything is going according to the plan.
- Product Owner → Construction Manager. Well-informed about the investor’s timeline, and his goals. He is a real savvy in the industry – he knows the sector’s specifics. He is able to cooperate with the builders’ team. On the top of that, managing the investor’s budget is his responsibility.
- Stakeholder → Investor. By definition, he is a source of money that ignites the construction process in the first place. He also gives the construction manager access to all information about the aims of the construction.
Knowing that, let’s imagine the situation when the investor puts on the construction manager’s working vest and appears on the construction site giving orders to bricklayers.
Coming back to the IT project world – the biggest and most important difference between Product Owner and Stakeholder is that only the Product Owner knows how to manage projects and assets keeping specific tools and tricks to maintain the Agile rules. The Stakeholder will not be able to do that without implying delays and conflict situations.
Stakeholder and Product Owner – possible consequences of mixing the roles
What sort of trouble can we provoke by becoming a Stakeholder and a Product Owner?
- We won’t be accessible for the Development Team at all times. Which will strongly affect and slow down the decision process and the entire project.
With our frequent absence, we can misjudge the project’s priorities.
- A very high risk of building an app for ourselves, and not for our users. It will result in a product that simply won’t resonate in the market.
- Product Owner is responsible for the Product Backlog. If we mess in it, we will have to prepare for a chaos. Our developers will be clueless about what they are actually working on.
- If we are not 100% sure what has to be done at a certain stage of a project, we might fell into another trap. And that is forcing our developers to work according to their intuition, instead of the Backlog instructions.
Get things in the right place
The best decision we can take as an investor is to stick to our Stakeholder’s role and leave the rest on the highly-skilled Product Owner’s shoulders. Avoiding the mix-up will help our construction end faster and in stable conditions.