discovery sprint cover - EDISONDA

Product Discovery Sprint deliverables – what can you expect?

A Discovery Sprint helps validate a business idea quickly and is the perfect first step in building useful and scalable applications and business systems. It gives us a well-developed general frame for the sprint structure and a tested set of tools, allowing us to conduct it systematically and gather crucial information optimally.
If you want to know more about the Discovery Sprint process, read our article.

All activities during the sprint are connected and planned in sequences so that insights from the previous exercise serve as a basis for the next move. After the discovery sprint, you will receive functional and business specifications, key screens of the concept and an executive summary. What does it mean, and what to expect? In this article, you can find examples of deliverables, their description, and key benefits.

What do we want to build?

Business design workshop

The first step to making the idea tangible is to map your vision of the product precisely. Is it a redesign of an existing digital solution? Are we transferring the offline process into digital? Are we creating a new solution? Depending on the answer, we can tailor the following steps to match the project’s needs. Based on the workshop materials, we can prepare the sprint deliverables.

We gather answers to the business questions during the workshop and map key assumptions. It helps us to understand why you want to build your solution and what problem it will solve. We define the recipients and think about their specific needs. We compare the planned solutions with those of competitors and define our unique value proposition. We focus on the sprint subject while keeping the whole ecosystem in mind. The main objective is to determine the longlisting goals and identify possible challenges.

Why do we do it?

  • to get the rationale for why the idea is worth investing in
  • to understand how this idea fits into the broader business context
  • to be able to propose adequate solutions
  • to be aware of the potential limitations
  • to respond to the potential risks before they even appear

Who will use our solution?


Persona is a well-known artifact in the design thinking process. It is a fictional but realistic description of product users, representing similar behaviours, goals, and motivations. It summarises data and visualises insights.

The optimal practice is to create a persona based on research, for example, interviews with end users or analytics from the current application. If we don’t have any research, we can build proto-personas instead, but as it is based on assumptions, we must remember that it will need to be verified later.

When building personas, we must remember that this is not an average user. It represents common characteristics of actual groups of people (shared attitudes, goals, pain points, and expectations). It’s also not the same as a marketing persona because we focus less on demographics and preferences and more on needs, reservations, actions, and reasons.

Why do we do it? 

  • to trigger empathy and take the user’s perspective
  • to focus on real needs and verify assumptions
  • to gather initial requirements and help think about solutions
  • to make it easier to imagine and refer to
  • to translate an abstract idea into „flesh and bones”

User/job stories

This is a map of requirements and a description of the features of the application from the user’s point of view. After we define our personas, we can start thinking about what those people try to achieve through our tool from diverse perspectives. The stories should be short, informal, non-technical, and general. The important thing is to focus on how our work translates into a gain for the user.

The standard structure of a user story is “As , I want to so that ” for example, “As a respondent, I want to have my answers automatically saved so that I don’t have to start over”. It focuses on the role, which is especially helpful when we have a lot of multiple personas with diverse processes to complete in the system. When we want to focus more on the context of use, we can apply job story: “When , I want so I can ”, for example, “When I exit survey and get back after some time, I want my answers to be automatically saved, so I can easily start where I left off”.

Keep in mind that through this exercise, we are gathering requirements and not working on final solutions yet, so it is focused on user intentions, not the way of implementation or interface.

Why do we do it? 

  • to map the requirements and scope of the product
  • to capture the goal along with the function
  • to get the initial view of the complexity of the system
  • to use natural and easy-to-read language instead of long pages of specification
Discovery Sprint Deliverables - EDISONDA
  • to quickly verify if the idea for some feature makes sense
  • to create a basis for information architecture and access rights mapping
  • to be able to translate it into the implementation and testing plan

What is the scope?

Functionalities prioritisation

Usually, during the process, we gather many ideas, and it’s challenging to implement them all at once, especially when every feature seems equally relevant. In this case, it’s beneficial to use a simple value-effort matrix to map the relative importance of actions.

This simple matrix can help us divide functionalities into smaller groups and show the implementation’s order. In further work, we focus on the “quick wins” (high value & low effort) and choose 1 or 2 “big bets” (high value & high effort). Our “maybes” (low value & low effort) are perfect gap fillers, for example, when waiting for feedback and having some free time to use. And finally, “time sinks” (low value & high effort) are the things we decide to omit for the time being.

To capture the whole picture, it’s best to gather people with diverse backgrounds together for this task. The business team can refer to value and effort for the organisation, the UX team can advocate for users, and the development team can estimate the difficulty of implementation.

