Johanna LozanoWhen building a complex new product, US companies need to trust their nearshore partner to facilitate a discovery phase in which the goal is to literally discover the project’s requirements. At this point of any software development project, there are a lot of questions to answer in order to estimate how much time, money and effort it will require. Some of the most frequent questions for the product owner are: Who is going to use this application? What are the most important functionalities? How are we going to monetize it? The list goes on.
The principles of a good discovery phase were covered in a recent blog post I wrote, and I have summarized them here for you.
In order to clear these concerns, in the nearshore software development company where I work, we find it good practice to hold sessions in which we bring together professionals from different areas, such as development, design, product management, marketing, and so on. During these sessions, this multidisciplinary team defines a baseline for building a product that meets everyone’s expectations, from the client to the user. We have a lot of experience running discovery phases: in some cases, clients have come to our offices, in other cases we’ve traveled to the clients’ HQs.
Our Approach to Product Discovery
We started calling this process the “product discovery phase”, since it has as a main goal: discovering of the app we are going to create. It’s a moment prior to the development process based on the questions I mentioned before. Through different activities with the client, the development team will look for answers and start to visualize the product they are going to build. They do so by focusing on the outcome of the development process; those mid-term results that are not seen immediately after the discovery phase, but that will follow the app’s launch such as impact, value, ROI, profit, and so on.
For that, it’s important that everyone involved understands the importance of prioritization, to identify which set of functionalities should be developed first in order to maximize the outcome. Having all kinds of roles present during this process allows the team to gain different perspectives.
Product discovery can last between a couple of days and a couple of weeks. There’s no magic recipe; each app, idea and team are unique and the process should be adaptable to fit their needs at the time.
The following steps are used at UruIT for discovery sessions:
1. Uncover the purpose
This first activity is focused on the “why”. As we start the discovery phase, we wonder what the project’s ultimate goal is. We cannot build a great product if we do not know why we are building it in the first place. By understanding everyone’s expectations, we uncover the motivations and the context necessary to make focused decisions while executing the project.
Suggested activity: A simple, yet effective activity to facilitate this discussion is to hand over post-its to the discovery participants and ask them to put into words why we are here, at this moment, discovering this product.
2. Business Overview
The following step is to discuss the app’s business model and understand the company behind it. For me, it’s a fundamental moment to comprehend how this app idea came along, what the company is like and how this product will help the business grow.
Suggested activity: At this stage I like to list a set of questions about the company, product, competitors, business idea, and so on, and answer them together with the team. It’s important that everyone participate so that no questions about why this app should exist are left unanswered.
3. Define metrics
The primary question of this third step is how to measure the success of the product once its developed. By setting a timeline, the idea is to identify milestones and criteria for assessing the product’s success. Goal-setting methodologies such as OKRs are great options for deepening the discussion.
Suggested activity: an easy way to orient the talk is by asking “Where do we want to be in…?” and highlight time milestones (such as “in three months”, “a year from now”, “in 5 years”), so we can set goals for each.
4. Lay out the constraints
At this stage, the conversation becomes more realistic. We all know there’s no such thing as unlimited resources. In fact, each project I’ve been in has its limitations, such as a restricted investment or a hard launch date. That’s why we believe it’s important to know which constraints are the most important ones and with which ones we can be more flexible.
Suggested activity: A very visual and fluid way for getting this discussion started is by having scales for each aspect within the project (time, quality, budget, scope, and so on), so the team can define how important they are and identify possible trade-offs.
5. Identify risks
Following through, our goal here is to identify risks that are worth worrying about, so we can focus on those other than the ones that are out of our hands. As important as listing the things that could go wrong in the project is recognizing that we can handle some risks, but not all of them. For example, you cannot really do much to prevent the laws related to your business from changing. However, there are a lot of aspects of product development that we can control. At this point, it is important not only to identify the risks, but also brainstorm possible solutions or workarounds for each.
Suggested activity: A funny way to identify risks is by drawing a zombie and asking, “What keeps us up at night?”. All the team participates, chipping in with concerns and ideas to prevent them.
6. Comprehend users’ needs
Questions at this step are related to the app’s final users. Who are they? By chatting about our ideal user and what this person is like, we can list how we imagine he or she will interact with the software. This process is a great instance for the team to propose a user interface (UI) that would be suitable for those users. Besides the visual aspects of the product, it’s important to make sure that the user experience within the app is the best it can be. The idea, either its code or design, could be awesome and very well built, but none of this will matter if the product does not fulfil users’ needs.
Suggested activity: Having a UX Designer at this stage is vital. Some of the UX activities I recommend for this step are creating an empathy map and/or drawing user personas to gain more insights.
7. Process and working agreements
Now it’s time to define how the software development process flow will work. At this stage the team can agree on a work methodology (hopefully an agile one), schedule checkpoints and other meetings, set responsibilities and working agreements to make sure everything is clear and ready for getting started.
Suggested activity: Creating a first draft of the Definition of Ready and Definition of Done is a good idea.
8. Build a story map
The story mapping technique introduced by Jeff Patton is a clear way to view the entire user journey the app offers. To do so, the team creates a grid of user stories which are laid out under headings that represent the workflow through the product. At the end of the day, the story map becomes a visual representation of the product backlog and it can also give a sense of the project size.
Suggested activity: Learn more on the story mapping technique here!
These 8 steps are core to any discovery phase we run at UruIT, but there are other activities you can add to keep discussing other aspects of the project, such as:
- Aesthetics alignment
- Architectural discussion
- Choosing tools
- Mapping out the first sprint
- Retrospective meeting at the end of the Discovery
After setting goals and deciding which activities your discovery phase will be focused on, it’s time to organize all of it in a schedule, considering the activities for each day. We, for example, like to arrange our plans for the discovery week in a Trello that looks something like this:
In a nutshell, product discovery is a nice opportunity for the team to frame the problem the app should solve, explore different ways of building it, and get everyone aligned with the project’s roadmap. It’s built collaboratively, which boosts its chances of success, in my opinion.
Hope you found this useful and I wish you a happy discovery!
Add comment