"Great things in business are never done by one person. They're done by a team," Steve Jobs once said. This insight also applies to product management: As product people, we can't achieve product success on our own . We rely on the support of others including stakeholders and development teams. This article shares my advice on fostering collaboration and forming an effective maximise the chances of offering a great product.
Listen to the audio version of this article:
Organise the Team around a Product
As the name suggests, a product team is focused on a product. This sounds simple enough. But in practice, organising teams around products can be challenging, especially when a company lacks a clear understanding of what a (digital) product is and if it does not embrace a product-led way of working.
A first step to form effective product teams is therefore to identify the products in your organisation. But what is a product? I view it as an entity that creates tangible value for users and possibly customers as well as the business. The former is achieved by solving a problem or by providing a specific benefit. Think of Google Search, which addresses the challenge of finding information online, and Flickr, which allows people to share photos.
Creating value for the business can be accomplished in three ways: First, by directly generating revenue, like Adobe Premier Pro does, for example; second, by helping promote or sell other products or services, as an online store such as Amazon.com does; and third, by increasing productivity and reducing cost—something an internal software platform achieves, for instance.
Once you’ve identified and selected a specific product, you can take the next step and determine the people who are required to create or progress it and generate the desired user and business benefits.
Involve the Right People
For a team to succeed, it is crucial to have the right people on board. To effectively staff the product team, I recommend including the people shown in Figure 1.[1]
Let’s look at the product team members in Figure 1 in more detail starting with the person in charge of the product. This individual leads the product team, not by being the boss but by exercising emergent leadership. They achieve this by earning the trust of the team members and by embracing the right leadership styles: being a visionary, inclusive, and affiliative leader who empathises with the team members and practises active listening, as I discuss in more detail in my article Leading without Being the Boss.
Additionally, the person in charge of the product must have the necessary expertise. This includes a sound understanding of the market, the user and customer needs, and the competition as well as solid product management skills such as the ability to develop an effective product strategy and an actionable product roadmap (as I explain in more detail in the article The T-Shaped Product Professional).
Finally, the individual must be empowered to decide if no agreement can be reached within the product team. If you are familiar with my work, you’ll know that I am a big fan of collaborative decision-making—finding decisions that everyone can support. However, if the product team members cannot agree, then the person in charge of the product has to have the authority to decide. This avoids that the team is trapped in endless arguments and product decisions are delayed.
The key stakeholders in Figure 1 are representatives from different business units who are required to make the right decisions and effectively implement them. For a commercial product, they might include a marketer, a sales rep, and a customer support team member, as I explain in more detail in the article Getting Stakeholder Engagement Right.
To do a great job, each key stakeholder requires the necessary expertise, authority, and availability to work on the product team. For example, the marketer must be able to create the right marketing strategy for the product. Additionally, the stakeholders must be willing to act as team players, no matter how senior they might be.
Note that including stakeholders on the product team replaces a traditional stakeholder management approach with a much more collaborative one. Instead of sending status reports to stakeholders or having steering committee meetings, the individuals are now actively involved in progressing the product and they actively contribute to its success.
The development team representatives are members of one or more cross-functional development teams. It’s important that they have the right skills to spot and evaluate design and technology opportunities and to develop a rough understanding of the likely effort required to implement product decisions. The skills typically include architecture, programming, testing, and if the product is end-user facing, UX design capabilities.
If the product is too big to be managed by a single person, then the other product people who work with the person in charge of the product should also be on the product team. This ensures that their knowledge is leveraged and that their concerns are addressed. It also maximises the chances that everyone involved in managing the product has the same understanding.
Last but not least, the product team should include a coach who might be an experienced Scrum Master, agile coach, or product coach. Having this individual on board is beneficial, as the product team, as I have described it, is cross-functional and self-managing. It contains people with different roles and skills, and it lacks a manager who tells people what to do. Instead, the team members jointly identify and organise the work required.
All self-managing teams I have worked with greatly benefited from an experienced coach. Conversely, when the role was not properly filled, the teams either took longer to become self-managing or failed to do so altogether. This shows how important the role is. The specific tasks the coach should carry out include helping the team members collaborate, for example, by using a Kanban board, facilitating meetings, and removing blockers and impediments.[2]
Use the Right Goals
A team is, by definition, a group of individuals who work together on the same goal. As Henry Ford once said, “If everyone is moving forward together, then success takes care of itself.” It’s therefore important that you align the product team members by setting the right goals. To help you with this, I’ve created the framework shown in Figure 2.
The goal-setting framework shown in Figure 2 suggests that a product team needs four different objectives: a product vision, user and business goals, product goals, and sprint goals. Let’s take a look at them. The vision describes the ultimate purpose for creating the product and the positive change it should bring about. The user and business goals describe the value the product should create for the people using it and the company providing it.
The product goals communicate the specific outcomes a product should offer, such as acquiring more users, increasing engagement, and generating revenue. Each product goal should help you make progress towards a user or business goal. In a way, the product goal is the most important objective for a product team to achieve strong alignment and effectively progress the product. All product team members should work on the same product goal at a given point in time. This aligns everyone and ensures that the various deliverables and outputs—for instance, the source code, the end-user documentation, the marketing collateral, and the training materials—fit together.
The final goal in the framework in Figure 2 is the sprint goal, which directs the work of the development team members. It is derived from the product goal, and it describes the outcome of the next sprint. Meeting this goal should therefore be a step towards achieving the product goal. You can learn more about my goal-setting framework by reading the article Leading through Shared Goals.
Empower the Product Team
With the right people on board and the right goals in place, we’ve addressed two building blocks of effective product teams. But to become a high-performing team, the group must be properly empowered. Rather than being handed a vision and being assigned user, business, and product goals, I recommend that the product team has the authority to determine the goals—within the boundaries set by the business strategy and, if applicable, the product portfolio strategy. [3] Figure 3 illustrates the team’s ownership of the goals. Additionally, the team should have ownership of the plans that contain the goals: the product strategy and the product roadmap, as shown in Figure 2 above.[4]
If the product team has this level of empowerment, then there are three consequences: First, the team members will have to carry out the necessary work to determine the right goals and develop the right product strategy and roadmap as well as to regularly review and update the goals. This is best done by having regular, collaborative strategy workshops as well as attending sprint review meetings. The latter ensures that the team members have a shared understanding of the development progress and its potential impact on achieving the product, user, and business goals.
Second, the team members should determine the goals together. This is best achieved by using collaborative decision-making techniques including the selection of the right decision rule, for example, using unanimous agreement or consent, as I explain in more detail in my article Making Effective Product Decisions.
The final consequence is that the product team members are collectively responsible for meeting the goals—with great power also comes great responsibility, as all Spiderman fans will know. It’s the job of the product portfolio manager or the senior management sponsor to hold the product team accountable for meeting the goals with the person in charge of the product being the primary point of contact.
Build Trust and Create Psychological Safety
An effective team is not a loose collection of individuals who happen to share a work assignment. It’s a tightly-knit group whose members trust each other. To achieve this, give the product team members the opportunity to get to know each other, for example, by (partly) collocating the team and by carrying out team-building activities. This is especially helpful when the team is new or when its composition has changed. Additionally, as the person in charge of the product, you should lead by example and be willing to trust the other team members. This includes supporting and empowering the individuals, empathising with and actively listening to them.
In addition to trust, a high-performing product team requires psychological safety. People have to know that they won’t be penalised when they make a mistake. That’s particularly crucial when innovation is present, as this requires the ability to experiment, fail, and learn. As Albert Einstein said, “A person who’s never made a mistake has never tried anything new.”
To create psychological safety, be willing to admit mistakes and share stories of your own failures. Additionally, hold people accountable for meeting agreed goals. But don’t lay blame or accuse but empathise with the team members when a goal is not met. Then look into the causes and explore how you can correct the situation and avoid the same issue from recurring, for example, by using my feedback framework.
If you find it challenging to build trust and create psychological safety, consult the product team coach who should be able to advise and support you.
Form the Team Early on and Keep it Stable
The only constant is change, and product teams do change over time. But if the team composition changes too frequently—for example, a new sales rep or marketer shows up every other month—then the team is likely to experience low productivity, handoffs, and loss of knowledge. As pointed out earlier, effective teams rely on trust, and building trust and becoming a closely-knit unit does take time.
You should therefore aim to keep the product team stable. Ensure that the team members understand that they’ll be working on the team for an extended period—months and years rather than days and weeks.
Additionally, form a product team early on in the product life cycle. The team should be assembled in time to carry out the initial discovery and strategizing work. It should continue to exist until the product is discontinued. This fosters long-term thinking and gives the team members the opportunity to develop a deep understanding of the market and user needs, the competitive landscape, and the underlying business model.
Notes
[1] The product team composition shown is influenced by Steven Haines‘ and Marty Cagan’s work as well as team concepts made popular by agile frameworks like Scrum including self-managing and cross-functional teams who are empowered and practise collective ownership. Additionally, it is based on my leadership work, especially my book How to Lead in Product Management.
[2] If you are interested in how a product team as I have characterised it and a Scrum team relate, refer to my article Product Teams in Scrum.
[3] Note that the following list does not contain the sprint goal, as it should be set by the person in charge of the product together with the development team(s), assuming that a Scrum-based process is used.
[4] As you may have noticed I didn’t list the product backlog. Here is why: I find it most helpful to view the backlog as a tool that directs product delivery and that is jointly owned by the person in charge of the product—as well as the other product people on the team in the case of a large product—and the development teams. But I recommend that you connect your backlog to the roadmap by copying the next goal on the next product goal on the roadmap into the backlog, as I explain in more detail in the article The Product Roadmap and the Product Backlog.
Post a Comment or Ask a Question