How to research your problem area and product

Watch my Product School talk based on this post.

Introduction

Discovery

Discovery in the product world is the process of doing research for a problem area or product. There are many forms of discovery involved in product management and entrepreneurship.

Two well-known forms of discovery are product discovery and customer discovery.  All things considered, one of the most important responsibilities of a product manager or entrepreneur is to fully understand the problem area and product being worked on.  

The reason it is so important to have a deep and broad understanding of a problem area and product, is because a team can have the best executed solution the world has ever seen; however, if the problem is not correctly identified or understood, then the solution will likely miss its mark in meeting customer needs.

Methods for Discovery

In order to make sure your team executes with the most potential for success, it is of the utmost importance to conduct thorough research on your problem area and product.

This post will cover the following methods for discovery:

1. User Research

2. Stakeholder Research

3. Competitive Analysis

4. Product Analytics

User Research

According to usability.gov:

User research focuses on understanding user behaviors, needs, and motivations through observation techniques, task analysis, and other feedback methodologies.

User research is critical for discovery because it brings you in direct contact with the customer. This allows you to dive deep and understand the nuances of the user problems and processes that cannot be discovered through basic data.

When conducting user research, you want to make sure that you are talking to the right people to get the most learning.  The best way to make sure you find the right people is by having clear criteria on the types of users that currently or might want to use the product.  This traditionally has been referred to as a “persona” but over time is moving towards being defined as a “job to be done”.

Identify potential personas

The definition of personas from usability.gov:

[Personas] create reliable and realistic representations of your key audience segments for reference.

Effective personas:

- Represent a major user group for your website

- Express and focus on the major needs and expectations of the most important user groups

- Give a clear picture of the user's expectations and how they're likely to use the site

- Aid in uncovering universal features and functionality

- Describe real people with backgrounds, goals, and values

The definition of a job to be done from jtdb.info:

A Job to be Done is the process a consumer goes through whenever she aims to change her existing life-situation into a preferred one, but cannot because there are constraints that stop her.

The reason this article mentions personas and jobs to be done is because they are both similar practices with the intent of helping you as the PM or entrepreneur clearly define characteristics about the user. 

Another way to define the characteristics of the target audience for your research is to simply use the 6Ws:

1. Who the user is

2. What the user is doing

3. When the user does this thing

4. Where the user does this thing

5. Why the user does this thing

6. How the user does this thing

For the purposes of this post, the following content will not pick any specific framework to use, but rather highlights the importance of understanding in total product or problem area. 

Having a clear understanding of the 6Ws articulates the details of the user problem.  It sometimes feels redundant or like overkill, but it can be the difference between building a mediocre product that fails to gain traction, and the next hit application.

In order to identify this criteria, it is good to start with initial hypotheses based on whatever understanding or research you have. This can come from prior experience, product intuition, third-party research, or anything else that seems fitting.  The user research then aims support, reject, or build out these hypotheses.  

There is a school of thought around not having personas/jobs defined before the user research; however, I have found this difficult because it then leaves you without a clear starting point.  On the other hand, the risk of having hypotheses around personas/jobs too early is that you can get stuck going down a path based on incorrect data. It is important to fully vetted whether your initial hypotheses are valid or need to be adjusted.

Find and talk to people 

Once you have a baseline of criteria for people who embody the characteristics that are relevant to your product area or product, you must go to find people to speak with.  

For a product that you already have launched and have users for, it is good to use your own database of users and reach out to for interviews.  If it is about understanding usage questions, make sure to query your database for active users of the specific product. For questions surrounding acquisition or churn, make sure to query new or inactive users from the database.

If you have a new product or new problem area that you need to talk to prospective users about, try finding similar or related products both internally and externally to establish a population of users to talk to.  For example, if you are building a new local marketplace and want to understand the ins-and-outs of what a user needs for the marketplace, you might go talk to Craigslist users to understand their workflows. On the other hand, if you are a PM at an e-commerce site building a new tool for B2B sellers who currently have to use the B2C selling tool, you may go talk to sellers who use the existing tool to understand how it does and does not meet their needs currently.

