---
title: What does a designer do during a product discovery sprint?
teaser: How to help your team discover the right product using your design chops.
tags: product design sprint,product strategy,validation,customer,successful products,map,startup
author: Vendela Colavecchio
published_on: 2023-11-28
---

We recently published a blog post about [What a Developer does on a Product Discovery Sprint]([https://thoughtbot.com/blog/what-does-a-developer-do-during-a-product-discovery-sprint](https://thoughtbot.com/blog/what-does-a-developer-do-during-a-product-discovery-sprint)) and I thought it would be helpful to highlight some of the things that a designer does during these as well.

Dave opens the post with a list of tasks that for a developer might not feel like they align with their typical day to day skillset:

* opportunity trees
* assumption boards
* market segmentation matrices
* pitch decks
* critical paths
* customer interviews

I don’t know what a designer’s role looks like at your company, but for us at thoughtbot, at least some of these things feel within the realm of a designer’s job description: assumption boards, critical paths, and customer interviews are all exercises that we’re accustomed to running during a [product design sprint]([https://design.thoughtbot.com/sprint-guide/](https://design.thoughtbot.com/sprint-guide/)) in its “traditional” form.

However, during a product \*discovery\* sprint, or an [incubator]([https://thoughtbot.com/incubator](https://thoughtbot.com/incubator)) session, these all take on a slightly different flavor. To learn more about how to run these exercises in the context of early product validation, check out our updated [Playbook]([https://thoughtbot.com/playbook#validation](https://thoughtbot.com/playbook#validation)). Facilitating the discussions and exercises is still something designers can do for these projects. An especially helpful angle that designers can contribute during these is to figure out ways to visualize the discussion to become a helpful artifact for the team. Here’s an example in [FigJam]([https://www.figma.com/blog/introducing-figjam/](https://www.figma.com/blog/introducing-figjam/)) where we turned a discussion into a critical path that outlined an overall process our problem space was in.

![Diagram of post-it notes outlining a customers journey using a financial account](https://lh4.googleusercontent.com/WJIMw1iEKD8v3LwqNx07mSWgtxfOKuJtGbWRQKkAHRkZfSSiEDG1i1_MZO_fXA3IEOlConomagaVN1K91p28LHMzbrCtU7TWL6UEhm49UoJyW0iO10l3A_a2jEcKIZAbVtSbx1HUNvXGCzS1rmeuPKk)

Another difference is that these early validation sessions don’t always result in the need for a robust prototype and lots of wireframing and visual design the way other projects do (although sometimes they still will!). But there are other ways in which design is an important asset for testing out early ideas:

* Landing pages to collect sign ups
* Visual assets for running ad campaigns to collect data about interest
* Pitch deck design
* …and aforementioned prototype if relevant

Aside from these more visual and traditional aspects of your contributions, there are lots of things that Dave mentioned that will apply to how you can help as a designer too:

* talk to customers
* share your advice and ideas based on all your previous experience working on products. You probably know more than you think you do.
* pair with your team’s developer
* use your organizing skills to organize things (the Trello board, the interview notes, the [list of assumptions](https://design.thoughtbot.com/sprint-guide/exercises/assumptions-board/))
* share your unique designer perspective with your team
* help with WHATEVER needs to be done. You don’t need design skills for this. You need teamwork skills

As a designer you’re used to thinking from a user’s perspective. This is the hat you want to be wearing while tackling all this!