How we work together

All teams have different needs that cause them to organize, communicate, collaborate, coordinate, and recruit differently. There is no one-size-fits-all all. Entire books have been written on just this subject! I’m going to share some of my experience and opinions on how best product teams can work together. For some of this I will take the perspective of the product design team since they are often, from my perspective, the most misunderstood. However, most of these points can be applied across many varieties of product teams.

Finding effectiveness

So, what are your needs at your company, and how should you organize yourselves? With most organizations and the individuals I speak with, this needs to be a mixture of reactive and proactive. What are the problems we’re facing now versus where do we want to go and be? Many design teams, for example, start out in vastly different places and have vastly different maturities depending on who the starting members are. Still, many design teams end up looking more and more similar as they mature. I think there’s a good reason for that, but also pitfalls to avoid.

The widely celebrated O'Reilly book Org Design for Design Orgs says there are 12 qualities every design org should aim for to be effective, but I find these applicable to most product teams as well:

1. Shared sense of purpose
2. Focused, empowered leadership
3. Authentic user empathy
4. Understand, articulate, and create value
5. Support the entire journey
6. Deliver at all levels of scale
7. Establish and uphold standards of quality
8. Value delivery over perfection
9. Treat team members as people, not resources
10. Diversity of perspective and background
11. Foster a collaborative environment
12. Manage operations effectively

We could spend a long time discussing any one of these points. Still, I’m going to attempt to remain brief with a few key tips that I’ve found have worked over the years—my own interpretations of a few of these points through the lens of the design ops areas of organizing, collaborating, and humanizing.

Organizing

Problems, not products. Outcomes, not outputs.

We should organize teams around problems and outcomes, but not products and outputs. Your folks should be organized around the thing you want to be solved, not a derivative of it. If people are focused on products, for example, they may not give attention to a key part of the user journey that occurs outside of that product but has a significant effect on the outcome they are trying to achieve. In other words, they forget the overarching funnel they are a part of. This harkens back to designers always being trained to ask why repeatedly until they get to the core of a problem. Same same.

“A design team’s output is the result not only of their skill, but the sophistication and sensitivity of how they operate.” –Org Design for Design Orgs

I love that quote. It reminds us there’s more to giving results than just butts in seats. A lot more.

First team

In Patrick Lencioni’s book about organizational health, The Advantage, he outlines an important distinction that teams need to make about how they’re organized: namely, who their “first” team is and who their community of practice is and not getting the two confused. Many organizations start creating silos early on out of their departments or LOBs (Lines Of Business), thinking that those are the folks who need to work and spend most of their time together. Meanwhile, what Lencioni and other folks like Marty Cagan (in his Empowered book) posit is that those are simply your communities of practice, folks who can help each other with the tactical, surface-level work but not to innovate or get closer to solving the core why of a problem.

Your First Team, in the case of SaaS design ops, is generally the Empowered Product team (generally a Product Manager, Design Lead, Tech Lead, and Product Marketer but your context and needs may be different). People who get really good at breaking down problems together in a collaborative, non-waterfall way. It’s also important to understand that this doesn’t mean they aren’t being given direction. Non-waterfall or operating in an empowered way does not mean that a team like this gets to do whatever it wants. They know what direction is meaningful and how to negotiate for better direction. For example, if a leader directly tells a designer what to do and how to do it, the result is probably not going to be great. They aren’t trusting the designer to do what they do best, and hopefully, that designer can negotiate, rationalize, and educate that leader to bring them along to a better way. If that same leader instead tells an empowered team that they, together, need to reach a certain outcome and allow them to self-organize using their specialized skills to figure out how best to do that, then the results will be much different.

The best advice I have to continue to flex into this space would be to create very intentional opportunities for it to manifest. Rituals, events, social gatherings, team-building, etc., you name it, with the empowered teams that will be working together, with very intentional collaboration and shared leadership. Do not let the PM lead everything—take a stance as a team and defend your approach as a team!

Role definition

Defining the role of the individual designers, as well as the design team as a whole, can often be an incredibly difficult task in organizations. This has less to do with the organization itself than it does with people’s experiences and biases they’ve built up from elsewhere before that. Common biases might include thinking design is a service, that it’s purely visual, or that it’s an added step.

My most successful method in building a case to change people’s preconceived notions of Product or Product Design is to do what most other corporate functions do in similar scenarios and prove their ROI (Return On Investment). This means making sure you launch and learn through measuring rather than launching and leaving. Not only does this help paint a clear picture of what Product and Product Design’s roles in the organization are, but it also helps you make better decisions! This is an important part of building an outcomes-over-outputs mentality that will really help you excel in the Product space. If you're a Product person that doesn't know how to measure the return on what you're doing, let alone connect your work to broader business outcomes in general, I think you will continue to struggle.

