Discovering Your Product Before Jumping Into Development

Julia Macalaster

While this article is written with a focus on startup founders building out their MVP, the Discovery Process is useful for all teams looking to build new products or feature sets. The process will help you to gain clarity around project goals, assumptions, and risks and align your team around the shared vision for the product or new feature set.

At Def Method, we work with a lot of companies looking to build out their MVP. To kick off this process, we encourage founders to go through what we call a Discovery Process. During this deep-dive workshop that lasts two to five days, the Def Method team collaborates with you to clearly outline what you’re building and how you’re building it. Through a series of intensive exercises and product design/prioritization, we help to align the team on product goals and scope.

STEP 1: Understanding the Product and Addressing Assumptions  

Goals Risks and Assumptions:

One of the main risks of building out an MVP as a startup is the assumed alignment of the founding team. Yes, you may be speaking with your team on a daily basis, but if I asked you today what your primary goal is, would all team members have the same answer? How about if I asked all of the team members how they would prioritize feature development? Would everyone agree?

Assumptions about alignment can slow MVP development and get a founding team tripped up as they construct their vision for the company. Investing the time in sitting in a room together and fleshing out these assumptions is always worthwhile and will pay off in dividends through streamlined product development and clear, shared company goals

We kick off every Discovery Process by unearthing assumptions and finding agreement and alignment among the team. This first exercise starts as a conversation with the group with one person taking collective notes on the whiteboard. It is imperative during this time that everyone has the opportunity to voice their own opinions and thoughts. We start by asking the following questions:

  • What are your goals for the company?
  • Where do we hope the company to be six months from now? One year from now? Three years from now?
  • What are the key risks for your company?
  • What are the main assumptions you’re making?

We then end this exercise by asking, “What is your one primary goal for the MVP?” Typically when speaking about the company goals, several different statements will be written on the board. We ask this question so that the team has a true north. Yes, ruling the world may be your ultimate goal, but what’s your primary goal for the MVP?

Does | Does Not | Is | Is Not:

Once we’ve clearly outlined our goals, risks, and assumptions for the project overall, we start talking about how we will define our product. To do this, we use an agile exercise called Does, Does Not, Is, Is Not. This exercise is pretty simple:

  • Start by drawing a four-square grid on the whiteboard.
  • Hand out small square sticky notes and a Sharpie pen to each team member (we ask that team members use Sharpie pens to cut down on the amount of words they can use and to make the stickies legible to everyone in the room once they are placed on the whiteboard).
  • Starting with Does | Does Not, set the timer for five minutes and ask participants to write down what, in their mind, this product will do, and what it will not do, focusing on the MVP.
  • When time is up, go around the room and have each team member place their sticky notes on the grid drawn on the whiteboard and review their thought process for what they wrote. Make sure to talk through any discrepancies in opinion.
  • Repeat this process for Is | Is Not

The goal of this exercise is two-fold. First, it gives the engineering and product team a better sense of the product the owners are looking to build. Second, it fleshes out any remaining assumptions about what the MVP will and will not include.

At this point, we’ve successfully completed the first step of understanding the product and addressing assumptions. This step is critical because there is no sense talking about the directions if you don’t have a clear destination in mind. Now that we know the destination, we can start to map out the best way to get there.

STEP 2: Understanding the Product

Now that we have our destination in mind, we can start to map out how we plan to get there. The next stage of the Discovery Process is focused on understanding the product in greater depth and initiating the conversation about prioritization.

Draw the Map:

Drawing the customer journey map helps the team visualize the various aspects of the MVP and highlight areas that may be missing. In order to draw the user journey map, you will want a long whiteboard, typically one that takes up the whole wall.

To start, the team will outline the main user personas for the application. These typically shake out to be something like: user1, user1, admin. For example, if you are creating a marketplace that connects buyers and sellers, your user personas would be: buyer, seller, admin. These user personas will be written on the whiteboard in circles on the far left-hand side of the board.

Next, we will start to draw the map starting with the top user persona. What was that primary goal we outlined at the beginning of this process? What will the user have to do in order for you to hit that primary goal? Starting with this in mind, start to think about the customer journey. Pages should be drawn as squares, and along each step you should outline the action the user will have to take to get to the next page.

Once you have the map drawn out, take a step back. Did you remember everything? Is the map missing anything? The wonderful thing about whiteboards is that they can be erased! Don’t be beholden to your original design. Typically, user journey maps take a couple tries before they are correct, so get comfortable erasing and re-drawing.

Prioritize the Workflows:

Now that we have our user journey map drawn, we can start thinking about the workflows that will be included in our MVP. Workflows are similar to epics in “agile speak”, in the sense that they are a bigger collection of features/user stories.

For this exercise you will need a flipchart or smaller whiteboard.

As a team, start to break down the MVP into individual workflows and write the workflows on the whiteboard. We typically like to walk through the workflows from an end user standpoint. For example, “As a user I would like to be able to sign up for an account”. You should try to keep the number of workflows listed to less than fifteen for an MVP.

Once you’ve listed out the workflows, the team will vote on how to prioritize them based on a system that takes into account the user, the company, and the technical feasibility. The scale goes as follows:

  • Value to the end user: 1-5 with 1 being the least value and 5 being the most value
  • Value to the company: 1-5 with 1 being the least value and 5 being the most value
  • Technical feasibility: 1-5 with 1 being the most technically difficult and 5 being the least technically difficult

The team will walk through the stories together and each person individually casts a vote. If the votes from participants are different, you will have a quick conversation about why and then the decider will determine what to rate that story as. Once all votes are determined in each category, the totals are summed for each workflow.

Now you have a pretty clear picture of which workflows are highest priority and which ones are lowest. Have a conversation as a team about how this prioritization shook out and then categorize each workflow as being P1, P2, or P2 (priority one, priority two, priority three). This prioritized workflow list will prove to be invaluable as you begin product development.

In this second step, you clearly outline the MVP and align the team on product prioritization.

STEP 3: Think Creatively and Test Assumptions

The next step varies depending on the stage of your project. If you and your team have already worked with a designer and have user tested product designs, we will take this time to break down the product into user stories and outline development prioritization. If your team is just getting started out, we will take this time to focus on outlining the product design, building out rough prototype designs and testing those designs with the end user.

Overall, this time is for thinking creatively about the MVP we plan to build and outlining a plan for the next steps in terms of product development. During this time, the team should test some of the assumptions made about the product by performing user testing.


By the end of the Product Discovery, you and your team should be aligned on goals, have assumptions tested, and have a clear roadmap for how you will get there. While the process can be exhausting, the team comes out the other end more informed on how to successfully build out the MVP.

For more information on the Product Discovery and how to work with Def Method, feel free to contact!

Read Next Article -->