What is the product trio? 

The product trio is the deliberate coming together of three key roles related to product discovery and development: The Product Manager, the Engineer, and the Product Designer. In the product trio, these cross-functional roles work collaboratively to help inform decisions and ideation that lead to a much better product. 

See, before the product trio, each of these roles would usually operate in a more isolated way. Each would be focusing on their area of expertise with little crossover, aside from a weekly stand-up where more often or not you learn that your efforts were misaligned. 

By creating the product trio, you give every role visibility of the product development at every stage. Each role is involved from the very beginning. The Engineer and Designer have access to product discovery, the Product Manager is clued up about the build stage, and in general, there’s more accountability and collaboration in this model. 

This close collaboration means that decisions are made faster, roadblocks are cleared more efficiently, and everyone stays on the same page. It’s not just about building great products; it’s about building them with less friction and a whole lot more fun.

Each role typically champions one of three core product concerns: 

• Viability: This covers the commercial aspect, examining whether a product is a sound investment. The Product Manager focuses on aligning the product vision with business goals, ensuring that the product makes sense in the market landscape.
• Desirability: This refers to the degree to which customers need and value a solution. The Product Designer often leads the charge in understanding user needs and translating those into design solutions that resonate.
• Feasibility: This is all about the technical side of things. The Engineer evaluates whether the proposed solutions can be realistically built, ensuring that the design aligns with what is technically possible.

Without the product trio structure, these responsibilities are isolated to the specific role only. This can lead to annoying situations where a Designer has dreamed up a stunning product idea, only to be told that it’s not feasible by an Engineer. 

The idea with the product trio is that over time, the constant visibility and synced-up nature of the team will make team members start to consider other things. A Designer will start to think about the viability of their idea, ensuring that it delivers the best user experience while also helping to achieve business objectives. This fluidity encourages the team to think beyond their primary roles and tackle challenges from different angles, creating more efficient product development. 

What are the three roles in a product trio? 

We’ve touched on them a bit, but let’s dive deeper into the three roles that make the product trio what it is.  Each role brings a unique perspective and set of skills to the team, contributing to a well-rounded approach to product development. Let’s take a little look: 

1. Product Manager

Hey, that’s you (most likely anyway). Now, a lot of people view the Product Manager as the captain of the ship, the leader of the product trio. We don’t like that, because it suggests that the other roles aren’t as important – and that’s just not true. You need the Engineer and Designer as equally as you need the Product Manager. 

Instead, let’s consider the Product Manager as the driver. They steer the direction and ensure that what gets made aligns with the company vision. They define what to build through a Product Requirement Document (PRD) and track the progress through the roadmap. 

By the way, if you need a hand putting together a PRD, we’ve got this handy template you can download and edit to make your own. 

So what will a Product Manager do within the product trio? Well, some key responsibilities include: 

• Vision and strategy: The PM establishes the product vision and long-term strategy based on market research, user feedback, and business goals. 
• Prioritization: With limited resources and time, the PM prioritizes features and initiatives, balancing customer desires with technical feasibility and business viability. 
• Stakeholder communication: The PM serves as the bridge between various stakeholders, ensuring everyone is aligned and informed about product goals, timelines, and updates. 
• Performance tracking: After launch, the PM monitors product performance through analytics and user feedback, iterating on the product based on insights gathered. 

For a full list of Product Manager tasks and responsibilities, check out the article below: 

2. Designer

The Product Designer is focused on making your product look and feel good, creating user flows, and thinking about the UX and UI of the product to enhance customer experience. The goal here is to make something user-friendly, highly functional and good looking. They’re focused on making your product as desirable as possible. Some key responsibilities include:

• Prototyping and wireframing: Using customer research, the Designer creates prototypes and wireframes to visualize how the product will look and function. This allows for early feedback and iterative improvements before development begins.
• UI/UX design: The Designer crafts the user interface and experience, focusing on creating a seamless, engaging journey for customers. 
• Collaboration with Engineers: The Designer works closely with the Developers to ensure that the design can be implemented effectively. They provide specifications and support during the development process, addressing any design-related questions or challenges.

3. Engineers

These guys are the builders. The people who turn your concepts and ideas into tangible software and tools that can be used and experienced. They’re down in the nitty-gritty of writing code and managing the technical aspect of the product to bring it to life. 

It’s important to see your Engineer as a core role within your product trio and wider product team. If you dismiss them from the earlier planning and put them in the box of ‘engineering’ or ‘development’ you’ll isolate them and build walls that keep them in the dark when it comes to the wider process. Shine the spotlight on your Developers and make them a standout part of your team. 

The things Engineers should do in a product trio include: 

• Technical feasibility: The Engineer assesses the feasibility of proposed features, evaluating whether they can be built within the existing technical constraints. 
• Development: The Engineer writes code and builds the product according to the design specifications provided by the Designer. 
• Responding to testing and QA findings: Engineers work closely with the QA Team who conduct testing to ensure the product functions as intended. Developers will work to fix any bugs identified during QA to  optimize performance, and enhance the overall quality of the product or feature before launch.

What are the advantages of the product trio team structure? 

So what’s the allure of the product trio? Why is it becoming a fundamental team structure that more and more PMs and Product Teams are following? Well, the simple answer is that it’s better than what we were doing before. It’s transforming the potential of product teams, making them more effective while helping them to build bigger and better products. The list of benefits is extensive. 

Collaboration

The biggest, most identifiable benefit of the product trio is that it boosts collaboration to a whole other level. It fosters a unique blend of skills and expertise that helps improve execution. 

You’re all in a better position to make informed decisions on the product, as you’ll ALL understand user needs, technical capabilities, and business objectives. It resolves conflict quickly and prevents conflict. 

User-focus

The composition of the product trio helps to emphasize a commitment to a user-centric approach to your product development. Of course, this is down to you as the Product Manager as you uncover user insights and conduct customer research. However, because of the close-knit nature of the product trio, the rest of the team will have a deeper understanding of customer needs and pain points, helping them to create a better product. 

Alignment

A well-formed product trio ensures that everyone stays aligned on the product’s direction. With the Product Manager, Designer, and Engineer working side-by-side, there’s less room for miscommunication or silos. Everyone is clued in on priorities and can make adjustments on the fly without losing sight of the bigger picture. It’s like having three parts of the brain working in perfect unison, keeping the project on track and on point.

Speed

By having this trifecta of talent working closely together, the product trio naturally speeds up the development process. With quicker feedback loops and real-time problem-solving, decisions can be made rapidly. No more waiting around for approvals or lengthy email threads – just fast, effective action that gets things done and moves the product forward.

What are the common mistakes when implementing a product trio structure?

Of course, to get the most out of the product trio, you need to do things properly. You may already be working in a product trio, and that’s fantastic. Yet, far too many teams are making key mistakes in how they operate this squad, making the whole framework kind of pointless. These mistakes are known as anti-patterns and can reduce the effectiveness of your product trio. 

Let’s take a look at these common mistakes – these anti-patterns – and explore the solutions to these problems so that you can make sure that your product trio structure is effective. 

1. Siloed work due to strictly defined roles

Sure, having clear roles can help keep things running smoothly and give your team accountability, but when boundaries become too rigid, collaboration can suffer. 

Despite the product trio being designed to help you avoid it, team members may start working in silos and focus on their strict duties. People can begin to disengage from parts of the project that technically fall outside their remit. The result? Inefficient handoffs and missed opportunities for input.

The solution:

Break down those walls! Encourage a more collaborative approach where everyone, regardless of their title, can contribute their insights. Let your Designer, Engineer, and Product Manager weigh in on every aspect of the project, fostering a sense of ownership and keeping communication lines wide open. You can do this with regular standups to track progress, as well as by having a roadmap that’s visible to all. After all, teamwork makes the dream work, right?

If you use ProdPad as your central Product Management tool, then you’ll be able to give everyone in your whole organization the ability to easily submit product ideas, feedback or join discussions and see progress of everything in your backlog and beyond. This is how you foster a true product culture where contribution from everyone is encouraged and supported. 

2. Separating the product trio from the rest of the team

There are many roles, outside of the product trio, that play a massive part in product development. There’s a risk, if you focus too much on the product trio alone, that you make it feel like a secret club, ignoring everyone else. You don’t want to employ the product trio structure in a way that makes the rest of the team feel left out and on the fringes. 

There’s a particular risk of the secret club effect during product discovery work. When the product trio work in isolation, it creates a disconnect with the broader team, leading to handoffs that fall flat, misalignment, and poor communication. If the rest of the team doesn’t feel involved from the start, they’re less likely to rally behind the product vision. Heck, if they’re that isolated, they might not even be confident about what the product vision is.

The solution: 

Product discovery doesn’t have to be a closed-door meeting. Involve the rest of the product team as much as possible, tapping into their skills and interests. You could even set up a dedicated Slack or Teams channel for the “Product Trio,” open to the whole team, where discussions are transparent and inclusive. This keeps everyone on the same page and invested in the product’s success from the get-go. The product trio should sit within the whole Product Team, and not become its own separate entity. 

3. Role confusion

Remember what we said about having strictly defined roles? Well, turns out there’s some nuance to that. Although you don’t want to create a rigid environment where there’s no overlap or accountability for tasks outside of a team member’s remit, you don’t want to do a complete 180 turn and be too fluid. 

When roles overlap or responsibilities aren’t clearly defined, things can get messy – fast. If, say, the Product Manager starts making design decisions without consulting the Designer, it can erode trust and stifle collaboration. You don’t want to be stepping on other people’s toes.

The solution: 

Clarity is key! Clearly define each trio member’s role while encouraging open dialogue. Everyone should feel empowered to leverage their expertise and challenge each other’s perspectives in a constructive way. 

By maintaining a healthy balance of authority and collaboration, the product trio can avoid stepping on each other’s toes and keep the focus on building an awesome product. You don’t want to be rigid like a stone in your roles, nor do you want to be completely fluid like water. The sweet spot is being a nice, wobbly jelly where there’s some flexibility. 

4. Lack of shared vision

If the trio isn’t aligned on the product vision, things can go off the rails quickly. One person might prioritize features based on market trends, while another is all about aesthetics. You need to have a unified direction or a North Star leading the way, kind of like the Three Wise Men. Without it, you’ll become directionless and the product risks feeling disjointed and missing the mark.

The solution: 

Regularly revisit and refine the product vision as a team. Make sure it’s a shared goal that everyone not only understands but actively supports. Everyone in the product trio needs to live and die by the vision. It’s the why to everything you do. Alignment is key to making informed, cohesive decisions that drive the product forward in a meaningful way. Here are some great product vision examples to inspire you.

5. Ignoring user feedback

No matter how well the trio works together, ignoring user feedback is a surefire way to build a product that doesn’t meet user needs. If the team gets too wrapped up in internal discussions or preconceived ideas, they can easily miss out on game-changing insights from real users.

The solution: 

Keep your users front and center by making customer feedback a non-negotiable part of the decision-making process. Prioritize user testing throughout development, and let those insights guide design and feature choices. Remember, the best products are built with users, not just for them.

