Uncovering best practices for better understanding and developing successful technical products

Tips for conducting an efficient discovery process and achieving outstanding results when building technical products

The discovery stage in product teams is still very open. Even with several best practices written by experts in the field or by co-workers, we still have a process that is very individual and depends a lot on the context in which it is inserted.

There are different approaches that product professionals use to conduct the discovery process. For example, some conduct interviews with users, while others analyze their competitors’ platforms or search for information in internal documentation to understand how services work.

Regardless of the method chosen, the overall goal of the discovery process is to better understand a problem and find the best way to develop a solution to it.

When dealing with technical products, the discovery process can be somewhat different from conventional platform development. Some difficulties can be faced when trying to understand the needs of the user, who in many cases can be an internal member of the company or a developer partner.

Also, the solution may be being developed specifically for the context of that company, making it difficult to find references from “competitors” who have already implemented something similar.

In this article, we will present some techniques we have learned over the past few months for conducting the discovery process on technical products, and how you can use them to get relevant information to help build what is needed.

Putting Technical Products into Context

Generally speaking, every product has a technical layer behind its user interface.

You cannot build a solution without developing an entire infrastructure that includes virtual machines, databases, information processors, and integration with other services.

Product differentiation is more related to the output your team delivers at the end of the cycle. Taking a banking application as an example, while one team focuses on creating the user experience, with screens and interactions, another team is responsible for developing the infrastructure that will be used by the application.

Examples of technical deliverables include API development, building data processing infrastructures (ETL, for example), integration with third-party solutions, creation of microservices, data management, and others.

In general, technical products are used mainly by the developers of the team or company. They are the enabling services of the solution as a whole.

Building Internal Products

Building internal products is an important use case within companies. In this case, we are referring to solutions that will be built inside the company and will be used within its context.

These solutions are not intended to be commercialized (at least not in the first moment) and will be used by the team that built them or by related parties that have this need.

Examples of internal products include process automation, microservices, dashboards, refactoring, and several others. These products can be used to be consumed in the solutions that will be commercialized by the company, such as microservices, or can be a means to optimize an existing flow, such as process automation.

Understanding Interactions

To build an efficient internal product, it is fundamental to understand the problem that needs to be solved. Let’s consider the construction of a microservice as an example. The first step is to understand the need that is motivating the creation of this microservice.

This need can be the optimization of an existing interaction or the creation of a new flow to be used by the company. To understand the interactions, imagine that you are responsible for building a microservice that will optimize an existing process. The first step is to interpret how the process is currently done:

• How is this process currently executed?

• What are the bottlenecks in this process?

• What is the ultimate goal of the process?

• Who do we need to optimize this process for?

• Why is it necessary to change the current process?

With this information, it is possible to better understand what is expected from the service and how it should be structured. From the answers, you can start to understand how to build this service, consulting other existing services in the company that provides similar solutions and analyzing how microservices are structured in the company.

At this stage, it is crucial to interact with technical leaders and developers in the company. They have the necessary technical knowledge to bring a more detailed view of the context and propose efficient solutions for the execution of the project.

In addition, it is important to consider the scalability of the internal product. Even if it is built to meet a specific need, it is necessary to ensure that it can be expanded and adapted to new demands.

This means thinking about how the product will be maintained, how it will be documented, and how it will be integrated with other systems in the company.

Developing Solutions for Other Companies

When we develop solutions for other companies, we are often dealing with products that already have competitors in the market and similar solutions. 

A crucial point here is to understand the real needs of the company for which you are developing the solution. To do this, you need to learn the problem they face and how you can help them solve it.

By understanding this problem, we can start looking for competitors that deliver similar solutions in the market. And before you think that there are no competitors, know that there always are, whether they are direct or indirect, and they always demand solutions that can solve (or at least “remedy”) difficulties in technology.

If you can’t find a direct competitor, look for groups of tools that together can solve the problem at hand. By analyzing them, you will be able to identify what each one offers best and how your product can extract the best from each of them in your solution.

An excellent way to analyze competitors’ products, especially when it comes to technical products like ours, is to look for public documentation of their solutions.

These documents usually contain detailed information about all the features present in the product, their limitations, and how they can be used. They can provide valuable context about how the solutions are being delivered to the market and how your product can stand out from your competitors.

If these products need to be integrated with buyers, you can be sure that there are integration examples, use cases, and documentation to read.

What I’ve Learned

Working with technology products, I had the opportunity to follow and conduct some discovery processes.

In general, the best way to start a discovery is to understand with the leadership what the starting point is about the problem to be solved. In some cases, we already have the whole context in which we should act, while in others we start with just an idea of what we should address.

Whether we are building products for internal use or commercialization, technology products require the understanding of the people who deal with them on a daily basis. Talking to developers and technical leaders is key to getting good results in a discovery process.

These people have experience with these types of products, either building or using them, and can provide better visibility into the technologies and complexities involved.

Another important point is to look at competitor solutions as a reference. These solutions can show you how to start the first designs of your solution and how to reduce the use cases to something more feasible. You can look for documentation, do tests whenever possible, conduct trials, and explore as much as you can of these solutions.

Documenting the process depends on each person. Some people use Notion, Trello, Mic, or other tools. It is significant to document in a way that other people can access and understand the research performed. In many cases, more people looking at the evidence can bring valuable insights that were not previously realized.

I hope I have helped in some way.

See you in the next post.