Turf wars are an occasional side effect of employing talented people who care a lot about their work. Power struggles aren’t limited to boardroom intrigue though, as skirmishes are waged daily by individual contributors.
In digital product organizations, developers, designers, product managers, product owners, product marketing, and program management offer valuable contributions, but each role significantly overlaps with at least one of their peers. And while it often feels like there are ‘too many cooks in the kitchen’ on strategic topics, there are also gaps where important activities go unfulfilled.
Design Thinking can be the glue that bonds a fractured team. In this article, I detail how I have collaborated with designers using ‘Double Diamond’ Design Thinking as a framework. I have found that this approach delivers better solutions, builds commitment, breaks functional silos, exposes gaps, and makes work a happier place.
Product Teams Are Broken
My own experience with collaboration-challenged product teams isn’t unique. I know this because I’m in the process of fielding a global survey on digital product team roles. Despite it’s length, almost 400 people have volunteered 15 minutes of their lives to answer the survey, likely because they feel the daily pain caused by ambiguity in their own teams.
REQUEST: if you play any role in bringing digital products to life, please add your voice here before the survey closes on March 31st
Based on comments from survey respondents, it is not unusual for UX designers to struggle to understand what service designers do, product marketing managers feel increasingly sidelined, product owners aren’t sure if they’re actually product managers, and each of these roles tends to step all over each other when it comes to strategic product decisions.
Here are just a few examples of the comments I’m seeing from the survey responses:
“I have experienced a few times that my role as a service designer is too overlapping with content designers, UX designers and sometimes user researchers.”
“I have just started out in this role and feel these questions are valid since the line of ownership is blurred”
“Even though my current job title is Product Owner, I feel like it should be called Product Manager as a product owner per se in scrum is the person who takes care of the backlog only. It might be interesting to see from this research if those two are somewhat the same.”
“My main issue with the roles is that there’s currently slightly too much of an overlap with UX design and UI design (UI is part of UX anyway, so frustrating that they’re separate roles to begin with).”
“Our designer wants to own business decisions on the product because he does the end user research but he doesn’t talk to the business decision makers and doesn’t understand the cost side of our business.”
“I’ve also been thinking about this topic quite a bit lately! It does appear that the role of design within organisations is changing, and there is some ambiguity and confusion about what that role could and should be.”
“I agree that product marketing managers are very under-represented and still I find myself explaining what I do because many don’t fully understand the role.”
In Search of a Framework
In my own career in product management, as my teammates as I sought to reach a détente, we searched for framework that could outline who should do what. From my vantage point, the area of greatest debate was in product vision, scope and prioritization; topics where increasingly strategic designers and I often had spirited discussions.
Stepping in to mediate, our leadership suggested that product could own the ‘what’ and design and developers own their respective ‘how’. At the time I was satisfied with that because it ‘kept design out of the product scope discussion’. In hindsight though, I think that was the wrong approach because it didn’t leverage what talented designers and strategically minded developers could bring to the table. I’ve since come to believe that the drive for people in small product teams to exclusively ‘own’ things is part of the problem.
Democratizing Design Thinking
It turns out that a solution was always at hand. While our product team wrestled over responsibilities, designers had been applying design thinking principles to their own work all along. Unfortunately, contrary to the philosophy of the Stanford d.School, the institution credited with popularizing the concept, Design Thinking was never seen as relevant to the broader team.
“At the d.school, we believe everyone has the potential to become an innovator. No matter what field or industry you’re in . . .”
Amidst the hype over the concept today, it may go without saying that design thinking isn’t just for designers, but it’s still important to emphasize this point here because the first step in leveraging design thinking to address team issues is to democratize it for use by the entire team.
Overcoming Limitations and Opposition
I should acknowledge that there remains debate about exactly what Design Thinking ‘is’. At a minimum it’s a philosophy that advocates approaching problems with an open mind. It’s often taught as having five mindsets of re-framing, radical collaboration, curiosity, bias toward action and mindfulness of process. But as soon as someone calls it a process or methodology, that’s when the debate tends to rage.
Opponents argue that it’s too high-level to serve as a method and can’t be applied as-is. The mindset aspect of Design Thinking does go a long way to creating a culture of openness and trust in the team, but with new teams that haven’t developed a culture, it’s hard to escape people’s desire to know what to do when. Design Thinking doesn’t specify that in detail —especially not as it should be exercised by other roles.
For this reason I have found it necessary to elaborate the concept further with my teams to make it actionable, blending the various activities that we need get done into a design thinking framework.
A Double Diamond Crash Course
Design thinking comes in many shapes and sizes. Literally. The conventional depiction offered by the Stanford d.School is a hexagonal expression containing five phases, while an alternative version is the Double Diamond, created by the British Design Council.
I like the double diamond because it captures the divergent and convergent thinking phases of the problem solving process. This emphasis on the different mindsets is helpful because for non-design team members, the open ended nature of the ‘discover’ and ‘develop’ phases can be the most uncomfortable.
In conventional team processes, it’s during this very first phase of problem solving that the different team roles are most at odds. Here, designers are eager to pursue many diverse directions, while developers, product and leadership are aching to find a focus as quickly as possible. By expressly stating that the entire team is currently in a ‘divergent phase’ you can diffuse this tension, reminding the team:
‘hey everybody, right now we’re exploring a broad universe of solutions, so please resist any temptation to add constraints or narrow our focus for the time being; we’ll get to that in a little while.’
Despite its name and iconic diagram featuring exactly two diamonds and four phases, the double diamond is not necessarily a four-step sequential progression from beginning to end. The concept was developed specifically for an industrial design context where it’s difficult to revise a finished manufactured product. However, applying the double diamond to an agile software context means repeating iterative and parallel phases that vary in length as appropriate for the complexity of the problem at hand.
From Mindset to Action
While the double diamond is helpful in setting the right mindset, it’s necessary to ‘flesh out’ the framework with actual activities in order to for it to serve as an actionable approach.
Let me give you an example. In a recent collaboration, a UX designer and I outlined how we would work together to identify product opportunities within an B2B IoT space and then elaborate and execute a minimum viable product. He liked my use of mock press releases to express the vision so we agreed I’d take the lead on that during the ‘define phase’ and he’d pitch in a bit. Meanwhile he had the entire user interview operation (part of ‘discover’) on speed-dial. We both agreed that we’d share responsibilities on the product roadmap.
This collaboration turned out to be both successful and fun because we were explicit about when we were diverging or converging, and we also allowed significant sharing of the most strategy-influencing activities.
The manner in which we collaborated on that particular product was unique to the phase and the current problem, and may not be exactly how I work with designers in the future. The implication here is that a new collaborative design thinking approach needs to be elaborated with the team for each unique problem at hand.
That can be difficult but it gets easier with practice. To make it even easier, I have been developing an inventory of the ‘stuff product teams do’ as I have worked with different teams to develop products. The result is a list of nearly 100 activities which I can draw from when I discuss collaboration with my teams.
BONUS: Check out my Product Team Activity Inventory segmented by double diamond phases which you can use to turn a design thinking mindset into action
No team will repeat the same activities for each problem, nor is it likely that a team would perform all these activities in the context of one product, but having a long list of activities serve as a basis for discussion with the team about what needs to be done helps ensure key activities aren’t overlooked.
Apply Collaborative Design Thinking in Six Steps
Below are the steps that I go through when applying cross-functional design thinking to overcome team silos:
- Teach Design Thinking: The entire team needs to understand the basic tenets of the concept. Expose the team to an objective source; an external expert that is not in the team to coach or perhaps have the team read a book like Change by Design by IDEO CEO Tim Brown.
- Seed a Sharing Culture: Core to this concept is the idea that everyone is invited to contribute to key activities. Nobody should be ‘the decider’ on any topic by default. It’s difficult to prescribe how to build such a culture, but this is the type of thing that could be institutionalized in a ‘team norms’ discussion as a start.
- Develop your Activity Inventory: In a team-wide collaborative workshop, develop your own inventory of the convergent and divergent thinking activities that ‘could’ be performed in building your product. A goal here is to have all functions understand the main activities performed by their peers. You could work backwards from my list of Product Team Activities.
- Discuss Your Approach: for each new product, feature or problem, select the activities (from your inventory in #3) that the team believes will be necessary and associate one or more team members with them. Depending on the scale of the problem, this can be the type of thing discussed in a kickoff meeting, in the cadence of a sprint planning, or even in a short meeting. For large scale topics, also make a point to discuss activities that you won’t be doing.
- Announce Phase Transitions: When you have completed a divergent phase that has resulted in multiple options, review all those options with the team and decide together whether you’re ready to move on to the next phase. Key here is announcing to the team that the mindset is changing from divergent to convergent from that moment on.
- Maintain your Inventory: In a form of a retrospective, look back at the activities that were useful in tackling your last problem as well as things you might have done better. Questions such as ‘Did it help to complete a Business Model Canvas?’ or ‘Should we have drawn a journey map?’ will help the team consider how to work better next time.
What Collaborative Design Thinking Does for You
Despite the limitations of design thinking and the need to adjust the activities in the double diamond it for each new context, establishing a team culture and problem solving approach as I’ve described does a couple of amazing things for product teams:
- Makes work a happier place: builds cohesion by removing adversarial role playing
- Delivers better solutions by leveraging talent and ideas from more people
- Builds commitment by inviting each team member to invest in key decisions
- Breaks functional silos by exposing the team to their peers’ activities
- Reduces gaps by using an existing inventory of activities, requiring teams to consciously ‘opt out’ versus ‘overlook’
I hope this helps bring peace to your product teams. And if you like the idea of collaborative design thinking, I’d love your claps!