Published 20 Dec, 2021 6 minutes of reading
At Modyo, we always say that a product is born when it goes into production. This frame of mind is essential, because it kickstarts a permanent awareness of the importance of every process in the entire lifecycle of a product, particularly during development, starting with the Product Discovery stage.
The contents below serve as a quick guide to empower and familiarize agile teams with this process in their organizations, reduce uncertainty under a new digital framework, and get the most out of the discovery exercise.
1. Always keep the importance of product discovery in mind
A product discovery is a process that identifies what we are going to build. It's the stage where you'll define objectives, filter ideas and identify potential risks during the implementation or delivery stage.
Discovery can be done "standalone" or included as part of the product. Once a discovery has been completed, the entire team (including the client) must be very clear about the tactical definitions needed to guarantee a flawless delivery.
It's important that the entire team involved in the discovery stage understands that the process is not only to define business rules and UX/UI (as prototypes) or define content architecture. Discovery is also about technical definitions that are fundamental to the delivery of any product. Each business rule, logic or interface decision has to be connected to the domain structure, to architecture definitions, and these decisions can even be reconsidered based on those findings. Key elements such as ubiquitous language and domain definitions and even the roadmap of a Micro Frontend architecture can come out of this process.
2. Design a process that's time-bound
It's understandable that every organizational objective has a goal set within timeframe, so a discovery must be able to adapt to that strategy. But, what typically happens is usually that the discovery stage suffers the most due to short timeframes for delivery or under pressure of an already committed production release.
Time restrictions shouldn't lead to omitting your discovery stage or its key activities. Before resorting to shortening it, identify the objectives, activities and artifacts that can be managed within the allotted time frame you're given, without a loss in the quality of your results. There's proof that this is a widespread issue: 60% of UX professionals say that in their organizations, one Product Discovery is carried out for every 2-4 projects.
For example at Modyo, our Product Discovery models focus on defining and ideating directly from business needs. We have 5 types of discoveries depending on the goal and timeline, objectives and resources. These discovery types vary in length for the weeks required for execution, and according to the level of certainty, requirements, scope, and even the type of product itself.
3. Have a variety of tools and methods
Methodologies can be very diverse, and change depending on the situation. However, each method always seeks to actively involve the customer and stakeholders. There are tools such as Product Discovery Methods that facilitate this execution according to specific needs.
But not all discovery activities serve the same purpose. Knowing what to do or what to ask is essential for each session to be clear, focused and facilitate the construction of both lofi and hifi prototypes.
At Modyo, we use resources according to the needs and objectives of each client. We seek to combine activities such as ATAM, OKRs, architecture sessions, impact maps, building user flows, and more. This is done with "artifacts" that are practical, promote good documentation, encourage agile teamwork, and ultimately contribute to a good delivery.
4. Identify the mission of each session and activity
Sessions will vary depending on any team's objectives, and it's your mission to ensure their usefulness, separate ideas in a productive way, identify risks by category, and identify the main technical limitations.
Regardless of the sessions you schedule, it's always important to identify each session’s core objective. Being mindful of the agenda adds value and prevents unnecessary wear and tear on your teams. The following are key types of missions:
- Strategic: these sessions identify transversal and strategic definitions. The customer must be involved as much as possible since they will be core players in establishing these definitions.
- Tactical: These sessions go into detail and define aspects related to the features and characteristics of the digital product to be built.
- Technical: This is where the technical teams of all parties involved must meet to reach a common consensus regarding the software solution that best meets the objectives set by the business.
5. Facilitate learning and growth among teams
One of the great challenges in this process is empowering those who facilitate the sessions, as well as ensuring the participation of those who contribute from the clients’ side. We recommend open spaces to talk and share ideas.
Executing this process digitally is not a problem if facilitators have the opportunity to practice, observe, and have learning curves that allow them to transfer knowledge and develop skills (especially soft skills).
At Modyo, we want all our teams to experience participating by listening in on, or leading within these spaces, always supported by the Socratic method of asking questions. We’ve learned that during product discovery stages it's important to listen in order to ask the right questions.
6. Don’t confuse Discovery with a Kick Off or a Brief
While many organizations transition into agile processes, they make the mistake of inexperience by merely copying models and implementing techniques and methodologies. This can be a valid path if mistakes are treated as opportunities, but in the end it's costly in both time and resources.
While adapting and under the pressure of deadlines, many organizations usually omit discovery or confuse it with other practices such as the elaboration of a Brief or a Kickoff. These exercises are usually performed with a reduced group, and lose sight of organizational synergy, or open the revolving door of reinvestment in both time and resources.
Looking at it practically, imagine that the discovery process goes in the middle of your Brief or your Kickoff. It's the glue that will reduce costs and keep your vision and core objectives on the table.
7. Exercise time management
Any product development lifecycle process will require business involvement, and it can be a challenge to find spaces for the necessary people to participate.
The biggest challenge is to lower uncertainty and perception about the process. We do this by helping those involved to understand how profitable the exercise is, and that it isn't just another appointment on the calendar. To this end, reducing stress and providing timely information is vital.
Instead of exclusive and/or eternal sessions, look for strategic sessions; always draw up a map of stakeholders in order to meet in time with key people—and by key we mean decision makers as well as experts in operational issues and those who are in the day-to-day operation.
Learning to find these people requires good communication, assertiveness, inquisitiveness, and is achieved at two moments: before the start of your Product Discovery and during each session. So taking note of who participates, knowing in advance who is going, confirming and scheduling in advance, setting reminders and placing the objective of the session or inputs in the appointments are all good habits that will not only facilitate participation but also help those involved to see that their time is valuable.
8. Take note of the risks with a purpose in mind
The value of discovery processes is not to accumulate information, but to know how to filter and organize it. It’s not valuable to have a lot of data, but rather, to know how to analyze it.
Evaluating risks is part of the key elements of discovery, and it's always important to identify them:
- Value generation risks: Are there real users who would buy or would be willing to use it?
- Usability risks: Is it usable and intuitive for users?
- Feasibility risks: Can we build it?
- Financial risks: Does the solution work for the different aspects of the business? Is it financially viable?
The main purpose of identifying risks in the sessions is to make scoping decisions that allow you to work in parallel alongside the definition of the plan, phases or even evolutions of the product.
We emphasize this because Product Discovery is not only for new products. Finding any risks in legacy systems and reducing uncertainty in multiple integrations will help any team plan and execute better.
Conclusion
We hope this guide helps you deliver powerful results in real practice, not just in theory, and acts as a supporting argument to help your teams move quickly towards adopting better discovery processes.
Concise, readable, actionable, domain-based product design, good architecture and well-executed methodologies will always be key for the whole team to have a good understanding of the product, solve vital problems, and organizations can actually benefit from truly being agile in implementing high-quality digital products.Photo by Mitchell Luo on Unsplash.