Why do we do it?

  • to make sure that we don’t forget about any valuable feature
  • to identify if there is anything not worth implementing in MVP
  • to determine the riskiest ideas
  • to encourage discussions and gather diverse perspectives

Information Architecture

This is the diagram with key categories and subcategories in the system. It helps us define the content structure, and we can use it later to describe how users will move through our solution and how the navigation will be structured. We ensure that labeling is adequate and coherent, map content inventory, and group similar elements. Then we organise and map relationships between information. This is the backbone of our product.

Business systems can have complex structures both vertically and horizontally. Clear information architecture allows users to find the right content quickly and without distractions. It can be tailored for different roles and include limited access to specific system sections. Remember that content and functionalities will grow, so information architecture should be easily scalable, especially when we create a Minimum Viable Product (MVP).

Why do we do it? 

  • to create a clear hierarchy of elements
  • to categorise groups of similar elements
  • to map structure
  • to discuss labels for categories
  • to have an overview of the scope
  • to understand the complexity of the system

Discovery Sprint Deliverables - EDISONDA

Roles and descriptions

This is the list of different roles, privileges, and access rights. It helps us to understand which part of the system will be accessible to which groups. We can personalise dashboards, processes, functions, and navigation for each role based on the list.

Usually, roles are organised hierarchically, which allows us to meet security requirements in the system – for example, users can only create roles that have the same or lower rank in the system. Some roles are “super-users” who can do almost everything, while others have a “view-only” level. We can distinguish roles that require an account from the ones that don’t. Our systems can be flexible, but it’s crucial to consider the role structure before developers create databases because it can take a lot of time and effort to reorganise it later.

Why do we do it?

  • to make sure that the right people see the right information
  • to block access for parts of the system that shouldn’t be seen by „standard” users
  • for data security
  • to not distract users with irrelevant content and functions
  • to help users navigate through processes

How will it work?

User flow

To estimate the time and effort needed to implement the target solution, we map the screens required to make the whole process work. We can see how many screens we need and in what order they should be designed.

We start with a flowchart that shows users’ decision-making process and steps for completing tasks in different use cases. Then we list screens and arrange them into a diagram that visualises connections between them. It describes key information or feature that users see on each screen and how it impacts their decision-making process through the product. Based on the flow, we can understand different use cases and see how they fit into the solution.

Why do we do it?

  • to see flow patterns
  • to have an overview of the scope
  • to understand the structure of the application
  • to understand the steps and their order
  • to make sure that process is complete and optimal
  • to mark relations between screens and modules to see possible passages


Based on all previous materials, we can propose what the final solution could look like. This is the visualisation of the application – typically 5 designs of the key screens. We present the most important views to help everyone understand the whole idea. We won’t dive into many details yet, but it’s a perfect foundation for initial validation and further development. The main goal is to support the narrative, so it should contain actual content to mimic the usage context as much as possible.

A concept can be done even with simple paper and pencil, but as a picture is worth a thousand words, we recommend taking advantage of a dedicated Design System. If you already have one, we can use it. If not, we use our internal library of components, which can be a baseline for building a consistent interface in the future.

The Design System allows us to use UI elements as bricks, follow specific guidelines, and show all system views instantly with their look and feel. It makes preparing high-fidelity mock-ups much quicker, and the new system is instantly consistent with other solutions to fit the whole ecosystem. A fully developed design system also contains code snippets for developers, which makes it easier to implement and saves a lot of time and money.

Why do we do it?

  • to agree on the content
  • to see the structure
  • to show to stakeholders
  • to present the app’s value
  • to make ideas easier to explain
  • to see how it works all together
  • to conduct the first validation of an idea

Executive summary

At the end of the process, we highlight key insights from our Discovery Sprint and make a compact presentation. It will help you spread your idea further, invite people to find out more, and get the necessary acceptance.

Based on all materials, it will be easier to estimate the time, effort, and cost of implementation. We recommend validating the product idea with potential clients before the development is started. Testing can include structured exploratory research or even informal conversations and feedback-collecting discussions. Our researchers can also help you gather feedback after the sprint to ensure that the target solution will serve its goal and fulfill both the needs of your end users and the organisation.


Want to find out more about the benefits of the Discovery Sprint?

    Do you wish to receive the latest information related to the topics of business and innovation design, as well as information about Edisonda's activities, projects, and offers?

    Please select the channel through which we can contact you (consent is voluntary):

    Information provided in the form will be used only in order to reach back to you. Contents of the correspondence might be archived. More details could be found in our privacy policy.

    Michał Madura
    Senior Business Design Consultant

    +48505016712 +48505016712