Helping Software Development with a Product Discovery Phase

Johanna Lozano, Uruit, https://uruit.com/

In the software development industry, it is really common that clients approach development agencies like ours with a product they want to create. However, sometimes these ideas involve a huge product or sometimes a smaller one, but it still has some undefined aspects; for example uncertainties about its potential users, its functionalities, monetization strategy, etc. which can make the estimation process difficult.

While still defining all of the elements of the desired product, we find it a good practice to bring together different roles to concretize and better the product idea before embarking on a whole project. A benefit that the client and software development team will get from this phase is that they can define a baseline with which they'll compare if the product is accomplishing everything that was expected of it from the beginning.

This article explains what the Product Discovery process is all about and why it is essential for a successful software development project.

What is a Product Discovery phase?

"Product Discovery" is the moment prior to the development process, in which we sit down together with the client to deliberate and discuss questions such as: What is the product? Which is the main goal of the product? Who is the target audience? How can we make it usable? How can we make money from it? What are the functionalities? Is there a roadmap? Are there any restrictions or considerations to keep in mind?

The Product Discovery Phase consists of various activities. Some of those that we are going to share here were taken from the book, The Agile Samurai, (we definitely recommend reading it!) and from a colleague Product Owner, Camila Gimenez.

Focusing on the outcome instead of the output

In product development, there are two important concepts: Output and Outcome. The output is everything that results from a development process: functionalities, requirements, mockups, prototypes, working software, etc. They are obtained almost instantly and some of them can be tangible (at least in a digital way).

On the other hand, the outcome can be considered as the mid-term results. They are not seen immediately after the end of the process and can be measured either quantitatively or qualitatively. This includes impact, value, change, ROI, profits, etc.

The Discovery phase is important, so we can focus better on the outcome of the development process. This means that at the end of the activity, we should have a better picture of what is the LEAST we could do that could also help obtain the MOST out of the product.

This is why it is important that everyone involved in the Agile team understand the importance of "prioritization"; being able to identify which set of functionalities should be developed first in order to maximize the outcome.

Understanding the problem and exploring solutions

A Product Discovery can last between a couple of days and a couple of weeks! At UruIT, we find it is just enough time to go through some activities we consider that have the most value. Here is how we do it:

1. Uncovering the purpose

The first activity we do with the team is ask ourselves "Why?" Have you ever been invited to a meeting but really don't get why are you there? What is the ultimate goal? Well, in this first step, the goal is to put into words all the assumptions of why we are there, learning about the product with the client, and what would be the ultimate goal of the development process. We cannot build a great product if we do not know why we are building it in the first place. Understanding the client's expectations will give us the context necessary to make all those smart decisions while executing the project.

The activity I have done the most during this step is simply handing over post-its to the client and its stakeholders, asking them to put into words why we are here, at this moment, discovering the product.

2. Business Overview

Then, the next activity we conduct is a discussion about the business model and getting some context from the business. A team could get together before the session and prepare a set of questions they consider important. However, the routine questions you ask when you are learning about a new business will also work, such as:

• What is the business model?
• How did they come up with the idea?
• What is the company's size?
• Who are their competitors?
• Who are their users?
• What should the app do exactly?
• Do they have a preferred technology?
• Where do they see the company in 3 months, 1 year and 5 years?

3. Defining some metrics

A next step is taking some time to define metrics that would help the team to measure the success of the developed product. The key question here is: "Where do we want to be in X amount of time". The idea is to identify possible milestones and criteria that could help assess the app's success.

The cool thing about this part is that after starting the project, these metrics can serve as an input for defining OKRs. "OKRs" stand for "Objectives and Key Results." it is a goal-setting tool used by teams to reach for their goals with measurable results. There are several tools on the market to set them with; we invite you to take a deeper look!

4. Laying out the constraints

As in all projects, there is no such thing as unlimited resources. For some projects, it is all about money. For others, it is all about the launch date. So, it is wise to know which of these is most important, and where there is some flexibility.

The client may have a time constraint because it needs the product to be launched at a conference in August, for example. We could also discuss the concept of quality, which functionalities are paramount and should have complete QA coverage (this will help the developers organize the workload once the project starts). Additionally, we should also discuss if there is a budget to mind; this will help the product owner in monitoring that budget cap each sprint and better prioritize the functionalities.

To do this part, you could play with some levers for each aspect within the project, and identify possible trade-offs.

5. Identifying the risks

There are a lot of things that could go wrong in a project. We can handle some of them, but not all. This exercise is about identifying the risks that are worth worrying about and ignoring those that aren't. You cannot really do much to prevent the laws related to your business from changing, for example, but maybe the client's availability is something you can solve. This is the chance the team has to put into words their worst nightmares before the project begins and ask for what they need to make it successful.

