How We Integrate Design into Mission Teams

Cansu Tecimer, product design manager, tells us what she learned from integrating designers into mission teams that had previously never worked closely with a designer on a regular basis.  

{{Divider}}

But first, what’s a mission team? If you’re not familiar, working in mission-based teams, also known as squads or cross-functional teams, is a type of organizational design that enables fast-growing companies to remain agile and innovative.

A mission team is a small group consisting of members from different departments such as designers, engineers, UX copywriters, and product managers. Rather than working in departmental silos, this organizational design enables people to work within their mission team(s) that focus on one part of the product, such as mobile payments, partner tech, or trip discovery.

All of our product designers are embedded within missions. We wanted our organizational model to be optimized so designers have a significant role in defining what we build. We encourage them to understand and have relationships with other disciplines within the product areas we work in.

Our motto, Don’t make design a black box, is meant to encourage all designers to give visibility into their thinking and make others a part of it.

Building design within teams

When I first joined as a product design manager, one of my responsibilities was to introduce design as a discipline within product optimization and partnerships — two teams that had previously never worked with embedded designers.

One of these teams was newly-formed, and the other was comprised only of engineers. While hiring embedded designers for these teams, I also needed to work as an interim-designer because the teams needed to deliver real results and hiring the right designer takes time.

The setup was not ideal. I was working with new teams that:

• never previously worked closely with embedded designers before
• wanted to quickly deliver outcomes that drive business results
• didn’t have time to do discovery research upfront, unlike the other product teams within the organization

However, when is everything ideal in start-ups anyway? When do all teams have the time, space, and resources to do everything by the book? Probably rarely, if ever.

The learnings I acquired while setting up designers within mission teams can benefit anyone getting accustomed to working in squads or cross-functional teams for the first time. I want to preface the following advice by saying none of these learnings can work without the support of partners in product and engineering, who also believe great products solve human problems and can only be built by teams that have shared ownership.

Here are four things that helped our mission teams build ownership and alignment in the products we built:

Understand users’ context quickly and continuously

At the time, the mission teams I was in didn’t have time to do an upfront user research, but fortunately, the product space was not too ambiguous. We also had many tools we could use to learn about our users’ needs quickly, before starting delivery.

One of those tools is Hotjar. The software enables us to learn about our users by creating heatmaps of their behavior, capturing recordings of people using our product, and launching surveys.

We used Hotjar to see how people interacted with our product and ask them why they were leaving upon exit intent. This one-to-two week effort, along with digging through past research into the motivations of our users, allowed us to gain context pretty quickly and prevented us from going into any product ideas blind to the users’ needs.

We continuously launch surveys at critical parts of our product and look into how people interact with it at various points to make sure we have a baseline understanding of our users at all times.

Share and give access to user feedback within the team

The best way to give people access to user feedback is to invite them to the research process. For us, that was not possible due to not having time to do a lot of discovery research. So we did the next best thing. We gathered all the findings into themes and shared the stories with the team through various ideation sessions.

Pro-tip: Bring snacks and ensure people understand how their ideas turn into actual delivery in the end.

To ensure user feedback was always accessible, the designer within one of our product teams started collecting all user feedback in one place. It was a simple spreadsheet with rows of feedback from customer support, some past interviews, and surveys, but it was a start in giving everyone access to past research.

Create the time and space to generate solutions together

Collective workshops like ideation sessions, brainstorming, and sketch sessions, serve two essential purposes within product teams. First, they enable everyone to have alignment and ownership of the product they are building. Secondly, they ensure a better result simply because more minds contributed to solving the ambiguous problems we have.

We needed first to build this feedback culture in our teams to have much stronger solutions as designers.

We did a few of these types of sessions within the teams I was in, and I’ve always found everyone excited to be part of them. They take about an hour or two and are a great creative break for the team.

Pro-tip: Bring snacks and ensure people understand how their ideas turn into actual delivery in the end. One thing we did to make sure of that, was to create a document with an idea backlog and their status. We also used this to give people a platform to continuously submit more ideas, which was not that successful. Doing workshops for these once in a while increases engagement for sure.

Make feedback and learning a core part of team culture

When I first started working with teams that were primarily comprised of engineers, one thing I noticed was that engineers didn’t give much feedback on designs. In some cases, they didn’t feel comfortable with it. In other cases, they felt detached from the product in general. And in all cases, they were never asked.

However, we needed first to build this feedback culture in our teams to have much stronger solutions as designers, and secondly, to speed up the development process by creating alignment up-front. I’ve worked with some great designers who created this culture of visibility into their work much better than I ever could. They simply did this by sharing their work often and actively asking for feedback.

Some tactical ways that worked for us were creating UX slack channels for the mission teams where the designer would publish their work in progress and ask for feedback from others. This allowed people to give asynchronous feedback and get visibility into unfinished work.

We also created space in the weekly team meeting for design reviews and to review how past experiments were doing. Doing this week after week allowed the team to continuously be critical about the things we were going to build and the things we had built.

Looking back

Doing these four things over time helped us tremendously in becoming a team that felt shared ownership of the product we were building:

• Finding ways to understand users’ context quickly and continuously
• Sharing and giving access to user feedback within the team
• Creating space to generate solutions together
• Making feedback and learning a core part of the team culture

There’s a great quote from Slack’s CEO, Stewart Butterfield, “We get zero points for just getting a feature out the door if it is not actually contributing to making the experience better for users, or helping them to understand Slack, or helping us understand them.”

To ensure this mantra is lived every day in product teams, it is crucial to find ways to continuously learn about our users, help everyone in the organization have visibility into the problems we solve, and ownership on the way we solve them.

‍