What should you focus on?

Start by checking on the understanding and maturity of Product and Product Design’s role, place, methodology, and processes.

• Are folks all fully trained and on board with Agile?
• Are there waterfall mentalities and approaches present?
• Have teams experienced much exposure to proper UX or Product Design?
• Are they actually talking to your customers and partners?
• Do they have a good relationship with teams who are a proxy for customers and partners, like Sales and Support teams?

You must make a concerted effort to move the organization from subjective decision-making to objective decision-making.

The more difficult perceptions to reign in at many organizations will be those more used to waterfall and design acting as a service to other areas in the business. Watch for evidence of decisions being made on gut, subjectively, or otherwise, with little user research and evidence. When working in Product and Design, especially on an empowered product team, we seek to mitigate risk, and working in these ways is the antithesis of subjective decision-making. Part of Product Design’s role is to champion parts of the scientific and engineering processes that support building great products and doing so efficiently.

• If someone raises a problem, we validate if it's actually a problem.
• If folks want us to suddenly react to one loud customer or partner we pause and instead look for trends and patterns to help all customers and partners.
• We chase the data, both quantitatively and qualitatively, and look for areas of risk, need, and opportunity.
• We match up our discoveries against the business' strategic goals to help us prioritize the wealth of information we begin to collect.

Tips & suggestions

These are things I have seen help teams progress through similar design maturity stages.

Communication

1. Elevate the Product and Product Design teams and have them share at events like your all-company rituals like “All Hands” and company-wide Scrums.
2. Note: This should be thought leadership, strategy, research, insights, and more, not just visual representations of work.
3. Also, do this at demos.
4. When presenting work at demos, explain the process, and NEVER leave out the reason why the work was important and what it solved.

Research

1. Help guide teams through research synthesis.
2. Have mandatory research synthesis after a research phase.
3. Communicate 1-2 insights per research study, even if the insight is there were no new insights.
4. Consider replacing “MVP” with “MEL”—Minimum Effort to Learn—where it makes sense to do so. Be clear about when your team needs to take more time to learn than they do to provide a return and why.
5. Dig for the core “why” whenever being presented with a problem or solution.

Collaboration

1. Include other cross-functional team members in more of the process. Bring them along instead of telling them later.
2. Enforce designers to help lead discovery and the maturation of its practice.
3. Form working agreements among teams.
4. Hire marketing designers to help support non-product design.
5. Embed as close to a 1:1 ratio of product designers and product marketing managers to empowered teams as possible.

Maturity

1. Ask other people at the company semi-regularly what they think Product and Product Design’s role is.
2. Find any way to put a stop to requests that treat the product designer like a service department.
3. Agile training for those exposed to waterfall.
4. Good Agile training for anyone regularly working in Agile. Seems like a no-brainer, but I have met way too many people following Agile blindly as a process instead of understanding the core principles/values and when to use/not use something.

Collaboration

Meaningful collaboration is one of the biggest problems many organizations struggle with as they scale, try to adopt an empowered product team mentality, or effective product design. So many teams I encounter think they’re collaborating, but what they’re really doing is communicating or asking for feedback after the fact. They don’t include each other in problem identification, ideation, or solutions in meaningful ways. Running effective meetings, when to have meetings, and how to collaborate asynchronously are things teams need to reinvent for themselves as first steps.

I’ve written extensively about collaboration in my articles elsewhere on Product Operations. What sometimes surprises people is that among recommending collaborating with your other organizational ops-pro counterparts, I also recommend collaborating with folks like HR on solutions. Many companies struggled with collaboration and communication due to the pandemic forcing them into a remote-work scenario they weren’t ready for. However, since so many others struggled or are struggling with the same thing, it’s at least semi-easy to google different ideas and see what others have done to evolve and adapt! Where the HR piece comes in is that our HR folks are often hearing great feedback from across the org about people’s pains and can play an excellent part in aiding improvements to team processes, tools, and other maturities.

Think about what remote work removes or adds as a good starting point. For example, remote work removes a lot of social interaction. Water cooler and hallway talk that’s super beneficial to building working relationships, solving problems, spinning up new initiatives, and more. Social interaction also aids diversity, equity, inclusion, and belonging big time. Do folks feel included or like they belong? If not, they may have trouble collaborating in a meaningful way. They might hold back in group scenarios, even when called upon. So, if we go back to our common Product ethos of always building empathy and/or seeking the deeper why I often don’t find collaboration to be the core issue. It’s often a symptom, and the core issue is something more touchy-feely, like folks not knowing each other well enough or building trust. Dig for the broader why.

On rituals

