Long story short: you need a Product Owner to make sure that you are going towards the finish line without meandering around. With such a person at your company, the team can focus on precisely defined tasks that generate more value than random undertakings.

When starting a software development project, it’s crucial that you know what kind of value every team member brings to the table. In some cases this is self-explanatory. Java Programmers write the code and Testers test it. Duh. However, there are roles that are hard to understand at first glance. A Product Owner? What’s a Product Owner?

Seriously, what does a Product Owner do?

He or she is the person calling the shots for the entire team when it comes to developing a specific piece of software. It’s the guy or gal who knows the app inside out, is aware of its advantages, but also realizes what needs to be done to make it stay relevant and/or better. The general assumption is that a qualified Product Owner will choose to perform work that generates the highest possible value.

Is it even possible to NOT have a Product Owner?

Not really. No one calls the shots completely at random. There’s always someone on the team who decides what you do next, and this is usually dictated by what they feel is necessary. This person is a Product Owner, even if their position is called something else.

But, if you don’t have a consciously selected and qualified Product Owner, you have an unqualified and unaware one. A senior programmer or manager who happens to make the decisions, but probably lacks the knowledge or experience or qualities necessary to make the right calls.

Who would be the perfect Product Owner?

Pobody’s nerfect, but you should always aim high. Thus, look for a person who’s both knowledgeable and available. Your team has to be able to easily reach the Product Owner.

Moreover, this person must be easy-going and have the ability to communicate in a clear and friendly manner. In a perfect world, he or she would be 100% into what they do, actively engaging with the team, and encouraging others to give 110%.

Also, your Product Owner (let’s call him PO) has to understand the area that your software is meant for. This means knowing the target industry, the client, and their business—in order to make the right decisions about the product. Only this way your project can support your client’s enterprise development.

How can the Product Owner raise the value of your work?

1. By being the mediator

The PO is the crucial link for the communication between the software development team and executives. He or she can answer questions coming from both sides, and support the programmers on a daily basis. With a Product Owner, there’s never a situation where the team isn’t sure what to do or what the CEO really meant. This results in the right decisions being made, efficient work being done, and a motivated team behind it.

being the mediator

2. By being a creative force

The Product Owner deals with your product every day, but mostly indirectly. He or she knows it and understands it, but doesn’t have to roll up their sleeves and work with the code all the time. This way the PO can look at your soft without the programmer’s tunnel vision, focused on more than just the problem at hand.

The PO can notice opportunities as well as gather and analyze data without any bias. Often the effect is a fresh idea that makes your product better. And when it’s better, your team feels motivated even more.

3. By understanding the scope of the entire journey

Turning an idea into a product is a complex process, and the Product Owner is the only person to grasp the entire thing. With specialists such as Java programmers focusing on their own tasks, and executives interested mostly in the general shape of things, it’s good to have someone who can lay out the entire roadmap. From planning to development to release to support, with future updates, risks, and fail-safes in mind.

Thanks to the PO, your software development team can dedicate themselves to figuring out how the app should work, and not what it should be about in the first place.

4. By planning (duh!)

Understanding the scope of the project is helpful in creating long-term plans. Still, short-term or sprint planning is just as important.

Defining objectives, adjusting them, refining the code when necessary—this is what makes your team sharp, focused, and effective. It’s a much better approach than staring into some remote general goal and drunkenly stumbling towards it, trying to grasp 10 issues at a time. What you really need is a timeline, milestones, priorities, and a general consensus among your team about what you are trying to achieve at any moment.

5. By creating and maintaining a backlog

With their extensive knowledge of the product, its goals, and the entire production/launch process, the PO can prepare an extensive backlog of tasks for the development team.

Knowing what’s ahead helps everyone to understand the rate of progress and reduce the risk of unpleasant surprises. With a backlog, you can shift priorities when necessary, which is an easy way of managing or entirely avoiding crises. And again, there’s a side effect in the form of your team staying properly informed and motivated.

“Nah, I don’t need a Product Owner”

Frankly, we haven’t heard anyone saying such a thing yet. This is because the advantages of having a PO are pretty obvious. It’s someone that makes sure everyone is doing their job, and that this job results in a healthy ROI.

In the case of our software house fireup.pro, most of the clients delegate their own Product Owner a.k.a. Product Manager. It’s not only possible but actually advisable. This is how we developed an information portal for the Trans.eu group. The PO helped us understand the goals of the project and focus on delivering an algorithm to suggest content based on user preferences. We knew what was needed, why, and what had to be done in the first place to satisfy the client. This resulted in the following recommendation from Trans.eu:

“Highly involved professionals, oriented on finding solutions, flexible in terms of changes in the project.” – Szymon Knychalski, Product Manager at Trans.info