The PO’s role

For every Scrum project, the customer appoints a Product Owner (PO) who plays a crucial role throughout the entire process. The PO determines what the team is working on and when. Scrum Master Erik van Eeuwijk describes the process in detail in this blog post. INFO assists and supports the PO in every way that we can, just like the team members. Paul van Putten, Product Designer at INFO, uses examples of the Stadsbank project to illustrate how a designer can support the PO to make an even better product.

Improvement vs. renovation

A possible risk when rebuilding a product, as was the case with the Stadsbank, is that the existing functionalities are always the jumping-off point. Often, users expect all these functionalities to be transferred to the new product. Yet, a rebuild offers opportunities to improve the system with different functionalities. The PO must gauge ​​where these improvements can be made and current users will have to accept changes to a system they have become familiar with.
To better understand the users, we first wanted to see how the Stadsbank employees were working with the existing system. Understanding the users and their needs is also important for the PO, because he/she is responsible for the end product that should add value for the end user. We were lucky that ‘our’ PO worked with the old system on a daily basis, giving us easy access to the end user.

Job shadowing

An effective way to understand the users and their needs is job shadowing. Job shadowing means watching an employee for a certain period of time while they’re doing their regular work. At the start of the Stadsbank project, we did a lot of job shadowing, observing the pawnbrokers during their daily activities.
Job shadowing has two important advantages. Firstly, it’s the most objective way to see an end user at work. Secondly, it provides you with the opportunity to get close to the users, so they get to know you. This is important when dealing with a target group that has been working together in the same way for years – you build a rapport. We observe, record and ask questions afterwards about interesting things or behavior that we’ve spotted.
One of the things we’ve noticed during the shadow period with the Stadsbank, was a pawnbroker showing his screen to the customer. When we asked him about this, we found out that it helps the customer to understand exactly what he or she has pawned to the Stadsbank. This need for transparency has been an important insight for us and has played a crucial role in the renewed online environment of the Stadsbank.

User testing

Besides job shadowing, we tested the most important system flows with the end users. Often, the PO was present as well. Conducting early tests with the end users serves two purposes: on the one hand you want to receive feedback, while on the other hand you want to introduce the users to the new product as soon as possible. We recommend involving the PO with these tests, so that he or she may become (more) aware of the end users’ wants and needs.
By definition, every software development process comes with uncertainties and you simply can’t anticipate every possible outcome in advance. During the design testing with users, it soon became clear that certain requirements that the Stadsbank had drawn up in advance, didn’t match the users’ needs. Since the PO had been present during these tests, he was able to provide feedback to the stakeholder who submitted the specific requirement. As a result, these requirements were adjusted. Testing with users offers the PO arguments to use when discussing the project with stakeholders.

How to write strong user stories

The PO is responsible for the Product Backlog, which consists of user stories: stories that describe what the user wants and why. Ideally, user stories are a means of communication in which the team searches for a solution together. There are a couple of possible pitfalls when writing user stories: the possible solution is described into too much detail. This leaves little room for investigation, since everything has already been set in stone. A PO is an expert on the business; he/she knows all about the what and why of the organization. The PO writes the first draft of the user story and should gather input from the team as soon as possible. During the writing of the user stories, we support the PO wherever we can. The designer looks for the underlying questions in a user story, to make sure that, together with the PO, the user story is as strong and comprehensive as it can be. This provides the development team with guidance and context, and ensures that every story has value, thus avoiding developing unnecessary functionalities.

Another possible pitfall is the lack of focus while writing the user story. A user story must be unambiguous. Anything that doesn’t contribute to the user experience, doesn’t belong in the story. The designer can help the PO to distinguish between the primary and secondary issues and to bring focus to the story. A lack of focus often translates into (way too) many details. Of course, sometimes details are important, but those are usually addressed during the sprint or further refinement. At the Stadsbank, for example, the final solutions were often devised during the sprint. Lack of focus also reduces the readability of a user story; it makes the story longer and it doesn’t contribute to adding value.

How to get the stakeholders on board

Stakeholders are the people who have a vested interest in the project. One of the PO’s responsibilities is to gather input from stakeholders and to create support. This can be a challenging task and we’ll help you by facilitating the collaboration between the PO and the designer(s). Right at the start of a digital transformation, we invite stakeholders for the various kick-off sessions that we organize. This way, we involve stakeholders in the development of the product vision, the technical vision and the collaboration vision.
Designers are mainly concerned with the product vision. We mapped out the employee flow at the Stadsbank. When you map out the flow together with different stakeholders, interesting discussions arise. It’s interesting to hear a manager explaining the policy and an employee talking about the way things actually go down in the workplace. The result is a complete picture of all experiences, pain points and opportunities.
After this exercise, we used co-creation to come up with solutions for the most important pain points. This method provides everybody with the opportunity to think of possible solutions for these bottlenecks. Visualizing ideas aids communication. Additionally, this allows stakeholders to be heard and to make a concrete contribution to the product.
During a sprint, the sprint review is the perfect time to involve stakeholders and show progress. You present what has been built by the team so far and give the opportunity to provide feedback. This review is important, because it’s often difficult for stakeholders to visualize what the development team is doing exactly. Since the PO is the ambassador of the product, he or she would be the perfect person to lead these sessions. It’s advisable for a PO to provide context during these sessions and answer questions, such as where are we in the project and what will be tackled in the upcoming sprint? This way, the PO takes responsibility for the work done and strengthens its position with the stakeholders.

How to optimally support the team

It’s paramount that the PO is available to the team during the sprint to answer questions, although the pandemic and subsequent lockdown(s) have made that a little more challenging. At INFO, we use Slack as the primary communication channel and always give the POs access to our Slack channels.
We advise POs to schedule regular meetings with the designer, to evaluate the stories and answer possible questions. This helps the PO to look ahead. Designers are the PO’s ideal sparring partner, because they’re never fully engaged in the current sprint and often have the most complete picture of the context and the business as a whole. Together with the PO, the designer outlines ideas, works out flows and writes user stories. This means that during the absence of the PO isn’t available, the designer is your go-to person for any and all questions about the product.