In today’s scenario, many companies are seeking continuous innovation, efficiency and operational excellence through the development of internal platform products. To meet the growing demands of internal users and offer solutions that truly add value to the business, it is crucial that organizations adopt robust product discovery approaches. It is very common to hear about discovery practices when we talk about customer-facing products . But can these same practices be used for internal, technical or platform products?
In this article, we will explore some of the essential best practices for conducting the discovery process, aiming to drive successful internal platform product development. Some of the practices covered include the CSD Matrix , journey mapping, interviews, idea repositories, and benchmarking. By integrating these techniques, companies will be able to make informed decisions, build effective products, seek to mitigate risks, and seek to attack the most important problem first.
Discovery Plan
Whether you are planning to start a continuous discovery or a specific topic, having a discovery plan will help you define a goal, the strategy to reach that goal, the hypotheses you plan to validate (or invalidate), the time you intend to invest in discovery, and the methods and tools you and your team will use.
This plan does not need to and should not be written in stone. It should be a strategic guide so that you and your team know where you want to go, and that way the plan can and should be adapted whenever circumstances change.
The structure I usually follow is as follows:
Discovery Plan
WHAT?
Title:
Objective:
Hypotheses:
Questions to be answered:
WHY?
Motivations for this discovery:
WHEN?
Estimated time:
Start date:
End date (if applicable):
WHO?
Permanent collaborators
Temporary collaborators
Support
HOW?
Methods and Tools:
CSD Matrix for Discovery
One tool that can help you build your plan is the CSD Matrix. I believe that a good practice to start any discovery is to have a good idea of what you already know about a given topic, what is still assumptions and to have a good mapping of what you still need to discover.
The acronym CSD refers to Certainties, Assumptions and Doubts. It is displayed through a matrix of 3 columns, one for each of these words.
“Certainties” represent the unquestionable aspects, facts or proven information that support a certain fact. “Assumptions” are hypotheses and estimates that are considered true, but still require validation. And “doubts” encompass the unknown and uncertain factors that may directly or indirectly impact your product.
By mapping these elements, teams can make more informed decisions, mitigate risks, and establish discovery plans to validate assumptions and reduce uncertainty. In other words, from this visualization, you will be able to gain valuable insights to start your discovery plan . A good source of input for the CSD matrix of platform products can be conversations with people who have been in the company for a long time and have a lot of context, or even investigation of existing documentation.
Read more about the CSD Matrix here .
Journey Mapping
Another well-established and well-known practice in the wor vk statistics and user count ld of customer-facing products that makes a lot of sense when we talk about platform products is Journey Mapping. There are several ways to identify opportunities, pain points or problems for users through journey mapping. For example, two approaches that I often use in the context of Engineering Platforms are Experience Mapping and Service Blueprint.
Experience Mapping
Mapping a persona 's experience is a process that aims to understand in detail the user's journey when interacting with a product or service. In addition, all points of contact between the persona and the product are identified and documented, from the first contact to the completion of the main objective.
The goal is to capture the emotions, needs, motivations, challenges, and expectations of the persona. This occurs at each stage of the journey, allowing for a holistic and empathetic view of the user experience . This mapping is a valuable tool for identifying gaps, pain points, and opportunities for improvement in the experience of your users who already use your products or processes.
In platform products, it is common to map experience in development processes, tool usability, and even understanding and engagement with documentation. It is also interesting to understand the step-by-step processes for developing technical tasks in the day-to-day lives of engineers.
Service Blueprint
Service Blueprint is a design and analysis tool that provides a detailed and holistic view of a service, from the user perspective to the organization's internal processes.
It maps the user journey, highlighting all the touchpoints, interactions, and processes involved in delivering the service. In addition, the Service Blueprint also identifies the supporting elements, such as people, technology, and policies, that are needed to deliver the service efficiently and with quality.
In the context of platforms, the Service Blueprint is essential. It is an approach that allows companies to identify opportunities for improvement, optimize their processes and offer more consistent and satisfactory experiences to external and internal customers. Especially when a given experience involves different tools, processes and documentation to achieve a goal.
Read more about Service Blueprint here .
Surveys and Interviews in Discovery
Other interesting methods for identifying pain points, needs and opportunities are surveys and interviews. A very positive aspect of internal platform products is the proximity you have with your users, who are usually the organization's own employees. This makes it much easier to schedule meetings for individual interviews, groups or to send surveys to specific user segments.
When it comes to surveys, opt for short surveys on specific topics with a clear objective to increase user engagement. Then, set a time limit for receiving responses and collaborate with your stakeholders and leaders to encourage all users to participate. When compiling data and sharing results, involve your entire team in this process whenever possible.
For interviews, in addition to having a pre-defined objective and script, always try to involve people who have more context about a given problem when it is an investigative interview. When you are just looking for new opportunities, prioritize scheduling more informal chats with user groups that can be entire teams or leaders and be attentive to what people have to say. Active, non-reactive listening is the main tool for this technique. And also, whenever possible, involve your team in the process or at least record the interviews so they can watch them later.
Repository of Ideas and Opportunities
Another interesting method of raising opportunities or even validating solution ideas for internal platform products are the public discussion and collaboration forums that your platform team can create.
One idea that can work very well is shared boards among different stakeholders and internal users. This board can be on Trello , Jira , a Slack channel , even a spreadsheet or any other tool that your company uses. The important thing is that it works as a repository of ideas and a space for your users to feel comfortable sharing materials, concerns, and ideas. But this space should also be open to receiving comments from other users.
For this approach to be successful, there needs to be constant management of inputs, user engagement and a clear positioning from the platform team that not everything included on the board can be prioritized, but that this is a means of asynchronous communication between users and the team.
Conducting periodic syncs with specific user segments can also be an interesting approach. Not only to identify pain points and opportunities, but also to gather feedback on your deliverables and how they can be improved incrementally.
Benchmarking
It may seem strange to talk about benchmarking for internal platform products, but this is a completely possible and very interesting practice to be carried out in this context as well.
Platform products have their own particularities within each organization, as in most cases they were designed and developed for that specific context. However, it is common for companies to experience similar problems and needs as they scale, launch new products or innovate within their domain and industry. But if companies experience similar problems, why not understand how they are solving these problems with technology?
A delicate point here is that companies will not always be open to sharing their internal strategies and solutions, especially with companies in the same niche and competitors. Therefore, it is important that you are able to find interesting research sources for your context, also outside your competitor map or in different business domains.
Exploring other ways to learn about companies without having to talk to them directly is also possible. Sources of information that I usually use are podcasts, lectures, public cases, blogs or technology media from companies, and the organization's own website, which usually have valuable information about successful cases or lessons learned by the company in solving a problem with technology.