Unlocking Success with Digital Product Discovery

Has anyone ever told you that you’re ‘overthinking’ something? Or by contrast, have you ever navigated a vague situation in work or life and were desperate for clarity, certainty? 

If you’ve ever overthought anything or been accused of over thinking, obsessing, analyzing prodding, or diving deeper into any subject matter, from a piece of dust to geopolitical points of interest then welcome to  Digital Product Discovery. A place where obsession is welcome and even encouraged and where problems, possible solutions and predicted outcomes find themselves prioritized.  

This post will explore what this key part of defining your product’s strategy is, and more importantly how to do it successfully. We’ll start with a short Freshman class for newbies, or a refresher for seasoned product people and evolve into more nuanced advice and analysis of phases and processes in the following order: 

What is Product Discovery? 

Back to basics 

In the software development industry, it’s 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 dev team will get from this product discovery 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.

Digital Product Discovery 101

The Product Discovery phase seeks to minimize uncertainty around a problem and reduce variables concerning an idea to ensure that the exact right product is built for the exact right audience. It’s the bullseye on the dartboard. It provides teams with the assurance that they are investing time, energy, talent and resources in the right place and creates the foundation from which successful implementations and launches are made. 

It’s the moment prior to the development process where together with the client we explore questions such as: What is the product? What is the main goal of the product? What purpose does the product serve? Who is the target audience? How will they interact with the product? How can we make it usable? How can we profit from it? What are the functionalities? What are the foreseen challenges? Is there a roadmap? Are there other considerations to keep in mind? And so on and so forth. 

Product Teams work within this problem space, or by extension in the solution space, either still trying to understand a problem’s existence, relevance, depth and breadth or alternatively focused on executing a solution. As a Product Team, this is the sphere that you work within so you know it well. As a user focused company, you are constantly gathering feedback and disseminating valuable customer insights as quickly as possible, informing your work and leading to new revelations in user needs. 

If you’re familiar with Dual-Track Agile then you may have a visual in your mind of two parallel roads or lines that represent the duality of agile principles and iterative improvements. But our experience is much more of a Jackson Pollock painting than a geometric image from grade school. Delivery and Discovery need to, should and do overlap and intersect and both are ongoing. The players involved? Everyone.

We recommend an inclusive, collaborative space though the degree to which each stakeholder will be involved will vary and depends on the company and project size and the way you involve various teams and individuals. It’s best to clearly communicate who needs to be involved from the onset to create rhythms early on. 

Ultimately, the number of people you need during your discovery depends on the size of your company but you should always be certain about the participation of Product, Design and Engineering teams so that everyone understands the various levels of involvement and how these will ebb and flow throughout the duration of any Digital Product Discovery.  

There are many benefits in involving teams across departments that impact the sharing of outcomes and insights from research and validation processes, the maintenance of balance, the equitable distribution of ownership, the pace and the maximization of expertise. 

Product Discovery Phase 

Know your priorities 

The Product Discovery phase is critical to enabling us to better focus on the outcome of the development process. It means that at the end of the activity, we should and will have a better sense of what is the LEAST we could do in terms of effort, resources and time to market that could also enable us to obtain the MOST out of the product.  

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 this agile discovery process and can be measured either quantitatively or qualitatively. This includes impact, value, change, ROI, profits, etc.

It’s important that everyone on the Agile team fully grasp the concept and meaning of “prioritization”; being able to identify which set of functionalities should be developed first in order to maximize the outcome. 

A Product Discovery phase can last anywhere between a couple of days to weeks. At Uruit, we let the tried-and-true activities that have the most value lead the way. Here’s how we do it, by: 

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’ve 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.

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?

Identifying 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’s 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!

Understanding constraints 

As in all projects, there is no such thing as unlimited resources. For some projects, it’s all about money. For others, it’s all about the launch date. So, it’s 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 devs 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.

Ranking 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’ve 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.

Taking users into account 

The next step is understanding 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 Product 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 Product 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.

Working agreements 

Next it’s 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.

Build 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.

Process and Progress 

Participation and planning 

We talked earlier about the importance of approaching Alignment, Research, and Ideation in the spirit of collaboration and inviting clients, team members across disciplines and various stakeholders in, but there also has to be enough lead time to make sure that participation happens. Blocking calendars early on is essential as is communicating expectations.

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 about the problem you are dealing with.

Remember that setting up interviews with participants can take weeks and collecting results of quantitative experiments that provide useful data and not just anecdotal one off’s also takes time. It’s well worth it to be thoughtful from the beginning and anticipate steps, needs and even setbacks. Broad participation will enhance the perspectives, process and results so make a point to make a timeline early and stick to it. 

Adding more steps according to the needs

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’s 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.

Envision a two month or even six-week window as a starting point for your timeline. This would involve thoughtful execution of scheduling, gathering information and creating the right opportunities for stakeholders and teams to review and evaluate insights. This fosters an inclusive and participatory clarity concerning timeline and actual progress and measures the depth of insight versus checking-off task lists. 

Provide an honest account of where things stand and always prepare those involved to make decisions and move the needle. This way, you’re creating transparency and clarity about the actual progress of Product Discovery, which should not be measured by the number of completed activities, but by the number of insights revealed and decisions made. 

Parting wisdom 

Wrap up

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

Would you be interested in learning more about our Product Discovery phase? Get to know more about this service we offer, and feel free to contact us too.

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.

Onward to development 

You’ve asked the questions from different angles and in various forms, have involved stakeholders and gathered user feedback, you’ve planned well so that wide participation was possible and executed the many phases with thoughtfulness, precision and depth. Be sure to remain curious; always finding ways to improve whether in timeline or content or execution. Move on to Product Development with confidence and the clarity in knowing that this is the exact right product for the exact right user. Bullseye.