There are many challenges along the path of creating innovative digital products, and the first of these is the moment of transition from discussing the idea to action. Many ideas look very good in presentations in conference rooms but don’t make it any further. They never have the opportunity to move to the implementation phase and be tested in the market. However, by delivering hundreds of projects, we have developed a method that helps you take an effective first step when creating digital products. This Discovery Sprint approach helps to overcome the innovation deadlock.
What is a Product Discovery Sprint?
A Product Discovery Sprint is one of the design thinking methods applied in the digital product development process. It allows the discovery of key information, risks, and characteristics of a planned product or service. It is the first and very effective step in creating digital products. Thanks to the product Discovery Sprint, we are able not only to define better what is to be designed but also to overcome the organisation’s resistance to moving from discussions to action.
I will describe the barriers and obstacles later, but the key value that our clients see in this method is the opportunity to conduct – at a relatively low cost – a business experiment, refine the scope of the product, and ask themselves key questions about the value of the idea, its market fit and the feasibility of implementation.
The second highly valued outcome is the concept that emerges during the sprint – a tangible result that helps to align the vision that each decision-maker has about the product. It allows a specific solution to be evaluated instead of describing a vague idea.
An important outcome of the product Discovery Sprint is also the estimate of the budget and effort necessary to implement the idea. This is one of the most frequently mentioned benefits of sprints by our clients.
Summing up, the main advantages of the Discovery Sprint are:
- Quick pace and well-defined schedule (2 weeks)
- Low cost in relation to results,
- Definition of core product scope,
- Mapped risks and opportunities for the idea,
- Design of the concept ready for stakeholder meetings and testing.
Design Sprint vs Product Discovery Sprint – what is the difference?
In the digital industry, terms tend to blur, and everyone interprets them differently. It is therefore worth clarifying how we understand these product design methods.
Both terms refer to similar activities carried out during the early stages of product development. The difference lies in the duration and the expected results.
A Design Sprint is a five-day design process consisting of full-day workshops to see if an idea for an improvement or product makes sense. This method of rapid prototyping and testing of digital products was created by the Google Venture team (i.e. Google’s living lab).
The principles and process are described in great detail in the book ‘Design sprint’.
During Design Sprint, the team refines the idea, creates an initial prototype, tests it with potential audiences, and makes the necessary adjustments. Each day is very precisely planned and dedicated to specific tasks.
Our team also runs such Design Sprints, but we know from experience that the principles of a Design Sprint, requiring daily all-day meetings for 5 consecutive days, are often not feasible. Even arranging a convenient date for the whole team often takes longer than the sprint itself.
As this is not always a method that suits the organisation or is even impossible to carry out, we have developed, based on our experience, a variation on it, which we call the product Discovery Sprint.
The Product Discovery Sprint takes longer – 2 weeks – and does not involve research verification. Instead, it gives a better and more precise product definition. It relieves time pressure, allows us to explore the topic better, and deliver better quality material. It also requires less of the client’s team time and engagement.
Why is a Design Sprint not always the best solution?
The Design Sprint is a very effective methodology, but it also has drawbacks that make it not always the optimal solution.
Firstly, it requires a very serious team commitment and not a lot of time – the idea is that the whole team should work, undistracted, for 5 consecutive days.
From our experience, we know that these are often extended days and require overtime – running such a sprint can be a really demanding project. In many cases, this is not feasible – the people involved have other ongoing responsibilities that do not allow them to detach themselves from their current tasks for a whole week, giving up answering messages and concentrating fully. In our approach, we, therefore, divide our time between team workshop work and project work. With this approach, the required involvement of the organisation’s experts is significantly reduced.
Secondly, the Design Sprint implies a readiness to work with design methods, which requires prior preparation and a specific mindset and skills. This approach means more drawing, prototyping, and readiness for uncertainty and experimentation, less defining and discussing assumptions or building precise models and final deliverables. Workshop work is not a secret art, but people not used to teamwork or prototyping may feel uncomfortable and not fully understand what is required of them. Involving a team unprepared to work with design thinking methods can even be extremely ineffective and cause the whole process to become less effective and frustrate workshop participants.
Third and finally, a Design Sprint requires coordination and a lot of preparation. All team members need to synchronise their calendars, templates need to be prepared for the work, respondents need to be recruited in advanced to take part in the research on a particular day, access to the workshop space needs to be ensured, and the whole process needs to be moderated very efficiently – otherwise the project can very easily go awry and be a waste of time.
A design sprint can work well in a start-up environment, or a team focused solely on innovation development, with people with experience in using design thinking methods who are ready for a very high level of commitment and pace of work. However, in our experience, in the environment of large organisations, this method is very demanding and difficult to carry out according to defined rules. Therefore, we have developed an alternative that works much better in large organisations.
How does a Product Discovery Sprint work?
In our approach, a typical product Discovery Sprint lasts 2 weeks and requires around 1 week of preparation.
We conduct a series of structured workshops, where we meet together and, using different methods, first share ideas to identify the best and then create a prototype.
One week before the launch, we start preparations. To run the sprint smoothly we:
- take care of the logistical aspects,
- gather knowledge about the industry (so as not to discuss the obvious and waste the experts’ time),
- build a proper glossary of terms and learn the industry jargon,
- conduct an initial benchmarking of competing solutions,
- carry out an initial UX audit of the competitors,
- conduct interviews with decision-makers to gather their perspective.
Week 1 – discovering needs and defining the product
On the first day, we conduct a business design workshop lasting approximately 4 hours. During the workshop:
- we analyse the key business objectives,
- describe the ecosystem of related products,
- define the customer journeys,
- analyse target groups,
- prepare initial personas.
With a well-developed and tested workshop structure, we are able to gather all the key information, which is then organised and refined.
During the first week, we also need access to a subject matter expert who can answer questions that arise during further analysis. On the fifth day, we conduct a workshop to present requirements and elements of functional specification and verify these assumptions with the product team. All prepared documents and artifacts are presented and analysed. The workshop lasts approximately 2-4 hours, depending on the complexity of the product and its context. During this workshop, we also select the screens and features that will be designed during the second week.
Week 2 – concept
The second week is dedicated to concept development. Designers use the knowledge they have gathered, deepen their understanding of the problem the product is intended to solve, create sketches, and then mock-ups and finished designs. If the organisation has a design system in place – which helps a lot, the design is developed using this tool.
The last day of the sprint is dedicated to the presentation of the concept in front of the team. The concept is discussed in detail and verified in terms of business assumptions and completeness and correctness. We also collect feedback on the entire process.
Presentation to decision-makers
Once the project has been revised, the business designer prepares an executive presentation, which can be presented to the board or other project sponsors and serve as a pitch deck.
Below is the standard Product Discovery Sprint schedule:
How to prepare a Discovery Sprint?
To make effective use of the team’s time and energy, it is worth taking the time to plan the details and preparations properly. The project lead is responsible for preparing all key aspects of the sprint, including clear communication with everyone involved in the process.
The role of the facilitator is to make sure that all areas are well prepared, and these include:
1. Understanding the business objective and context of the organisation
Our team usually comes to the organisation from outside, and we need to familiarise ourselves with the organisation’s structure, business model, and core products. We also send out a questionnaire about the Product Discovery Sprint topic before the sprint starts – we want to make sure that the workshop participants have a good understanding of the business goal of the product they want to build.
2. Communication with the product team and decision-makers
An equally important aspect is to explain the process and purpose of the sprint to everyone involved. By explaining exactly what we want to do, why we want to do it, and in what order, we raise the awareness of all participants. This way, they know the project’s purpose and what to expect over the next few days. We also explain what they will receive at the end of the sprint and in what form.
3. Gathering materials
We ask the project team to provide e-mails, briefs, research results, or presentations describing the business idea. The facilitator gets information about the industry and makes sure that the idea has already been initially discussed within the product team. We also want to ensure that the product target groups are known and that the sprint participants have knowledge of their needs, gathered through exploratory research. We also ask for branding materials and access to the design system, if it has been implemented in the organisation (which speeds up the product development significantly).
4. Collect answers to product questions
To deepen participants’ awareness, we ask them to answer key product questions:
- What exactly do you want to build? What is the essence of your product idea?
- What is the purpose of this application?
- What exact problem will it solve?
- Who will be the first 10 customers/users of this product?
- What are the competing solutions in the market?
- How will the product impact your organisation? In which areas?
- How do you know this is what the audience needs?
5. Fine-tune the course and set the dates, and take care of the logistics
We know from experience that a sprint needs to be planned well in advance in order to align the calendars of all the required participants. We also remember to book the right space – virtual (appropriately prepared interactive whiteboards at Figjam, Mural or similar) or physical. For teams that have never worked with these tools, it is a good idea to ask in advance to test the access and perform some simple tasks to familiarise participants with the programs.
6. Preparing the agenda for the initial workshop – knowledge transfer
The initial business design workshop has a relatively standard structure, but this needs to be adapted depending on the amount and quality of material the team has presented, the size of the team, and the type and complexity of the product, so make sure that all issues are adequately covered.
What kind of team to engage for the Product Discovery Sprint?
The size and composition of the team largely determine whether the objective of the sprint will be achieved. A team that is too small or lacks a key expert or decision-maker might fail because there will be a lack of business knowledge. On the other hand, a team that is too large will slow down the work because it will make logistics more difficult and cause much more discussion.
This is why it is worth selecting the participants appropriately – ensuring that all the key players in the project take part, but no more than is necessary. It is therefore not recommended to invite a larger group ‘just in case’. This will disrupt the sprint and participants who are not involved will see participation in the sprint as a waste of time.
The ideal team for a product discovery sprint consists of:
Moderator – business designer/analyst – this is the person moderating the sprint, conducting the analysis, and gathering key information about the audience and the organisation
UX designer (sometimes combining the role of a business designer) – a key role during the development of the concept – prototype 5 screens
Graphic designer (if a UI concept is to be developed) – this is the person who will take care of the final shape of the concept created during the sprint
Product owner – this is the leader of the project and the person responsible for its business success, deciding on the direction of development and the functionality of the solution
Industry specialists/ideas (preferably understanding different business contexts) – these are key subject matter experts who have a good understanding of the market, customer needs, and the business needs of the organisation
Decision-maker – the person who sponsors the project – participation of such a person is optional, but highly recommended.
Analysing the history of sprints, we come to a conclusion that, on the side of the organisation verifying its idea, a specialist team of 2-4 people is the best solution. Such a group allows to gather different experiences, but on the other hand, it does not slow down the work and does not cause too many discussions. Working with one expert is possible, but there is no opportunity to confront different product visions and exchange knowledge.
Moderation and experience required
An effective sprint requires very good moderation and structure. To run such a process effectively and efficiently, you need to have a good understanding of the business, design thinking methods, and group dynamics. This requires an interdisciplinary approach and a lot of experience in business processes.
The ability to translate business issues into a design is an essential competence. Developing it requires experienced practitioners who, after understanding the needs and context, develop a useful and intuitive tool.
As facilitators, we are the guides who lead the team through the exercises. Our job is to understand the idea, analyse the opportunities and risks and create a prototype that shows how the solution can look and work.
Why conduct a Product Discovery Sprint?
A discovery sprint is, in our view, the best way to move from talking to action and overcome the innovation deadlock. It is a method that allows you to combine the potential of a project team that knows how to develop a concept and industry experts who know the market and customer needs.
Product Discovery Sprints are valuable in at least several respects.
Requires specific solutions – the method requires answers to structured questions and forces the creation of a prototype – a tangible result of the work that can be shown to multiple audiences to gather their feedback.
Brings tangible results – the result of the work is a precise description of the requirements and functionality of the planned system and a concept to visualise the idea.
Optimally combines the use of industry knowledge and design competence – optimal ideas come from specialists who know their industry and its problems very well. On the other hand, these are rarely people who can design an IT system or application that solves a given problem. Combining the expertise of experts with the competence of designers allows the potential of both groups to be used optimally.
It has a structured process – organisations that employ intelligent people are a great place for endless discussions and searching for all kinds of arguments. If you do not impose a framework on such a process, it will go on for months and will not lead to any specific results. Therefore, in addition to a leader who will be responsible for the progress of the work, there also needs to be proper moderation and structure, setting timeframes and targets to be achieved.
It is a business test of the product – to see how the product will be received by customers, you have to show it to them. There is no other effective shortcut. Therefore, the process by which the concept is developed and specific scenarios for using the application are described addressing the need for a test. The test itself is not part of the sprint we run, but we recommend that it follows immediately afterward.
It helps overcome the innovation deadlock – large organisations are not always good at developing innovations (which is why they often create special units to take innovative products off the market or buy startups). Product Discovery Sprint is a methodology tailored to the corporate context that breaks the vicious circle of fear of taking risks and pursuing projects that do not guarantee a short-term return on investment.
With this approach, instead of wasting six months on discussions and programming, you can test any business idea in 3 weeks.
Sources of innovation deadlock. Barriers to innovation and how Discovery Sprint helps to overcome them?
Working with large organisations, we have become very familiar with the inertia that often prevails within them. This is partly due to the scale of the organisation, which forces processes to be slower, but it is partly due to the standards and values that are promoted.
The difference in working on products between teams in an early-stage startup and a corporation is the completely different working culture and priorities. Large organisations naturally put stability and a sense of security first, which makes it much harder to bring innovative but risky ventures into the discussion. And on top of that, talking about them takes much, much longer and requires a lot of signatures and approvals.
Discovery sprints, with their clever structure and time constraints, allow you to respond to these challenges and deal, at least in part, with the difficulties naturally present in any large organisation and red tape.
1. Innovation theatre – this is the phenomenon whereby an organisation pretends to innovate in order to create a good impression and complacency while failing to take real action. Strategies are created, and innovation programmes are launched, but the move to the implementation phase of ideas is delayed and replaced by lengthy discussions and the search for mythical business cases.
Solution: The Product Discovery Sprint requires discussion and action. The team has to roll up the sleeves and start prototyping.
2. Abstractness of conversations – ideas sound good in behind-the-scenes conversations and look promising as slides in presentations. But the proxy for their value is talking about the specific use scenarios and problems the product will solve.
Solution: The Product Discovery Sprint forces you to act and move from the level of abstract conversations to concrete discussions about market needs and how to respond to them.
3. Lack of decisiveness – the owners of the idea – the internal innovators – most often do not have the budget to start creating a product. Moreover, owners may feel that management does not understand the challenges and needs that arise in the market, or they may not feel the pressure to change. Most innovative projects fail or are halted along the way, and only a small proportion bring real, but often ground-breaking, change. In risk-averse organisations, deciding to invest in an inherently high-risk project often takes a long time.
Solution: With a relatively low entry threshold, it is much easier to decide to start a project with a small step. It does not require a budget declaration of hundreds of thousands of Euros or a commitment of many months. At the same time, based on the results of the sprint, it is much easier to decide whether to continue the work or suspend it – the analysis carried out allows the risks and potential of the product to be assessed much more accurately.
4. Distraction – an excess of simultaneous projects, an excess of meetings (not always needed), and the expectation of permanent availability, make it difficult to focus on priorities and there is no space to pursue good ideas that could help reduce the excess tasks in the future.
Solution: A sprint sets a very specific timeframe and forces focus. At the same time, due to the involvement of the external team, experts do not have to sacrifice much of their time and stop current projects or postpone other urgent tasks. This is one of the most valuable features of a sprint – the plan and structure force focus so that the idea will be delivered within a specific deadline.
5. Fear of taking risks – in conservative organisations, risky decisions are often avoided and investment in innovation is always risky. Procedures often require estimating revenue and calculating return on investment. Very often, at an early stage, this is not possible or simply detached from the foundations.
Solution: The risk of executing a sprint is much lower than executing an entire project, so it is much easier to convince an organisation that such a step is worth taking, without a complex profit and loss analysis.
6. Lack of skills and competencies in product development – designing and implementing digital products requires a specific set of competencies. Innovators who have a great understanding of market needs do not know how to create new products and do not have the competences to create them themselves.
Solution: If the sprint is led by methodically prepared specialists, the team does not need to have experience in design thinking working methods. A hired design team is able to turn knowledge and ideas into a tangible solution using their experience and knowledge from other industries.
The investment of time and money should come with the promise of tangible results that can be used in subsequent stages of product development.
What is the outcome of a Product Discovery Sprint?
The following deliverables are produced as a result of the Product Discovery Sprint:
I. functional and business specifications
II. product concept (design of 5 screens)
III. presentation for the management (executive summary)
I. Functional and business specification.
As part of the specification, the following materials are delivered:
Answers to key business questions – the assumptions and vision of the product are the rationale for why it is worth investing in building it at all
Definition of target groups – key information in any user-centered design process is needed to understand who will use the tool being created
Personas – a classic design thinking tool to trigger empathy and better take the perspective of the future user
Product usage paths – the customer journey – is a tool for capturing the usage of a product from the perspective of the entire process
Business objects – data model that will be used to design the database at the later stages. Some of them are very concrete (vehicle, rack, assembly line), and some are more abstract (annual assessment, certificate, etc.). Defining the objects describes their metadata and the logical relationships between them. This makes it easier to create the data structure needed when designing the database.
Roles and their permissions – each system has corresponding accesses for different roles. We describe these access rights, resulting in a simple and understandable matrix of users and permissions.
User stories or job stories – a description of system functions in the form of application usage scenarios, defined for each role.
Information architecture – a diagram showing the division into sections and categories, which allows navigation to be designed at a later stage
List of modules and screens – a description of the main parts, allowing a catalogue to be prepared of the elements that will need to be designed and programmed.
Screen flow diagram – a diagram defining the successive screens through which a user passes when performing a task. These tasks follow directly from the user or job stories described and are therefore an essential element of a complete specification.
II. Functional and visual concept of the product (UX/UI)
Screens of the designed solution – we usually assume that 5-10 key views will be created. Our experience has shown that this is the optimum number of screens to show the essence of the product.
There are just enough of these to be able to design them in a short time while still creating a design that explains the core of the idea. The typical systems we work on consist of dozens and sometimes hundreds of different types of screens, but such a concept is enough to show the navigation structure and key functions of the system in a way that allows us to understand the business idea and assess its value.
III. Idea in a nutshell – presentation to the board (executive summary)
The key issues and concepts are developed into a presentation that can be used as a tool to communicate the idea to a wider audience.
Business value of the Product Discovery Sprint
The specification helps to clarify the scope of the product – it describes what needs to be in scope and what is just optional. Such a description allows development teams to provide initial estimates of implementation costs.
In turn, the concept is crucial to show how the tool will look and what it will do. People vary in their level of technical competence, market discernment, and ability to imagine digital solutions, so such a visualisation allows them to have a far better understanding of what is to come out of the design work.
The most important thing for us is that the results are concrete, tangible, and easy to use. This is why we emphasize developing materials in a way that can be understood by a wide audience. The resulting presentation in the form of an executive summary at the end is, at the same time, a pitch deck that the innovator can use to gain a budget for product development.
In summary, the Discovery Sprint allows us to refine the scope of the product and build a basic prototype version in just 3 weeks.
Infecting with an innovative approach
When running digital product discovery and definition sessions, we also noticed a very significant value associated with promoting the design thinking approach within the organisation. Aside from the sheer pleasure for participants in learning new methods and doing something for the first time, it’s hard to ignore the fact that involving employees from different specialities allows them to catch a new perspective.
By being involved in the design process, they can understand the behind-the-scenes of design and catch the design thinking approach bug. It’s difficult to measure this aspect, but we see that participants in our sprints instantly see the value of design thinking. By participating in a sprint, they become the vanguard of grassroots change and innovation in the organisation, soaking up design thinking. It is therefore also a way of rapidly developing the design competence of the team and introducing a culture of innovation.
Taking the first bite and stimulating an appetite for design
The first step can sometimes be the hardest, and a small success helps to find the energy and enthusiasm to move forward. That’s why breaking down the process into smaller chunks and starting with a small, quick, and concrete action yields great results. Discovery Sprints are a chance to achieve a first – motivating – success in a very short time.
The team involved in the work will be happy to see the result, to see concrete results and to show them more widely in the organisation, and boast to the managers. This builds motivation for the next steps and the fight to complete and implement the project.
The result is a growing appetite for designing and continuing the work. If management sees the concept, begins to understand the performance and value of the system or application, and knows the approximate cost of its implementation, it is much easier to get a positive funding decision. The person deciding on the budget is not buying a cat in a poke, he sees what he will pay for more or less, and is able to assess whether what he or she sees will be of value to the organisation and its customers.
Experience shows us that the result of a successful sprint, is a growing desire to develop more bold and sometimes crazy or groundbreaking business ideas.
How much does a Product Discovery Sprint cost?
Each consultant or team will use different pricing, depending on experience and methodology. When pricing a sprint, we take into account the preparation, execution, and development of its results and the presentation to decision-makers. The cost varies depending on the complexity of the product, the difficulty of the project, and the size of the team involved on our side. An approximate cost can be found on the Discovery Sprint description and pricing page.
We price the Sprint as a package, which includes the work of the entire team and the transfer of copyright to the resulting materials. In the budget, we provide the specification and product concept. These two key deliverables allow you to make an informed decision about further product development. Is an expenditure of a dozen thousand Euros or Dollars a lot?
In assessing this – after all, not insignificant – investment, it is worth taking several aspects into account, including the organisation’s own time and the lost benefits.
Don’t ignore the invisible costs of your own organisation’s work
An organisation’s own time is a cost that is very often overlooked because no one invoices for it – the time of a company’s employees, especially the decision-makers, is therefore invisible in the budget and overlooked. And this is, in many cases, a huge investment.
We often witness lengthy processes, meetings, and deliberations, often consuming many meetings and inconclusive discussions (because they lack structure and appropriate tools). Such discussions sometimes last for months and consume hours of deliberation, and preparation for ineffective meetings, and generate a lot of frustration.
When you consider the salary levels of the key decision-makers who engage in these conversations and the scale of the teams involved, the process often consumes a much larger budget and often produces no resolution and no tangible results.
It is also worth thinking about the lost benefits of not having a product or solution in place. While idle discussions are taking place, competitors are creating solutions and conducting experiments that could give them a market advantage.
This is a cost that is extremely difficult to quantify, but in this age of ultra-fast development, time lost to idle discussions is a very large cost to the business.
Discovery sprint and what’s next? Research as a prelude to the product design process
The sprint is only the beginning of product development. If the idea passes the business test and sponsors can be convinced, the next step is product development. A step-by-step design and implementation work, starting with the creation of a prototype with key features, or the so-called MVP (minimum viable product).
Before launching the full process, we highly recommend using the concept created during the sprint to conduct research with the audience. Exploratory UX research in the form of in-depth interviews with usability test elements or in the RITE methodology (i.e. rapid iterative research), brings objective and invaluable first-hand knowledge. We write more about the choice of optimal behavioural research methods elsewhere.
The research also results in confirmation of whether customers see value in the project being developed. This way, you can check whether they will use it and whether it meets market needs.
How do you get started?
If you have an idea for a product that you think is business-appealing and mature, but you don’t know what next steps to take and how to convince decision-makers in the organisation, running the Discovery Sprint is a good idea to move from talking to action.
If you have project experience and feel up to running such a sprint yourself, you can download our checklist and the sprint programme we use, or refine it according to your organisation’s requirements.
Download the guide: How to prepare and run a product Discovery Sprint >>>.
And if you need help with moderation and project skills, don’t hesitate to contact us. Let’s talk about the potential of your idea and plan the Discovery Sprint.
We wish you the best of luck developing your innovative digital product!