Product Owners: Making the development team an active member of the product

As a Product Owner, part of our job is to be an interface between all members of the team. In addition to being the owner of the backlog, we must report on each sprint to our stakeholders, provide feedback on the progress of the feature, etc.

At LumApps, we believe that a good product requires the dev team to be one of its most active parts. Investing time presenting each new feature, providing feedback, etc. has many advantages, such as: building trust between members, developing transparency towards the stakeholders, and improving features altogether.

Each of our feature teams consists of the following roles:

• A Product Manager (PM) who delivers the vision and the roadmap of the product
• Several Product Designers (PRD) who work with different teams. They conduct user interviews as well as provide the high-resolution mock-ups to implement
• A Product Owner (PO)
• Front-end and back-end developers
• A QA engineer

Since I joined the team as a Product Owner a year ago, we have been striving to increase the awareness of all members of the team on the product vision and making. There is still some way to go, but let’s take a closer look at the steps we have already taken.

Take the time to present each new feature

A feature is not only about adding a new function, it also impacts your product with side effects such as performance loss or unintentional coupling between packages. For the development to be successful, one requires a wider view which includes technical best practices. The latter are also key indicators to evaluate the risks and the possible drift in cost, perimeter and/or time of the project.

The time spent preparing and presenting each new feature of the product is not lost, it is invested. Remember that your dev team is the one who creates the feature and that members are its first users. It is important they understand clearly what is expected and why they are working on this feature.

Once the perimeter of a new feature has been clearly defined by the PM and the PRDs, I present it to the whole development team. My aim with this presentation is to associate the team to the product vision as the technical expert and gather as much feedback as possible to reduce or get a better estimate of the impact and risks.

Design together

Designing a feature is usually a task for PMs, POs, and PRDs. Of course, it is simpler to keep as few people as possible during conception to avoid getting too far. However, it is also important to include those who build the features to know whether it is technically possible and to know which element(s) could be at risk.

In the last couple of months, we have updated our design process to include the dev team during the last stages of the conception. Participating in the debate allows the developers to become actors of the roadmap.

These discussions allow me, as a PO, to identify risks, such as a component not present in the design system and requiring additional development time for example. This step is also an opportunity to roughly estimate the duration and the complexity of the development.

Favor direct collaboration

It is not simple to keep a good communication going, in particular during hectic sprints. It is also not ideal for the PO to act as an intermediate between all members of the feature team. Doing it this way leads to a loss of information and a lack of fluidity during the sprints.

In my feature team, we favor direct collaboration between members. The front-end team works closely with the PRDs to implement the mock-ups as accurately as possible. When defining a new API, the back-end developers work with front-end and mobile developers to create APIs that are useful and which require little maintenance.

All these tasks are performed directly by the dev team, without my presence as a PO, enabling trust and commitment in the feature team.

Listen to feedback

A feature is developed based on the market requirements and the PM’s vision. Although users are the target of the work done during the sprint, developers are the first users of your feature. Their feedback is beneficial and can help you to achieve your goal more efficiently.

Recently, one of our features was identified as high priority due to a market opportunity. Because conception had to be quick in order for us to seize this opportunity, I made the choice not to invite developers during the early conception phase. Together with the PM and the PRDs, we brainstormed a solution that seemed satisfactory at first.

When we moved to the final phase of conception with the dev team, I presented the solution we came up with. Their first feedback was:it is too complex for them to understand. It would have also been very complicated to develop, suggesting that it would have been bug-prone.

This feedback was very beneficial to us. We reworked the user experience of the feature together, making it both clearer and easier to use. The new iteration was agreed with the PM and the PRDs and is now the version in production. This experience taught me to keep the features as basic as possible, without anticipating every possible user action.

Share customer feedbacks and statistics

As said in the introduction, part of our job as POs is to provide feedback on a regular basis to the stakeholders (PMs, customers, etc.) and to work closely with them to get the most out of a feature. But we should not forget that the dev team thrives on that same feedback, and not only during the lone sprint review.

During the sprint review, I have started to share statistics on our released features. Providing statistics shows to the dev team that the work they are doing is never in vain. It is used by real users and customers, even if the feature is a low reach target. This transparency is very appreciated by the team.

To conclude, these five improvements to existing processes have improved the mood of the team. They also made PMs and PRDs aware of the difficulties that developers might face and reduced frustrations. Lastly, they have facilitated communication between all members of the team, making us more efficient and happier in our daily work.