Understand the nuances

When conducting user research, it can come in the form of both surveys and interviews.  Generally speaking, surveys are best when you want to talk to a larger group and get quantitative data that helps you understand the problem.  Interviews are best when you are interviewing a smaller group of people and want more qualitative data. The reasons behind these statements are that surveys are cheaper in terms of time and setup. They are also easier to pose numeric responses.  Meanwhile, interviews are more expensive in terms of time and setup, but they allow for off-script questions that allow an interviewee dive further into details that the interviewer might not have thought to ask.

With that in mind, surveys are not limited to purely quantitative data, and interviews are not limited to qualitative data.  Surveys can have open-ended questions that can allow the person answering to input freeform answers that give qualitative feedback.  Likewise, interviews can be setup to record specific data points to gather quantitative data during the experience.

All things considered, regardless of the medium, it is critical to form questions in a way that allows you to dive deeper into the problem area to validate or reject hypotheses.  Quantitative data should help support demonstrating the frequency or severity of a problem. A question can be asked, “How many times a week do you experience this problem?” to quantify frequency to help size the opportunity of a problem.  Alternatively, a question can be asked “What do you do in order to address this issue?” in an interview to allow an individual to be more open-ended in helping the interviewer understand different ways a problem is handled in the current state of affairs.

All in all, it is important to leverage user research to understand the nuances of a problem with qualitative discovery and assess the prevalence, severity, or frequency of a problem with quantitative data.

Stakeholder Research 

A stakeholder for your product or problem is anyone who is remotely tied to or affected by the product. Stakeholders include internal and external individuals. It is critical for you to identify stakeholders and consult them as a part of your discovery. They have a unique and differentiated perspective of the product and problem that neither the PM/entrepreneur nor the customers have. Creating or changing workflows for stakeholders can have serious implications for your product. 

Identify potential stakeholders

Stakeholders come from a mix of internal and external partners. Some examples of internal stakeholders include:

• Legal

• Sales

• Marketing

• Support

• Operations teams

• Partner product and engineering teams

Whereas external stakeholders include:

• Contractors

• Clients of a service (which sometimes can overlap as the customer)

Identifying stakeholders involves listing any person, group, or entity that your product or problem area touches.  This can mean that it touches them directly (such as when a business partner uses your product to execute on its goal)s or it can affect the stakeholder indirectly (such as an operations team that executes on the goal from the business partner using your product, and is by nature downstream from a direct stakeholder).

The best way to identify these stakeholders is to map out all of the entities that are affected by the problem you work on, or mapping out user flows for an existing product and identifying everything that the user flow affects and who is involved.

Understand stakeholder impact

Once you have identified the key stakeholders, it is crucial to understand how the problem affects their work.  

This can take many forms.  For example, changing your product could impact how the sales team pitches.  Alternatively, approaching a new problem could open the company up to liability and would affect the legal team’s workflow.

In the end, truly understanding how your stakeholders are affected generally should come from interviews or emails to gather the qualitative assessment.  If your product or problem area has tracking or data points that can be associated with a stakeholder group, this can also help to understand the problem area. Surveys generally do not capture all of the data necessary to understand stakeholder impact because these types of problems are frequently nuanced in nature which makes it difficult to capture them via a form input.

Gather stakeholder expertise

Finally, it is important to gather knowledge that any stakeholders have in the problem area or product you are working on.  This almost always comes in the form of interviews, discussions or emails.

One example of this is interviews with the customer support team.  This team is the closest to the customer and his or her issues. Support teams frequently tally how often a problem occurs and will propose workarounds to customers.  This is a huge area of opportunity to gather knowledge on a problem area or product.

