3 Ways to get Design, Dev, and Product Management to Work Together Effectively

A couple weeks ago, I had the honor of speaking on a panel at Boulder Startup week with my work colleagues whom I greatly admire.

Working at Pivotal Labs has taught me the true meaning of that quote, “Culture eats strategy for breakfast.” In order for multi-disciplinary teams to work effectively together, you have to start with your relationship with each other as people. It is all about fostering a culture of profound respect and trust. At Labs, we strive to structure all our engagements with a Balanced Team.

What is a “Balanced Team”?

It is summarized as three things:

1. Co-located and dedicated to one product
2. Sharing the vision; no silos, no handoffs
3. Multi-disciplinary with high value on collaboration and iterative development

What this looks like at each organization can vary, but in general it means one team of people per product. There are certainly exceptions for larger products (e.g., Netflix, Spotify, Google Chrome, etc.) and I will address this later on in the post.

The team is responsible for the product, is in communication daily, and feels a deep ownership over what is created. This removes a culture of blame, and if anything goes wrong, it falls on everyone on the team.

When we say “shared ownership” this is what it looks like for each role:

• Designers are the “Empathizer-in-Chief,” with an obligation to the team to understand the customer at an expert level, translate high-value needs into product, and have an important authority to prioritize customer problems.
• Developers “Raise High the Roofbeams,” with an obligation to the team to envision the best possible solutions based on available technology, commit to the customer outcome, and have an important authority to measure outcomes over time.
• Product Managers are “The Scales of Justice” with an obligation to the team to translate vision into execution by balancing customer needs and business value against feasibility, make fast and concrete decisions despite inadequate evidence and conflicting priorities, identify and ensure that the appropriate feedback loops are implemented to continuously de-risk the product, and have an important authority to delegate decisions to the appropriate persons on the team.

Credits: Janice Fraser (http://www.slideshare.net/clevergirl)

One thing to note: If you’re a two-person startup with one person playing two roles and other person playing one, you may be asking, “What if I can’t get a third person? I’m bootstrapping here!” This is completely doable, but it will be vitally important that the person who is playing a dual role is consciously balancing both voices. Just be aware of the risk having one voice muted by the other two if someone is not there consistently advocating for that third point of view.

What are the benefits?

Here’s our top three at Pivotal Labs:

1. Get to a better outcome faster
2. Make your feedback loops tighter so you can avoid rework
3. Create a sense of shared ownership, trust, common understanding and empathy to work more effectively together

Building products is hard. Every day you’re making hundreds of little decisions. When you’re working alone and you have a question about what direction to go in, you’ll often make a decision based on the available information at hand, your experience, and your assumptions of what the rest of the team wants. So when you’re working together, you get the benefit of everyone’s knowledge at hand (making the experience pool bigger!) and fewer assumptions.

So, if you’re working on a UX decision, dev can steer you to a more achievable solution. PM can help you remember what the business requirements are, and everyone can help to remember “What did Patty say in that user interview?!”

How does it fit into the daily workflow?

While the process is a little different depending on what stage of the product lifecycle you are in, we have two grounding meetings per week where everyone is together. If you’re a startup with remote resources, try at the very least to have these two touchpoints. If you can be face-to-face, all the better:

1. Planning: Happens at the start of week to see what we will be doing and discuss items that may need clarification.
2. Reflection: Often called Retros, these happen at the end of week to see how things went, how everyone is doing, and what can we do to improve things. This is a safe and creative space where the team takes an honest look at how we are performing as a team.

At Labs, we sometimes kick off a project with a short “Discovery and Framing” engagement that focuses on validating and invalidating the product’s riskiest assumptions. This helps with creating the first one or two weeks worth of backlog, and increases our confidence that we are not just building the thing right, but we are also building the right thing.

One common mistake (and we are sometimes guilty of it ourselves) is not bringing Dev into the conversation early enough during the beginning of the product lifecycle. Because PM and Design are usually the ones conducting user interviews and synthesizing feedback during the initial Discovery phase, Dev might not enter the picture until halfway through the Framing (or “solutioning”) phase.

Developers are often informed about what is just now technically feasible. Having the most relevant information about what is at the cusp of technology means you can validate or invalidate implementation assumptions. Marty Cagan recently wrote about this as well.

Sharing the stage with Nick Wade, Ethan Andrews and Erica Birkman

So what are some next steps?

When we came together to plan for the panel, our goal was to make sure the audience left with at least one actionable step they could take the very next day. Every change begins with a small step to integrate new ideas into your world.

1. Have meaningful conversations as often as you can: Train yourself to notice when you’re making decisions on behalf of another “voice”, and make a conscious effort to engage that team member in conversation before taking any other steps.
2. Dissent, but also give each other the benefit of the doubt: It is important to remember that dissent is invaluable — you need a dissenter, even if you don’t agree with the specific dissent itself. Dissenters open up discussion and sharpen everyone’s thinking. There’s a great story about this in the book “Sway”, and it even impacts how the Supreme Court is set up. At the same time, always remember that you are all on the same team. Listen well to your teammates — there is tremendous value from each voice.
3. Value group facilitation over heroism: Don’t try to be a hero. As Janice Fraser puts it, we need to be good participants in a team dialogue that gets the right thing to happen without drama, forever. It’s unnatural, and we need to be taught how to do it, but we can do it! At the end of the day, reflect on how things went right or wrong, figure out what happened, devise a new next step, do it quickly, and do it without drama. This is only possible when we stop acting like heroes, and work as a team.

At the end of the panel, I heard a really interesting question about what does Balanced Team look like across platforms or with really large products? I wasn’t satisfied with the answer I had, so I did some research and found this article by Ken Norton. It emphasizes tactically dividing up ownership across PMs around customers, not code repositories.

Envision a feature you might want to build, such as rescheduling a doctor appointment. How many PMs need to be in the room when you talk about this feature? How many deciders? Is it one patient experience PM who has the final say? Or an iOS PM, an Android PM, an account system PM, a web PM, and a backend PM… you get the point.

All in all, a great time. Huge thanks to the BSW volunteers, janice fraser, Tessa Reuber, Erica Birkman, Ethan Andrews, Nick Wade, Matthew Heidemann and Mike Gehard!