5. Overemphasis on process

Processes are great for keeping things on track, but when the trio sticks too rigidly to them, creativity and innovation can take a hit. Sticking to the playbook when the situation calls for a pivot can limit the team’s ability to respond to new insights or opportunities.

The solution: 

Flexibility is your friend! Encourage a culture where the trio can adapt and change gears based on new information. Being open to experimentation and shaking up processes can lead to innovative solutions and a product that’s always evolving, just like your users.

The rule of threes 

In the world of product development, the magic of three shines brightly through the product trio. By integrating the unique strengths of the Product Manager, Designer, and Engineer, teams can foster collaboration, enhance alignment, and speed up the development process. This trifecta empowers each role to contribute to a shared vision while remaining aware of the broader implications of their work.

The product trio isn’t just a structure to follow; it’s a mindset that encourages cross-functional teamwork and a user-centered approach. As you consider implementing this model, remember that maintaining open communication and flexibility is key to avoiding common pitfalls. Embrace the power of collaboration and let the product trio be your guide in creating exceptional products that meet both user needs and business goals.

The product trio allows you to create a better product. ProdPad helps with that too. Our tool gives you the functionality you need to become a better Product Manager. Why not give it a try yourself to see what we’re talking about? 

The post The Product Trio: Why Three is the Magic Number appeared first on ProdPad.

Why is Product Team Structure important?

The structure of your product team is the spine that supports how you do things. It dictates how ideas flow between teammates, how decisions are made, and ultimately, how successful your product becomes. Without the right structure, even the best ideas can get lost in the chaos, and your team might end up feeling like they’re constantly on the back foot.

A well-thought-out team structure ensures that everyone knows their role, who they report to, and how their work contributes to the bigger picture. It’s the difference between a symphony and a garage band—both can make music, but one is a lot more likely to hit the right notes consistently. It helps with task prioritization, making the whole team more efficient, innovative, and, let’s be honest, a lot more fun to work with.

What are the benefits of a solid Product Team Structure?

Putting together a great product team structure comes with many benefits. Would you like to hear them? Of course, you do. Nailing your product team structure can: 

• Improve communication: A well-structured team knows who to talk to and when, cutting down on mixed messaging and “I thought you were doing that” moments.
• Enhance collaboration: By building a team structure that better connects departments and roles, you’ll be better equipped to work on the same goals. 
• Boost efficiency: When everyone knows their responsibilities and what everyone else is working on, there’s less time wasted on duplication of effort or stepping on each other’s toes. Just smooth sailing ahead.
• Accelerate value delivery: A strong structure allows your team to move faster from ideation to execution, bringing valuable features to your users before they even knew they needed them. 
• Increase product quality: With a balanced team, every detail gets the attention it deserves, leading to a polished product that your users will love—and that you’ll be proud to ship.
• Strengthen accountability: By knowing what everyone is responsible for, a solid product team structure makes it easier to track progress, celebrate wins, and address any hiccups before they become full-blown issues.

Roles on a product team

To build the best product team structure for you, you need to first understand the various roles that can fit into a team. These roles are your building blocks, the Lego pieces you need to fit together to create an effective team. 

Some of these roles are essential – you won’t get away with not having them in your product team – while others can supplement your team depending on factors like your industry, type of products, and finances. It’s best practice to have defined roles with specific responsibilities, but we all know that best practices can often end up as a pipe dream. 

Many team members within a product team structure will wear multiple hats depending on what your company needs. A Product Designer can also fulfill the responsibilities of a UX researcher. A Product Manager may also be doing jobs that may fall under the job spec of a Product Marketer.

The number and types of roles in any product organization will vary. Because of that, we’ll cover the core and supplementary roles that are possible. 

First, let’s look at the key roles that you’ll see in 99% of product team structures:

1. Product Manager

The role of a Product Manager is multifaceted, and the scope of responsibilities and tasks will look different for every team. In a nutshell, the PM is focused on the entire product strategy, owning the product vision, collecting user feedback, leading product discovery, and bringing vetted solutions into reality. Sounds like a lot right? Well, that’s because it is. 

In bigger teams, some of the responsibilities can be delegated to other roles to support the Product Manager, but for many, they’ll be working around the clock to complete these tasks.

2. Product Owner

The Product Owner is like a Product Manager for your agile sprint cycle. One of their main priorities is to review the backlog and act as a representative for your customers by understanding their needs and writing user stories.  

There are a few other key responsibilities of a Product Owner. You can check out the full list below to help you better spec out the role . 

Now here’s when things get complicated. In small teams, the Product Manager can also be the Product Owner. That’s because it’s best to think of the Product Owner as a responsibility instead of a defined role. It’s one of the many hats that your team members can wear. 

Regardless of whether it’s a separate role or a responsibility, you need someone to complete the tasks attributed to the Product Owner, so it’s still a crucial role you can’t ignore, even if it is fulfilled by a pre-existing team member.

3. Product Designer

The Product Designer is responsible for making your products look good and feel intuitive to use. You need this role in your product team structure if you’re hoping to build an effective product that works. Concepts like UI (user interface) and UX (user experience) rule the designer’s world. 

Again, depending on the size of your team, a Product Manager will often be dipping into a Product Designer’s responsibilities. However, if you’re looking to restructure your team and define the specific responsibilities for each role, read on about the difference between a product manager and a product designer.

4. Engineer

The engineer’s role is pretty self-explanatory. They’re the people putting the product together, often coding the software and bringing the ideas from the Product Manager to life. It’s important to see the engineer as a core role of the product team, and not exclusively belonging to “engineering” or “development.” 

The product team needs an engineer’s perspective on the feasibility and viability of any product solution. Your team may have an amazing, outlandish idea, but an engineer will help keep your feet on the ground and ensure you only focus on what’s possible to make. 

Supplemental roles on a product team

If your team is big enough and has enough resources, you might invest in additional roles that support the core product management team.

These roles could be:

• Product operations. These folks are devoted to optimizing the way the product team works, through tools, data analysis, and other facilitation. Learn more about how your team could harness the power of product operations.
• Data analyst. When SaaS analytics tools just don’t cut it anymore for a complex product, a product team might bring on their own dedicated data analyst to support product discovery and retrospectives with key performance metrics being tracked.
• UX researcher. Since understanding and improving the user experience is central to great product management, a full-time UX researcher might come on board to support the team.
• Growth marketer. Some of the most effective product feature changes can actually be a matter of product marketing, rather than hard code. Working hand-in-hand with a growth marketer brings a wider range of ideas and solutions to the table.
• Legal expert, business analyst, or domain expert. These specialists especially come in handy if you’re in a highly regulated field, such as finance or medicine, or when launching in a new market.
• Customer Success Manager, or Account Manager. Most of the time, the most valuable insights don’t come from the Product Leaders themselves but from the external customers. Having the customer experiences brought into the product development process via your customer-facing team brings that deep understanding of the customer base to the product team.

How to approach your Product Team Structure?

So, how do you piece all these product roles together? Well, there are many different formulations and constellations you can try to build a high-performing product team structure. Here are just five of some of the most successful ones that work well across multiple types of companies. 

The Product Trio

The product trio is a model that revolves around a Product Manager, an Engineer, and a Product Designer. Think of these as the three musketeers of product, combining to work together on Product Management as a whole or on a specific problem within a product.

Product trios are small by design, to facilitate collaborative decision-making while still being balanced. What makes this structure so effective is the tight-knit collaboration it fosters. Instead of working in silos, each member of the trio is involved from the very beginning, which means fewer surprises down the road and a more cohesive final product. Decisions are made faster, roadblocks are cleared more efficiently, and everyone stays on the same page. It’s a recipe for not just building great products, but building them with a lot less friction and a lot more fun.

A product trio is a flexible concept, and you can include other roles in this team if it works for you. It’s just that these there are the most common. For example,  if you’re a user-focused team, you can add a user researcher to your trio to make it a quad, or a squad.

Product squads

Product squads are similar to product trios, with the main difference being that they’re not limited to three people. A product squad is modeled after the product trio, with you then adding roles that might be key for your Product Development, based on your industry or goals. 

For example, if your company is expanding into a new market or region like Germany, you may want to create a ‘Germany Squad’ for that region that includes the core three roles as well as a legal expert who knows that domain.

The benefit of product squads is that they’re flexible and can be molded around your aims and goals. It gives you the ability to build your squads in a way that makes the most sense for your product. 

With squads, you’re empowered to tailor your teams to what’s needed, and failing to do so is a common sign of a poorly constructed team structure.

Cross-functional teams

The cross-functional team is an evolution of the traditional team structure, where different departments are grouped into their own siloed teams. In this traditional structure, product teams, engineering teams, and design teams are separate from each other, focusing on their specific work. This approach leads to each team operating as a faux agency for the other, handing over what’s required to other teams while waiting for their own requests. 

As you can imagine, this traditional approach fostered less collaboration, resulting in siloed thinking and mismatched product planning. The cross-functional team structure is designed to fix this. 

In a cross-functional team, a team is made up of folks with diverse skill sets, pinched from each department, working towards the same goal. With this team, silos are broken down to foster deeper collaboration between the company. You get a diverse range of perspectives and a shared sense of goals and responsibilities. The team members in these cross-functional teams are able to report back to their departments to ensure that the right hand knows what the left hand is doing.

User persona structure

One popular way to structure your product teams is to divide teams by user segments, or user personas. This is a good option for companies that serve different types of users, as this allows you to focus on and cater to the needs of different customers. 

In this model, you can divide your teams to focus on a certain type of user, with one team working to make the product better for one segment, while another focuses on a different one. This approach helps you position good customer experience as one of your core objectives, as each team works on addressing specific pain points and needs. 

For this structure to succeed, each team needs to fully understand the needs of the customers they’re building for. You’ll need to use data-backed insights, behavior analytics, and also consider running a Customer Advisory Board.

A negative of this approach is that it can harm coordination between different teams, making it important that the Product Manager implements ways to ensure good communication between these customer-focused teams.

Performance metrics structure

As long as you’ve clearly identified your target KPIs and metrics and have aligned them with business goals, you can decide to structure your teams by working to improve specific metrics. 

In this structure, each team – which can be a trio or a squad – performs tasks and creates features that help them achieve or enhance their North Star metric values. For example, one team can focus its effort on improving user activation, while another works on boosting customer lifetime value. This makes it easier to measure product success and gives each team a clear focus.

Be mindful that this approach to team structure isn’t for everyone. You’ll need a fixed set of KPIs that won’t change often, and you’ll also need highly coordinated cross-team functionality. If you need a hand picking the best KPIs and metrics to track, we’ve got a definitive list of PM KPIs you can download.

Product Team Structure in action

So you’ve seen the structures, but how does this work in real life? Well, we’ve spoken to Trevor Acy, who formerly held the role of PM and Associate Director of a 1000-team-member company with about 30 product teams, about how they approached their team structure.