Another example includes discussions with the operations team.  If you are working on a problem area or product that has multiple users, such as a tool to generate business content for the end-user, the primary partner might be a business team who generates the content, but they might employ a secondary stakeholder in the form of an operations team to execute populating and publishing the content.  In this scenario, it is important to not only interview the business team who owns generating the content, but also the operations team doing the execution. These two stakeholders who are partners may have different and conflicting perspectives on the problem or product area.

Competitive Analysis

When thinking through the full extent of a problem area and product, it is critical to assess different competitors as you form customer problems and a product strategy.  

The different ways to do competitive analysis include assessing:

1. Direct competitors

2. Indirect competitors

3. Well designed products

4. Poorly designed products

Direct competitors

Analyzing direct competitors is the easiest and most direct way to do research on a product and problem.  It is generally pretty straightforward because your problem and product will have high overlap with the direct competitor.

A good example of this can be found with CRMs (Customer Relationship Management software).  Compass has its own CRM product for Agents to use in order to facilitate workflows for managing relationships with past, present, and prospective clients.  

When understanding the problem area for CRMs, the team tested other CRM offerings to understand what they did well and what they did poorly.  In this scenario, two great direct competitors were Contactually (now a part of Compass) and Salesforce. Contactually was the top choice of CRM for real estate agents because it was light-weight and easy to loop in real estate-specific data.  Salesforce, on the other hand is not used as much for real estate; however, it is the gold-standard for CRMs in the world.

When assessing both CRMs, the team focused on how the software fit well into user workflows and how it could be cumbersome or lacking in functionality that was critical to the agent relationship management model.

Aside from literally using the direct competitor products, it is also good to talk to users of these products to understand what their customer problems are and how the competing software meets these needs, and where it falls short.

All of this data helps to paint a picture of the existing market and what customer expectations are for your problem area and product.

Indirect competitors

Finding indirect competitors to reference can be a little trickier to identify; however, if you have clearly formed customer problems, they will start to become apparent.

An indirect competitor is an entity that represents a conflict between vendors whose products or services are not the same but that could satisfy the same consumer need. 

Building upon the CRM example from above, some indirect competitors that further the research for a problem area or product include Google Sheets/Microsoft Excel and iPhone Notes.  When assessing customer problems for the CRM, Google Sheets/Microsoft Excel met the customer needs for custom columns and filters whereas iPhone Notes offered the ability to quickly access and create freeform data that was easily accessible on-the-go.

Analyzing how potential or current customers use indirect competitors helps to identify gaps in your current problem statement and product. It also helps you break through your existing mental model of the problem and product to think bigger and more creatively about the customer.

Well designed products

Understanding the full extent of your product and problem area can extend beyond the competition to also include products that have great implementations and address their respective problems well.

As a product manager or entrepreneur, a micro-problem that comes up frequently in any experience is the concept of on-boarding.  Doing broad research and discovery on a problem area and product involves understanding the different flows that will be a part of the product and how these flows have been accomplished for experiences that are completely unrelated to your domain.  This helps to break out of the usual boring flows, get creative, and build better experiences than what is expected in your product area.

A strong example of this is the Beats Music app on-boarding experience. Not only has it outlived the app itself, but it also set a paradigm for future products.  On-boarding is a tough experience to build because you have to not only collect information about the user, but you also have to explain the application and do all of this in a concise experience so that the user does not get bored and drop off.

The Beats Music app on-boarding experience was one of the first to move away from stagnant inputs and descriptions to be more interactive and game-like.  When you started the app for the first time, you selected which genres that you liked, and the more you tapped a genre, the more you demonstrated that you liked it and the larger the genre grew.  This came in the form of a visually-appealing interface that showed interests both as a scalar and relative input.

Poorly designed products

When assessing different products and problems during your learning, it is also good to note which products were designed poorly and did not address customer problems well.

