How to kickstart product discovery
A design sprint story
An old co-worker and friend called me and told me about a problem their team had. They had been working on a problem for almost a year and a half and were still stuck on it.
In the past, the company had been completely engineering-led. All the sales, all the customer communication, all the discovery, and all the solutioning done never had a designer, PM, PO, researcher or any other individual involved.
The result?
While the organization had a superpower for delivering what customers wanted with high quality and on time, the product had turned into 20+ unique products within the same market. Different engineers would work with customers directly and build the product based on what the customers told them. Since there was no bigger picture strategy or team member that brought all of the research together, every customer was a different implementation and the problem grew exponentially as more customers came on.
Eventually, the organization transformed into a service company instead of a product company without even realizing it. The customers had great relationships with the engineers and would ask for new features over time, different verbiage, changes to colors, etc. The engineers would do the custom work for a price and that product configuration would change more and more from the others. Even though the customers had 90% of the exact same needs and were in the same market, the product handled those needs in very different ways. In short, they had built what the customers had told them to build, not what they should have built.
My old co-worker who called me was tasked by the new CEO to transform the company and team to be a product company instead of a service company. The strategy was to find the commonalities across the different customers and build one product that satisfied the needs of the vast majority of them. This product could then be configured easily, and distributed at a much higher volume across this market and eventually into adjacent ones. After a year and a half in, they had made some big strides, but couldn’t seem to nail the new product.
So what had they done well before I came in and why hadn’t it worked?
Made changes to the team
Engineers who completely disagreed with the new strategy and vision for the company had to be let go and replaced. It’s unfortunate, but can be necessary to make changes like this for such a significant shift in company strategy.
Hired product team members
Another step in the right direction, a UX/UI designer joined the team as well as a product owner (while I'm a much bigger fan of the Jr. Product Manager role compared to a product owner role, they were largely the same in this case).
Nine months of discovery
Most of the time was spent talking with all of the different customers and internal team members to understand the existing product, use cases, market, and overall problem space.
While it seemed incredible to me that the organization had made drastic changes to its team and strategy, I was in shock to hear that they still had not delivered what they set out to after so long. After hearing that the team had done 9 months of discovery, I asked a few more questions and came to two major conclusions that had hurt the team.
So what went wrong?
Not enough solution discovery
Product discovery is an art and science and takes years to get good at. One of the things that a lot of young product people don’t understand is that discovery is only as good as the solution you produce. If you spend too much time in the problem space and “thought-land” instead of building and testing big ideas with real customers, then you’re going to feel like you’re doing good work, but nothing major will materialize.
A side note: This is a common observation that I have and a feeling that I share when I’m “in the weeds”(looking at the details) on a project. While it can feel like you’re making progress day-to-day, you start missing the big picture and forget to find the fastest way to reach your outcome. One of the most important things about being a great Product Manager is being able to work in the executional details, and then come up for air and look at the big picture to reevaluate the situation.
A young product team
The team had only just formed and the team members were largely inexperienced in real product work. There was no establishment of Sr. Product Managers, no Lead UX designer, and no standard for product development to help them through this.
Great. This was actually a great problem to have. I was not up against a huge culture shift or well-established team members who would fight me all the way. I had a young, open-minded team who was very frustrated with their progress, and wanted to do better, but didn’t know how to fix it. We just needed a way to get moving quickly on a tough problem.
My friend reached out to me because he had seen me run design sprints in the past and participated in a few of them. He knew how powerful they could be and had run a couple with this new team already, but still was unable to make progress on the problem.
If you’re unfamiliar with the design sprint, it is a set of collaborative sessions that helps a team to align on a problem, iterate on solutions to that problem, and build a working prototype to test the solution all within 1 week. Here are some resources for you to check out if you want to learn more: The Design Sprint is still king, Sprint
I told my friend that I needed to interview the individual team members before we could do anything and set off to learn more.
A side note: If you ever want to run a collaborative session for a team you don’t know, it’s almost a non-starter if you don’t get to interview the team first. It’s okay if you’re doing a large general session, but if you really want to help a product team, you have to understand their motivations, skill level, experience, and how they view the current problem and team. If you only ever work with the person at the top (usually the one who hires you), then you’ll be missing most of the important stuff.
Interviewing the individual team members always blows me away with surprises and this was no different. Here are a few of my favorite takeaways from the conversations:
- Engineers were not involved in discovery or solution discovery
- No one felt like their ideas mattered because they would just build whatever their boss wanted at the end of the day
- They had prioritized the wrong customer and built another custom solution for them instead of a new solution
- There were over 20 unique customers
- There was no process for how to do discovery
- Team members saw the product and strategy differently than their boss did
Just like when interviewing customers, when I heard the same couple of problems across different team members I knew I could answer why the team had not made more progress and try to find a way to help them.
The biggest problem that stood out was the misalignment of the actual product goal. It stemmed from a lack of understanding around the product strategy, and a frustration with the initiatives started that contradicted the strategy.
The second problem that stood out was that even though my co-worker had told me that they had been doing discovery for so long on this problem, the other team members didn’t see it that way, and understood the customers differently.
These were key insights that I would make sure to address right away during the sprint. With the team interviewed and my findings solidified, it was finally time to start helping the team.
A side note: Interviewing individual team members works because you’re an outsider, and you don’t have any political motivation within the organization. There’s a strangely large amount of trust that occurs right away, and it’s important not to betray that trust. Do not communicate your interview findings to leadership or their boss. Not even the big takeaways if you can help it, but not the raw notes. Betraying the trust of the team in this way will ensure your failure in trying to help them improve as a team.
The Design Sprint
I’m getting close to having facilitated about 50 design sprints, so I’m probably a bit biased, but the decision to run a sprint with this team instead of taking a different path was pretty easy. Below are some common issues that you can likely fix by running a design sprint.
- Project Kick-offs
- Testing a new big risky idea
- When your team has been stuck on the same problem for a while
- When you want to introduce your team to design thinking principles
- When you want to kickstart your team to do rapid prototyping
Since it was the first time I was working with this team to help them with creating a big new product that they had been working on for over a year and they had struggled to create and test the new version of the product quickly, they checked all 5 of these common needs!
I aligned on the plan with my friend, set the date, and got to work planning the sprint.
Flash forward to the date that the sprint happens.
Side note: Even though I’ve run a bunch of design sprints and other collaborative sessions with the team, I still get extremely nervous about upcoming sessions. I often can’t sleep the night before and have occasionally vomited from the anxiety. I say this because I want you to know it’s pretty normal to feel this way before a big session and to keep a few things in mind to calm you down. It’s just work and really isn’t that important in the grand scheme of things. The team coming in does not have the same expectations you do. They’re probably happy to think they get a day off from their normal work. You’re going to survive the day. Even when something goes wrong during the sprint, and something always does, you’ll find a way to get around it….because you have to solve it to leave and get dinner.
Monday
The first day of any sprint with a new team is always the hardest. You don’t have an established relationship with team, they are usually unfamiliar with how a good collaborative session should work, and there’s always a ton of misalignment in the room.
So start the day strong, and start the day simple. Some simple things will always make the sprint more effective:
- Show up with healthy snacks and drinks for the team
- Get there early and set the room up
- Have music playing while the team starts to come in
- Skip the introductions, but don’t skip the warm up
- SET AND GET EXPECTATIONS
Setting and getting expectations is something that is so simple, but is so often missed. Simply have the team write down on sticky notes what they’re expecting to get out of the sprint, and then present it to the team. This does a few key things.
- You get to address any misalignment and tell the team why they are actually there
- Team members get introduced to working alone together
- Every team member participates right away
- You complete one thing right away and build momentum
I don’t want to go into all of the details of a sprint, so i’ll just try to highlight a few of the things that happened.
- We aligned on the long-term goal of the sprint. Every team member had a shared understanding of a well defined goal we were trying to build towards
- We defined how we would measure our success
- We identified the risks that we wanted to mitigate using this sprint (Remember, design sprints are just a way to mitigate product risks)
- We interviewed customer experts to define and prioritize the problem space
- We created a visual representation of the customer journey and decided which part of it we wanted to focus on during the sprint
AND THAT’S JUST MONDAY! It’s easy to see that this first day of the sprint starts with the end in mind and focuses on aligning the team on a focus area. The team finally could concretely share what success looked like and had already decided the most important part of the customer journey to help them reach that goal.
Tuesday, Wednesday, and Thursday of the design sprint helps the team actually create solutions that are tested on Friday with real customers to determine if their solutions are on the right path to success. The design sprint uses voting and collaboration techniques, (like working alone together), to help move the team quickly through the double diamond of divergent thinking and convergent thinking to actually create the testable solution for within a single day. I won’t lie to you, there are always bumps throughout a design sprint, but that’s why you have a facilitator! You have someone there who keeps the team moving, forces decisions, removes roadblocks, keeps the energy high and ensures that the outcome is reached. I’ll repeat it, you bring in a facilitator to ensure that your team reaches a specific outcome.
Now, let’s take a look back at the original problems the team was having to see how the design sprint helped them address them.
- Engineers were not involved in discovery or solution discovery
- The lead engineer participated in every part of the design sprint.
- No one felt like their ideas mattered because they would just build whatever their boss wanted at the end of the dayEvery team member got to create multiple solutions, and had an independent platform to contribute and share their point of view.
- They had prioritized the wrong customer and built another custom solution for them instead of a new solutionWe never even looked at the old solution. There was no risk of prioritizing the wrong customer because we had aligned on the end goal and what success looked like right away.
- There were over 20 unique customersI added a customized exercise to address this issue, we aligned on two major users and one customer.
- There was no process for how to do discovery
- This is a great benefit of design sprints! They actually show your team a real life way to do discovery with customers extremely quickly (However, i don’t recommend running design sprints constantly).
- Team members saw the product and strategy differently than their boss didEveryone had the same understanding of the goal we were trying to achieve and aligned on and even contributed to creating the solution that would help us reach their goal. If even a team member disagreed, they committed.
Pretty cool right?
I knew that things had gone very well the following week after I had sent over the design sprint report findings to my old coworker and the rest of the team.
“Can you run another design sprint with us next week on a different part of the customer journey map we made?”
YES! This is actually a pretty common pattern for first time teams running a design sprint. They’ve never felt such alignment, and have never built and tested a solution so quickly that they have to repeat the process. It’s hard to imagine going back to the way you were working after participating in a great design sprint.
So I signed on for one more round of fun with the team to focus on a new portion of the customer journey. We were even able to shorten a good amount of the sprint because the goal had not changed and there was already a ton of alignment between the different team members.
Breaking point
I mentioned that I don’t recommend running design sprints constantly and that they are especially good for kickstarting a project or to help move a tough problem that the team has been stuck on for a long time.
After running two sprints with this team and sharing the learnings, i had stopped working with them. This is also a common trend because you’ve just given the team so much new work to think about, define, and ultimately implement for their customers.
So how do you help a team keep learning quickly like this without running sprints?
While sprints are a great way to kickstart discovery and introduce a team to fast product learnings, they are largely unsustainable. They take up a ton of time from the team and they lose more value after you gain the first few big insights. The next step is to move into continuous discovery habits with the team. Luckily, the team now trusted me because of the design sprints and they were open to trying out working in a little bit different way.
The key is to draw the parallels to the design sprint so that they can understand the overall outcomes it helps you reach and then turn that into a smaller repeatable process they can implement.
- Monday - Define what you want to learn and why. Define what success looks like.
- Tuesday - Gather inspiration and many ideas quickly, generate messy but defined solutions
- Wednesday - Decide on the best solution quickly and move forward
- Thursday - Spend time building small prototypes that reduce important risks
- Friday - Test with real customers early and often
Take these principles and work with the team to define:
- How can we decide what we want to learn about and why?
- How can we focus on the outcomes and success we want to achieve right from the beginning?
- When is the right time to create new solutions? When is the right time to iterate on a solution?
- How can we make quick decisions that are well informed and aligned up?
- How can we easily build small testable prototypes?
- How can we easily get regular feedback from customers?
It’s important that the team starts small here and gets a lot of help making changes to the way their working and measuring if their more successful or not. Remember, implementing good discovery in your organization is very different from kickstarting discovery. Kickstarting might just take a week or two, but implementing good discovery is something that you’ll have to work on continuously. The goal is never to think about implementing good discovery at a team, but getting them to understand the principles behind good discovery so that they can flourish without you there. So that the team’s mindset about their work fundamentally shifts and they are able to self-correct when things go wrong. This is my personal goal when I work with a team and what I consider a best practice of the best consultants. There’s nothing more fulfilling than to see a team start to understand and do good discovery without me. It’s when I know it’s time for me to move onto the next team.
Thanks for reading, now go run your own design sprints, build some cool stuff, and put it in the hands of real customers!