Manage the Product, not the Team
Focus on your job as the product manager or product owner, and manage the product, not the team. Provide guidance on the product, including its market, value proposition, business goals, and key features. But let the ScrumMaster or coach tackle people, process, and organisational issues; let the development team figure out what needs to be done to implement the user stories and other product backlog items.
It a common mistake to step in and take on the ScrumMaster role if there is no ScrumMaster or if the individual is struggling to do a good job. While this may hep you in the short-term, it’s going to hurt you in the long run. Taking on too many responsibilities means spreading yourself too thinly: something will have to go. You will either neglect some of your porduct responsibilities or put your health at risk. Neither is desirable. (For more guidance on the relationship between the product owner and ScrumMaster see my post Every Great Product Owner Needs a Great ScrumMaster.)
Treat the Team as an Equal Partner
Remember the Golden Rule? Treat others how you want to be treated. The team members are not your resources but the people who create your product. If your relationship with the team is poor, then your product is likely to suffer. Assume that the team members want to do their best. Respect their UX/UI and technology decisions and their right to determine how much work can be done. Be honest and open. Provide constructive feedback and share your concerns. But don’t tell people how to do their job and refrain from assigning tasks. Development teams should manage their own work (using a sprint backlog or Kanban board). If the team struggles, then it’s the ScrumMaster’s job to help the team—not yours (as discussed above).
Help the Team See the Bigger Picture
Developing a successful digital product requires more than technical knowledge. It’s virtually impossible to develop the right solution without understanding the product context, including who the customers and users are, what value the product creates for them, what makes the product stand out, and how it benefits the business. You should therefore help the team acquire the relevant market and domain knowledge—for instance, by involving the team in research and validation work, inviting them to join you when you visit customers— and ensure that they are aware of the product strategy and product roadmap as well as the business goals and KPIs. This will not only lead to better technical decisions and a better product. It also eases your workload: understanding the bigger picture allows the team to help create user stories and to support you in managing the product backlog.
Involve the Team in Product Decisions
While you own and manage the product, the development team should understand and support important product decisions. The best way to achieve strong buy-in is involving the team members in the decision-making process. This also leverages their creativity and knowledge and is likely to lead to better decisions. There are a number of techniques that help you achieve strong buy-in including the following ones:
- Creating shared goals: a vision, release goals, and sprint goals everyone agrees on;
- Involving the team members in research and validation activities, for example, observing users or building MVPs and jointly analysing the resulting data;
- Engaging the team in developing and updating the product roadmap;
- Collaborating on the product backlog: prioritising items and creating user stories.
Be aware that collaboration requires leadership. As the person in charge of the product, you should be open and collaborative but decisive at the same time. Aim to build consensus with the development team, but don’t shy away from difficult conversations. Don’t settle for the smallest common denominator and have the courage to make a decision if no agreement can be achieved: Great products are not based on weak compromises.
Spend Enough Time with the Team but Don’t Neglect your Other Duties
Make time to collaborate with the team in order to work on user stories, answer questions, and participate in meetings. If you are not available or difficult to reach, you are not guiding the team. In the worst case, people get fed up with trying to get hold of you or waiting for an answer and stop consulting you. Consequently, you may end up with a product that requires extra rework or has features that cannot be released.
If, however, you feel overwhelmed by the team’s questions, then coach the team to help people see the bigger picture and involve the team in product backlog management and user story creation. This will allow them to carry out their work autonomously and it reduces the amount o questions you have to answer during the sprint while the team is implementing the stories.
As important as it is to make enough time for the team, don’t neglect your other product management duties, such as, engaging with users, working on the product strategy and roadmap, and managing the stakeholders. If you become too team-focused, your product is likely to suffer.
Expect High Standards but Don’t Push People
Hold the team accountable and expect that people do a good job–that commitments are kept and agreements respected, that sprint goals are delivered, that the team adheres to the definition of done and creates software that works, is documented, and tested. But recognise that software development can be challenging and that human beings make mistakes. Don’t be mad with the team if the sprint goal is missed once. But don’t accept it if the team repeatedly doesn’t deliver what was promised. Use the sprint retrospective to investigate the causes and explore how you can help, for instance, by creating smaller user stories or better acceptance criteria.
Don’t force work on the development team and don’t ask people to carry our more tasks than they can realistically cope with. Otherwise the team may become demotivated and start to take shortcuts like compromising quality and neglecting documentation. In the worst case, people will fall ill or leave. Instead, involve the team in setting a meaningful sprint goal that provides motivation and guidance for the team and respect the team’s right to decide how much work can be done. This creates a sustainable pace and keeps your team motivated.
Give the Team Room to Experiment and Learn
In order to generate value, a product has to offer something new; it has to innovate to a greater or lesser extent. To help your product create value in the future, the team requires time to learn their skills and to investigate new technologies and tools. But this is unlikely to happen if you expect that people work new features all the time. You should therefore give the team enough room to experiment with new ideas and acquire new knowledge. Some teams use gold cards to allocate time in a sprint for experimentation and learning; others use hack days. Whatever works for your team, help people prepare for the future. This will benefit your product and the team morale.
Fully Participate in the Meetings (or Don’t Show up)
This might seem like a trivial piece of advice, but I’ve seen my fair share of product people who half-heartedly participated in meetings with the development team. Therefore, come prepared to a meeting and fully participate—silence your phone, put away your laptop and tablet—or don’t attend.
In a Scrum context, the two most important meetings for product managers and product owners are usually sprint planning and sprint review. You should always aim to be present at these meetings and do the necessary prep work, such as, prioritising the product backlog and refining user stories for sprint planning or inviting the right people and selecting the right product validation technique for the review meeting. But don’t facilitate the sessions. Let the ScrumMaster take on this role.
Learn More
You can learn more about effectively guiding the development team as the product manager or product owner by:
- Attending my Product Leadership Workshop;
- Reading my book Agile Product Management with Scrum.
| Reference: | 8 Tips for Collaborating with the Development Team from our JCG partner Roman Pichler at the Pichler’s blog blog. |
