Balancing Between Client and Team from the Product Owner’s perspective

Product specification

As a Product Owner or a similar role that is essentially the interface between the client and the engineering team, you’ll often find yourself trying to compromise between one and the other. Challenging situations may happen during all phases of product development, including product specification and product delivery. I will focus on the product specification phase and offer advice based on my experience on how some of those situations could be prevented or handled.

What is essential to have the right product?

To understand our goal when defining product (features) specifications, we need to set grounds for what we are trying to build. On a high level, there are three main aspects of a successful software product:

• It must solve a particular problem or bring value to the users
• It must be easy to use
• It must be delivered at the right time

Everyone who has had experience as a Product Owner knows that in addition to these three main aspects, there is a vast complexity of qualities to consider when building a software product. There are numerous ways to determine the characteristics of good software, but I find these seven most important:

1. Usability — user experience and usefulness
2. Availability — readiness to perform its function when needed
3. Performance — the speed at which software functions are performed
4. Scalability — ability to handle an increasing volume of transactions and data
5. Maintainability — the ease at which it can be changed or extended
6. Security — confidentiality, integrity, authentication, authorization
7. Profitability — ability to bring financial value or reduce the cost of maintaining

Often, the client and the team value these aspects of software quality differently. For example, technical debt is significant for the engineering team because the team is aware of the potential problems it can cause in the future. On the other hand, solving technical debt brings little immediate value to the client.

Gathering requirements / defining specification

During my experience as a PO, it often happened that different aspects of software quality were directly conflicted in a single requirement when both client’s and team’s perspectives were considered. Each requirement that brought this kind of challenge was particular; unfortunately, there is no straightforward advice that could be applied in all situations. However, there is something I developed for myself as a checklist when considering whether a potential new feature makes sense and whether it should be introduced to the software:

• Does it fit the product’s purpose? — Each Product Owner must know the product vision and have it documented and shared with all stakeholders, including the engineering team. Answering this question means assessing whether the requirement is aligned with the product vision.
• Does it add value for the users? — In addition to understanding whether a feature is aligned with the product vision, a PO must understand which and how many users will benefit from it.
• Does it impact users’ ability to learn and use a system easily? — This question helps define how generic or specific a feature should be.
• Does it impact other aspects of software quality? — Here, a Product Owner should consider at least those seven characteristics described above, whether and how each will be affected.
• Does it add (unnecessary) complexity to the software? — Understand how it impacts code maintainability.

Changing Requirements

In addition to initial feature specification, changes in existing features’ requirements are another integral part of the Product Owner’s life. There are different reasons for changing existing features. It could be that business or users’ needs have changed. Still, it can also result from a client’s indecisiveness, a communication gap, or the inability to reach out to the end users and get their feedback.

If requirements change too often, that could lead to the team’s discontent. The team feels that there is a lot of throwaway work and no sense of accomplishment when the goal to deliver the desired feature is constantly slipping away. On the other hand, users are also affected by the prolonged time until the value is delivered.

While changes in requirements are often necessary, it is good to recognize and prevent the frequent changes resulting from indecisiveness, miscommunication, or lack of feedback.

There are several ‘tools’ a PO can use to enhance the product specification process, which can be used for both initial requirements gathering or changes in requirements:

• Collect user feedback through various methods such as design demos, usability testing, or AB testing. If end users are not reachable, think of who else can provide valuable feedback. For example, members of the QA team are the ones whose mindset is set to look at the product from users perspective.
• Perform feature design sprints — a process in which features are designed one sprint ahead of development. During the design sprint, design mockups are created, used to collect user feedback, and refined based on it.
• Include Dev team members in UI/UX phase — their perspective is extremely valuable and even time-saving when deciding what can be done given the current circumstances — software architecture, hardware capabilities etc.
• Document conclusions in written form — the benefits of having written conclusions (requirements, decisions and assumptions) are apparent. Still, nevertheless, it’s important to emphasize how this habit can be a ‘life-saver’. It could prevent unnecessary feature changes when everyone is reminded why certain decisions were made in the past.

Refusing requirements

Most POs at some point had a situation when a client’s requirement made sense, it was completely justified, but the engineering team said, ‘No — This cannot be done’. For me, saying ‘No’ to the client is one of the most challenging aspects of the PO role, but over the years, I’ve learned that sometimes it is necessary. These are some of the tips on how to either prevent or handle those uncomfortable situations:

1. Inspire the team by helping them understand the larger picture. You can achieve this by inviting engineering team member(s) to some business meetings. It’s probably not efficient to invite all team members to all meetings. Still, having at least a few team members support you in the planning session when the ‘unpopular’ requirement is going to be discussed is very useful. Hearing from clients directly increases the team’s empathy toward their needs.
2. Assess the experience of Dev team members within a given project domain. If necessary, look for the advice of senior colleagues within the company.
3. When saying ‘No’, explain why and offer alternatives. Arguments, why something can not be done, must be well understood and presented. Also, discussing alternatives that the team finds acceptable and presenting them to the client when saying ‘No’ is always necessary.

Takeaways

While it is difficult to summarize all the challenging situations a Product Owner faces when balancing feature specifications between the client and the team, it is helpful to remember some of these tips:

• Understand the ‘why’ — Make sure you always understand the ‘background’ of each requirement, how it fits the product purpose and what business or personal need it solves. Make sure the engineering team shares the same understanding.
• Find a ‘fine line’ between generic features and specific user needs. While generic features are preferable from the point of software maintainability, they might not be quite intuitive to the users. On the other hand, not all very specific requirements have to be transformed into a new feature. Finding a ‘fine line’ comes with experience, but it’s something to have in mind with each requirement.
• Refrain from being overconfident and making assumptions — after years of experience in a PO role, I’ve sometimes fallen into a trap that I understand best what are users’ and team’s needs and so I can make decisions quickly. That caused me to make some mistakes. Always ask for user feedback and team input.
• Be transparent in both ways — very often, compromises must be made when defining or changing specifications. Make sure that all sides are aware of those compromises and why they had to be made.

Blog by Esena Gušić, Product Owner at Atlantbh