Start your project with Spark
Find a solution that's right for your business, on your terms.
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
As a product manager, you make product decisions every day. Some are big decisions, and some are small but they all contribute to the bigger picture. With continuous discovery, you infuse as many of those decisions with customer input as possible, and to do this, you'll need to reduce the cycle time between customer touchpoints.
Teresa Torres defines continuous discovery as:
Product discovery is just - How do we do that? How do we make good decisions? The key is to do it in a customer-centric way, and by incorporating continuous, fast feedback cycles with customers, you can move away from a waterfall project mindset and progress to an impact loop mindset. Continuous discovery and feedback cycles will drive you and your team to create consistently better, more impactful products.
As companies grow and mature the problems product teams face around identifying and validating new product ideas change, and best practices must adapt to accommodate those challenges. Continuous discovery creates a regular cadence of interaction between product teams and the customers they’re building for.
A great product discovery pressure diagram for enterprises & startups from Productboard
Applied effectively, continuous product discovery makes your product teams more efficient and impactful, driving real business value. Keeping the entire product team aligned around the product vision and strategy will lead the way to deliver new features and capabilities with confidence.
At Spark Equation, we conduct continuous product discovery to reduce risks around every product and feature set that is built and delivered. We leverage the Double Diamond approach for conducting product discovery, where discovery and delivery overlap and intertwine with each other.
During Discovery, product teams need to follow a proven, effective blueprint to consistently identify, test and validate new ideas. Here’s Spark Equation’s Discovery Blueprint:
Understand and uncover the underlying challenges
Step 1: Explore the problem space and discover the underlying user need
Step 2: Define and interpret your findings
** Repeat the cycle if necessary
Define the optimal solution
Step 3: Ideate creative solutions
Step 4: Prototype solutions, test and collect feedback to drive solution validation
We assist teams with business and product alignment in Continuous Discovery →
To move quickly, teams should perform small activities regularly to help them learn more about your users. Instilling a habit of performing bite-sized discovery activities can not only help small businesses but also enterprises, who are lacking dedicated product discovery resources to learn about their users.
Teresa Torres talks about the power of co-creation (you + users) and regular interactions in her continuous delivery talk:
Co-create with your customers. Too often we see teams take a validation mindset where they think that if they solved the customer's problem, then validated it, they’ve got it right. But that's not the case. If you engage with your users early and often, you will develop a relationship with them where they feel comfortable telling you that your product is missing something. You’ll start to develop a co-creation mindset and invite the user to participate in developing an excellent product.
Our advice on where to start:
Notice the theme is “each week”. It’s important to be customer-centric and commit to engaging with customers every week, gather feedback, and iterate.
Henrik Kniberg is an Agile & Lean coach, who spoke about how to be more customer-centric at the 2019 Mind the Product Keynote in London. If you haven’t seen his keynote, we highly recommend checking it out. He shared some key insights after years of working at Spotify, LEGO, and Minecraft about minimizing the gap between user and maker.
Our favorite example:
Lego took about 4 years to first launch their Lego Universe, which shut down after 2 years. Minecraft built their game with 1-2 people and released it in 6 days. Users were able to tweet their feedback straight to the Minecraft team, which they listened to closely and in turn had over 100 releases within the first year. The feedback they received and the changes they made, the team never thought of. The difference? Lego instead of doing tiny small releases each week with user feedback worked on their product until “perfection”, but when they released it they found that users didn’t like it. Lego ended up wasting tons of time and resources on a product that users didn’t want. Minecraft was able to earn $80 million in revenue within the first 15 months, before being sold to Microsoft for $2.5 billion. Minecraft is still the top 1 best-selling video game because they continue to listen to their users & release often.
Minimize the gap by:
1. Releasing often
2. Incorporate real user feedback from small releases
3. "Slice the elephant"
You can start small and release only to a small group of users, gather feedback, iterate, and when you're ready, move on to stages 2, 3, and so on. But don't lose sight of the high-level theme or vision of the product.
4. Autonomous teams
Reduce handoffs, work as one small team and learn from the users
5. Radical transparency
We see this often, everyone is sitting in the "dark" and running in circles - misalignment and no view of the bigger picture. You need autonomous small teams, tightly aligned and loosely coupled
Use interviews to discover opportunities, they help map out the opportunity space. The purpose of a generative interview is to understand your user's context well enough to identify solutions and if they can drive your desired outcome.
The key is to generate multiple solutions for the same target opportunity. Most teams consider a lot of ideas, but they consider a lot of ideas for different problems. Instead, we want to generate and consider multiple solutions for the same problem or opportunity. This avoids "whether or not" decisions like "is this a good idea or not?" and prevents the team from confirmation bias. Rather compare and contrast decisions and ask which of these solutions best addresses the target opportunity. When we compare and contrast solutions, we can make a relative judgment by asking " which of these ideas looks most promising?".
Teresa Torres recommends an opportunity tree because it reminds all product teams to test all of their connections, ensuring that you address real customer needs while driving a desired business outcome. This is a continuous process, and it involves exploring many solutions. As a result, our understanding of the opportunity space evolves and you and your customers will get inspired for new solutions and try to identify whether your desired outcome is feasible.
Too many teams when choosing experiments assume success. They assume product ideas will work, so they skip conducting the obvious tests. Assuming people will want your solutions, will know how to use them, and where to find them, is risky. Run the experiment because we don't test to learn from successful cases, we run experiments to learn from the failed cases.
We want to discover opportunities that will drive that desired outcome or key result. Opportunities can be customer needs, pain points, desires, and wants, but we won’t want to include every customer opportunity, just the ones that if addressed would drive our business outcome. Discovery is only as good as the outcome you set. Teresa Torres recommends this to be a 2-way negotiation between the leadership team and the product team. Too often, product teams are told what outcome to drive, or they set their own outcomes without input from business. We want leadership to provide input on what creates the most value for the business and product teams need to provide input on what is feasible.
Successful product discovery begins with defining outcomes you'd like to achieve. These outcomes measure success, optimize processes, and justify the time and effort of proposed solutions. Measure product discovery success by using Leading Indicators - quantifiable metrics, you can measure as the team progresses through each cycle of the Discovery process.
** At the end of every discovery cycle, you have three choices - Build, Discard or Keep Learning
How to become a successful outcome-driven product team?
1. Collaborative mindset - Get the right people into the process that allow you to move quickly while leveraging the right expertise on the team.
2. Shared understanding - The best way to facilitate team decisions is to base them on a shared understanding of the business, customers, and solutions you might build. You need to work from the same starting point and keep everything transparent.
3. Foster a continuous mindset - The best teams foster a continuous mindset. This means that their discovery is never done, their delivery is never done, and they embrace continuous iterations.
Next-level product teams come together around a clear product metric and run continuous feedback loops through discovery and delivery to make forward progress. Continuous impact is a series of fast feedback loops, all orbiting around your central product metric. Product metrics define success for the team and address a critical business bottleneck. Solid product metrics like:
But whatever metric you choose, focus on leading indicators to business impact, rather than business-level metrics like revenue or agile velocity. Here’s why: the most concrete measure of benefits of product discovery is high adoption and engagement rates for all new features and great qualitative feedback from users. But these metrics are all lagging indicators of product success and they can only tell you whether the product or feature you already built is well-liked, they don't provide any context that can help the product team hit their outcomes at a higher rate, and grow over time as their discovery practice improves. We will talk more about this in part 3 of our product development series.
Here is an example from Tim Herbig:
Depending on the size and scope of the initiative or project. Discovery should take you anywhere from 1-4 weeks to complete for the first release. This means the team will need to timebox discovery activities to get the project rolling, but Continuous Discovery never ends. After the first release, you gather feedback, iterate, and release at a consistent pace. It’s also a good idea to document the release notes, one to share with your stakeholders, but also with your users so they know what to expect in the new release. When we work with clients we start their discovery process and create a stable framework for their teams to use, but once they feel comfortable taking over, we transfer our team and step in for maintenance and product support.
So are we! There's a common misconception that teams need to be co-located to be effective, but given the right process, toolset, and work environment teams can thrive.
Here are some best practices and tips from our product team:
Product management coach Tim Herbig, sheds some light on remote product discovery.
Check out the next part of our series on OKRS in Product Development
.png)