The owner’s opinions and ideas are vital for the development team to construct a successful solution. No one knows his business better than the owner himself. The team needs the product owner because his participation and feedback are essential, providing the key link to a final decision. In this blog post, we will discuss four principles that will lead to successful cooperation between the production team and the product owner.
1. Product owner sets up the priorities.
When the product owner provides the development team with a list of their desired features he should also provide them with instructions what is needed in the first line.
In our experience, there have been cases when we received a feature list and started from the most complex and important functionality, but even though it was complex and important from our point of view, if it does not coincide with the product owner’s point of view, the processes/solutions are impeded. That is why we believe that the first principle of a successful project: always ask the customer about their priorities before the team starts working on any new functionality.
2. Product owner specifies all uncertain points.
People often misunderstand each other. Confusion can occur as a result of contradictions, insufficient knowledge, or incomplete/poor descriptions when the customer presents his wish list along with essential requirements, or when he describes a particular part of the system. Moreover, issues can arise at every facet of the development stage, and it is normal to discuss them.
In order to eliminate or at least minimize their consequences, the development team must constantly question and seek clarification of every term at each stage of the process. This is the second principle of cooperation.
IT Craft follows the Agile approach that encourages the team to examine the issue that demands clarification. It is essential and vital to involve all team members during the analysis and feedback process.
Certainly, the main work must be done at the initial stage when you clear up the requirements and settle the scope of the work. During the development process, it is better to discuss a task with the product owner and develop a feature he wants than to do the task quietly (without clarification) and not have it meet his expectations.
However, if the feature needs major corrections or there have been some misunderstandings, the customer will probably decide to shift the feature into the next sprint and improve the functionality when it is not critical for him. Openness and willingness to cooperate help establish trusting relations, which in return, are the keys to an efficient workflow.
3. Product owner needs structured information on the work progress.
It is not a secret that when a tech team is working hard on new features, they have a lot of tasks in a task/bug tracking system. The tasks usually have complex interrelationships because developers need to track all issues and changes in order to make the whole system function properly. However, these task/bug tracking systems are unchartered waters for the product owners where they can easily drown. We have seen this situation more than once in practice.
On the other hand, the product owner needs to trust the development team in order to form his own opinion on how ready the functionality is. Therefore, he needs to see the progress on all key elements in a comprehensive form.
The product owner must see the progress of the work, but he does not have to track all technical tasks assigned by developers and testers because it requires too much time and effort. This is why the development progress must be shown in a smooth and seamless manner which is not too much detailed (only key parts) but it must be intuitively clear. This is the third principle.
One of the possible ways to show the progress and get feedback in return is to demonstrate the tracking system as a mind map. Mind maps can contain special symbols with a clear, conventional meaning. Mind maps help exchange relevant information. For example, about:
- status: in-progress, done, new
- new questions
- new answers
- canceled features
- new bugs found by users
Here is an example of a mind map that demonstrates the progress of the work to the product owner:
4. Product owner always needs a demonstration of a completed functionality.
There was once the following situation: we were ready with a new feature, but we had to persuade the customer to try the result. He was going to put it off until the release. After a series of persuasive discussions, he agreed to do it. Upon trying the feature as developed, he replied:
“Oh, this is not that convenient! I did not imagine it like this, I did not want it this way…”
As the result, we had to redesign the feature. The good thing was, however, that we had clarified it before we released the new functionality. From this experience, we formulated the fourth principle: Make a demonstration of the newly created functionality as soon as it is done.
This is why we also ask our customers for User Acceptance Scenarios. If they struggle to prepare one, any of the team members (usually, a business analyst) has to make such a scenario and have it accepted by the product owner. This way, developers will be aware of what the product owner expects from the new functionality. Even if we are not able to present a demonstration in person online, we can always make a demo-video and send it to the product owner. The demo-video will familiarize the product owner with the results of the long-term working relationship so that they can make sure they make an investment, not just a business expense.
Last but not least. IT Craft team members blended all the above-mentioned principles into our problem-solving processes. We find it important to use the gained experience to continue growing and improve collaboration with our customers.