How to gather requirements during the Product Discovery Process?

Empathy means trying to look at the things form the interlocutor's perspective. For a software developer, it can be hard to understand business processes and circumstances and with which the business owner is dealing with. On the other hand, entrepreneurs might not have the knowledge required to launch a software development process. 

Hence, mature software development companies perform product discovery sessions. Assuming that the stakeholder has a clear vision of the business processes, the 'translation' is a relatively easy-going process. However, many issues regarding the business logic are usually discovered during the conversation, when the tech team is already involved. Therefore, it is a must to display empathy and acumen while collecting data and defining the product. 

First date 

Many entrepreneurs and founders have a firm belief in their ideas. The product design process shall begin with simple questions tackling the major goals of the solution. Surprisingly, some founders discover loopholes and are unable to finish the sentences listed below.  Sometimes, answering to the most basic issues causes concern, which leads to reflection regarding the service:  

• For [target customer]
• Who [statement of the need or opportunity]
• The [product name] 
• Is a [product category] 
• That [key benefit, compelling reason to buy]
• Unlike [primary competitive alternative]
• Our product [statement of primary differentiation]

As you can see, clarification of the product's main goals is very simple. This is a very first step towards establishing a goal mutual with the dev team and the stakeholder: the product itself. The worth of mentioning is that the first questions you might hear from an experienced Business Analyst are mostly not tech-related. This might cause a bit of uncertainty but is a necessity during the initial stage of product discovery.

I need vs. I want

Behind every functionality stands a benefit to be achieved or problem to be solved. One of the common mistakes of the salespeople is paying to much attention on features instead of discovering the real obstacles that the specific business is actually facing. Distinguishing benefits to be achieved and problems to solve is the major goal of every discovery process.

When the client says:

I'm afraid that my income will be measured improperly

This UI is very unintuitive and it slows down my sales team

The target group will not understand this message

We have a clear situation, that he's trying to solve an issue rather achieve a benefit. By answering like:

• So unprecise measure has decreased your income?
• You need to simplify the UI.
• The target group is too old for this kind of content?

We NAME the problem that the client is dealing with. This leads us towards solutions which we can discover during further stages. 

In another case, our goal is to name the benefit. So, when the client says:

We need precise reports delivered instantly.

Our landing page must gain traffic by 30% next year.

Additional button over the footer could increase the revenue.

The goal of Business Analysts is to name these benefits and seek specific solutions to achieve them. Each feature has its context and a reason to be implemented. Unfortunately, useless features are most often the reasons why software development projects can't fit the budget expectations. Excluding them is a truly win-win situation.

His story, her story, User Story

As we can see, understanding how the application will be used is more important than its architecture (at least at the beginning of the Product Design Process). That is why describing the major features with User Stories has become so popular in the IT world in recent years.

A User Story can be made using the following templates:

AS A <ROLE>  I'D  <FUNCTIONALITY>  IN ORDER TO  <RESULT>

IN ORDER TO <RESULT>, AS A <ROLE> I'D <FUNCTIONALITY>

...or…

IN ORDER TO AVOID <PROBLEM> AS A <ROLE> I WANT <FUNCTIONALITY>

IN ORDER TO ACHIEVE <BENEFIT TO BE ACHIEVED> AS A <ROLE> I WANT <FUNCTIONALITY>

Samples above display clearly how providing easy questions can result in collecting precious information regarding the product and its functionalities. The language used above is mutual to both groups; stakeholders and even software engineers. On the one hand, we describe the workflow and even environment of the user, on the other the application's workflow, instantly suggesting its features. 

Prioritize or die

Have you ever heard about Eisenhower's Matrix? The 34th President of the United States was well-known for his effectiveness and productivity during his service in the Army as well as during the presidency. His secret was clear and very simple model of prioritization, commonly called "Eisenhower's Matrix"

THE EISENHOWER MATRIX

NOT URGENT URGENT IMPORTANT schedule do NOT IMPORTANT eliminate delegate

Defining the urgency and importance of specific features is very helpful especially during the prototyping and scheduling further steps of development. Very often founders imagine some functionalities as the most attractive and realize that they are not the necessities for the first users. Postponed implementation will not only make the process more cost-effective but also allow the founder, the analyst and the dev team to focus on the necessities.

Eisenhower's Matrix helps to answer one of the most important questions of every founder: if you’d be short of cash, which functionality you’d exclude first? Distinguishing might be difficult, but there are few solutions to achieve that goal. One of them is the Cartesian Questions. Answering them will help us realize the consequences of picking one of another path of development.

The questions are:

1. What would happen if you do?
2. What would happen if you don’t?
3. What wouldn’t happen if you do?
4. What wouldn’t happen if you don’t?

Answering the Cartesian questions displays the business, budget and technology-related issues. The answers demonstrate the real reasons, obstacles, and needs appearing during the product discovery.

Gathering requirements in a nutshell 

Product discovery is a part of a complex design process, tackling a variety of aspects such as technology, finances, business environment. In many cases, plot twists show up and even most down to earth visions require validation. Another aspect is the possibly clear explanation of the goals of the project. The experienced business analyst must possess the knowledge and acumen to as the right questions. However, I strongly recommend founders to ask the questions themselves before looking for the team that will be turning vision into reality.