Coaching – Collaboration

In this article, I continue the series on coaching product managers by talking about another critically important skill that is so often misunderstood or under-appreciated, and that is collaboration.

Collaboration is one of those words that is used so often in so many different ways that it has lost its meaning for many people.  Of course they are think they’re collaborative.  Few view themselves as anti-collaborative.

But in the context of an empowered, cross-functional product team, being collaborative has a very specific meaning, and it is most definitely not how many people, especially product managers, are inclined to work.  So this is often a critically important area for the manager to focus on during coaching.

In the article Beyond Lean and Agile I talk about the three critical characteristics of strong product teams, no matter what processes they use, and the second one is that strong product teams solve problems collaboratively.

In particular, it is no longer the old waterfall process of a product manager defining requirements, and handing them off to a designer to come up with a design that meets those requirements, and then handing that off to engineers to implement the design.

So what do we really mean by collaboration?

Let’s start by talking about what collaboration is not.

First, collaboration is not about consensus.  I’ve written earlier how important it is not to confuse collaboration with consensus.  While we like it when the product team is in agreement on the best course of action, we do not insist on this.  Similarly, collaboration is not about democracy.  Rather, we depend on the expertise of each member of the product team.  Generally speaking, if the tech lead feels a specific architecture is called for, we defer to the tech lead.  If the designer feels a specific user experience is called for, we defer to the designer.  Occasionally there will be conflicts and judgement calls, and normally we’ll run a test to resolve.

Second, collaboration is not about artifacts.  Many product managers think their job is to produce some form of document capturing “requirements,” or at the least, they are there to write user stories.  It is true that sometimes we need to create artifacts (especially when team members are remote), but that is certainly not how we collaborate.  In fact, these artifacts more often get in the way of actual collaboration.

Why is that?  Because once the product manager has claimed something is a “requirement” it pretty much ends the conversation, and moves the discussion into implementation.  At this point the designer feels like she’s there to ensure the design conforms to the company style guide, and the engineers feel like they are there just to code, and we’re back to waterfall.

Third, collaboration is also not about compromise.  If you end up with a mediocre user experience, and slow performance and limited scalability, and dubious value for customers, as a team you lose.

We need to find a solution that works.   By that we mean that it is valuable (valuable enough that target customers will actually buy it or choose to use it); it is usable (so users can actually experience that value), it is feasible (so we can actually deliver that value) and it is viable for our business (so the rest of our company can effectively market, sell, and support the solution).

As we’ve discussed extensively elsewhere, in order to do this, we need to know what we can’t know, and admit what we don’t know, and focus on discovering a solution that works.

And that requires true collaboration.

Remember that our job in product is to solve the problems we are asked to solve, in ways that our customers love, yet that work for our business.  That’s our job as a cross-functional product team, and each member of the team is there because they bring necessary skills.

This all starts with true and intense collaboration with your design and engineering teammates.

My favorite way to actually do this is to sit around a prototype (usually created by the designer) so as a team you can consider and discuss the proposed solution on the table, and the designer can consider different approaches to the experience, and the engineers can consider implications of different approaches and the potential of different enabling technologies, and the product manager can consider the impacts and consequences of each potential direction (e.g. would there be privacy violations, or would this be something that would work with our sales channel?).

Note that while doing product discovery, certain tools and techniques serve both to facilitate collaboration, as well as to provide an artifact as an output of that collaboration.  Two very popular examples of that are prototypes and story maps.  The very act of creating and discussing prototypes and story maps facilitates true collaboration.  And if you are diligent about keeping your prototype or story map up to date, then they can also serve as an artifact capturing the learning and decisions from the discovery work.  The real benefit and purpose of the tools in this case is in fostering the collaboration, however, it is a nice side-benefit to be able to have an artifact at the end.

Notice that the product manager and engineers aren’t trying to tell the designer how to her job.  And the product manager and designers are not there to tell the engineers how to do their jobs.  And the designers and engineers aren’t there to tell the product manager how to do her job.

Rather, in a healthy and competent team, each member of the team is counting on the others to have done their homework and bring the necessary skills to the table.

But please don’t misunderstand this as designers are only responsible for usability, and engineers are only responsible for feasibility, because this would miss the real point of collaboration.

Designers often have insights based on deep understanding of our users and their behaviors that lead us in a different direction in terms of the problem we’re solving, or our approach to the problem.  These insights will often have big impact on value, and indirect impacts on things like performance.

Similarly, strong engineers have deep insights into the enabling technology that often leads us to entirely different solutions to the problems we were assigned, often much better than anything the product manager, the designer or especially the customer could have imagined.

If I had to pick the one thing I love the most about the feeling of true collaboration on an empowered product team, it is the form of magic that happens when you have people that are a) motivated and b) skilled in their respective discipline – product, design and engineering – and they sit around a prototype or watch a user interact with our prototype, and the engineer points out new possibilities, and the designer points out different potential experiences, and the product manager weighs in with the sales or financial or privacy related implications, and after exploring a bunch of approaches, they find one that actually works – it’s valuable, it’s usable, it’s feasible and it’s viable.

In my experience, there are two situations where this most often goes wrong.

The first is that the product manager has not done her homework and she doesn’t know the various aspects and constraints of the business – sales, marketing, finance, legal, privacy, etc. – so the product team really doesn’t have the information it needs to solve the problems it has been assigned (which usually means they’re back to implementing features on a roadmap).  That’s why we discussed early in this series on coaching that as a manager your first priority is to assess the product manager and create a plan to get her to competence.

The second is arrogance.  If the product manager believes the solution she already has in mind is clearly the best, even if she is right, collaboration is stifled, and she probably now has a team of mercenaries rather than missionaries.

While it’s true that the majority of the actual collaboration for a product manager is happening with her designer and engineers, there are several other examples where we need true collaboration as well.

A healthy relationship with stakeholders is one based on true collaboration.  The product manager is not there to “gather requirements” from stakeholders, but the product manager is also not there to dictate solutions to stakeholders.  Rather, the strong product manager understands that each stakeholder is responsible for some key aspect of the business, and they are a key partner in helping to come up with a solution that works.

A common and clear example of this is that often what we are trying to do has legal implications, maybe around privacy or maybe around regulatory compliance.  The legal stakeholder is your partner on understanding these constraints, and helping to evaluate the suitability of various approaches.

Again, a constructive, collaborative relationship with stakeholders is predicated on the product manager having done her homework so she can be that effective partner with the stakeholder and not just some form of facilitator or project manager.

Everything I said above is doubly important when we’re talking about collaborating with company executives.  In general, the more senior in the organization, they more the executives care about everything – customers, brand, revenue, compliance – and the more important it is for the product manager to have done her homework.

Collaborating with stakeholders and executives involves listening carefully to try to understand the constraints, and thinking hard about solutions that would work for our customers and our business.

Another important form of collaboration, especially in companies with a direct sales force, is engaging with prospective customers to determine if your product can meet their needs.  It is natural for the prospect to try to dictate requirements for features, but your job is to work to understand their underlying issues and constraints, and then work collaboratively with your prospective customers to determine if there’s a general solution that will meet their needs.  This form of collaboration is at the heart of the customer discovery program technique.

Collaboration means working together with our designers and engineers, stakeholders and executives to come up with a solution that solves for all of our constraints – this is what we mean by solutions that our customers love, yet work for our business.

Getting good at true collaboration is at the heart of how strong product managers work.  It’s a combination of skills and mindset, and it often takes active coaching by the manager to help the new product manager develop this capability.