Building an application or any other IT system meets many challenges. One of them is close cooperation between a Product Owner and a Scrum Master. How to define the role of Product Owner in a software project? Why can it go so terribly wrong? Let’s put on the Scrum Master’s spy-glasses and investigate the 7 critical points for a project’s success or failure. Which one will be a sin and which one a win when it comes to the Product Owner?

The agile approach in delivering successful apps has to rely on swift communication between a client and a software house. A huge responsibility lies here on a Product Owner’s arms, and his or her attitude towards a product, a Scrum Master, and a whole development team. If anything slips on that line, it may undermine the quality of work at every sprint, and at the end of the day – the product itself.

It surely doesn’t help, that most of IT projects have to face the geographical distance between a stakeholder and a software house. In other words, if both sides of a deal come from different countries or even continents, it means that the entire cooperation will be happening online. Everything from Product Design Workshops up to launching the MVP will have to be discussed via video conferencing, online meetings or webinars. This makes the relationship even more vulnerable to misconceptions and delays.

Product Owner in IT Project – 7 Sins or Wins


So, what are those aspects that can be as well the dark and the bright sides of a Product Owner? How will they affect the product creation?

  1. Motivation – The worst case scenario is to have a Product Owner who is not interested in the project. If he or she has a vague and chimerical vision, or he doesn’t care at all, they will hardly motivate any engineers on the other side. Product owners who don’t feel the motivation themselves will harm the project big time. Demotivated team members won’t be able to deliver high-quality and flawless features.

  2. Availability – The second case is that a Product Owner is busy with other responsibilities and they slow down the flow because he or she is not available. It’s a frustrating situation because one or more teams don’t get the necessary information they need to proceed with the product, and finishing particular features on time becomes a problem. This means the Sprint Goal is at risk.

  3. Communication – In Evojam, most of the projects we carry, are with companies scattered around the world. That’s why there’s a fat chance to meet a Product Owner in person. There has to be an established standard of communication and dedicated media tools. Otherwise, the entire project will drown in frustration, because lousy communication between Product Owner and the Dev team will smother the work process.

    We need to keep in mind, that it’s better to over-communicate than to under-communicate! Why? Because working with remote clients or teams imply the fluent exchange of information is harder to maintain. Therefore, there is no such thing as too much contacting. Whenever you feel you communicate enough, you most probably communicate much, much less than you think.

  4. Project Kickstart – If we skip a kickstart in a project, we will risk a false start as far as cooperation between a Product Owner and a team is concerned. Not having a kickstart would bring a harmful improvisation to the table. Meaning – we would have to gather all the valuable information as the project goes on, instead of discovering the possible flaws and risks and at the very beginning of the project.

    If we do things right, on the other hand, and we will carry a kickstart, we will have a chance to get to know each other with a Product Owner. It might protect us from possible future conflicts between a Dev team and a Product Owner.

  5. Feedback – If being open to feedback we called an art, then we would have to call reacting to critical feedback – a martial art. This is the essential part of every successful IT project. Now, if a Product Owner doesn’t act like a primadonna, we will be fine. That role requires an open-minded person, who doesn’t have a problem with receiving … perhaps even harsh notes from the software team. The ideal situation is when a Product Owner is, in fact, easy to reach and open to discussing problems with a tech-partner.

  6. Process – Every well led IT project needs to base all activities on a process. To minimize the risk of delays and errors, everything needs to be in a right place in one objective scenario. All team members should commit to these processes at the start of the project to overcome any potential difficulties in later stages.

    The process should be agreed before the project kick-off! A Product Owner should discuss these strategies with a Scrum Master, and the Scrum Master is responsible for implementing them.

  7. Mandate – It’s all about being a decision maker. When a Product Owner does not have a mandate within the organization, it means he or she is a proxy and a runner for the one who is actually calling shots in the firm. Project-wise, it’s a terrible mishap, because a Scrum Master and the developers are banging their heads against the wall most of the time.

    To solve this, a Product Owner needs to reclaim an independence in the decision process. Otherwise, the app building will take ages.

Conclusion

Obviously, it’s not a magic formula that will guarantee the project’s impressive success, but solving problems indicated in this article will play a huge role in any IT project.

Maybe there are some more issues we should add here? Does anything come to your mind? Let us know!