I am a big proponent of regularly being critical of your rituals—the existing ones, spinning up new ones for underserved needs, and killing ineffective ones. Ironically, the most effective method I have seen of determining this is with a ritual!

Many of us are used to holding retrospectives where we dive into what went well and what could be improved. The problem though is that many teams aren’t asking meaningful enough questions during these sessions, nor are they committing to action from what they discover. These types of retrospectives should be held, at minimum, every month, just on the status quo of doing the work, but also every time a significant milestone is hit, or outcome is achieved. In addition, when they are held, they should be structured in a way that makes them productive and useful. This might mean folks providing mandatory feedback in some scenarios, or it might mean assigning DRIs (Directly Responsible Individuals) to each issue that’s raised to chase it and seek improvement. I have seen a great many ways to make retrospectives more effective, but the key has always been that there are takeaways based on what people raise, and someone is accountable for actioning on that feedback. If your retros become just an area to complain, pat backs, or document, they should be retired– the same goes for most other meetings.

Regularly revisiting your Definition of Done (DoD) can accomplish this similarly. The real takeaway here, which many folks I coach hear me say over and over, is that we need to iterate on our processes almost as much as our products. And often, that means removing what’s no longer working first and foremost, and secondly, a bias towards action.

Stealing from POPs & L10

POPs is a concept that I first heard popularized from the Ken Blanchard organization of facilitation experts. It’s basically a framework to help you run better meetings and avoid ineffective ones.

L10, or “Level 10” meetings, are a strict concept from the EOS (Entrepreneurial Operating System). They attempt to help keep your group on-task in a meeting and learn good etiquette and habits. For the most part, I think they can actually inhibit meeting productivity, especially around collaboration, though I have seen them help significantly in improving communication and coordination of efforts up to a certain point.

Say what you will about POP and L10 meetings, but there are a few things that we can steal from those processes that work.

POPs:

• Every meeting should state on the invite its Purpose.
• Every meeting should state on the invite the Outcome you will achieve by the end of the meeting.
• And every meeting should state on the invite the Process by which folks attending will be reaching the outcome.
• It’s a few short words, nothing more, not a paragraph.
• You instantly give people context and support neurodiverse and anxious people.
• You give people enough information to make a better-informed decision about if they even need to be there.
• If you’ve struggled to outline these items, then you probably shouldn’t have a meeting.

L10 meetings:

• The only thing I recommend keeping long-term from L10 meetings is the rating system. Implementing this, even temporarily at certain cadences, can ensure you’re soliciting feedback and improving.
• Everyone must rate the meeting from 1-10 at the end of every meeting and say why.
• Generally, you remove 1 point for everything that could have been better
• E.g. I give the meeting 8/10 -1 point for So-and-so being late and -1 point for Shmoe not being prepared.
• This gives us all quick feedback on what we can do better next time.

Only some people are fans of the cutting honesty of an L10 rating system, but POPs works! The idea is that we’re constantly enforcing a bias toward action, meaningful conversation, and building positive feedback loops.

Creating collaborative environments

I touched briefly on DEIB (diversity, equity, inclusion, and belonging) and how it affects collaboration, but other big things that affect it are confidence, competence, and adaptation.

Everyone has comfort zones, gets nervous or anxious, and requires time to build subject matter expertise. However, if we allow one person to lead constantly, others miss out. Likewise, if we play to the nerves of some folks and allow them to use their anxiety as a crutch, they may never grow. This is advice shared by someone who has been diagnosed with autism, anxiety disorders, panic disorders, and a slew of other fun things that I could easily use as a shield to keep me safe from scary situations when people would enable me to do so. I constantly warn folks not to confuse equity, inclusion, and belonging with excusing, enabling, and overcompensating.

All that being said, here are experiments I would try:

1. Get other folks to lead other rituals just like they do stand-up.
2. Ask people where they want to grow and what they want to be doing in 1-3 years, and give them opportunities to do so.
3. Ask people how to make collaborating more comfortable to achieve the outcomes you want. Include items like this in your team working agreements and definitions of done where applicable.
4. Ensure when people present demos, they speak to the why the thing was made (the more they know the why, the better they can contribute outside of the surface level).
5. Suggest collaborative sessions with the empowered product teams. Sometimes they just need a nudge.
6. Collaborate with HR to create DEIB pulse checks and improvements.
7. Create templates in collaborative tools to help speed people to collaboration
8. Teach people collaborative tools like Figma and Miro to enable them (for some teams I’ve been on, we have held regular Figma and Miro training or Q&As until folks were comfortable).

Communities of practice

The advice above goes double for DCOP (Design Communities Of Practice). What I have found helpful when trying to get involved in DCOP efforts is to give accountability. Take ownership yourself for a week or two of rituals and communications, but then ask someone else to take over the next week. The simple act of leading, participating, or building materials, causes folks to build more investment overall. It also exposes the team to more points of view, preventing them from growing too far in one person’s vision or direction.

