As a product manager, you’re ultimately responsible for the success of your product.
You can ensure that success through understanding the outcome you’re trying to realize and to make sure that it’s the right outcome. Once you know you’re trying to realize the right outcome, you need to make sure you have the right outputs. This is why it’s so important to effectively work with your product development team.
You can’t hope to deliver a solution all on your own. You need to make sure you can lead a group of talented developers, QA experts, and product designers through influence and inspiration.
This post takes a look at the key things to consider when working with a product development including:
The key roles on a product development team
Who leads a product development team
How to successfully work with your development team
Typical product development team interactions
Product development team roles
The first step in figuring out how to work with a product development team is understanding who you should have on the team. The exact makeup of a development team will vary based on your organization and the product you’re working on, but there is a general set of roles that most development teams have.
Those roles include developers, quality assurance engineers, product designer, and a product person. You may also have a scrum master if you’re explicitly using the scrum framework.
Developer(s)
Developers are the people on the team who have the skills to create an aspect of a usable increment of the product. These developers may have the sufficient skills to work on the entire tech stack, or they may specialize in front end or back end.
One of the developers may work as a tech lead. The tech lead's responsibility is to coach the other developers on engineering practices and may be involved in continuous discovery as part of the product triad that includes the product manager and product designer.
QA Engineer(s)
A QA Engineer performs risk analysis, codes automated tests, identifies any bugs that could affect the product’s performance, pinpoints potential issues that may disrupt the user experience, and creates new testing processes.
Product Designer
A product designer champions the user experience. As the tem builds new features or rolls out upgrades a product designer sense checks how the feature or upgrade works in practice, and the impact it has on the user experience. The product designer also performs research to understand customer requirements and expectations, as well as establishes the product’s visual style.
Product Person
Depending on your product team structure you may have a product manager, a product owner, or both.
A product manager has profound knowledge on the developed product and everything that goes with it. The product manager typically works with top-level management, sales and distribution, product development and quality assurance to coordinate decision making and product strategy.
A product owner clarifies product backlog items and makes decisions about how to prioritize them. As a result, the product owner is primarily focused on the relationship with the product development team.
Scrum Master
The scrum master is the guardian of the process. They ensure that the team’s environment is set up to allow the team to succeed, remove obstacles that get in the way of the team and coach and mentor the team on their chosen practices.
You don’t necessarily need all these roles, and you may occasionally need additional roles. The trick is to keep your team as small as possible while ensuring that you have all the skills you need to discover the problem you’re solving and deliver an appropriate solution.
Who leads a development team
If your development team works in an agile manner there isn’t a formal leader identified for the team. Instead, the team self manages, which means they manage their own work, decide how to achieve goals, and seek ways to continuously improve.
Even though there isn’t a formally identified leader, successful teams will see leaders emerge for particular aspects of the team’s work. One example is the product triad consisting of the product manager, product designer, and lead engineer. This group “leads” the development team by performing product discovery to understand the problem space and formulate the piece of the solution that the team will work on next. This approach is frequently referred to as dual track agile.
Leaders will also emerge from the group of developers on your development team. Because the team is self managing, different developers are able to take on a leadership role in matters related to their particular specialty. This leadership is often exhibited in the form of making decisions and establishing good practices for the rest of the team to follow.
Another form of leadership you’ll see in a successful self managed team is leadership by example. Members of your team adopt informal leadership roles by modeling the type of behavior that everyone on the team should mirror when your team faces challenges.
This type of leadership also exists in less successful teams. The difference is that the behavior modeled is often counterproductive and leads to poor working relationships among the team.
How to successfully work with your development team
One way you can take a leadership role on a self managed team is to encourage discussions about how you will work with each other. These discussions are important regardless of your working arrangements, and take on an additional level of importance when your team works remotely.
Here are some of the key discussion points to have with your team.
Establish shared understanding of your outcome
You need to trust your team to make the right decisions that further progressing toward your desired outcome. To ensure they successfully do that, you need to make sure that they understand the outcome to the point where everyone can pretty much describe the outcome in roughly the same way.
You want everyone to understand the problem you’re trying to solve and why. Techniques such as the problem statement and the opportunity assessment help you guide conversations about outcomes.
These conversations give everyone a chance to verbalize their current understanding of the desired outcome, then reach a shared understanding of that outcome.
Including people in a discussion about the outcome is more powerful than asking them to read about the outcome. When your team members are involved in a discussion about the outcome, they can think about it in terms meaningful to them, which provides clarity.
Clarify responsibilities
Even though team members in self managed teams typically self select what tasks they will work on, it’s still helpful to have clarity around the type of work that each team member will generally perform.
As your team starts working together, have an open discussion to come up with an initial understanding of everyone’s experience, skills, and interests. You can use job titles and roles as an initial guide to determine who does what, but feel free to adjust where appropriate. These types of discussions are especially important when you have multiple product people on your team.
As you determine who does what, you’ll also want to agree who will make certain types of decisions. When you know who will make which decisions ahead of time, you avoid discussions about who should decide when a decision comes up. It also prevents people from stepping on each other’s toes.
It’s important to remember that your agreements about roles and decision responsibilities are not set in stone. Be willing to reflect on how your team is working together and make changes to responsibilities and decisions based on what you’ve experienced and what you’ve learned as you work on your product.
Clarify Communications
In addition to knowing who is going to do what and who will make certain types of decisions, you also need to make sure your team is clear on how you’ll communicate with each other. That includes how you’ll handle quick questions, what tools you’ll use, where you’ll record different types of information and how you’ll want to handle different interactions.
When your team is colocated, you’ll probably rely heavily on spontaneous conversations in your team room along with whiteboards and a selection of tools to record key information you’d like to refer back to later.
When even just one person on your team is remote, you need to be much more explicit about the practices you follow for team communication. You may need to find some technology solutions, such as Slack Huddles, to replicate the feeling of being in the same room such that spontaneous conversations can start up.
It’s best not to view your communication agreements as set in stone. The communication practices you select when you start working together may not make sense once you become more familiar with everyone’s working styles. If you find that a particular mode of working together is not effective, have a conversation with your team and see what changes make sense.
Agree on the practices you’re going to use
There’s more to communication than talking and recording information, especially when it comes to software product development. You’ll also want your team to agree on which engineering practices you’ll use and how you’d like to use them:
Pair programming - your developers should decide if they want to code in pairs, and if they do, how frequently will they use that technique and what ground rules they’d like surrounding that practice.
Refactoring - your team should discuss how you want to incorporate refactoring into your development practices. Do you track refactoring as separate backlog items or does it happen organically?
Test driven development - How extensive will your efforts be to create automated tests and where does the QA engineer fit in.
Continuous integration - how frequently do developers share their code to a central location and how many scans do you include in the build process?
Continuous delivery - how frequently do you deliver code to your customers and how automated is that process?
Definition of ready - what does a team need to know about a backlog item in order to start development work on it?
Definition of done - what must be true in order for a backlog item to be considered finished?
Typical product development team interactions
When your team considers communication, you’ll also need to agree on the specific interactions you have as a team to guide the planned discussions that occur alongside the more spontaneous conversations.
The scrum framework provides a good set of interactions that your team will have. Your team should consider which of these interactions make sense for your particular situation and how you’d like to structure them.
Backlog refinement - Do you flesh out backlog items as part of a continuous discovery effort, or do you have specific meetings to refine your backlog items?
Sprint Planning - How specific do you want to be about the backlog items that your team plans to deliver in the upcoming iteration?
Standups - Does your team need to sync up every day and what’s the best way for that coordination to happen?
Sprint Reviews - At the end of an iteration how do you update stakeholders on your progress and get feedback on what you built?
Retrospectives - How does your team reflect on the past iteration and determine revisions to your approach?
How airfocus helps you work with your development team
In order to work effectively with your development team, you need to have a shared understanding about the outcome you’re trying to deliver. airfocus’ intuitive drag and drop interface and outcome based roadmap functionality help you build that shared understanding.
If you’d like a better way to reach shared understanding with your team, try airfocus today.
Kent McDonald
Read also
Experience the new way of doing product management
