I first ran a product sprint at Sparkfund, where our small but growing startup team faced a pivotal moment when we needed to find our next great idea — fast. I ended up leading and sponsoring many more sprints as our business and product team grew, and even had the good fortune of bringing in product discovery coach Jim Morris to lead us.
For many of these, the sprint team was co-located in a big conference room, surrounded by sticky notes and colorful voting dots. But for some sprints, team members were divided between the office and remote locations, so we developed new templates and practices to bring the power of design thinking to the screen.
Now that I'm at Kevel — a remote-first company — and we're faced with a global pandemic, my discovery is now all remote, all the time.
Here's why it's important to keep doing product discovery while we're remote:
Most obviously: talking to customers is core to product work! Testing continuously with customers leads to the innovation and success we need to advance our business goals. Product pro Teresa Torres says we should be talking to at least two customers per week.
According to research by Humanyze, when the pandemic started, professionals spent much more time speaking with our five closest colleagues at work. At the same time, contact with our "weak ties," our colleagues who are more distant, dropped by 30%. This could be a disaster for innovation.
Bringing together a cross-functional group for a product sprint can help alleviate some of this loss by creating a venue for innovation that includes perspectives from across the business.
These resources focus on the Google Ventures-style week-long discovery sprint made famous in Jake Knapp’s Sprint.
But a full structured week is not the only type of sprint-like activity that will help your product discovery efforts. You could pick and choose elements from the sprint as needed, focusing on just a few of the pieces you need for your project. Or, you could institute continuous customer discovery, using design thinking techniques along the way.
Do what works best for your team! The resources I provide here are for the classic week-long sprint. Feel free to adapt them to your needs.
That last thing you want is to be in the middle of a productive sprint session, when suddenly you realize that you need to get permission to buy the next usage tier so that Bob can use Lucidchart.
In my opinion, you'll need the following types of software:
Digital meeting with video and screen share
Obviously. Use whatever your team is most comfortable with here. At this point, we're probably all familiar with the big ones:
This will be important too. Again, use what your team is familiar with. I prefer something with simultaneous editing, like Google Docs, but you can use a non-collaborative tool if you do a lot of screen-sharing. Options include:
Virtual whiteboard / flow charts
Essential for user maps, sticky notes, and dot voting. Anything that allows you to draw shapes and move them around is going to work. In my opinion, it's best to also have collaborative editing and infinite paper.
Prototype and design
Again, use what your team (and most importantly, your designer) is most comfortable with.
But, as the GV team caveats, choose a tool that you can move fast with — not the tools you'd use to build a real product.
The classic week-long GV sprint looks something like this on a calendar:
It's a lot of time. The GV team says a week-long sprint is best when you're facing a big challenge:
If you're going for a week-long sprint, it should be to tackle a problem that deserves those chunks of time from your team. If you feel like you are in a situation that requires this much time and you need to get buy-in, the GV team has recommendations on their website for getting alignment.
I recommend blocking the time on everybody’s calendars, with clear events like in the snapshot above, showing when there will be work and when there will be breaks.
Ideally, you want to avoid people ducking in and out to go to other meetings. It distracts from the work at hand.
That said, it's also important to be flexible. It's a wild time, and if somebody’s kid pops in the frame or your colleague needs to step away to deal with the AC repair person, that’s OK. We’re all going to do much better work and feel more psychological safety if we make space for the challenges our colleagues run into.
Before you start, think about the office supplies you'll need your teammates to have on hand.
I once led a sprint with a remote engineer who couldn't find a single piece of blank paper in their house. Don't let the absence of office supplies in your colleagues' homes get in the way.
I suggest thinking ahead to understand which supplies your team will need and mailing them in advance. It will feel special for the people participating in your sprint, and will show that the company is willing to invest some dollars in this process just as they’re willing to invest their time.
Here's my shopping list:
Before the first session, create templates for all the online artifacts you're going to need.
Here's my mega-template. Feel free to make a copy and use it for your sprint, or change it to suit your needs!
This is where you'll write your sprint goals, questions, and link all the artifacts you co-create. You can even keep user testing notes there. After the sprint, you can come back to this document to see what you did and why.
Everything is ready to go, and you're diving into your sprint agenda. Because you’ll work over video, it’s especially important to keep an eye out for social dynamics that might be easier to spot work through when you are in person.
I find that it’s pretty straightforward to port your user map with stickies and whiteboard lines over to a digital white boarding tool like Lucidchart or a slide deck tool.
I definitely recommend that the person updating the map share their screen in real time. Ask a lot of questions to ensure that you capture the wisdom of the group as you’re editing. “Is this right?” “Does this go here?”
I made a Lucidchart template that you can copy and edit yourself.
It’s a little more painful to transition to digital here. We lose the benefit of all standing in front of the same wall and physically moving and clustering sticky notes.
But it can be done! In remote sprints, I like to create HMW notes in a tool like Lucidchart. In my template, you'll find stacks of notes with a workspace for each person:
Folks can create as many notes as they need, just by copying and pasting the shape. No trees harmed!
When it’s time to organize the notes, everybody can copy their notes into a different workspace (in Lucidchart I use a new tab) and cluster together cards that thematically relate.
For dot voting, I use little and big circles instead of real stickers. Make as many copies as you need!
This is one place where it’s nice to have a tool that allows real-time collaboration, like Lucidchart or Google Slides.
Lightning demos might be the hardest step to port over to digital because they involve so much drawing. My recommendation is to pick a person on the team who can draw the lightning demo images in real time. The designer is often a great fit for this. The drawer can upload images to the digital white boarding tool as they go:
If you can’t have a dedicated drawer, you can take screenshots of the tools people demo and add them to the digital board. You can find this example in my template:
I like this method a little less because it lets us off the hook from boiling down the things we like into a simple drawing. Still, better than nothing!
When it comes to sketches, I highly suggest that folks work on their own pieces of paper and sticky notes. Paper is powerful here because it’s a lot more seamless to translate our ideas freehand on paper than it is to figure out how to represent whatever shape we want in an online design tool. You can do all steps of the sketch process (notes, crazy 8’s, and the sketch) on paper.
Then, when it’s time to do an “art museum” — where the team reviews, discusses, and critiques the sketches — everybody can submit a photo to be laid out side-by-side on your digital whiteboard.
Here’s another place where an “infinite paper” tool like Lucidchart succeeds.
Maybe the best part of a digital sprint: you can do dot voting with little circles. For some reason, I find this immensely satisfying.
(Did you catch the flag that a colleague constructed with a bunch our voting dots on top of striped wasi tape?)
Your storyboard — the big-picture, comic book-style layout of your prototype — can be a combination of paper and digital. Grab screenshots of parts of the solution sketches that will represent different steps, sketch out new sticky notes to upload them, or make a quick digital sketch.
You can use this example as a starting point in my template.
Once you’ve created your prototype, it’s time to user test!
When following the GV process, recruitment happens earlier in the week. I think it's important to be super explicit in written communication with testers about logistical stuff like instructions for joining and the technology you'll use. If they need to be on a specific device like a phone, tablet, or desktop, make sure that’s clear. Specify what meeting platform you’ll use, and send the URL as soon as you can. I even like to send a link to download the Zoom client.
Make a clear script and practice it beforehand. I have a basic script and note-taking template; feel free to riff on it!
Be prepared to explain technical things, since not everyone is familiar with your tools.
Take notes as you go and grid results from the tests so that you can easily compare results across interviewees.
I hope this has given you a few ideas to test as you incorporate more discovery into your remote ad product work.
MaryLauran leads product for the UI and management API at Kevel, which enables dev teams to build custom ad servers in just weeks. She is a product leader based in Washington, DC and has expertise in IoT energy monitoring in addition to ad server management.