But what about an example where things haven’t worked out that well? We’ve also chatted to Antonia Landi, a Product Coach & Consultant, who’s got a lot to say about what was learnt after a poor approach to getting an engineering team more aligned with business goals .

Who is responsible for setting the Product Team Structure?

So, who’s the mastermind behind setting the product team structure? Well, in the world of product management, that role usually falls to the Chief Product Officer (CPO) or other product leaders, depending on the size of your company. They’re the ones who have the bird’s-eye view of the product vision, company goals, and team strengths, making them perfectly positioned to assemble the dream team.

But this isn’t a solo gig. Setting the product team structure is often a collaborative effort, with input from key stakeholders like engineering leaders, design heads, and even HR. 

As a product manager, you definitely have a voice in the process. Your insights into how the team operates on the ground are invaluable when it comes to making adjustments or advocating for the right mix of people. You’re certainly one of the key advisors helping to shape the blockbuster team that’s going to build the next big thing.

Factors to consider for your Product Team Structure

When choosing a specific structure that works best for your team, there are a few factors you should definitely consider when evaluating your options. This additional context can help you determine which one is most effective for you. 

Some things you should make sure to do is:

1. Structure your team with experience in mind

The amount of product or professional experience can determine how you structure the team. If there are more senior Product Managers, then these seniors can be carved off into product trios or squads to work more autonomously. However, if the team leans more junior, you might choose a structure that provides more guidance or oversight.

2. Consider your product line

If you have a small product portfolio or specific short-term projects, you might want to structure around project (or “initiative”) teams. This teams-within-a-team, such as a single Product Trio, is focused on a particular goal or problem.

On the other hand, if you have a diverse suite of products, it might not be feasible to create separate mini-teams to manage each one. That takes a ton of resources and organization. Instead, you might choose to stay more integrated and centralized.

3. Consider the size of your company

This one seems obvious, but it’s worth saying. If you have a small company, your product team is likely also small. Structure options are pretty simple. But if you work in a large company, there might be more options and flexibility to try new team formulations. For example, with more designers and engineers in-house, the more likely you can pull one of each to create a cross-functional team.

4. Remember that change happens!

As product people, embracing change is basically our job. So, remember that teams are not fixed! Allow them to grow, flux, change, and evolve. Like your product lifecycle, your product development cycle style will change and evolve. The structure that works for you now doesn’t need to be the structure you use in a year.

Pitfalls to avoid in product team structure

When building a product team structure, there are many things you can get wrong. One major issue is diving into reorganizing your teams without first evaluating your goals and objectives. These play a massive part in how you build an effective team.

The best product team structure is designed, in part, to avoid some of these product management pitfalls.

1. Conflicting priorities. Individual teams that are working in silos, or without great communication, can end up working against each other! Structure wisely and align your teams by writing good objectives and key results.
2. Psychologically unsafe environment. No single ego or voice should dominate the team. Everyone needs to feel they can speak up, challenge decisions, and make bets.
3. Poor meeting management. Even the best team structure can feel ineffective or annoying if meetings are: a) useless, or b) not frequent enough. Learn how to run a great product team meeting.
4. Using the wrong tools. It’s really important to invest in the right tools for product management teams. So important that we’ve dedicated a whole section to it!

Tools to facilitate good product team structure

No structure will work well if people aren’t supported with the right tools! Designers need their design tools; developers need their engineering tools.

But what about all the cross-functional collaboration we just talked about? You need to find the right tools that help the team work together. There are several categories of collaboration tools, which include:

• Video meetings, such as Zoom
• Messaging, such as Slack
• Virtual brainstorming, such as Miro
• Project management, such as Trello
• Product analytics tools, such as Mixpannel

If your team is hybrid or fully distributed, check out these tools for remote teamwork.

Building the Dream Team

When piecing your product team together, there’s a lot to think about to ensure that it works. You need to focus on crafting a team that matches your needs, focuses, and aims, as well as budget. Whether you opt for product trios, squads, cross-functional teams, or something different, you need to do your discovery and research to make sure that it’s best for you. 

A good product team structure is designed to make you a better team and ultimately, create a better product. The way you organize your teams is vital, but you’ll miss the mark if you’re not empowering these teams with the right tools. We’ve already mentioned some of the most effective collaboration tools but purposely foregoed to mention one of the most important: your product management tool. 

As your centralized platform for your roadmaps, planning, idea generation, and more, you need a product management tool that facilitates effective collaboration within your team structure. ProdPad does just that . 

In ProdPad, you’re able to capture feedback, ideas, and strategy all in one place. It also helps you present your product roadmap, manage experiments, and measure outcomes, boosting transparency and accountability within your entire team. If you’re not already in love with ProdPad, why don’t you give it a try? 

The post How to Nail Your Product Team Structure appeared first on ProdPad.

We will cover:

• Why it’s important to train them
• What does useful product feedback look like? 
• The challenges of getting good feedback from your customer team
• How to train your customer teams to speak to the roadmap 
• How to structure a training session
• How and when to deliver the training
• Examples of good product feedback to show them
• Don’t let them forget! 

You’ll also get a downloadable, editable, ready-made slide deck to use with your teams to deliver this training.

But first…

Why is it important to train your customer teams to get useful feedback?

Because it will make your job easier, faster and more successful. Simple as that.

If what your customer teams submit as feedback from users is the best it can be, it will significantly cut down the amount of time you have to spend deciphering, interpreting and extracting insight from each piece of feedback. 

It’ll require less follow-up questions from you, less digging and delving. If you’ve coached your customer team mates to ask the right questions and capture the right insight, then that is a job you don’t have to do. 

Nearly all the Product Managers we speak to have experienced the same problem at one point or another. A Support rep submits some user feedback to the Product Team which just reads “customer wants a calendar integration”. Sigh. Now you have to send the customer an email, or pick up the phone and ask them why. Why do they think they need a calendar integration? What is it that they think a calendar integration will do for them? Are they hoping to reduce the number of missed appointments? Are they just wanting to cut out the need to manually update their calendar? Or maybe they want everyone else in their family to know about the appointment? What is the problem they need to solve? 

Because it’s only once you know the fundamental problem they have, that you can evaluate the best way to solve it. And yes, that might end up being a calendar integration, but it might equally turn out to be a new push notification or an automated SMS. 

If you don’t uncover the problem to solve for each piece of user feedback, then you’ll end up in what Janna Bastow (our CEO and Co-Founder and inventor of the Now-Next-Later roadmap) calls The Agency Trap. If most of the pieces of feedback your Customer Teams send over are actually feature requests, then you can easily end up building to order. Functioning like a software agency rather than a product-led organization. 

So, to be truly effective as a product company, you’ll want to be finding out the problems your target customers have and solving them in the best possible way. And training your customer teams to get to the heart of the problem, is one of the important ways you can achieve that. 

What does useful product feedback look like?

Before we launch into how to go about this training, let’s decide what the end goal is. What exactly is useful feedback? What does it look like? 

Here are the core principles of useful product feedback.

• It’s clear who the user is and what type of customer they are  
• It explains what the customer is trying to achieve
• A problem or challenge has been articulated
• There’s an understanding of how often this problem is felt
• There’s an indication of how important solving this problem is for the customer
• The situation or context of the customer is noted
• The motivation for getting this task done has been identified

Now, I must caveat that list. That is the absolute dream. If every bit of feedback ticked all of those boxes you would be flat out winning at Product Management and Customer Experience. The reality won’t be quite so perfect… but this gives you something to aim for! 

What it boils down to is this… you want feedback to tell you the customer is trying to achieve, what problem they have encountered and how important solving that problem is to them.  

The challenges of getting ‘good’ feedback from your customer team

Over in our article 5 Ways to Get Customer Teams to Share User Feedback, we covered the reasons why it’s often hard to get any sort of feedback shared by your Customer Teams. But here we’re concerned with the quality of that feedback. 

So why is it hard to get the right kind of feedback from these colleagues? 

The customer is always right

You’ve heard this right? Customer Service or Support reps will have this mantra gently whispering away to them all day long. They’ll have grown up on this principle – it’s ingrained and underpins all their customer interactions. You don’t disagree with the customer, you don’t argue with them!

And, of course, we don’t want them to disagree with the customer! We just want them to delve a little deeper. We want them to help the customer really understand what is at the heart of their request. It’s about not just taking what they’ve said at face value and reporting it back to Product verbatim. 

But this isn’t easy and maybe it doesn’t come naturally to Customer Teams. They aren’t therapists after all. 

It takes longer

Customer-facing colleagues are often super busy (isn’t everyone ), so taking the time to dig deeper can often be something they don’t have the time to do. 

It is far quicker to just make a note of what the customer has said and ping it over to Product. Done job. 

How to train your customer teams to speak to the roadmap 

This is another advantage of having your Customer Teams well versed in delving into the problems underlying their customers’ feedback. 

Let’s say a customer declares that they need a certain feature. Once your customer teammate has successfully taken that request back to the underlying problem they want to solve, now they should be able to talk to the different ways that problem is already being looked at by the Product Team (if it is). 

This is why it’s important to have your roadmap structured around problems to solve. It makes it super easy for a CSM to hear a problem, find said problem on the roadmap and advise the customer of where that sits in the priorities. And maybe even give them some sneaky previews into the different ideas that are being explored as a part of the initiative to solve that problem. 

They can even invite the customer to be part of the discovery or testing of the solution! That will go a long way to making them feel listened to, valued and invested in the product.  

They will have flipped a simple feature request into an exploration of the customer’s struggles or desires at the same time as giving them a window into the scientific workings of the Product discipline, tirelessly working to discover the best solutions. Trust me, the customer will walk away from this feeling impressed. It’s win/win. 

How to structure a training session

By now I think we’re clear on what useful feedback looks like and why it’s important to coach the Customer Teams to be able to deliver it. But how do you actually go about coaching this stuff? How should you explain it to them? What tips and advice can you give to help them coax out the most useful insights? 

Here’s how you should structure your training. 

1. Tell them why it matters
2. Explain what is in it for them
3. Be clear about what the most useful feedback looks like
4. Give them examples of great feedback
5. Outline the questions to ask
6. Show them examples of flipping feature requests into useful feedback

Tell them why it matters

When it comes to training your colleagues around this, the first job is to win their enthusiasm for the task. You need to convince them that working to delve deeper into customers’ feedback is worth their time and effort. So start by focusing on winning them over to actually being coached in the first place. If you fail to explain how important this is, in a way that means something to them, then they ain’t gonna be listening all that well. 

Explain what is in it for them

Which is why it’s worth giving them the overall benefits to the organization – providing you the right insights to ensure you can build the most valuable product for your customers and therefore increase retention and acquisition – but ALSO the more immediate benefits that will directly impact them and their job. 

Those might include:

• Better relationships with their customers (thanks to talking for longer, digging deeper and increasing their understanding), making communication easier and interactions happier.
• Being able to deliver more positive news more often – rather than saying ‘no we don’t have that feature’, they can say ‘we’re actually exploring how to solve that problem in a better way’.
• Having to deal with far fewer disappointed customers who expected a feature request to be actioned, but instead understand that their problem is going to be explored.

