In the previous article, I provided a brief introduction to the role of the PO and described what typically entails in the tasks and responsibilities. One of the more central areas is user needs and requirements. That's also the area I intend to delve into this time.
Proven methods for gathering needs/requirements
As I have written about before, there are many different methods for effectively gathering the needs, requirements, and desires of the business. Unfortunately, there are no foolproof top lists that show which methods yield the most results. The only recommendation I can give is to try out different variations to see what works best for your team and organization.
Throughout my work in various types of organizations, both large and small, public and private, I have come to the conclusion that there is no one-size-fits-all solution. Different methods work differently well depending on a variety of factors, making it difficult to point out a specific approach or method.
One common method often used by frontend developers and UX designers is personas, which are fictional user profiles with names, characteristics, and goals. These should be based on real user interviews, but you can also create a few personas to have a sufficient number.
If you've never worked with personas, you might find it a bit suspicious, but the truth is that it can provide quite a lot and, above all, visualize your users' needs in a completely different way than just reading texts in a document.
User surveys and interviews are another effective way to gather needs. It can be challenging initially, especially if there is no product to start from, but if there is already a product/service used by multiple users, this is a great way to gain a deeper understanding of their needs and what they would like to change.
User dialogues, feedback, and user journeys are other ways to create more structured processes for ongoing needs gathering. By user journeys, I mean following the user through the system/service/product and observing their behavior and areas that can be improved. There are technical tools available to assist with this, such as Matomo, AWStats, OW Analytics, Octopussy, among others, but they only provide a technical picture of a flow.
To create a more comprehensive experience, you may need to film the user, track eye and mouse movements, and ask the user to "think aloud" to gather as much input as possible.
In addition to all this, there is the constant concept of iterative development with small, incremental steps and continuous feedback. Prototyping has been around since the 80s, so it's not something new, but with today's modern tools, it's very easy to create sketches, wireframes, prototypes, and mockups.
Tools like Figma come to mind.
Active listening with empathy
This is also a recurring theme. One of the most fundamental building blocks is the ability to listen actively and empathetically. It's a difficult art to master but one of the most important aspects. That's why I emphasize it so much.
For example, see my article in the series about creating the optimal development team, which discusses how to handle stress, conflicts, and challenges, or my blog series on becoming a Super Scrum Master, where I talked about personal growth as a leader.
With that said, I won't elaborate much more on this topic. I encourage you to read those articles where you can find more tips on this.
Collaboration and communication with stakeholders
Another important aspect of your role as a PO is the art of collaborating and communicating with other stakeholders. To succeed in this, you need to both engage and involve stakeholders. You can achieve this by involving them early in the process so they can participate in decision-making and influence from the beginning.
This way, you also receive their feedback and comments at an early stage, allowing you to easily adapt the product to emerging preferences.
The more time you dedicate to truly understanding your stakeholders' needs and goals, the more effective your communication and collaboration with them will be. Another point to consider is that you indirectly build trust among stakeholders. If they see that they can trust you as a PO and your commitments on behalf of the team, it automatically strengthens the trust between you.
It's also important to build long-term relationships with stakeholders. If you're attentive, humble, and curious, you can go a long way, especially when combined with active and empathetic listening.
Managing conflicts
Even if you have a good dialogue with your stakeholders with open, honest communication channels, conflicts or disagreements may arise that need to be resolved. There are several reasons for this, but one common cause is suddenly having different opinions on how something should be resolved or prioritized.
When this happens, and it will, it's important for you as a PO to be well-prepared and try to put yourself in their shoes and understand their perspectives. Active and empathetic listening is particularly important here because it affects the team's future. If you can't reach an agreement with stakeholders, it can have significant negative consequences for the entire team and its future deliveries.
The best advice I can give is to make an effort to find a compromise with stakeholders, aiming to reach a solution that satisfies their desires while not compromising the product's goal. It may be utopian to think that everyone will come out of this conflict/agreement super happy, but you may be able to find a solution that causes the least harm.
Document and learn from past mistakes
I have previously talked about the importance of documenting and learning from your mistakes. It becomes especially important when communicating various decisions to the team. This helps create transparency and avoid misunderstandings and ambiguity. At the same time, it can be challenging to know how to document and, more importantly, how to structure everything. My advice to you is to not dwell on it too much but just do it! It's like starting to exercise.
If you sit at home contemplating starting to exercise, thinking you'll go and work out when you feel ready, chances are you'll never do it. Documentation is similar. If you spend too much time thinking about how to structure everything and which methods to use, you'll likely never get started with the documentation.
Instead, focus on getting started with documenting in some way, and simultaneously think about how to structure everything. I understand that it can be tedious to shuffle around and organize data afterward, but I have seen this fail several times because the person involved got caught up in how to do it instead of just doing it.
In the next section, I will discuss how you, as a PO, can manage the backlog with some simple methods and how you and your Scrum Master can keep it up to date constantly.
