Inside Kumu: the Product Design Team's Process

A look at the meetings, rituals, and exercises our product design team relies on to build trust and stay efficient

There are a few things every design team needs to be effective. Two of the most essential are trust and communication.

This is a deeper dive into the Kumu Product Design team’s day-to-day, meeting cadences, rituals, and anything else that helped build that trust within the design team and has helped us stay connected and efficient.

But first, some quick caveats:

That said, this is a living document. The design team continues to iterate on this process as we grow in skill and in number. So please don’t think this is the “right way” to do things. This is just what’s working for us. We’re just trying to be transparent about how we work for anyone who’s curious.

Daily Rituals

"Stand-up" or Status Updates

Who: Product designers
What: Each designer sends a list of things they worked on yesterday and are working on today
When: Every Tuesday to Friday, 9:30 am
Why: To be aware of what others are working on and if they are blocked and need help

This is the only daily ritual we have. We used to have this as a 15-min call to hear updates from everyone but, as we’ve grown in number, this took up too much time and was inefficient. So far, sending updates via Slack has helped. This ritual allows everyone to keep tabs on what everyone is doing or has done over the week (or past few weeks).

Weekly Rituals

Warm-Up

Who: Product designers
What: Kick off the week together
When: Every Monday, 1:00–2:00 pm
Why: To ease into the work week with something light and fun

Warm-Up


Every Monday, we kick off the week together. The hour-long meeting consists of four parts:

Weekend update (15 minutes): We each go around the room and share a quick highlight or two of what we did over the weekend (if we’re using Google Meet, one person starts and then nominates the next person). It helps us start the week on a positive note and allows us to ease into the workweek.

Tasks and Blockers (15 minutes): We look at our kanban board and discuss the statuses/progress of our tasks. This also helps us see if any designer has a blocker or is overloaded and needs help in the coming week.

Critique/meeting schedule (15 minutes): We plan our critiques and team meetings in a Notion doc ahead of time so everyone knows what to expect. We go around the room again (one person starts and then nominates the next person) and each person decides if they have a project they’d like critiqued during the week.

Announcements (15 minutes): We share org-wide or company-wide announcements and updates specific to the design team. This includes topics like branding alignments with the brand team, updates to the design system, new company policies, hiring plans, and designer candidate progress.

Design Critique

Who: Product designers, and any guests the presenter chooses to invite (e.g., their PM, tech lead, researcher)
What: Run through a list of designs submitted for Critique on Tuesday
When: Every Wednesday from 10:30–12:00 pm
Why: To move projects along, help anyone who gets stuck, and share context with the team

Design critiques at Kumu are not product reviews. Critiques are not the forum to suggest new ideas, make major product decisions, or determine product roadmaps. It is a safe space for feedback independent from roadmap decision-making. Our design critiques focus on unblocking problems and generating ideas, elevating the quality of the designs, encouraging consistency in the product, and sharing context.

We’ve learned that designers are not always able to think quickly on their feet since some problems are more complex and involved than others. We saw that sharing videos a day before allows asynchronous consumption and additional thinking time and helps better involve everyone, especially those who may need more time to think before giving feedback.

So ideally, a day before the design critique, designers asking for feedback will share a short video walkthrough of their designs. These video walkthroughs (typically, 5-10 minutes in length) discuss the context, the scope, and the different explorations of the design solution. This is done with the objective that the other designers are given time to watch the videos before the design critique, digest their contents, and provide more thoughtful feedback.

But, some circumstances require different approaches. So, if designers are unable to send video walkthroughs early, we adjust. It’s not a hard rule.

Cooldown

Who: The product design team
What: Wrap up the week
When: Every Friday 4:00–5:00 pm
Why: To hang out and relax

Cooldowns, Spotify playlists, hangout, games


In remote settings where water-cooler conversations are hard to come by, time to hang out needs to be carved out actively. Cooldowns are our time to bond and have fun as a team—both important to building trust in each other.

We start with Highlights. We take a couple of minutes heads down to reflect on the week prior, looking back at our calendars to remind us how we spent our time. We compile highlights in a Notion doc to celebrate the little victories.

We would usually do one of three things here:

We end with Kudos or shout-outs as a way to recognize people who’ve helped us during the week and to express that we appreciated their help. This might sound weird and superfluous, but it’s actually an important part of our rituals. It give us a space to recognize when someone does an excellent job and it also helps us acknowledge under-the-radar effort. Because, sometimes, it really is the small things that help build trust between teammates:

Monthly and Quarterly Rituals

Retrospectives

Who: The product design team
What: An opportunity to review our current processes and team-wide responsibilities
When: Twice a month, every other Thursday
Why: To create a space for feedback on our design processes or our team

Retrospective board on FigJam


This is one of our newest rituals. We tried to have this once a month before but we somehow always forgot about it. Now it’s a scheduled meeting and we’re seeing if we need to have it this frequently.

During retros, we talk about What Went Well, What Could Have Gone Better, Shout Outs, and Ideas on how we can continue improving our small organization. It’s a great way to hear what other people are having trouble with and to hear others share ideas on how to solve these problems.

Offsites

Who: The product design team (including design interns)

What: A full day of activities outside the office

When: Quarterly

Why: To learn, bond, and (maybe) brainstorm

Eating out at NIU by Vikings and going to Boracay


We have two types of teambuilding offsites: one with the Design team and one with the product teams.

Again—because it bears repeating—our process isn’t perfect and we continue to iterate on it. We still struggle with a lot of things like watching all the videos that are shared asynchronously prior to design critiques or communicating our progress and getting feedback from important stakeholders, especially leadership. What has been key for us is designers being vocal about what’s not working and being open to changes and experimentation. We are all aligned in wanting processes that enable us to do our best work while still allowing us to have fun.

Given that, I thought it’d be useful to put this out there just in case it might be helpful for other teams. With that in mind, we’d love to hear what YOUR design team does too! We’d love to learn what works for you and what hasn’t!