A
telephone blueprint

Why Discovery Phase Matters, And How It Can Help You Build Better Blockchain Products?

You have an idea that you want to turn into a product, but at the same time thousands of questions:

  • What should I do first? 
  • How can I estimate the time and resources that I need for product development?
  • How can I make sure that I am not the only one to care about this and that it will solve an actual problem?
  • What is the most important part that I should focus on first? 
  • Even though the actual problem exists, do customers care about it and will they hire your product to solve it? 

There are a lot of questions you have to answer in order to start with product development, and in this article (it’s long and useful – you have been warned!) we will cover how you should address these questions and how the discovery phase can help you make every detail clear and well-defined.

What is The Discovery Phase? 

The Discovery phase is a link between the idea about the product you have and the realization of that idea into an actual product in the user’s hands. 

The Discovery phase is a part of a product development process that focuses on collecting and analyzing information about a problem, product, stakeholders, target markets, and competition. It ensures the building phase can run smoothly, and the risks of any impediments and misalignment are reduced to a minimum. Once you finish with it, you ensure that the features are well-scoped, prioritized, and technical aspects are recognized and taken into account.

When it comes to the time needed for this phase, it usually takes from 2 to 8 weeks. The time needed depends on the scope of the project, unknown variables, already collected information, etc.

What is The Purpose of The Discovery Phase 

1. Minimize risks 

The purpose of the discovery phase is to clearly understand and define risks that may occur, predict obstacles and dependencies that exist by creating a well-rounded plan for building the product. This way, you are minimizing the potential adverse situations during the building phase.

2. Stakeholders vision alignment 

Lack of a shared vision between stakeholders should come out during the discovery phase and be refined until there is a joint alignment. Making sure this happens early, before the building of the product starts, enables you to avoid a lot of problems that would occur if those misunderstandings come out later on, during the build phase.

3. Reduce costs

Organizing the discovery phase and postponing the start of product building (development) may look like a waste of precious time and money, especially in a situation when those resources are limited. However, Discovery Phase ends up being an investment as it reduces the costs and minimizes the risk during the project when changing and navigating back to the right course will cost significantly more time and money.

Roles 

The most important role when it comes to discovery phase participations:

Keep the team involved. That is the best way to ensure benefit from each team member’s expertise. Otherwise, if they are not aware of the project background, they may not be able to contribute fully.  

The three roles that are necessary to run this phase are: 

Man riding a purple rocket
  • Product manager 

Someone who will lead the full discovery, the one who will ensure that progress is made and the entire team is moving toward the defined goals. 

The one accountable for the full product, hence, for this phase as well.

Illustration of a girl holding a giant pen
  • Product Designer 

Someone who can put himself in the customers’ shoes and challenge each step from a customer’s perspective, asking questions such as: “Why should I care? What can that product do for me?”. 

The one responsible for Low-fidelity design and user testing.

Illustration of a man writing on the laptop with red background
  • Engineer(s)  

Make sure that all needed information from the technical side is gathered and clarified, so there are no significant impediments that may threaten product development. 

The one responsible for Technical Architecture and Specification 

The others are welcome as well, especially the experts that can consult the team on different topics during the whole phase. 

Discovery Phase Steps

There are numerous ways how you can organize and run your discovery phase; essential parts are the same, while others can differentiate from case to case. Building a new feature for a current product, a new product for the existing customers, a new product without a current market, etc. 

In any case, the following steps should be taken as a part of the discovery phase, but you don’t need to follow this order blinding, so be free to adapt it to your needs. 

We will talk about WHY and WHAT you should do. The last part – HOW is somewhat covered, but it leaves you with proposals and space to find an optimal way of doing things that suits you the best.

1. Map Stakeholders 

The common practice is to start with WHY, but there’s something you may do before that. To prepare and set up the base for upcoming steps, you should be aware of your resources. So, define clearly who are your stakeholders and who are your team members.

To have a better perspective you should create a RACI matrix that will help you consult and include the right people to right meetings, decision-making processes, and conversations. 

You have to be sure that you understand each stakeholder’s role, the influence they have, and their perspective. Another tool that may help you is the Stakeholders Matrix.