Otherwise, my biggest DCOP tip to begin is to ensure you’re organizing around problems or outcomes and not outputs, derivatives, etc. There are very seldom times you can break that rule. Be careful with it.

Humanizing

How do we ensure hiring, onboarding, and professional development practices treat employees like humans first? Well, if you’ve been following along with me, there’s a lot of overlap. For example, making it a point to get to know people and spend time together socially goes a really long way.

One of the biggest problems I see managers and leaders need help with is putting or calling people into positions that they want them in rather than what the person is good at, wants to grow into, or is interested in. Sometimes this is okay to push people to grow, but oftentimes this can go drastically wrong, too. The real key is to get to know your people, actively listen and seek feedback. This starts with the 1-1 and helping create a growth plan for the person you will work on together. This doesn’t just apply to the manager-subordinate relationship, though. We often have 1-1s amongst colleagues with strong mentorship relationships in place, and many of the same things apply!

1:1s and growth planning

1:1s in the remote work scenario are a great way to get to know people socially. However, we can’t forget the importance of targeting at least a portion of that time toward meaningful feedback, action, and growth. Avoid project status updates and have more meaningful growth conversations.

Pointed question examples (not dissimilar to user interviews):

• What feedback do you have for me this week?
• What did you struggle with this week, or what’s bothering you? How are you navigating that, or do you need help? How could I have helped sooner?
• Anything you’re really enjoying? Want to do more of or improve at?
• If I weren’t your leader anymore, what do you think you’d suddenly struggle most with? (Make sure to preface this one with the statement that it is a growth question and that you aren’t going anywhere.)

Every third or fourth 1:1, I think it’s important to work on or check in on a team member’s growth plan. Where do they want to be longer-term? What are their non-project-related goals? What progress has been made? Specifically, how can I help them go further faster? Have I helped or hindered? Are they more interested in surface-level work, strategy, or leadership? Has that changed? Why?

Better 1:1s and targeted growth planning are always a great way, to me, to bring managers and leaders closer to their reports and mentors, helping them see people as human beings. It helps break down the barrier many people have between personal chat and business time.

Interviewing

Remember, people have lives outside of the process.

• Too many back-to-back meetings can be hard.
• Assignments and “tests” should not be spec work (work that company could actually use).
• Getting a candidate to do work as part of their interview should include compensation. This goes double when sourcing from marginalized communities.

Provide tools

• Enable folks to get good work done for you if you are going to ask them to do a presentation or test.
• Give access to presentation or Figma templates, even if they’re created specifically for the interview process.

Prioritize the “First Team” over the community of practice.

• Make sure the people who will be working with this person most get to know them and ask them questions.
• Talk about problems and outcomes over outputs and assets—this is a time for you to show the team's role.

Remove bias

• In group interview scenarios, do not let other people see opinions or ratings until they are all collected (yes, they will peek, yes, no matter how much you think you can trust them and think they can’t be biased).
• Ask everyone the same questions.
• Crackdown on leading questions.
• Let people know you want to build and support a diverse workforce. As such, ask them if they require any alternative approaches, allowances, clarification, tools, etc, as part of the process. People may be scared to divulge areas of diversity or adversity.

Onboarding

Just like with product work, make sure you’re not losing the why.

• When introducing people or asking them to seek out and introduce themselves, make sure that they know why you want them to meet those people. “He’s a back-end developer,” for example, is not enough information. What are the important whys that I would go to those people for?
• Make arduous or boring parts of onboarding more straightforward by articulating to people why it’s important.

Reinforce with meaningful connections.

Gear towards improvement and action.

Remove barriers to success.

• Make sure all of your team tools, templates, and knowledge-base resources are well organized, easily searchable, and accessible
• Can people find what they are looking for? If they are curious? If they are assigned/accountable for something?
• Is information siloed or overlapping amongst LOBs (Lines of Business) in meaningful ways?
• Can you reduce the clicks to access things?
• Can you reduce the time it takes to find something?
• Apply typical UX thinking and best practices to improve your tools, templates, knowledge base, and other resources!

In conclusion

I hope some of my experience and opinions help you in building stronger, more communicative, collaborative teams.

Further reading

1. Org Design for Design Orgs: Building and Managing In-House Design Teams by Peter Merholz (Author) and Kristin Skinner
2. 12 Qualities of Effective Design Teams (an excerpt from Org Design for Design Orgs)
3. Empowered by Marty Cagan
4. Making of a Manager by Julie Zhuo
5. Traction: Get a Grip on Your Business by Gino Wickman