A great example of this is the redesign Snapchat did for its navigation.  The goal for the redesign was to expose Snapchat’s third-party media through the discover tab, but what it did was bury the most addicting feature that users craved, Snapchat Stories.  Snapchat took a well-functioning and growing product and ignored user feedback to create a poor design that furthered business goals over user workflows.

Product managers and entrepreneurs can learn from these mistakes by making sure they do not replicate the same design paradigms, but more importantly, learn to not follow the process and steps taken that led to these poor decisions.  For Snapchat, it was a result of poor research, poor testing, and poor monitoring. This example only furthers the argument that PMs and entrepreneurs should fully understand the problem area in order to make the right product decisions. Beyond this, PMs and entrepreneurs need to test and validate their decisions before fully committing to them.

Product Analytics

Analyzing product analytics is another great tool in understanding your problem area or product.  Product analytics help to tell the story in a quantitative manner and can yield light on details that a user might not think to share during a user interview.

Digging into product analytics can come in the form of looking at current product usage, similar product usage, and different user flows/funnels.

Current product usage

If you have an existing product launched, understanding the problem area and product is as simple as looking at the tracking data.  In an ideal world where key metrics have been previously established and tracking is firing correctly, looking at your metrics of success, metrics of failure, secondary metrics, and counter-metrics can help foster a deeper understanding of the problem area and whether your product is meeting the needs of the user.  

Similar product usage

In a scenario where you are working at a large company that might have similar or tangential products to the one you have or are building, digging into these other products’s analytics can help you to establish a baseline, or it can be a comparison data set for understanding your product.

An example of this at eBay is the way the company represents listings for an item. There are multiple experiences that exist to represent a listing that have nuanced purposes. The first is the generic listing page that is the source of truth and standard representation of a listing.

A second experience to represent listings is one was optimized for Google PPC. Its goal was to surface a listing for Google Ads, and if the listing sold while the ads were still running, it would surface another listing in its place.

Finally, a new listing experience was built with the goal to group listings as products (i.e. have all iPhone listings from different sellers on a single iPhone product page). This was aimed to help facilitate shopping flows where buyers who are looking for an iPhone can land on a page just for iPhones that could handle all variations of iPhones from different sellers and help the buyer navigate to the specific listing that met his or her needs. As eBay iterated on its representation of a listing, it was able to leverage these similar experiences to aggregate analytics data to better understand the user needs more fully in order to build better experiences.

User flows/funnels

Lastly, analyzing product analytics for user flow/funnels is the perfect way to see what users do before and after they interact with your product.  

For yet-to-be-launch products, these funnels help paint a picture of the full job the user is trying to accomplish. This can help you to see how the addition of your product affects the problems the user is encountering and help form hypotheses on how your work will best meet the user needs.

Wrap-up

Truly understanding a problem area and product requires a lot of digging as well as mixing qualitative and quantitative data.

It is critical to have a broad and deep understanding of the problem area.  Your work might only focus on a small piece of the overall problem; however, it will still tie in to areas of the problem that you have actively decided to not address.

Researching the product and problem comes from a mix of direct and indirect research.  Direct research comes in the form of user research for people who have or do use your product, stakeholders of your product, and digging into the analytics of your product.  Indirect research comes in the form of talking to users of similar or competing products, analytics of tangential products, and competitive analysis.

Products evolve and develop over time.  To be successful as a product manager or as an entrepreneur, you must have a passion and dedication for developing a rock-solid understanding of the problem area and product; in turn, you will be more successful in delivering the most value for your customers. 

Collaboration in Product Management

Watch my talk on Collaboration in Product Management that I gave at Product School.

Product management is a weird discipline. It’s so much fun because you are at the center of every piece of the puzzle for launching a product, yet, you don’t have any tangible deliverables.  

A PM is responsible to deliver a Product Requirements Document (PRD), and maybe some Engineering tickets in JIRA.  Some PMs are also responsible for data analysis, others are involved in wire-framing designs as well. Ultimately the end deliverable for every product manager is simply the product itself.