Use the list of stakeholders and separate them in one of three categories according to the impact they have and in one of three categories according to the influence they have. Once you do that, cross those groups and make the following matrix: 

Stakeholders Matrix
Stakeholders Matrix
  • Monitor
    • Keep them updated about your progress, what and why you are doing. 
    • Ask them about changes in their world and their predictions, and note how it may influence your product.
  • Maintain Confidence 
    • Ensure they understand milestones, and report on the progress you are making to achieve those milestones.
    • Be sure you are aligned on the Roadmap and keep asking them about insights they have that might modify that Roadmap and general strategy.
  • Keep informed 
    • Inform them regularly on updates on the strategy and Roadmap.
    • Make sure they are aligned and working to support your plan.
  • Collaborate
    • Work day-to-day with them on creating new ideas and executing current ones.

Keep your stakeholders updated and informed during the discovery phase, be transparent to each of them, and make sure that everyone is aware and informed of the progress and decisions that are made. Don’t forget to measure their satisfaction and think about different ways of communication (or new channels) that will be suitable for each of the previously mentioned groups.

2. Define Problem

No matter how good you think your idea is, you have to agree that it’s based on your opinions, not on the facts. So you should look at your idea as a set of hypotheses that have to be validated before you start building it. But even before setting up the assumptions, you should gather the facts. 

If you set the hypothesis right away, the process of gathering the facts will be limited by the perspective of that hypothesis, and you’ll only use the facts to understand whether you are right or wrong. You’ll be getting YES or NO answers. So we do not want to look through the prism of our assumptions and manipulate the facts by connecting them in units logical to our assumptions.

So here you should try to focus on the problem space. After you understand what are the existing problems, make sure that you ask enough questions and with them clearly define and divide what is and what is not the problem you want to solve, you can move to the next step.

3. Market  

This is necessary to understand whether there is an actual problem you are looking to solve, but it is equally important to define the market you are a part of. Just to be sure that there is potential for your idea. Analyze following market aspects:

  • Size – Maximum number of potential customers 
  • Value – Number of potential customers multiplied by the average amount they spend yearly or the total value of all products and services sold within a year.
  • Trends – Factors and moves that have affected a specific market, and ones that may impact on the market and your product in the future.  
  • Growth – Rise in sales or size of a particular market over a period of time.

For analyzing the market, you may use PESTEL analysis and Porter’s Five Forces.

4. Set Hypothesis

Now when you have an understanding of a problem you are solving, and you gathered all the facts, it is time to form a hypothesis (assumptions).

Your goal is to based on the problem and facts you gathered, propose a solution defined through a hypothesis. 

Be open-minded. We have learned that it is not good to be wrong, to fail, but in product development, it is definitely good, and in most cases, it is impossible to be right upfront. We want to test our assumptions, validate them, and modify based on the insights and information we collect. 

Defining the hypothesis always comes with analyzing the risk that comes with each of them. So, to be prepared, and act proactively, invest some time in risk management. You can do that, by:

  1. Analyzing potential risks related to each hypothesis.

Just think about what may go wrong. What can happen and have an impact on the hypothesis you defined.  

  1. Measuring the probability of occurrence of a risky event.

The way to go is to present probability by separating each risky event within one of three categories: low, medium, and high. This you can do by empirical data – how often does the problem occur?

  1. Measuring the impact that risky event may have on your product.

What would happen if this risky event occurred, how much impact would it have on the product? Here you should separate each risky event in previously mentioned categories: low, medium, and high impact.

Now when you have risky events defined and placed into impact and probability categories, you can form the following matrix:

Risk matrix, probability vs impact

Once you created the matrix and mapped all risks, you can proceed to and decide whether you want to act proactively by reducing the risk (you should do that for upper right events) or maybe just accepting the risk (that you may do for lower left events). 

Keep this matrix updated and try to be as proactive as possible.

When you bridge the gap between the problem and solution space with those assumptions, the next step is to ask yourself – Who will care about this?

5. Define User personas and JTBD

To understand who you are solving problems for, you should use both personas and JBDT methods. They may be somewhat mutually exclusive, but there is a benefit if you try to map your target customers via user stories and explain their behavior and broader context through jobs to be done. 