Be clear about what the most useful feedback looks like

Next, you’ll want to be explicit about what useful feedback looks like. So take the principles we’ve covered above and explain them to your trainee. But don’t just use the theory, make it crystal clear with some concrete examples. 

Give them examples of useful feedback 

Whether you actually find a great example from your real feedback inbox, or you make something up to illustrate the point, make it crystal clear by showing them something concrete. 

Outline the questions to ask

Now they’ve seen what the end goal is, take them through the best ways to get there. Here you need to arm them with a list of questions to help them dig deeper, help the customer unpick what it is they need, and get to the heart of the problem. 

Those questions could be:

• What do you think that feature would do for you?
• Why do you feel you need that particular functionality?
• What is the problem you believe that feature will solve?
• What are you trying to do?
• What is the outcome you want to achieve?

Show them examples of flipping feature requests into useful feedback

This is a top tip from our Head of Product here at ProdPad, Kirsty Kearney-Greig. She has done this with our Customer Teams to great effect. It involves picking out a real piece of feedback that they have submitted to the Product Team and flipping it from less useful feedback to some very valuable insight. 

Having the two interpretations side by side is extremely helpful when it comes to understanding the difference. 

Original piece of feedback:

“The customer wants access to the revenue fields via the API.”

Improved feedback after delving deeper and asking the right questions:

“The customer has a monthly report for the Board that requires them to add their revenue numbers per agent per week. Cutting and pasting them from the Rental Report in our product is taking about 2 hours of their time each month. This is time they don’t have to spare! They were wondering whether they could access the right revenue fields via the API and set up an integration that will automatically feed the data into the Board report. They need a solution that greatly reduces the time they have to spend on this task, if not remove it completely.”

How and when to deliver the training

You can’t just email this around and expect much to change. This is coaching that needs to be delivered face to face (well, face on a screen to face on a screen at least). You want to speak directly to your trainees and be able to see their reaction (so you can respond accordingly). 

Do it properly – use a slide deck

So I would urge you to deliver this training to them formally. By that I mean that you’re explicitly standing in front of them, with a slide deck, at a pre-planned time. Don’t worry, that’s as formal as it needs to get. I’m not suggesting everyone has to wear a suit and keep a straight face. The important thing is that this doesn’t come in the form of a passing comment or two. You need to get across the importance and therefore you should give this training the gravitas it deserves. It will help set the right tone and expectations with the team. 

If the thought of creating a slide deck for this fills you with dread, do not worry! We have you covered. We’ve knocking up a ready-made deck for you to download and use with your team. So all you need to do is book in the time with them.

Get a slot in their regular team meetings

In terms of when to deliver the training, there are a few pointers I can give here. If you can, try and deliver the training to multiple customer-facing colleagues at the same time. And try to ensure their managers and leaders are in the room. It’s a good idea to speak to the commercial leaders beforehand and stress the importance, asking for their support in encouraging their teams to work in this way. 

But, if your customer-facing teams are doing a good job, their calendars will be full with customer or prospect calls. So finding a time in the diaries can be extremely tricky. Therefore, it’s a good idea to get yourself a slot in their existing, regular team meetings – that way you know everyone will be there and you don’t have to struggle with finding a time. 

Or do a roadshow

If even that is proving hard, then you could consider taking your slide deck on the road. Yes this will take up more of your time, but I’m hoping you’re sold on the value this could bring! Slot yourself in with each team member for half an hour and run them through the training. 

Make it part of onboarding

Then, once you’ve gotten around everyone, you’ll need to think about new starters. Here I would suggest you speak to HR or the team leaders and ensure this training becomes a standard part of any new starter onboarding for any customer-facing role. 

Don’t let them forget! 

Once you’ve delivered the training to your customer-facing team mates, don’t dust your hands off and walk away. You need to keep reiterating this message if you stand any chance of it becoming a habit for your colleagues. 

This should be considered as ongoing coaching rather than just one-off training. So whenever you spot a piece of feedback coming from a team mate that falls into the ‘not as useful as it could be’ category, take it to them and give them that feedback in the moment. Work with them on how it could be delved into and the exploratory questions they could have asked. 

The post How to Train Customer Teams to Get Really Useful Feedback appeared first on ProdPad.

Why is it important to get internal stakeholders to share product feedback?

But first, why do you need to bother with this? You speak to your customers and users right? Isn’t that enough? Why do you need to struggle away trying to extract insight from other people in the organization?

Because, wonderful as you are, you can’t possibly gather ALL the feedback yourself. A big part of your role as a Product Manager is to speak directly with the users of your product, listen to their feedback and explore their problems. But you have customer-facing team members in the organization who are engaging with multiple individual users all day, every day. If you’re not tapping into that, you have a big hole. 

As Kirsty Kearney-Greig, our Head of Product here at ProdPad says…

For Kirsty here at ProdPad, it’s especially important that her and her team hear all the feedback coming in from customers, because, without it, there’s a risk that she could become blinded by her own experiences. 

I’ll let her explain…

Without a broad range of customer feedback, from as many different flavors of your user base as possible, you’ll fail to understand the whole gambit of experiences and needs and, as a result, fail to take them into account when you’re prioritizing your roadmap, assessing product ideas and deciding what you build and when.  

The challenges of getting stakeholders to share customer feedback 

Getting your hands on all that great insight your customers are sharing with other colleagues is easier said than done. And that is for a number of reasons. 

1. Everyone is busy

Tell me the last time you managed to get through every single thing on your to-do list, exactly in the order you initially planned it. It doesn’t happen right? And especially if you’re in a reactive, customer-facing role. Hopping from one customer or sales call to another all day long. It’s hard to fit in requests from other colleagues. They will certainly get pushed down the priority list as urgent issues come in from customers or revenue-generating activities need to happen.

You tend to get a lot of “oh, I’ll log that feedback later” – with people planning to come back to it at the end of the day and add all the feedback they’ve heard. That’s high-risk for you as a Product Manager. If ‘share feedback’ becomes an item on a to-do list instead of happening in the moment, then there’s a high chance it gets bumped down the list and might not even happen at all. 

2. It’s your job, not theirs

This sounds harsh, but it’s real life. When customer-facing teams are measured on call volume, response time, resolution time and revenue, they are always going to prioritize the tasks that most immediately impact those metrics. This is another reason that sharing feedback can, all too often, slide down the to-do list, in favor of those activities that relate directly to their own KPIs. 

Obviously, longer term, sharing customer feedback and having that impact the decision-making in Product will ensure the product develops in line with customer needs. That will lead to improved customer satisfaction, fewer sales objections and more revenue. But there’s a longer tail to realizing that benefit, and when you have immediate KPIs to hit, it’s not always front-of-mind. 

Even when you do manage to convince your colleagues to send through feedback to you in the Product team, there are challenges around how that is delivered to you and the format it arrives in. 

3. You’re getting feature requests and product ideas rather than feedback

Does this sound familiar to you? A colleague has spoken to a customer and sends you a message (in whatever format that comes) to tell you ‘the customer wants X feature’. End of message. 

How useful is that to you? Not very. Why do they think they need that feature? What do they think that feature will do for them? What is the problem they are trying to solve? THAT is what you need to know. Because maybe X feature isn’t the best way to solve that problem. Maybe you have a better way of solving the problem already on the roadmap. If not that, then you can at least take that problem and run it through discovery to explore a bunch of possible solutions to find the best and most efficient one. 

If you’re just taking feature requests and building to order, then you are falling into what our Co-Founder and CEO Janna Bastow calls ‘The Agency Trap’. 

If your Customer teams are taking feature requests and telling the customer that they will submit it to the Product team, they are setting the expectation that that exact feature will be considered. This can set everyone up for a fall. It’s much better to delve into the route of the problem, listen to the frustration or need the customer has, and have them feel heard and that a solution will be thought about. But we’ll come to how you help your customer teams flip feature requests into genuine feedback in a moment. 

First let’s talk about the challenge of format….

4. The format is all over the place

If you don’t have an organized and communicated way of submitting feedback to the Product team (and sometimes, even if you do), then you’re no doubt getting it in all sorts of shapes and sizes. 

Ultimately, we would always say that some form of feedback submission is better than none at all. So, at least you’re getting something here. But still, there’s room for improvement if feedback is flying in at you from all angles and in a variety of different states. 

One CSM tends to ping you a message on Slack, another fires off an email to you, a third person always forwards you entire recordings of hour-long customer calls, another mumbles a few sentences at you during a meeting. That creates a lot of work for you to collate it all, turn it into something useful and consistent, before you can even start to analyze what you have. Not ideal. 

5. They’re always asking for progress updates

It is absolutely reasonable that your stakeholders request updates on progress when they share feedback with the Product team. They need to keep their customers informed. But there are ways to make this less of a time drain for you as the Product Manager (and we’ll come to those ‘ways’ a little later on). 

Otherwise you will spend far too much of your time fielding questions and digging around for answers. If every time a CSM has a customer call, they come to you asking for updates on all the feedback that customer has given… and you have to do that for every CSM and every call they have… well, you won’t have a lot of time to do much else! 

Yes, those are the challenges, but how do I overcome them, I hear you shout. 

Fair enough. Let’s get to the solutions…

How to get your internal stakeholders to share feedback with the Product team 

1. Make it super easy to submit

Like we’ve said, everyone is busy, focused on their day job and their primary KPIs. They are all working in their own context and have their own work to do. So, if you want your colleagues from other teams to regularly and routinely share their customer feedback with you, you need to make it fast and convenient to do so. 

Let’s face facts, if you require them to log into a different tool which isn’t their own – not one of the tools they already use day-in, day-out – it ain’t gonna happen. Or at least not as often as you’d like. 

If your Customer teams have to leave their context to share feedback with you, then it’ll almost certainly end up as a to-do list item that they plan to come back to at the end of the day – log in once and get it all done in bulk. We’ve already talked about how infrequently those good intentions actually happen. You don’t want this. 

To get the most feedback from other people in your organization, you want them to quickly and easily fire it over to you in the moment (or, at least, immediately after the moment). If you stand any chance of making that happen, you need to give them fast ways to do so without leaving where they are. 

As Kirsty says,

Luckily we can help you with this. If you use ProdPad as your tool, as the central repository for all your feedback from multiple sources, then you can give your internal stakeholders a veritable plethora of fast and easy ways to share their Feedback with you. 

Those ways include:

• A browser extension
• An email drop box
• Through Slack or MS Teams
• Via an unlimited number of customizable Feedback Portals which can be embedded wherever you need 
• Directly from your CRM (like Salesforce)
• Straight from Support tools (like Intercom or Zendesk)

None of these routes require your stakeholders to log into ProdPad. They can simply send the Feedback in with a quick email or a click on the browser extension, or, with the CRM and Support tool integrations, they don’t need to do anything at all. They can just record the customer interaction as they usually would in their own tool and you can have that automatically route into ProdPad as Feedback. 

2. Let them see it makes a difference