The irony is, the product manager owns no one piece of the product, yet is responsible for every part of it.  Designers make and deliver the designs, engineers write and deliver the code, but all a PM has to show for is some documents, emails, and meetings.

So what makes a product manager successful at his or her job? Ultimately there are a lot of different skills that a PM must bring to the table, but one of the most important strengths that a product manager must leverage is collaboration.

Collaboration: the action of working with someone to produce or create something

Google

The focus of this post will be on variety of viewpoints a product manager can take on when he or she is facilitating collaboration. I have learned to embody the topics below through my time as a product manager at eBay.

Team player

Successful collaboration in product management at a large company requires being a team player; but what exactly does that mean?  In my eyes, being a team player as a product manager is like being the captain of the soccer team.

The soccer captain

The soccer captain does not get to decide who is playing where, that’s the coach’s choice.  The captain is seen as a leader for the team and has the responsibility of rallying the team around the goal of winning the game.  In the end, the captain is not the person who wins the game by him or herself, and the soccer captain is not telling everyone what to do.  The entire team is on the field playing together and having to coordinate together to score and win the game. The goalie, the defense, and the offense all have slightly different roles but are expected to help contribute to all parts of the game.

Being a team player with the Squad

Being a team player in product management to facilitate collaboration is very similar.  The product manager is not a football quarterback calling the shots, but rather he or she is the leader that is helping guide the team towards accomplishing goals.  Engineers and designers have different roles, but they all need to work together to deliver a quality product. Everyone on the team ends up collaborating on the designs, the product requirements, the engineering quality, and the release.  Engineers should weigh in on designs giving feedback on what is feasible and what tweaks can be made based on technical limitations; designers should help check the final code to check for quality representation of the designs and ensuring a quality user experience.  All parties should be giving feedback to the product manager’s requirements.

The product manager, engineers, and designers each own their own piece of the pie but also collaborate on the other parts of the product.  No one person is dictating what everyone else is doing, but all three parties are supporting each other in their responsibilities and deliverables.  

At the core of each team, the product manager is the leading front to help facilitate the collaboration across design, engineering, research, data, and any other needs of the product.

Being a team player with partners

In large companies, it is rare for a team to operate in isolation; generally, the team either has a dependency on a partner team or is a dependency for a partner team.  Despite not being on the same team, it is still super critical for the product manager to maintain the team player mentality when collaborating with partners.

Sometimes different teams have competing priorities, this can lead to friction when deciding how to prioritize resources and deliverables.  One thing to keep in mind is that despite being on different teams in the company, everyone is still working at the same company. The company, in essence, is one giant team of people who are working towards furthering the company to achieve its goals and be amazing.  This is a critical mentality when managing partnerships across teams.

In situations where I have partnered with teams with competing priorities, I have found it helpful to remind everyone that we all have the same common goal of making great products that further the company; this sets a great base for collaboration.  It’s helpful to manage these potential conflicts by finding common ground. Sometimes it comes in the form of finding shared goals for our products, other times it’s about aligning on shared values and objectives.

Ultimately, finding the shared common ground is the first step to getting larger buy-in from partners on your collective goals and furthering the teams to win their respective games.  This helps everyone to align and get results.

Aside from garnering buy-in with partner teams, being a good team player for collaboration also requires simply being friendly.  Over time it is easy to sniff out people who are only out for themselves, and it catches up to them later. In a larger company, you’re never truly independent and in control of your own destiny.  If you only ask for favors but never help others, or if you only return favors for partners who have helped you before, you may struggle to succeed long term.

Moreover, compromise is also a big component for great collaboration in companies.  There will be times when you and another team partner on a project and do not see eye-to-eye on everything.  When faced with these situations, it is best to seek a middle ground and make compromises. Attempting to bulldoze a partnership to get 100% of your asks without any compromise does not lead to productive team partnerships.  There are times when it happens and it is out of your control, but generally speaking, compromising on the project fosters positive collaboration and shared success.

