WHY IS PRODUCT DISCOVERY IMPORTANT

At ITIDO, we often hear partners ask us what a discovery phase is. Yes, it’s a buzzword in the world of IT products. However, there are tons of business value behind it. Let’s dive deeper. Let’s learn what constitutes discovery and why teams should engage regularly in its inherent activities.

Start with what and why

Before designing a solution, we should define what should be created. And to do that, we need to understand what problems users face. What are the needs, both latent and explicit? The software should address customers’ jobs to be done. All while development resources are used efficiently.

To understand the what, UX researchers first need to ask why customers are interested in solving problem A or B. Feeling the end users’ pain, so to speak, is also key during conversations. In fact, frameworks inspired by design thinking define the starting point as empathizing with users. Usually, that means face-to-face exchange, experimentation and research. For relevant examples, check this excellent product discovery activity guide by the New York Times.

Most often, a discovery phase is associated with product discovery and development. In some organizations, customer discovery and development run in parallel to the product process. Here’s how the product and the customer motion differ. While the former is centered around features and capabilities, the latter uncovers problems and end-user needs. In other cases, product and customer discovery is practically one thing sitting at the beginning of the product development cycle.

The perks

Performing discovery brings a lot of learnings and clarity on the table. And it is particularly useful for startups as well as new products in mature companies. Among the benefits, we feel the most important boil down to:

Making sure the team develops the right features. Releasing something the market isn’t interested in is one of the most common reasons startups’ failure.
Helping customers visualize the scale and complexity of the features needed. As a result, some may be deferred to another phase while others may be included in the MVP.
Diagrams produced during discovery help define the flows that the end user will go through.
Estimating the efforts and budget needed to complete the initial or follow-up releases.
The client’s first-hand experience in a working environment with the team.

Keep in mind that discovery means iteration. Whatever is developed should be once again checked with users. Validated assumptions may change. This is also part of the work required before product launch. The results are later used by software architects, developers, quality engineers, and customers.

Our approach to discovery

Partners we work with are at different stages of their product journey. Some are just starting. Others have up-and-running MVPs seeking business and technical scaling. There are also those who have experienced setbacks. They are in the process of replacing an internal team or an external supplier with a new technology partner. This variety has implications for the way we prepare for the actual software development.

We came up with the ITIDO Software Delivery Process (ISDP) by diagnosing our diverse partnerships. Designed to be ergonomic, ISDP’s Preparation phase caters for all above mentioned customer groups by emphasizing on the necessary prep activities suitable for each. These include discovery.

Further readings:

Greenfield projects, for example, require us to work hand in hand with customers to test their hypotheses. Together, we conduct user interviews, focus groups, surveys, and even do field observations. Whatever assumptions get confirmed are fed as “features” into a click dummy prototype. We then perform another round of validation. This time there is something people can touch and feel. With mature projects, our team looks into existing data from tools like Google Analytics, Yandex, and LaunchDarkly.

Besides tackling the what of product development, we also focus on how to bring a solution to life. In other words, we strive for building the right thing and building the thing right. For us at ITIDO this entails designing the architecture, coming up with a suitable tech stack, and agreeing on the project management approach. Another crucial output are the time-and-material estimates for a set scope of work, e.g. the first product release. Needless to say, this is super important to whoever is approving the budget in the partner organization.

If you want to learn more about ITIDO and how we validate software solutions, don’t hesitate to get in touch with us.

ITIDO