For the start, it is essential to determine the two most important customer target groups: primary and secondary ones. Later on, you’ll have time to refine them as you collect more and more information.

While defining your personas, you will be using the JTBD method to understand “What job would consumers want to hire a product for?”

In case you are not familiar with jobs to be done or user stories, below are their common formats:

User stories JTBD

For collecting all the needed information, you may consider organizing interviews and surveys. While going with a survey is a good option, as you may reach a more significant number of people, the interviews are a preferable option. It is the way you will capture users’ feelings, behaviors, beliefs, and other emotional aspects that you want to focus on.

In the meantime, while you are speaking and gathering information about your target groups, you should be validating your hypothesis and adapting them based on your newly collected insights. 

6.  Focus on Competition

We mentioned customers, other stakeholders, and the team, but someone who you must not forget are competitors. You will identify and analyze your competitors, the way they are trying to solve similar problems and strengths and weaknesses of their solutions. By doing so, you will better understand the opportunities for your product and what to focus on. Also, you may analyze how customers are reacting to solutions that currently exist, especially to the ones similar to yours.

Ask yourself: Why would they move from existing products and start using mine?

Once again, based on all insight, keep validating, and adapting your hypothesis. 

7. Define Minimum Viable Product

When you have a refined and validated idea, it is time to bring down all the product functionalities (features) to epics and user stories. Only this way, you’ll make sure that there is a common understanding of product requirements between all stakeholders and especially between team members

Here we are introducing the concept of building a minimum viable product. MVP is a product with a minimum amount of features to satisfy users’ core needs, the functionalities that bring the most value to customers. Hence, you will be able to develop it faster than an entire product, receive feedback from the user earlier, and act upon that by adapting our product. 

The benefits are clear; you are saving precious time and money and ensuring that market feedback is coming in early phases of product development, which gives you enough time to act and make the product customers will love. 

So, it’s clear why you need to define what MVP is and why you need to list the essential features of the product, the ones without which the outcome would not have desirable usability. For this step, you may use the MoSCoW method.

While defining and prioritizing the features, you have to take into consideration two parameters, value each feature brings to the users and time needed for its development. 

After you define features, split them into user stories, estimate effort needs for development each of them as well as values to the user they bring, you may start with prioritization by putting each user story in one of following columns:

Moscow method

Congratulations, now you have a scope of your MVP, but there is still a job left to refine each of these features.

8. Document requirements 

You worked hard to come up with a list of features (MVP) that enables you to define the scope and helps you to make sure that all stakeholders are on the same page, and there are no misunderstandings between you. 

Although it is somewhat definition of the scope and a source of the requirements, the list of prioritized user stories may not be the right level of details that you want to have in your documentation. You want to take a step further and refine each of the user stories by describing its acceptance criteria with the Gherkin scenario.

Gherkin scenario

This way, we’ll not only make sure that the alignment between stakeholders is set but between the team members as well. 

This step is an additional effort that may not be undertaken in the discovery phase, but there are great benefits if you decide to go with it. It will help you and your team to reduce the risk to the minimum even before the building phase by identifying even the smallest impediments. 

Also, it will make future communications easier, as all team members will have a single source for all product’s requirements, and you won’t be required to answer numerous times on each of their questions.

Write down refined user stories in the Product Specification document, and don’t forget to share it with stakeholders. 

9. Architecture & Tech stack 

In parallel with refining the product specification, the engineering part of the team will actively work on researching and discovering potential technical solutions for supporting product development. 

Engineers have to have in mind what are the options for your technical stack and what is the best way to go, taking into account all the nonfunctional requirements such as scalability, security, maintainability, usability, etc.

We won’t go into detail here as we have already underlined the importance of engineers’ role in the product discovery phase. 

The outcome of these processes should be Architecture & Technology Stack based on both functional and nonfunctional requirements.

P.S. Make sure that you covered and analyzed all risky assumptions related to the technology.

10. User flow & lo-fi design

Based on the project requirement and refined user stories, you can start with the development of user flows that are necessary input for creating the lo-fi design. 

User flow represents the visualized path of the user’s steps from the moment he starts interacting with a product by taking a series of actions to achieving the goal.