When it comes time to make compromises with a partner team, it is best to lay out your top priorities on both sides and what elements you cannot compromise on but also identity pieces that you can make compromises on. This helps both teams to accomplish their top priorities and succeed in collaborating.

Being a team player across squads is not just about how you can work with partners to achieve your goals, but also how you work with partners to help them achieve their goals.   Partnerships across teams are most successful when it is not an exchange, but when it's genuinely trying to see everyone succeed and do well. The good energy flows and helps you later when you need help from someone.  The product manager who is working to be a team player for both his or her sprint team and for the broader organization is the product manager who sees the most success.

Emotions

Successful collaboration in product management in larger companies requires a deep understanding of emotions.  Product management is a people-oriented job that requires you to have a grasp on your own emotions and be able to understand and work with others’ emotions.

Empathy

The first and most important aspect of fostering collaboration in product management from an emotional standpoint is empathy.

Empathy is defined as the ability to understand and share the feelings of another

Google

A lot of product management books and experts will discuss empathy in terms of being empathetic to user needs; however, empathy is also critically important to understandings your team and your partners.

In relation to your specific team, empathy is understanding the parts of software development that your engineers love (e.g. like building a brand new experience) and knowing what they dislike (e.g. such as fixing business-critical bugs on the weekend).  Empathy for your team might also be less directly associated with the product and more about understanding things that make them feel appreciated and valued.

Empathy towards your partner teams is understanding more than just what product they own or what their roadmap is, but also understanding their attachments to certain projects or the underlying struggles that may be involved with addressing competing priorities.  

Nonetheless, empathy for your team and your partners’ emotional experience can give you an edge in fostering great collaboration because you understand what makes them tick.

Excitement

A key emotional experience in fostering collaboration at a large company is excitement.

In true product management, it is rare for a team to be directed to execute on a specific task or forced to partner on a project.  Great product-led companies operate bottom-up in their directives. In a bottom-up organization, collaboration stems from excitement towards a common goal.  

As a product manager facilitating collaboration, it is key to get your team, and your partner teams excited about the project you are working on.  Maybe the excitement is about a new game-changing feature or an amazing design improvement. Other times excitement comes from using data to show performance or an opportunity.

Regardless, excitement is an extremely powerful emotion for motivating individual teams and partner teams to collaborate.

Calm and composed

Building products rarely goes exactly as planned; sometimes in collaborating with partner teams where certain things are out of your control, mishaps such as a missed deadline or a sudden change in resources can occur.  In these instances, it is critical to exercise being calm and composed.

The surest way for a collaboration to go downhill both within a squad or amongst partner teams is for an individual to lose his or her cool.  As a product manager, keeping calm and helping the various folks to remain composed ends up being one of those skills that is not written in the job description but ends up being extremely vital during hard times.

Remaining calm in a tough situation is easier said than done, but there are techniques that you can employ to let cooler heads prevail.  These include:

1. Practicing mindfulness

2. Turning a hair-pulling moment into a moment of laughter

3. Maintaining perspective of the big picture beyond the difficult moment

4. Taking deep breaths

Frustration is inevitable, but how you handle that is critical. Lashing out or being passive aggressive due to an aggravating situation will only backfire. When it is beneficial, have an open and non-accusatory conversation about whatever has happened.  Regardless of what happens, the best thing you can do is learn from it, adapt and laugh it off.

Having fun

An extremely underrated emotional experience that helps fuel great collaboration is having fun.

Work takes up at least 40 hours a week (generally more). This means as a product manager, you are spending a large chunk of your life with the folks on your squad and with folks on partner teams executing product roadmaps.  People naturally tend toward situations that are more enjoyable and fun.

In product management, there are ways to make sure you and your respective teams are having fun with what you are doing.  Not everyone is lucky enough to work in technology and build the future, that in itself is fun.