It’s important to show your internal stakeholders that the Feedback they share with you actually contributes to the product planning. Otherwise you risk them thinking it’s a pointless exercise and ceasing to do it! I’ve heard Salespeople (in other companies – obviously not ProdPad!) saying “There’s no point telling Product. They just ignore it.” Don’t let that happen in your organization!

Being open and transparent about your product process. Giving everyone full visibility on your flow and prioritization is the best way to ensure you don’t fall foul of this with your Sales or Customer teams. 

If you currently have all your product planning hiding away in spreadsheets or slide decks you need to speak to us here at ProdPad! Having an easily accessible, always up-to-date home for all your product planning is the best way to ensure full transparency into the process. This will mean everyone in your organization understands how Product work and exactly how Feedback feeds into product ideas and prioritization decisions. 

You can also ensure that your internal stakeholders and Feedback submitters see the specific progress relating to particular pieces of Feedback when you use ProdPad. This is the powerful proof they might need to feel assured that their Feedback does impact the product strategy. 

For example, let’s say Customer Success Sally sent some Feedback in through Slack, advising that her customer was frustrated that she’s not spending as much time using the product as she’d like because she’s traveling a lot at the moment. As a Product Manager, analyzing your Feedback, you spot that ‘use when traveling’ is a theme across a number of customers (because ProdPad’s AI Signals tool has highlighted that for you ). So you create a Roadmap Initiative to address this problem – ‘How can we help our customers use our product on the move?’. You come up with a bunch of different Ideas in ProdPad and your AI Assistant automatically links all the related Feedback (including the piece sent in by Customer Success Sally) to the Ideas. 

Next time Sally has a call booked with that customer, she can hop into ProdPad and see a list of all the Feedback she’s submitted. She simply finds this piece and gets an instant update on the workflow stage of the related Idea. She knows, with one click, that you explored three different Ideas, validated a mobile app as the best solution and that mobile app is now in QA testing. What a wonderful update for Sally to deliver to her customer! 

I tell you what, Sally is convinced of the value of sharing Feedback with the Product team. You’ll be enjoying a steady flow of user insight from Sally forever more. 

You might not always be able to show that an individual piece of Feedback has resulted in a corresponding product Idea that hits the roadmap, but you can and should reassure your internal stakeholders that their Feedback contributes to a critical mass of Feedback which feeds the theme analysis. 

Kirsty, our Head of Product, has another top tip to help you convince your stakeholders that their Feedback submissions are important…

3. Make it easy for them to track progress 

We’ve talked about how time draining it can be for you to be constantly dishing out updates to all your customer-facing colleagues. So let’s explore how you can empower them to self-serve this information. 

Because, if they can quickly and easily check up on the Feedback they send through then they’ll be encouraged to keep sending it!

We’re not saying that there shouldn’t be an onus on you as PM to provide these updates, but the right tool can take the weight of this from your shoulders. You then just need to acknowledge receipt of the Feedback and give an indication of what you might do with it, and let the tool help you in terms of smaller incremental updates.

Take the earlier example of Customer Success Sally and the updates she was able to see about the mobile app in QA testing that was linked to her Feedback about using the product while traveling. Sally was able to go into ProdPad, look at her Feedback list and quickly see the workflow stage of the linked Ideas. It looks like this

With ProdPad, you can show all your customer-facing team mates how to set up their Feedback view, customize it to show the information they most care about, and let them hop in here whenever they need an update. You’ve just saved yourself a bunch of time. 

As Kirsty says,

4. Give them clear guidance on what to submit and how

Sometimes people don’t do things because they’re not quite sure how. That’s human nature. So remove all doubt from your colleague’s minds and be crystal clear about what and how to submit Feedback to you. 

We’ve already talked about the propensity to have product Ideas submitted when, in fact, they should have been framed as Feedback, having identified the problem to solve. So, step one here is to give everyone clear guidelines on what is an Idea and what is Feedback. 

Publish, share and socialize those clear guidelines and make sure it’s easily accessible for all your colleagues. Make sure you put it where your Customer teams spend time so they don’t have to hunt around for it.

Consider spreading the word in the following ways:

• Join a Sales meeting and present the guidelines to the team
• Do the same in other customer-facing team meetings
• Post the document on your intranet
• Pin it in relevant Slack or Teams channels (or whatever communication tool you use)
• Email it around
• Find out how to flag it in a prominent place in the CRM, Support tool or whatever tool your customer-facing colleagues use every day

Make sure they are always on hand, so your stakeholders don’t have to hunt around to find it. Because, let’s face it, they won’t. 

What should those guidelines look like? 

Well, we’ve gone ahead and created a template document with a ready-made distinction that you can download and distribute to your team. It’s based on the definitions we use here at ProdPad for our own customer Feedback and product Ideas. We hope you find it useful!

In essence, the distinction looks something like this:

Submit product Feedback if it is about:

1. Improvements on existing features
2. Bugs and issues
3. User experience (UX) enhancements
4. Performance
5. Aesthetics and design

Submit a new product Idea if it is about:

1. A new problem space
2. New markets or use cases
3. Innovative idea
4. Complementary products

Remember, any format is better than nothing at all. But if you can give them easy frameworks to submit their feedback it will reduce the time you spend, as the PM, interpreting what they’ve sent. 

You have to strike a balance between making it easy for them to submit feedback versus helping them to craft it into the most meaningful thing it could be. We think we’ve struck that balance here at ProdPad with our own Feedback processes, so download our template (as soon as it’s ready) and see how it works for you. 

5. Train the team

Our final piece of advice to maximize the amount and the quality of the Feedback you get from your internal customer-facing colleagues, is to spend some time coaching and training them. 

Be gentle obviously. You don’t want to bowl in and start telling them how to do their jobs. But you do need to give them some practical ways to extract the most valuable insights from their customers, in terms of product experience. 

Help them understand how to delve deeper into customer requests or comments, to get to the heart of the problem they need solving. You want this to become a habit for them, so every time a customer says “I need your product to have this feature”, they pause, reflect, then ask the right questions to flip the feature request into a problem to solve. 

Those questions could be:

• What do you think that feature would do for you?
• Why do you feel you need that particular functionality?
• What is the problem you believe that feature will solve?
• What are you trying to do?
• What is the outcome you want to achieve?

Another top tip from Kirsty:

For example, if a customer is asking about API capabilities, you don’t just want your Customer Support people to simply list off what capabilities are and are not available. You want them to delve deeper and ask the customer why they want to know about the API – what do they need to use the API for? What are they trying to do via the API? What is the outcome they want? What problem are they trying to solve

When that has been answered, bang, there’s your Feedback. 

Another of Kirsty’s top tips is to make an appearance at the customer team meetings and deliver this coaching en masse. Rock up to a Sales meeting with the examples on slides, join a CS meeting and take everyone through this training. Then make sure you’re consistently reinforcing this training. Give feedback on the Feedback – not only is this great for acknowledging receipt, but it will also help make this extra level of analysis a habit for your Customer teams. 

How are you going to manage all this Feedback??

If you implement all our suggestions here you’ll be enjoying a consistent flow of useful Feedback from all of your customer and prospect facing team members. So, you better make sure you’re using the right tools to help you manage all that insight. Come speak to one of our Product Management experts here at ProdPad and we can show you all the tools you’ll ever need to gather, analyze, prioritize and action all this customer feedback. 

The post 5 Ways to Get Customer Teams to Share User Feedback [with free template] appeared first on ProdPad.

We’re sharing it with you because it’s a productive way to work out priorities as a team, and it’s a really helpful method for mapping development. Who said product management couldn’t be fun?

One of your biggest jobs as a product manager is to translate and prioritize what feels like a million inputs flying in from across the company into just one cohesive product roadmap. To help you with this, we want to share one of our favorite feature prioritization frameworks with you. 

During this game, everyone gets a chance to bring up the priorities they feel are important for the future of the product. But which priorities will win?

You’ll want to set aside an entire morning or afternoon for this riveting afternoon of discussion, debate, and feature prioritization.

The more people you involve in the process, the better the understanding will be across the board. A good mix of internal stakeholders and active users will provide you with more valuable insights than just getting your product teams together in isolation.

Below you’ll find our easy how-to guide on running your own Product Tree session using this fun visual tool. We’ve also got a brilliant eBook about all of the most important prioritization frameworks for product managers. Just click the banner below to get your copy.

How to run your Product Tree Game session 

What you’ll need:

1. The Product Tree template (download below)
2. Post-it notes (leaf-shaped Post-its are perfect)
3. Sharpies 
4. A whole afternoon 
5. Coffee? Can’t hurt!

Step 1: Print our Product Tree template 

The Product Tree is what you’ll use to run your session. Get our free Product Tree template here, or draw your own out on a big whiteboard.

Each Product Tree consists of four elements:

• The trunk represents the core features already in your products.
• The branches are feature branches. Optionally, you can increase the thickness of single branches that are more important.
• The leaves are individual features that the workshop participants will place on the branches. The closer the leaves are to the trunk, the closer they are to being delivered.
• The roots represent the infrastructure and technical requirements that support your product. As with any tree, the bigger it gets, the more support it needs from its roots – so remember your technology as you expand your feature list.

That said, how you fill out this tree depends on the kind of product you want to build. If you want to focus on one area, your product could be the roots, and the area you’re focusing on would be the trunk.

Or, if you’re running a platform with multiple products, the platform itself could be the trunk, and the main branches would represent each of your products. 

Whatever the scale of your approach, you’ll need to list out the main areas of your product and label the branches of your tree accordingly. If your product areas have chunky bits of functionality or features within them, you could add those to the stubs of the branches. 

Step 2: Prepare your leaves  

Print out all the features you already have in your product, or want to add to your product. Or, write them down on Post-it notes. Also, make sure to have plenty of empty Post-its at hand for adding new ideas!

Don’t worry about adding all your existing features, because if you have a feature-rich product, you’ll be there all day.

Step 3: Get your group together  

Anyone can play this game. The more kinds of stakeholders you involve, the richer the output. It becomes especially interesting if you get customers involved in placing new features on the branches according to which they would most like to see in your product.

If you have more than 10 people joining in, prepare multiple sets of trees and leaves – ideally, you will have 4-10 people working on one single tree. This includes one observer per tree, whose role it is to ask the participants to clarify what they mean if there’s anything ambiguous on the tree. 

Step 4: Put the leaves on the tree 

Ask everyone to write their feature ideas on the (hopefully) leaf-shaped Post-it notes, then get them to place the Post-its onto the tree wherever they think they should go.

The further away from the trunk they are, the more into the future you’re planning. Leaves closer to the trunk are closer to deployment, while the canopy of the tree is more about long-term growth. 

Step 5: Prune your Product Tree 

Now the fun begins – like green-thumbed gardeners, get cracking on pruning the tree!

Pruning in this case doesn’t always mean outright cutting things from your tree, though. Really, ‘pruning the Product Tree’ is more about assessing what you put on your tree, and then collaboratively reorganizing it.

