We recently published a blog post about What a Developer does on 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 in its “traditional” form.
However, during a product *discovery* sprint, or an 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. 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 where we turned a discussion into a critical path that outlined an overall process our problem space was in.
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)
- 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!