Moreover, having fun can be more than just the work in front of you, but it is also the environment and attitude set forth every day.  Just because you are at work does not mean everything discussed has to be purely work-related. It goes a long way asking your team and your partners how their weekend was, or understanding and talking about hobbies they might have.  This blending of topics can bring more interesting and fun conversations to the work environment. When folks are having more fun collaborating because of the tone of the environment, the collaboration improves tenfold.

Being upbeat and light-hearted makes collaboration in product management a pleasure.

Relationships

Collaborating effectively in product management requires great relationships.  Relationships matter. You'll hear entrepreneurs talk all the time about how important relationships are to growing and succeeding, the same applies to product collaboration (as alluded to in the section on being a Team Player).

Trust

A critical component of building great relationships for collaboration includes building trust with teams and partners. Trust in these folks and their expertise. If you second-guess them or override their work, it breaks trust.  On the flip side, if there is an expectation for you to provide something, honor your word and deliver results; this builds the team’s trust in you.

Managerial relationship

Your relationship with your manager is also critical in furthering collaboration in product management.  

Manage up; not in a way that makes you a sycophant, but in ways that further your team. Try to avoid being in a passive relationship with your manager waiting for him or her to tell you what to do.

Push yourself and your manager to help you grow and execute. Use your manager to facilitate conversations and decision making across the organization. You won't win every negotiation, sometimes you have to escalate and partner with your manager to move the needle. Having a great relationship with your manager will allow to move faster and collaborate better around the company.

Positive reinforcement

A key part of building great relationships for collaboration is positive reinforcement with your team and your partners.

Explicitly letting your team or your partner know when they have done a great job or have gone above and beyond is extremely rewarding on both sides.  It encourages great work and fuels positivity for future collaboration.

In special situations, it is also great to send emails to a team member or partner’s manager commending the individual on their efforts.  This type of impromptu positive feedback is rarer, but it leaves a great impression on all parties. Helping your partners and team further their career is a sure way to build a strong relationship and further your abilities to have positive collaboration.

Never burn bridges

Product management involves working with a lot of different parties over time, so it is key to remember to never burn bridges.

In large tech companies, people switch teams a lot and priorities shift over time.  Sometimes you end up working with someone and you do not have the best time or relationship.  It is easy to want to blow someone off that you have not had a great experience within the past; however, the world is smaller than it seems, and you might end up working with that person again in the future.

Even when a collaboration with someone is hard, it is still better to preserve the positive parts of the relationship than to write the individual off.

Communication

In my experience, one of the most common points of failure when collaborating in product management is a failure in communication.

Productive communication for facilitating collaboration across teams and partners is not trivial.  Not everyone interprets information the same way, and conveying knowledge differs from person-to-person.

Source of truth

I find it helpful to have a central document that acts as a living record of what the project is and how it evolves.  This generally is my PRD (or spec) that details the customer, the problem, the objectives, any dependencies/limitations as well as relevant resources and people.  Some companies have a specific format that everyone uses, a lot of others do not. In a situation that does not have a specific format, I find it helpful to detail the core pieces mentioned above, but I also add sections and content that my team and partners ask for or find relevant.  In the end, the document format should fit the team and its needs.

I also find it helpful to have a centralized shared folder where I store everything relevant to the project.  This includes the PRD, other relevant PRDs, research, data, designs, you name it, it’s all in the shared folder.  This way I can share out a single document and folder that enables all team members and partners to explore what they need on their own time, and it also keeps a central source of truth.

Establishing deliverables

Moreover, when there are meetings and discussions surrounding a collaborative project, it is helpful to make sure there is a clear agenda, but it is critical to make sure that at the end of any meetings or discussions, it is explicitly communicated what deliverables are expected from folks and on what timeline.  It is all too easy to have a breakdown in communication surrounding what is to be done after a meeting and who is doing it. Meeting notes and summaries help mitigate this risk, but it is best to recap in-person and establish these expectations.