Moving features around or adjusting the thickness of a branch is just as valid as cutting an impractical idea (though you’ll still want to do that – but make sure hang on to them for the review phase). 

Together as a team, you’ll need to talk through the placement of each leaf, and work on refining where they sit on the tree as a whole. This means that you need to identify and remove branches, leaves, or even roots that are hindering long-term growth or putting roadblocks in the path of your solutions.

Once your team has put together their tree, they need to assess each leaf’s importance. How much value does it adds for your customers? How does it align with your product vision? And how much effort it would take to implement or to maintain? These are some of the questions you’ll want to throw out about each idea.

Consider the importance and impact to the customer, the relevance to your product vision, the effort required to bring it to market, and the impact on your business goals and product strategy.

Tips for having a successful Product Tree workshop

Here are some pointers on how to have a productive and fun Product Tree pruning session: 

• Personalize the tree to stimulate creativity. For instance, participants can add their own little markers to their ideas, or draw hearts around the features they really love. 
• Remember the significance of where leaves are placed. The closer the leaves are to the trunk, the more near-term they are. Leaves closest to the trunk are existing features, while leaves on the outer edges of your canopy represent the long-term future. 
• Don’t hesitate to use lines to show links or dependencies between features. Though try not to end up looking like Charlie in It’s Always Sunny.
• Don’t worry too much if the tree becomes unbalanced. Usually, the group participants or the observer will bring this up naturally. 
• Take pictures of the development of the tree(s) – this is useful for the review process. 

Step 6: Present and review internally 

At the end of the session, present your tree (or multiple trees if you worked in groups). Encourage everyone to ask questions and discuss. Often, more ideas will come up during this process, or leaves will be shuffled around.

Once you’re all packed up, take your product tree and the pictures you took and compare them against your current product roadmap. Useful questions to ask are: 

• Which “prepared features” got pruned? Especially if you’re working directly with customers, you might find that a much-loved feature is actually dispensable in the eyes of the user. 
• Do the trees retain their general shape? If you’re seeing an obvious imbalance – such as lots of leaves on one branch – this could be a signal that your users aren’t aware of (perception problem) or interested in (product/market fit problem) a whole feature set in your product. 
• Are you growing your product fast enough? If there are a lot of leaves close to the trunk, you may not be releasing new features fast enough; whereas lots of leaves on the outside shows that they’re looking for great things in the future. 
• What does your root system need to look like? If your customers are changing aspects of your infrastructure, it’s likely of critical significance to them to establish trust in the longevity of your product. 

At ProdPad we find the Product Tree game is a great way to dig into feature prioritization. Don’t forget to check out our free prioritization framework eBook, and if you need even more detail on the best way to run a Product Tree session, take a look at our free manual here. They’re both fantastic resources to help you with creating your lean product roadmap.

The post The Product Tree Game: Our Favorite Way To Prioritize Features appeared first on ProdPad.

In this article we’ll cover the following topics:

• Product designer vs product manager: What’s the difference?
• Product designer responsibilities
• Product manager responsibilities
• In practice product designer vs product manager: an example
• In practice product designer vs product manager: Separating the roles
• Product designer vs product manager: how can they work together?

Product designer vs product manager: What’s the difference?

Ok, what actually is the difference between these two roles? Well, the tricky thing here is that ‘design’ is often used as a catch-all term for ‘making something good’. So in casual conversation, you could say that a product manager’s role is to ‘design’ a better product, and you’d be right, but we need to delineate things a bit here by looking at what each role cares most about.

Ultimately, product managers think about the end-to-end product production process. So, while the look and feel of the product are right up there in their list of priorities, so are all the other potential causes for customer churn. That’s alongside managing the roadmap for everything from UI changes to bug fixes and quality-of-life updates. 

Designers have a smaller but no less important focus: their role is to make the product feel intuitive to use and look fantastic. That means that the UI (user interface) and UX (user experience) are their bread and butter.

Both roles are ones centered on continuous improvement and acting on feedback, but there’s a distinction in that product designers think mostly in visual and experiential terms, and product managers also deal with the overarching strategy – as well as ensuring the product’s overall value proposition. 

Product designer responsibilities

Whilst your product’s use case, value proposition, and market fit will be shaped by a bunch of different people within the business, product designers are responsible for delivering that all-important first impression. When potential customers are exploring your website’s product page, screengrabs from your offering will be the first thing they form an opinion on. 

But that look and feel stuff is just one part of product design. Here are three core areas of product development that keep designers busy:

1. Prototyping and workshopping user journey flows 

For brand-new products still in development, product designers perform the vital task of prototyping how the thing will actually tick on a screen-by-screen basis. |

What are users presented with when your app, platform, or suite first loads up? How does the core navigation function? What’s its overall flow of use? And, importantly, how intuitive and fun does all that feel?

Designers prototype these all-important user journeys using basic, indicative templates, until the product feels natural and logical to use.

2. User interface (UI), user experience (UX), and look and feel

Those user journeys dictate the user experience design of your product, and that, in turn, dictates the user interface. UX and UI are intertwined; how big and obvious does topline navigation need to be? How do nested panels and sub-sections function and look? How can you ground the user and help them know where they are within your digital maze? 

Once that’s all settled, designers are then responsible for making it look good and feel fun to use – applying a branded color scheme, a uniform design language, and adding flourishes like animations and transitions.

3. User testing and feedback

Product design is never a solved problem; things can always be improved. As such, product designers will often work alongside product managers to solicit user feedback. That might be through surveys and focus groups, or it could mean gathering behavioral insight with tools like heatmaps and eye-tracking software.

This will help product designers understand how users are actually navigating the product, and it’ll highlight areas for improvement that designers can take responsibility for.

Product manager responsibilities

The product manager is in charge of shaping the go-to-market strategy for a product – and ensuring that it always lives up to the vision the company and its users have for it. That makes it a job of continuous discovery and agility in adapting to new markets and customer needs. 

In essence, the product manager is the product’s biggest champion and detractor; a great product manager knows what needs to change and what to prioritize. They’ll handle the following tasks:

1. Analysis and innovation

Product managers need to be able to understand what’s lacking from the product in its current iteration and oversee the process of getting it from where it is to where it needs to be. 

That means collating feedback, learning where pain points are, and working with everyone from designers to marketers to plot out future innovation. Product managers are experts at refinement, and even though they won’t be designing in Adobe XD or coding in Python, but they’ll have a firm grasp of what needs to be done.

2. Managing the roadmap

Part of that refinement is knowing what’s urgent and what can wait, and in the product world, that means managing the roadmap. At ProdPad, we’re huge advocates of the Now-Next-Later roadmap framework, which incentivizes identifying problems and solutions instead of deadlines. 

Part of the roadmapping process is outlining OKRs (objectives and key results); the product manager should have a deep understanding of what you’re trying to achieve, and how to check that things are proactively moving in that direction.

3. Shipping, QA, and testing

In digital products, ‘shipping’ essentially means ensuring that the rollout of product versions happens on time and within budget. Product managers rally various teams to ensure that these deadlines are met, including overseeing the QA process and – if testing flags any urgent issues – working on steps to rectify things.

In practice product designer vs product manager: an example

Let’s imagine your company ships an app that functions as a front-end email client called MailBoxy. It’s a roaring success, but the work is never done, and you’ve got a laundry list of feature updates planned in the roadmap.

For the product manager, the task is to align teams on where the priorities are. That means meeting with department heads, listening to their concerns, and seeing how they match up with real-world user feedback. At the end of the day, the product manager massages that list into a roadmap of things that need to happen first, and ensures that everyone’s happy with what needs doing.

It’s decided that the next MailBoxy update needs to include a major UI change: currently, users are finding it really hard to schedule their emails at the point of sending. So the product manager puts that right at the front of the roadmap, and then the product design team gets to work. 

Here, the product designer(s) will workshop various solutions for making the ‘schedule email’ user journey more simplified, and ensure that the button to do so is made much more obvious. They might run a focus group to see how different versions of this system compare, and which ones users find the most intuitive. 

Once everyone’s happy with the function and the design, the product manager will oversee the dev team’s implementation of this new functionality, oversee the testing and QA process, and ultimately be responsible for getting that update shipped.

In practice product designer vs product manager: Separating the roles

In any line of business, it’s wise to ensure that different roles are clearly defined and have well-understood boundaries. By this we mean: people need to know where their responsibilities are, and are not.

But that doesn’t mean you should park these people in separate siloes and leave them to their own devices. This isn’t a product designer vs product manager situation – there should absolutely be collaboration and some natural overlap in their responsibilities. After all, everyone’s north star goal should be the same: making a great product.

In smaller companies, it’s usual to find people wearing many hats, but really, a product manager should define the strategy, and the product designer should work their specific flavor of magic to ensure that the UX and UI of the product fulfill that strategy.

Does that make product managers superior to product designers? Yes and no; it kinda depends on the makeup of the company. What’s important is that designers are given the tools, information, and direction they need to design compelling experiences. And that direction usually stems from the strategy being defined by the product manager.

Product designer vs product manager: How can they work together?

Unless you’ve got some big egos on your hands, product managers and product designers should naturally work really well together. They’re both working towards the same goal, and while product managers should take a keen interest in design, a great PM will be able to defer to the design team for the fun stuff.

If you really want these roles to gel, here are a few best-practice tips:

1. Communicate often

How often does the product manager actually sit down with the product design team? Regular, consistent meetings are a must if you want everyone to have the same idea of what the priorities are and where the user’s needs aren’t being met.

Face-to-face is great, but in a post-COVID world, the medium doesn’t really matter as much as the frequency. Product managers should book in a couple of weekly meetings: one with the product design head, and one with every department together. We know nobody likes meetings for the sake of meetings, but when you’re building and evolving a product, there’s no such thing a too much communication.

2. Know where the buck stops

This isn’t really specific to the relationship between product managers and product designers as much as it is a rule of thumb for every interdepartmental relationship: make sure everyone knows who’s doing what. 

It can be easy to accidentally allow responsibilities to slip between the cracks, and even easier to end up with duplicate work from overzealous team members who’re just trying to help. The product manager needs to be on top of this and – by setting clear goals – ensure that if something’s got to be done, everyone knows who’s responsible. 

3. Define shared OKRs

Teams that understand what their key objectives are are teams that know how to prioritize. Aligning everyone around a set of OKRs (objectives and key results) is an important way to align product teams – and keep designers focused on what really matters.

Defining your OKRs should be a collaborative process. Product designers might have some amazing ‘nice to have’ ideas, for instance, but if those updates don’t directly influence your objectives, then they ought to go on the back burner. Likewise, product managers need to be able to show designers how user-suggested changes will positively affect the product.

In other words, great product managers know when to say ‘no’, and great product designers should be informed enough to want to say ‘yes’. 

Aligning on OKRs is a surefire way to work within those parameters. 

4. Use a shared roadmap 

If you really want to align product designers, product managers, and everyone in between, you need to use a shared roadmapping tool that puts everyone on exactly the same page. 