Hand drawing user flows

You already have information about your potential users and what problems they are looking for (what goals they want to achieve). On the other hand, you have a detailed list of functionalities users may take to solve that problem. The only thing left to do is connect those dots and come up with the user flows.

Once you developed all the user flows and made sure that you covered the majority of the steps that users will take on the way of achieving the goals, you may move to the low fidelity design. 

Fidelity, in this case, refers to the level of details covered in the design. Therefore lo-fi design includes a low level of details that are presented based on the previously defined user flows.

The goal is to come up with a proposal that can be used for validation and receiving feedback from the stakeholders as early as possible. Based on that feedback, you can quickly redesign, re-write, re-do elements of design.

11. User testing

It looks like the idea you have is refined and polished and ready for conceptualizations. But, before you move to product specifications, there is one more crucial step – actual user solution validation.

It’s right, you already had to talk to users, but that was for the sake of understanding their problems and challenges they are facing. This time you’ll come to them with an idea, solution to their problems, and validate if it benefits them and if they will hire your product to do the job for them.  The goal is to get feedback from the customer about the solution you have. 

12. Estimation & Roadmap 

A roadmap visually presents the path that you want to follow by specifying activities (steps) and their timeline. It ensures that you are all aligned around the same idea as well as presents a perfect tool for iterating and communicating with team members and other stakeholders as well. Roadmap adds a level of transparency and allows anyone to have insight into your plans and keep them notified about changes you may take along the path you want to follow.

Roadmap for software development

As soon as you start with the development, you will start also updating the roadmap continuously. That will help you with providing refined estimates.

There are some steps we may have skipped, but they can precede the above steps. Before you define a problem and solution and start working on it, you have to understand your company’s goals. Most of the goals will fall into one of the following categories: revenue, growth, and customer satisfaction. We assume in most situations; startups focus on growth. Either way, your product strategy has to support your company goal. E.g., 

  • if the company goal is growth – building brand awareness, you may focus on user acquisition. 
  • If a company focuses on customer satisfaction, you should probably think of a feature that will increase the user’s engagement. We assume if customers are using a product longer, they are more satisfied with the overall experience, and that’s why they are spending more time using it. 
  • On the other hand, if revenue has to increase, think about how the company monetizes products, what possibilities exist there.

Outputs

Project Specifications 

Product Specification is your single source of truth for everything related to the project. Besides linking all the other documents, Project Specification contains a list of user stories representing the scope of the building product. Each user story should contain acceptance criteria defined through the Gherkin scenarios

It should be a live document, and it will change and adapt based on the new requirements and adaptations. But something always stays the same, the requirements, decisions, and conclusions noted in this document are a single source of the truth. 

Tech Architecture & stack

Primarily based on engineers’ research and opinion, but also in accordance with all team members, technical architecture and specifications will be developed. The Project specification document should explain WHY and WHAT is being built, while technical should focus on HOW to build it. While thinking of the best way how to support the implementation of your idea, you should have on mind, both functional and nonfunctional requirements.  

User flows & lo-fidelity design

Based on the project specification, you will develop a visualized path of the user’s steps and his actions to achieving his goal. Once you have that prepared (as explained above) you may proceed to low-fidelity design. It will help you to ensure that all stakeholders will have a much clearer understanding and expectation about the upcoming product. Also, it is an important input for the team when estimating the time needed for product development. 

RACI Matrix

RACI matrix helps to identify who are stakeholders and what are their responsibilities and roles. It also ensures each team member knows what is expected which leads to much easier communications.

RACI Matrix

Benefits

Before you rush to start with actual developing, even though if it may look as delaying the product development, go through the discovery phase as it will help you to:

  1. Consult with experts 

If you dedicate some time to researching and consulting on problem and solution space, you will allow yourself to hear and apply what you learned from exploring other ideas and expert advice. 

  1. Clear exception 

If you separate time and define product scope via a list of user stories, and in addition to that, develop the lo-fi design. You will be able to get a plausible timeline of the project that can be communicated internally and externally in external communication with stakeholders (customers and potential investors) by sharing clear and reliable expectations. Internally, you will decrease the possibility of undesirable changes and rescheduling while avoiding setting pressure on team members to come up with something faster, even though it is almost impossible. Each team member will know what they will work on and when.

  1. Increase credibility 