Managing expectations and updates

Lastly, in certain situations, status emails help with communication across broader collaborations.  In a massive company, it is impossible to make every meeting and keep up-to-date on the happenings of a project daily.  A weekly or bi-weekly status email helps keep all stakeholders informed, manage expectations of the team and partners, and maintain a paper trail for when things go awry.

Not all of these pieces are necessary for strong communication to facilitate collaboration.  It is best to figure out which methods work for the team and partners rather than force a method onto the group.

Self-inquiry

Additional aspects of furthering collaboration in product management include taking time for reflection, showing humility, and getting feedback throughout the product journey.

Humility

An underrated quality in a product manager that helps build collaborative efforts is humility.  

Over time, every product manager messes up, and that's OK. It might be a missed requirement, forgetting to include a key stakeholder, or a mistake in a number of other ways.

The best way to maintain trust from your collaborative partners is to acknowledge when you have messed up, be open about what happened, and learn from it.  Collaboration is not just about what works well, but also about what does not work well.

Your partners will respect you more for recognizing a point of failure as opposed to sweeping it under the rug or casting blame elsewhere.  The acknowledgement and openness of your mistakes conveys strength and courage, both of which put you in a better position for future collaboration.

Reflection

Sometimes things go well and other times they fall flat on their face.  Ultimately you will be able to build relationships and trust for collaboration through reflecting on your experiences building products.

As a product manager, your collaboration skill sets will grow if you take time to reflect on how your working relationships are in practice.  

Furthermore, your partnerships grow stronger within a team and with partner teams when you take the time to reflect with the respective members as a group.

Feedback

The best way to build your collaboration skills and encourage folks to collaborate in the future is to ask for honest feedback.

It can be hard to hear negative qualities about yourself, but you have the potential to learn so much more at a faster rate when you let your guard down and ask your team and partners to identify areas of strength and more importantly areas for improvement.

Not everyone is comfortable hearing tough feedback, and many are uncomfortable giving blunt feedback.  It is critical to not be defensive and to simply listen and understand feedback when it is given. These moments are difficult for a lot of people, but they can be the biggest opportunities for growth as an individual and as a collaborator.

Leadership as a service

Last but not least, one of the most impactful perspectives a product manager can lean-in on as a collaborator is practicing “leadership as a service”.

[Leadership as a service is] the job to develop collective capability with a sense of shared endeavor. Leadership as a service is not about extracting work or anything from teams but it’s about serving them and inspiring them by service. Leadership as a service is a philosophy and set of practices.

Abhishek Tiwari

This idea of leadership as a service is meant to flip the roles and tasks of a leader upside-down.  Traditionally, a leader is telling everyone what to do and setting the direction.

As mentioned in the Team Player section, collaboration in product management is less like that of a quarterback and more of a soccer team captain.  The team has to execute as one, and no one person is calling the shots.

A great way to collaborate with a team and with partners is rather than asking someone to do something, instead ask “How can I help you to accomplish X? What are ways that I can help make this easier/faster/better?”.  

This inverts the entire model and truly reflects the nature of a product manager’s role, the facilitator of everything in order to launch great products.  This nuanced approach to viewing collaboration and leadership makes a HUGE difference in how the team and partners execute. Not only does it send a positive tone, but it also helps you as the product manager know exactly where to lean in and support the team in executing their tasks.

Leadership as a service is the icing on the cake for great collaboration in product management.

Conclusion

In summary, collaboration in product management is not a trivial feat.  Many ideas and practices go into fostering great collaboration, including:

1. Being a team player

2. An emotionally sound environment

3. Strong relationships

4. Great communication

5. Self-inquiry

6. Leadership as a service

Product management requires a mixed bag of skills.  Collaboration is one of the hardest yet most important ones to hone in your product career.

There is no single right way of collaborating. The best thing you can do is be open, be honest, and always work to further the team, product, and company.