A roadmap that shows what the immediate focus is, why, and how you’re going to get there – alongside OKRs and scope for comment and collaboration – is the simplest way to create a company with a true sense of purpose.

ProdPad helps product teams build out a considered and curated roadmap full of quick wins, feedback-based ideas, and long-term goals alike.

It’s a seamless and lean product roadmapping experience that streamlines collaborative ideation, goal tracking, feature update planning, and experience gap closing – all without messy Gantt charts or easy-to-miss deadlines.

The post Product Designer vs Product Manager: What’s the Difference? appeared first on ProdPad.

• Make great stuff
• Impress customers
• Grow the business

That should be how product management and product marketing teams work together, right? Their missions are tied to a singular north star, so their intertwining responsibilities should feel like a relay race, where the baton is handed back and forth with streamlined efficiency.

Only, sometimes that relay race can feel more like a competitive 100m dash. And that’s because product marketing and product management’s roles, despite having differing KPIs and roles, can overlap to the point where only a blurry line separates the two – and to where shoulders can get pretty bruised as they rub up against one another. 

And that’s not to mention that company and product objectives can really differ.

So it’s probably worth exploring what’s what. What, for instance, should be in a product manager’s wheelhouse, and where should a product marketing manager prioritize? And, most importantly, how can they work together to meet those three company-wide aims? 

Let’s take a deep dive into one of the business world’s most confusing battles: product management vs. product marketing.

In this article we’ll cover the following topics:

• Product marketing vs. product management: What’s the difference?
• Product management responsibilities
• Product marketing management responsibilities
• Product marketing: the basics
• Product management: the basics
• In practice: Separating the two roles
• Product marketing vs product management: how can they work together?

Product marketing vs. product management: What’s the difference?

Ok, basics first. In theory, what we have here are two roles with equal footing – neither product marketing managers nor product managers have any real authority over the other. Instead, they should work alongside each other to unilaterally influence each other’s strategies.

The really (probably too) simple way to look at the distinction between the two is to say that product managers think about things, and product marketing managers think about people.

That is to say that, whereas product managers focus their efforts on designing and improving physical or digital products, product marketers look at that product and think about how to convey what it does to the people making up their target audience. 

The go-to-market strategy of the latter is based on what humans find engaging, whilst the former takes a more nuts-and-bolts approach with its roots in development and/or manufacturing.

If we were putting it into ‘college science major’ terms: product is about engineering, and marketing is about psychology. If you’d like an even more tortured analogy, please Tweet us @ProdPad.

Need more clarity? No problem; let’s break each one down and take a look at their main responsibilities. 

Product management responsibilities

Product management is about putting the product itself at the heart of everything. Whether it’s a digital service or a physical object, product managers beaver away with the sole purpose of refining that asset. As the head of a team, their responsibilities include:

1. The design and development of the product
2. Managing QA and product shipping
3. Managing the product roadmap
4. Clarifying the product’s value

1. Designing and developing the product

If the product is new, the product manager might be involved right from its inception, helping to find the product’s reason for being, direction, features, and use case. Otherwise, the product manager will take ownership of an existing product and champion its ongoing development within the company.

2. Managing QA and product shipping

The product manager is ultimately responsible for getting the product out the door – at its initial launch and during any future updates. That means managing the team that handles testing, quality assurance, and on-time delivery.

Futher reading: How does this compare to a product owner?

3. Managing the product roadmap

Linked to the above is product management’s role in designing the product’s future. In software, that means feature rollouts, bug fixes, and ongoing improvements. The roadmap is based heavily on the customer experience and any identified areas for improvement.

4. Clarifying the product’s value

While the marketing manager will package up and articulate the product’s USP for your target audience, the product manager does that internally – which helps define marketing’s direction of travel. This sometimes includes writing use case and case study documentation. 

Product marketing management responsibilities

Product marketing takes what’s great about the project and figures out how to explain that to people in a way that they find irresistible. Their general responsibilities include:

1. Building a marketing strategy
2. Empowering your sales team
3. Making noise about the product

1. Building a marketing strategy

The go-to-market strategy is the summation of how marketing is going to proposition the value of the product to the people most likely to buy it. It’s the result of competitor analysis, market research, and clearly-defined documentation on how you’ll talk about the product externally.

2. Empowering your sales team

Product marketing management provides sales teams with crystal clear comms around the value of the product, shaping how it’s talked about with prospective leads. Your marketing manager may also be closely involved in shaping price and pricing tiers, based on market research.

3. Making noise about the product

Product marketing managers design campaigns that drum up interest for your project. They’re in charge of running demos and presentations, designing social media and content marketing strategies, as well as securing print, TV, and digital ads – all based on a strategy that clearly demonstrates the product’s benefits to your target audience. 

Product marketing: the basics

As we’ve discussed, product marketing is, in essence, the process of bringing your wares to market by drumming up customer interest. It differs from marketing in a more general sense because marketing writ large also includes brand marketing, digital attrition through tactics like SEO, and more generalized lead generation.

The core tenets of great product marketing combine to define your overall go-to-market strategy:

1. Market insights 

Product marketing begins with understanding the product’s place in the wider landscape. That means conducting research to learn what competitors are offering, how they communicate their proposition, and – importantly – how that’s landing with consumers. Done effectively, this market research will highlight a gap or opportunity that can form the center of the ongoing marketing strategy.

2. Product positioning 

Positioning is all about taking that gap your market research identifies and running with it. It’s about telling a story that answers questions about why your product exists, what problem it solves, who it’s for, and what makes it stand out. Telling that story effectively and concisely is what provides your product with a clear, rock-solid position within your industry.

4. Sales, customer success & partner enablement 

As part of your product marketing efforts, you’ll create collateral and assets that help sales, customer success, and partner teams drive growth. That might be video content that clearly demonstrates the product’s features, it might be a script that sales teams can use, or it might be brochures that sales team members can send to qualified leads. Product marketing and product sales teams are close allies, where insight and material from either one can help the other.

Product management: The basics

Product management is all about ensuring that the product at the heart of your business lives up to customer and stakeholder expectations. This role is even more important in product-led growth (PLG) companies, where the product is the star of the show, above and beyond the brand. Here’s what the product manager handles:

1. Product design and development

The product is planned as a solution to a problem that you know your potential customer faces. It’s then designed, built, tested and shipped, with the product management team overseeing all areas of the process. 

2. Product analysis

Does customer feedback paint a positive picture of how the product is performing? Or, with fewer Ps: how are things running? Product analysis is the art of learning what’s working, what’s not, and finding experience gaps that can be closed in future iterations.

3. Product innovation

With you analysis done, you can improve the product. If it’s software, that’ll be version updates with new features and bug fixes. If it’s a physical item, for example a running shoe with a big swoosh on the side, you’ll replace last year’s model with something even better. This is a cyclical journey, where analysis feeds iterative updates, and repeat analysis helps you discover further changes and improvements for the product roadmap.

In practice: Separating the two roles

In smaller companies especially, it can seem tempting to have one person operate as both the product manager and the product marketing manager. After all, they’re both roles fixated on building packages that drive revenue.

And there are some overlapping skills between the two, as well. Both roles tend to attract people who have a customer-first focus that defines their work. They’ll both know how to turn feedback into change, and they’ll often both like to move with agility to close gaps and make changes that have a clear impact.

But there’s a lot to do for one person. More importantly, any one person trying to fill both roles will always have an inherent bias towards one of the two disciplines, and that can lead to an unbalanced approach.

Product managers are often so laser-focused on improving the efficiency of the product that they can lose sight of what its actual customers are clamoring for, or miss vital commercial opportunities. Natural product marketers, on the other hand, can see commercial opportunities in what others might deem trend-chasing, and that can dilute what makes the product such a strong proposition in the first place.

In practice, product managers and product marketers should be seen as complementary roles – people that can help each other out. Here’s how…

Product marketing vs product management: how can they work together?

We get it, there are some obvious points of friction here. Companies in which these two titanic roles aren’t clearly defined, for instance, will run into problems with managers not understanding where responsibilities start and stop. Product and Marketing managers also usually have differing KPIs. Product managers live for great user or industry reviews and technical metrics like service up-time, while product marketing managers are geared towards things like share of voice and lead generation. 

And to top it all off, everyone has their own day-to-day work to be getting on with, which can make collaboration and unified thinking tough.

But there are a few key ways companies can help settle the ‘product marketing vs product management’ battle, and help the product itself flourish:

Build a culture of collaboration

We don’t just mean collaboration between product managers and product marketing managers. Heads of every department should be involved in regular planning and update sessions, and this sharing of ideas should be baked into the fundamental DNA of the company. 

Building collaboration into a culture means regular check-ins with clear actions that are assigned to each department. Software that knocks down walls and makes the roadmap more egalitarian will dramatically reduce the chance of mixed messages and overlapping workloads.

Plan your roadmap together

Product and marketing managers can give the product in question the best chance of success by working together on a roadmap that’s informed by what they both know. Working on the long-term future of the product together will help identify clearer priorities based on both technical and market insight – rather than one or the other in alternate spurts. 

That’s customer use and customer trends working together to build a roadmap for the product that both stakeholders are happy with. No surprises, maximum teamwork.

Set shared goals and KPIs

First up, ensure that the purpose and boundaries of each role are clearly defined and understood. Who’s in charge of gathering specific insights or creating certain assets, and where does the buck stops on any given problem? Most importantly, what are each of you trying to achieve? Your goals don’t have to be the same, but they need to be mutually understood at the very least.

With those things aligned, product managers and product marketers should share the KPIs that matter to each, talk about how and why they differ and then move forwards by treating the improvement of every metric as a shared goal. 

That way, marketing metrics become product metrics and vice versa. Having dual ownership of these KPIs ensures that nothing gets wrongly prioritized or ignored – and it keeps everyone driving the product in the right direction for the business as a whole, rather than for a single department. 

The post Product Marketing vs Product Management: What’s the Difference? appeared first on ProdPad.

We’re all familiar with the term, ‘passing the buck’ and how people evade or reassign responsibility to somewhere or someone else. Senior execs do it to product teams all the time. 

I’ve seen it happen to many product people in different ways over the years.  Perhaps you can spot some of the patterns below in your own organization and take action before they have an impact on your work.

Product management always takes the hit

You see it in companies where the bosses set expectations like unrealistic deadlines and then pressure the product team to stick to them. The team then has to struggle to get things out on time, even though it wasn’t their call in the first place.

Product teams could pass the buck to the development team – after all, they’re the ones who build and come up with the estimates that always seem to slip. But PMs always seem to take the hit for everyone else – and I think proudly so – I wouldn’t want to be advocating for a role that was known for throwing its teammates under the bus. Rather, PMs are known for defending the time of their developers (and designers), helping to get them breathing room and much-needed air cover. 

On the flip side, however, product managers often don’t get the same consideration from the rest of their organization, with the most notable offenders being sales teams and the executive team.