This one is related to the previous benefit. While you are setting and fulfilling expectations, you will gain credibility. Whether we are talking about potential investors or customers, they will look at you differently if you stick to your “promises” and justify the trust.

  1. Reduce risk and cost  

We have already talked about this. If you reduce risks and prevent undesirable changes and adaptations that affect additional efforts and resources wasted, you will save yourself a lot of money.

  1. Engage team timely  

If you invite team members to take part in product definitions and enable them to understand the idea background, they can propose better solutions, both technical and nontechnical once. Also, their creativity and motivation for later on building and developing something they had a chance to shape will be increased. 

  1. Understanding what users need

Instead of basing your ideas on your assumptions, you’ll get a chance to see what customers really want and need. 

7. Compatible with different development methods

The Discovery phase is equally important and applicable for any product development team, no matter which industry it comes from and whether it uses traditional waterfall product management or some agile methodology. It doesn’t limit your team’s way of work but helps them to get to the common ground and share the same vision and goals.

Why Isn’t This Phase Practiced By All IT Companies?

Even though the importance and usefulness of the discovery phase are apparent, there are plenty of IT companies that are not undertaking it, and there are a couple of reasons for that:

  • The illusion that it takes too much time/money that otherwise could be used for development. When you create a roadmap and place discovery phase, which takes e.g., a month, and after that, define that you’ll need three more months for building that product, plenty of people will immediately imagine how skipping discovery phase will lead to time and money savings. This reason is even more present in day to day work of development agencies that can have a hard time explaining to clients why they did not start with development already and why they have to pay for something whose results are not visible to them. 
  • We don’t like to be wrong. Imagine a situation when you came with a great idea, you separated money for its development, and you found a development partner. You approached that partner agency and even though you work out through the concept and product features, they are telling you that they have to take some time, analyze the problem space and come up with a conclusion. 

Conclude whether your idea is the best solution for that or you should adapt and change a bit. You may not be happy to pay someone who will come back and advise you to skip the idea and think of something else. 

But you should be satisfied and grateful that you saved time and money. Money that will otherwise be spent on product development and only then figure out that nobody needs the product you created and the assumptions you had were based solely on your perception of things, not on real facts. 

  • In most cases, the goal of outsourcing teams will be to get a job, find a client. One of the best selling points for them is lowering the price compared to competitors. The first thing you, as a development agency, will sacrifice is the discovery phase, as you only matter whether you delivered something that client wanted. But you are not interested if anyone will use it. These partnerships don’t last long, as well as products that are the outcome of that cooperation.

There are more reasons why this part of the product development process is usually skipped, as we may be excited to start working and building something; we are sure that we know everything about the clients and their needs. Or we have so much experience in this field that one month of activity can not be compared to our know-how. Well, in the end, some of those products may somewhat succeed, but even then, they can not last forever if they do not come back and undertake all the concepts of the discovery phase.

Conclusion

Congratulations! Besides the idea that you had at the beginning, you now have answers on all questions and you are ready for the next phase. Good luck with the building of your product and don’t forget that this is not a one time endeavor, hence come back to these steps each time you have a new idea/feature in your mind.

Know Blockchain Inside Out

Subscribe to MVP Workshop Newsletter

    Comments (0)

    Your email address will not be published. Required fields are marked *

    Your thoughts
    Name
    *Your email address will not be published.

    Interested in working with us?

    Let’s find the right solution for your blockchain ideas.

      Cancel icon

      Get free consultation

      Get in touch with us and we'll get back to you as soon as possible.

      Name

      Email

      Message


      Thanks for allowing cookies!

      We're using cookies and other tracking technologies to personalize your experience, analyze out website, and assist with our promotional and marketing efforts. See our Cookies Policy for more details and choose your preferences below.

      Use necessary cookies only
      Strictly necessary cookies

      Marketing Cookies

      Google Analytics
      AdWords Remarketing
      LinkedIn Insights
      Facebook Pixel
      Quora Pixel
      HubSpot
      Twitter

      Functionality Cookies

      Hot Jar
      CONTACT US