There are a lot of ways to carry out this activity. A funny one that I have used before is to draw a zombie and the question "What keeps us up at night?" on the board and then ask everyone to chip in with ideas. The other option, more formal but equally effective, is building a risk matrix, wherein you assess the impact and likelihood of each risk.

At this point, it is important not only to identify the risks, but also have a brainstorming phase with possible solutions or workarounds for each.

6. Taking the users into account

The next step is to understand who are the final users. What are their characteristics? What will they use the app for? Under what conditions will they use it? How is that interaction? Answering all these questions will help the team to propose a UI suitable for those users.

If you could invite a UX Designer to the Discovery session, that would be ideal. That way he or she could lead the session and sketch an empathy map or user persona to gain more insights.

Understanding the users and their needs is key to really know if a product can be a success. No matter how good the idea, code, design, or how happy the stakeholders are, it won't matter if the product is not used or if it does not solve a real problem. A Discovery Phase also means teaching a client about the importance of involving real users, either with tests, usage metrics, interviews, surveys, etc. This is the first moment where we raise the question of "How much do we know about our users?" and "How much remains for us to learn?" What is discovered here will affect the entire project (marketing, strategy, development), not just the UI.

7. Process and working agreements

Next it is time to define with the client how the software development process will be. Will the team follow Scrum? Then, we take some time to explain to the client how Scrum works; define the schedule for the daily and the ceremonies; explain the roles that will intervene in the team and what they do; discuss some working agreements, and if time allows, even create a first draft of the Definition of Ready and the Definition of Done.

8. Building a story map

Story mapping is a technique introduced by Jeff Patton. It provides us with a way to view the entire user journey of the app. In practical terms, it involves building a grid of user stories which are laid out under headings that represent the workflow moving through your product. This can be done over a series of conversations between team members. The main advantage is that it becomes a visual representation of the product backlog, aligning all the stakeholders in terms of scope and complexity. It also provides a sense of the project size.

You can find more extensive information on how to build one, but just to give you an idea, it looks something like this:

Once we start discussing the flow through the app with our client, it becomes something like this:

The interesting thing is that during the Discovery phase, it is possible to sketch everything for the first time, and then, start prioritizing the functionalities. We could create new "vertical lanes" and organize the stories according to each release; we can prioritize with the client which functionalities are relevant enough to go into the MVP and which ones should be considered for a future release.

Adding more steps according to the needs

All these steps are the ones we consider that are at the core of our Product Discovery, however, you could end up adding some other activities to discuss relevant definitions of the project such as:

• Aesthetics alignment: We ask the client to bring some web apps they like, if they have any particular preference for a UI or user interaction. It is possible to even start sketching some wireframes if there is enough time.
• Architectural discussion: Take some time to start defining and discussing the technological stack and the architecture.
• Choosing the project tools: will we need Jira or Clubhouse in the project? Do we need a new library? Or does the client have any specific request in terms of tools? You could define the tools with him, create the accounts and even start configuring them together if you have the time.
• Mapping out the first sprint: Once the story map is prioritized, start creating the first user stories and organize the first sprint with the team.

Hands-on

Once you have all the activities planned for your Discovery session, we suggest organizing the schedule, considering the activities for each day, taking pictures of the activities and documenting the results:

We encourage you to invite some users, managers, stakeholders, developers or designers. The more roles, the better! Having all types of roles during this session will help you identify different perspectives on the problem you are dealing with.

On the last day, do not forget to take some time to do a retrospective. A retrospective is an opportunity to learn and improve based on what you just did. All the team gets together to reflect on the Discovery session and can simply answer: What worked well? What didn't work well?

That way, everyone can share their opinion, and you can learn what to change, improve or maintain for future sessions.

Product Discovery in a nutshell

So, as we've seen, the Discovery has 3 goals:

• Framing the "problem"
• Exploring possible solutions
• Aligning ourselves as a team

We think that this phase brings a lot of value to the project. It allows us to envision the project roadmap and how we will reach the goal. As David Hussman once said: "Yet while the ability to deliver frequently is valuable, if you don't know where you are going, it is easy to iteratively not get there."

This article was originally published on https://blog.uruit.com/product-discovery-benefits/ is reproduced with permission from Uruit.

---

Related product management articles

How To Hire Scrum Product Owners

Five Rules for a Minimum Viable Product Strategy

More Agile Knowledge

Scrum Expert

Agile Tutorials and Videos

---

Click here to view the complete list of Methods & Tools articles

This article was published in September 2019