Sales teams may well ask for features to be built, rather than selling what they have. Saying they can’t sell the product until X feature is delivered puts all the pressure on the product team – but the sales team should take responsibility and learn to sell or reposition what they have. It’s easier for salespeople to expect the product team to add what they feel is missing. (And don’t get me started on the salespeople who sell things that don’t exist and dictate the roadmap!)

Executives with a badly formed business plan or model put the product team in a difficult position. A classic example is the agency trap, where the company (usually for short-term cash gains) accepts custom project/client work, while also expecting the product to develop at speed. But the product team only has so much time, and can’t do client project work and product discovery and development work at the same time, especially if the client work leads to a stream of deadlines to hit. And it’s not the product team’s decision or fault that they’ve ended up in a delivery-focused way of working. It’s been foisted on them by poor decisions at the executive level.

Unreasonable reliance on the product team

To be clear, the management team is responsible for creating a viable business and workable company strategy. But sometimes they over-rely on the product team to create something that doesn’t yet exist, in timeframes that they can’t know are reasonable (let’s be real: you and the dev team are still working out the scope of this thing, never mind how long it will be before you’re able to deliver). By doing this, management absolves itself of the responsibility of creating and maintaining a viable business, brushing it off as the product team’s problem with no consideration of whether it’s achievable. I’ve seen some teams given ridiculously tall orders.

A company strategy should encompass a realistic product strategy (plus realistic marketing strategies, tech strategies, and so on). It’s not a good strategy if it relies on miracle workers to make it happen or if it’s dogged by insurmountable problems.  The execs shouldn’t just ‘pass the buck’ on their bad decisions or bad planning to their product team and hope that the team figures it out. 

How do you stop it?

The product team must call out this passing the buck when they see it. To be able to do this product people must understand the wider company strategy and where the product strategy fits in it – it’s one of the most valuable things a product person can do. 

They should also understand who’s had a say in product strategy and where some of its assumptions came from. Was the strategy handed to the product team, or did they play an active role in defining how they could help the company reach its goals? 

If there’s a sense that others are ‘passing the buck’ to the product team, then call it out and set boundaries. If you don’t, then the product team risks having more work pushed at them, setting them up for failure further down the line. For example, if you keep agreeing to custom client work, to the detriment of discovery work, you set a precedent that you will always accept project work…  and the core product will never progress and the company won’t move towards its ultimate goals. 

Calling it out helps management and other team members to see the broken parts, like missing resources or misdirected efforts, so that they can help to correct them.

The post How Passing the Buck Sets a Product Team Up to Fail appeared first on ProdPad.

You’re a large company with unique challenges. You’re operating internationally, across a large portfolio of products and teams that have grown and changed over time, and tackling a huge range of challenges. No less, you’re doing it all in the middle of a pandemic! 

A good underlying product innovation culture helps to overcome these sorts of challenges, and we’ll show you how.

This article is based on a popular keynote presentation that I have delivered to a number of product management audiences across the world. Attendees are often keen to get a copy of the slides, so I thought I’d include them here for anyone that’s interested . They should help illustrate everything I cover in this piece and can help you talk through the ideas with your teams.

Innovation culture doesn’t just mean coming up with new shiny ideas. It doesn’t mean ignoring the important work in progress or all the context in which the business operates. 

An innovation culture means using the collective knowledge of your team to crack problems in novel ways. And these can be any sort of problems – product problems, process problems, organizational or team topology problems. You name it. 

Because you’re not defining the solutions to the problems. You’re creating the sort of environment where problems get solved.
Innovation culture is powerful. Just ask the likes of Facebook or Autodesk or others who foster cultures of innovation, and leap ahead of their competition…. and take home the profits because of it. Companies with a strong innovation culture massively outperform others of similar size on just about every measure of success, from revenue to growth to market share. 

via Suzie Prince – @pm_suzie

The graph above shows how Google, Netflix, and Amazon are massively outperforming on the S&P index. This is because, in these sorts of companies, their innovation culture has helped them adopt a way of working that reduces risk and the chance of failure, and increases their chances of landing on successful initiatives. 

When we talk about innovation culture, we don’t mean just in terms of product management. Innovation should be thought of holistically, and inclusively, not just in the domain of people who wear the product management or R&D hat. 

Everyone in the company has a role to play. 

A huge part of the value of a good innovation culture comes from how it enables different groups to work together towards the same goals, rather than against each other. This is why I call it a team sport.

Let’s get there!

So what sets these sorts of companies apart, and how do we get there? 

1. Acknowledge it will be tough

First, let’s acknowledge that it’ll be tough.

New ways of working are never comfortable for everyone involved. It ends up plowing through people’s perceptions. It breaks their existing processes that they’d just gotten tied down neatly. It laughs in the face of some of the metrics used to measure some parts of the business.

Depending on where you’re coming from, it can require a whole mindset shift. It can be like taking away a comfort blanket, and put people at unease. It can also end up putting more tangible things on the line, like bonuses, commissions, or even jobs, depending on what’s being changed and to what degree. 

You’re a product person. This is where your empathy skills come into play. Where you find that there’s resistance to new ways of doing things, get out and ask those Five Why’s – figure out why people are really resistant to change, and where possible, make adjustments to create a better balance. 

2. Get executive buy-in

This is a team sport, but if you’re not going to be allowed to use the playing field or any of the equipment, your team isn’t going to get far. 

You need to get at least some degree of executive buy-in.

Innovation can come from within and build upwards, but it too often gets trampled out if it’s not welcomed as the way of working.

Sometimes, what I’m writing here shouldn’t be an entire surprise to your company and its execs. This isn’t new stuff that’s untested and untrustworthy. Lots of organizations have forged the path ahead successfully and have shared their results along the way. But this buy-in is key. 

Your skills as product people come into play here – you’ll need to manage expectations upwards, communicate what’s needed and why, and articulate the benefits of this innovation culture to any execs who need clueing in. 

3. Use the whole team

And as I said earlier – innovation culture is holistic. Make use of the wider team.

As you might have heard from Marty Cagan – if you’re only using your developers for code, you’re wasting half their talent. The same is true for the rest of your team too. 

Remember, as Product people, it’s not your job to have all the answers. It’s your job to ask the best questions. To surround yourself with the experts of all different stripes around you in your team and make use of their knowledge. They’re no good to you if innovation is kept behind closed doors, however unintentional.

4. Break down silos with transparency! 

If you’ve got silos, break them down with a dose of transparency. 

It’s really common to hear about the mistrust that other teams have of their product management division. Examples of this can come in the form of sayings like “It’s where ideas go to die.” or “No one knows why product decisions are made.” We understand where it comes from, but it’s entirely preventable.

The product development process can be a mind-boggling one. 

After all, even consider the sense of time to someone in product versus someone in support or sales. 

If someone suggests an idea, it probably goes through Product. Let’s say 6 weeks later, that same person asks for an update. 

To the product person, 6 weeks is nothing. That’s a few sprints, perhaps a handful of things were actually done, but chances are, that specific idea wasn’t one of the things delivered. 

To the salesperson, 6 weeks is a long time. That can make or break a deal. And it’s made worse when they can’t see what was done instead. 

See, the product team isn’t ignoring these ideas or saying no out of spite. 

It’s just that there are always going to be way more ideas than can ever be built, and so, realistically, unless the idea is stellar and solves an immediate problem, it’s not going to be prioritized over everything else. 

In the past, the art of product management was always a bit of a secret process. Ideas would go in, and the product team would make decisions, and the finished product would come out. 

This leads to people in the rest of the team thinking that product management is a black hole. 

Or that product managers aren’t really doing much back there. It demoralizes and tends to end up with people not bothering to suggest their ideas anymore because they don’t trust they’ll see anything from it. 

It results in an innovation drain. 

All that will change with a good innovation culture. 

Good innovation culture should help to demystify the product management process. 

5. Make space for innovation!

You should create a space where team members can see what’s going on with their ideas and suggestions, and how it relates to the bigger picture. 

This creates accountability where there is otherwise a black hole. Anyone can see where their idea ended up, and whether it’s tied to objectives that have been prioritized at the business level, or whether it’s going to have to sit it out to let other ideas shine. 

You’re looking to create transparency in decision-making. That way, it’s not the product manager saying no. It’s the product management system, doing its thing – prioritizing the right problems to solve, and making it clear to everyone which ideas will solve those problems and which won’t. Ego and bias are removed from the equation. 

You’re just left with better product decisions and everyone with a clearer understanding of why.

Product Innovation culture is less wasteful

Some might be thinking that this whole innovation thing is going to cost a lot of money and maybe come up with very little benefit. 

But done right, a strong innovation culture means fostering a culture that avoids unnecessary wastage. 

In a traditional organisation with siloed divisions, every division is measured as either a profit center or a cost center. 

Management’s goal is to squeeze just a little more revenue out of sales and marketing, and to push down costs in areas like support, tech and operations.

Research & Development is a cost center

Do you know where product and innovation sits? We’re usually seen as a cost center. 

We’ve historically reported into a tech function whose job it was to keep a close eye on costs. Which gets the product and development team trapped in this old pattern of writing finely detailed specs, breaking them into points, and being measured on ‘velocity’, or how quickly the team can ‘burn down’ that stack of points.

This model might control costs, but it optimises for building features, not for solving problems.

And there’s nothing as wasteful as spending your time building the wrong things! 

These old vanity metrics lead companies to be misled about their productivity. After all, the engineering team is constantly busy, but are they working on the right stuff? 

It’s why you can have two companies in the same space, and one is much larger, and theoretically much more capable of delivering more value, and yet lags behind a smaller, nimbler competitor. 

Innovative teams are more productive

I’ve seen companies who put immense effort into getting their engineering teams absolutely swimming, churning out all sorts of stuff. And yet these teams still don’t produce much value. 

They put out mediocre launch after mediocre launch.

This is because, as good as their engineering team might be on the delivery side, their product processes leave something to be desired. They’re often still stuck in an IT project mindset, rather than embracing an innovation culture.

A strong innovation culture makes sure that the right things are built in the first place.

Lots of effort has already gone into smoothing out the delivery side of the business. But your innovation work sits upstream from that, in the strategy and discovery spaces. 

A sign of a strong innovation culture is that company level goals are always in mind, and that the problem space is deeply explored before diving into the solution space. This ensures that the work that actually goes to delivery actually is of value, and that lots of different viable options have been explored, and the team knows they’re likely heading down one of the best paths, not just the first one they stumbled upon. 

Iterating Innovation

These aren’t things that happen overnight, a strong innovation culture evolves.

It’s something you can measure, and learn from, and build upon, through training and tools and team retrospectives. Much like when you Build, Measure, and Learn on your own products every day. 

Whether your team and processes are particularly innovative or not is something you could measure as a baseline. I’ve given you some ways you might frame those measurements in this blog.  

Over time, you could make adjustments to the way people work (through training and tools and some of the techniques discussed here), to facilitate and build a stronger culture of innovation.

And as such, I’d say that innovation culture is the most important product you’ll ever work on.

And it’s something that you work on as a team.

The post Product Innovation is a Team Sport appeared first on ProdPad.