All Posts
-min.jpg)
For established enterprises and wide-eyed start-ups, the temptation to dive into a new project can be strong. You’ve got a great idea to improve your product, or maybe you’ve got something brand new and totally game changing. But remember, building software is both tricky and expensive, and correcting mistakes could be financially devastating, even for the biggest players.
Through our product discovery process, we are able to uncover, validate, prototype, and user test ideas quickly and efficiently to reduce risk before embarking on design and development projects for our clients.
This article aims to highlight the importance of product discovery and give a glimpse into working alongside a digital product studio to undergo this process. We will also be demonstrating some of the practices we’ve adopted here at Crowdlinker to make running product discovery more impactful.
Why should you care?
The Discovery process is all of the work you need to do to make informed decisions about what to build, when to build it, and the best way to go about it. It’s all of the research that turns your idea into a successful project. But if you already have a great idea, does all of this extra work really matter?
In short, yes. Despite what you might think you know about your customers, their individual needs can be extremely nuanced. To deliver the most desirable product to your intended market, continued research in this area can help you to evaluate just how well your solution really meets the needs of your audience.
For emerging start-ups, this of course is especially true, however, it is equally as relevant for more seasoned professionals, who might even consider themselves experts in their particular industry.
The problem with experience is that it can often lead to assumptions. It’s true, you probably know your customer well. You might even be an expert in the particular technology that you specialize in and have created numerous products before this. But sadly, that isn’t enough to give you the green light to go full steam ahead on your next project.
For many product developers, the end product might have worked well enough to give you the confidence to move forward. However, when diving into analytics and measuring the overall impact of the product, often, the data tells a different story.
Okay, it worked, but did the product have the intended impact you initially set out to achieve? Did your product meet the needs of your intended audience? Or did some of your features fall by the wayside?
Through leveraging customer interviews, prototyping, and user-testing, you can assess the feasibility, as well as validate the demand for your product before committing to a costly build. This reduces risk and saves time and money by reducing the number of sprints you have to take before creating a final product that is successful, propelling you towards your business goals.
Who should be involved?
During discovery, your aim is to develop a deeper understanding of your customers' world, and the context in which their needs occur. In order to generate a pool of well-grounded ideas, you should aim to leverage the expertise within a cross-functional team, utilizing that knowledge and gaining a variety of perspectives.
You should always avoid isolating the research within one particular role. By including multiple teams, you can understand the project from a business, user, and technical perspective. The discovery process could include, but not be limited to, the Product designer, Product researcher, Software engineer, Product manager, Product marketer, and even the Stakeholders. Basically you want to include anyone who has a stake in the product.
Digital product studios like Crowdlinker are able to give access to a variety of skills and expertise which Founders and product leaders can utilize to help them undergo a thorough discovery process. These studios typically align themselves with the organization they are partnering with, capturing business objectives, product needs, and success criteria. From this point, the digital product studio can break down problems into smaller pieces and uncover the most effective path forward.
At Crowdlinker we like to conduct product discovery with around 6-12 people. Undergoing a product discovery process with only 3 people probably won’t give you enough insights to get the information you need. Similarly, involving too many experts can create a chaotic environment and hinder productivity. To avoid this, our teams will occasionally break down teams into smaller discoveries with different people, and combine findings to get the best results.
When conducting discovery remotely, you probably want to aim to keep your team small enough to avoid confusion and disorganization, but large enough to get good insights. You should aim to keep that number under 12 people, and aim for somewhere closer to 6. In-person, you have more flexibility with the number of individuals you can include, but this is dependent on the space you have available. In these cases, if you have a large break-room or office you can work in, you could have more freedom in terms of integrating a larger pool of expertise, without worrying about the session descending into chaos.
Lastly, you must include your target market. Even with a comprehensive team of specialists, assuming you have all the answers could lead you down the wrong path. Nobody understands your customer better than your customer. In order to actively work to develop empathy, and close the gap of knowledge, you have to go out and immerse yourself in your customers' reality. Talk to them, hear their problems, and together with your team, generate ideas that meet real-world requirements.
How it’s done?
At Crowdlinker, we have implemented a four-step framework to conduct product discovery with our clients. This framework includes Problem Definition and Planning, Research, Solution Generation, and Solution Validation. A common framework used traditionally in product development would be to generate a list of initiatives, rank them in order of importance, and finally build the highest-ranking ones. This isn’t necessarily a bad framework however it excludes any fundamental research and works off the back of assumptions. (Teresa Torres goes through some best practices for conducting Product Discovery, in her Youtube video - An Introduction to Product Discovery.)
At Crowdlinker, our four-step framework allows our clients to move forward cautiously, testing an idea a little bit at a time. By experimenting and investing in data analytics, you’ll be able to determine the success of an idea, then make an informed decision about whether or not it is worth investing further into. But how do we do that?
1. Problem Definition & Planning
When working with a digital product studio, the discovery process begins with all teams and stakeholders finding alignment on the problem they’re trying to solve and what the next steps are. This involves asking difficult questions to figure out what the risks and assumptions are, what the unknowns are, and how to potentially reduce these risks.
At Crowdlinker, many of the clients we work with already have an established relationship with our company, which gives us a good jumping off point and makes for a quicker discovery. We may have been involved with building previous products for the client, or could be working on improving an existing product. Although each discovery is defined by the product, for example a heavy analytics project will be very different from a site build or page revamp, but we usually begin by following a template that asks the client a series of questions.
The questions we typically ask are there to help the teams to understand what the problem is they’re solving and why they are trying to solve it? Who are the users they’re solving the problem for? How will they measure the success of the product? What does success look like for the client? What areas need further research, and where are the gaps in the current data?
These questions help to define the project, and from there, the teams can start to create a blueprint of the next steps.
2. Research
Following problem definition and planning, user research teams and customer insight teams can begin using tools to go further with researching their intended market. This research is necessary to ensure the teams are better equipped to come up with solutions afterwards. Here are a few of the tools and activities that are used during this process:
By completing this research, teams can begin to validate the market, and the demand for a product, as well as understand the users’ pain points before they start considering what solutions to implement. Remember, these reports will be revised regularly based on any new insights or knowledge gained, to ensure the right problem is being solved and the project maintains focus.
3. Solution Generation
With all the research done, we should now have a pretty comprehensive view of the end-user and their overall needs. Additionally, the research should have given insights into what competitors are doing, what the current market is like, and which problem is being solved. Now it’s time to begin determining potential ways in which a product could solve this problem.
During this stage, teams can work together to visualize the solution and finalize the features of the solution. When building an application, the team can start building on the initial research to create a feature set. This is a high-level description of the functionalities you would need to include in your app to be able to solve the users’ biggest problems. This is not a list of features you like the look of, or that you hope would make you stand out. Remember, these features need to be based on research about your user and the market, not individual presumptions.
A User Flow chart/diagram can help all teams and stakeholders to visualize the users’ journey when using their product. This can help to define and confirm features, whilst highlighting any areas that might be less significant or potentially confusing for the user. A User Flow is a great way to put yourself in the shoes of your customer, but an even better way to conduct user flow would be to actually give this to your customer. By keeping the customer in the loop, it allows for a more user-centered design, giving you a better chance of building a product that engages your customer and meets their needs.
Digital product studios could also use this time to begin creating low-fidelity wireframes. This would allow stakeholders and clients to get a good basis of how the interface might look, without spending time and money designing something that will mimic the final product. By creating a low-fidelity wireframe, developers have the flexibility to adjust designs and key features as feedback rolls through.
4. Solution Validation
Next, stakeholders and teams would need to validate that the proposed solution actually solves the problem they have identified in the market they have researched through the previous stages, and to confirm that those users would be willing to pay for it. The goal is to not waste time and money building something that won’t be successful, making this the last chance to validate before the build takes place. So, how can you make sure that your product is going to be desirable for your users without giving them the product?
A/B testing can be a great way to compare 2 versions of a product in order to define which variant of features/design is most favourable amongst users. However, building 2 versions of your product can be expensive, and although one variation could appear more lucrative than the other, without first validating your ideas, this could potentially be an extremely costly way to learn. Rarely will teams pull a project at this stage, even when the results aren’t comprehensive or even promising, due largely to the fact that this way of testing requires a hefty output of resources and withdrawing at this stage could feel like a waste.
But how should we iteratively test our ideas to know whether or not a goal is worth pursuing? First, teams would need to select their top initiatives from the research collected in the previous stages of the discovery process. From there, solutions can be evaluated based on the assumptions that have been made, and any evidence that has been uncovered, either in support of, or against a particular idea. Ideas can then be evaluated based on risk and modified accordingly in an attempt to reduce those risks. By repeating this process a number of times, developers can begin to uncover, and subsequently minimize risk factors for potential solutions, increasing the chance of usability and desirability before diving into pricey builds.
Depending on the project, building a clickable prototype for end-users, developers, and product owners to test can help to gather accurate feedback before building a final product. This doesn’t necessarily have to be engineered by a programmer, and can typically be created by a UX designer, keeping the prototype simple, but still user focused. By using data metrics and collecting feedback from users, the stakeholders, developers, and product owners can confirm the functionality of an idea, whilst minimizing the use of time and resources.
What comes next?
Next, providing your discovery process has been earnest and thorough, and your results have brought you to a final solution with enough evidence to minimize risk, you can begin building your product. But this isn’t the end of the discovery process. Throughout each stage of your build, it’s wise to keep checking back on your research. This isn’t the time to forget all about your customer and begin a lengthy process isolated from your market. Your customer journey maps, empathy maps, and customer personas should continue to be living documents, helping you to stay on track and focussed to ensure your final product will perform well for the solution you intend to solve.
Can I skip Discovery?
Many people forego discovery, not just because of the extensive research involved, but discovery generally involves asking a lot of difficult questions. It demands product people to invite criticism, and it requires them to be flexible with their ideas. That means potentially tanking a much-loved idea or adjusting favoured features. The key thing to remember is that the idea is there to solve a problem, the problem is the showstopper here – it is the fundamental reason for creating a product in the first place. And if the feedback you generate concludes that the solution doesn’t solve the problem, it’s back to the drawing board. During discovery, the drawing board isn’t such a bad place to be. Exhausting all of your funding on a build you assumed would be desirable for your market but performs poorly – that’s a tougher pill to swallow than any negative feedback you might have received in the early stages. Marty Cagan’s article Discovery - Feedback , highlights the importance of inviting criticism when developing an idea, and dives into some of the most common excuses product people use to avoid hearing critical feedback.
Conclusion
Here are my final takeaways, and top tips for a successful discovery process:
For more helpful tips and tricks, Crowdlinker CEO, Aram Melkoumov sat down with Discovery expert, Teresa Torres in our Product Innovation Series podcast to answer all of your burning questions. For the full interview, click here.
