
The product in question is a SaaS platform for business management, which includes a specific module for financial management. The financial module was considered the main reason for negative reviews, detractors, and churn on the platform.
Some strategically important partners (key accounts) began to express their dissatisfaction with the tool, even threatening to cancel their subscriptions. Additionally, the number of new users who refrained from joining the platform due to this deficiency added to the challenge.
The project required rethinking the entire user experience with the financial module in a modular way, addressing the most critical points first to deliver quicker, phased improvements. Two key factors were crucial to the success of the solution: adaptability and cross-sector collaboration.
Given the team’s limitations, adaptability became our guiding principle throughout the process. Our product team consists of three members: a Product Manager and two Product Designers (myself included), who are involved in every stage from Discovery to Delivery. While I may be biased, our dream team comprises highly competent, talented, and strategic professionals. However, as the sole product team for a comprehensive and complex software with five modules — of which finance is just one — managing daily demands requires a great deal of adaptability.
Adapting existing frameworks to the specific realities of each team and company is essential, particularly when resources and team size are limited. Every organization has unique characteristics, challenges, and needs, making a flexible approach critical for success. By embracing adaptability, we can optimize efficiency and productivity, focusing on high-value activities and aligning product strategies with the company’s goals.
This ability to tailor and adjust frameworks not only maximizes the team’s potential but also highlights our skill in navigating challenges and finding creative solutions. Ultimately, this approach leads to better outcomes and a higher-quality product.
The second crucial factor throughout the process was cross-sector collaboration. Building a successful user experience encompasses not only the product’s aesthetics and usability but also an understanding of user needs, expectations, and behaviors.
A design team conducts various user research and interviews, but they don’t have daily contact with users. And who better than those who listen to users every day to help shape the product?
By seeking assistance from professionals who work in customer service (Customer Success, Technical Support, Client Training Specialists, and others) during the solution-building process, it’s possible to gain a comprehensive and diverse view of the product ecosystem with direct feedback from end-users.
Cross-sector collaboration allows each team to share their perspectives and specific knowledge, resulting in valuable insights to enhance the user experience.
The methodologies we used to solve the financial module issue were as follows:
It’s a tool used in the product or service development process to validate the relationship between the problem faced by customers and the proposed solution.
The canvas is divided into two main sections: the part which focuses on the problem, and the other part which focuses on the solution. Each section has specific components:

As teams fill out the canvas, they can clearly visualize how the elements of the problem and solution align and whether there is a fit between them. This allows for the identification of potential gaps or flaws in the proposal, as well as insights into how to adjust or improve the solution to better meet customer needs.
The Problem Solution Fit is usually a tool used during the early stages of product development, helping teams validate their hypotheses, understand the market, and direct their efforts to achieve a solid fit between the problem and the solution. However, in our case, the product was already established in the market, and we weren’t in an initial phase but rather in a phase of correction and improvement.
To adapt, we used the framework to “put out the fire” that was happening. The canvas was collaboratively built with other areas of the company, and by the end of the process, we had identified the main problems, divided into two parts: those that could be resolved in the short term and those that needed further study.
With this, we grouped all the issues that could be resolved in the short term, such as bugs and simple usability adjustments, and created small tasks for the development team as a temporary measure, thus generating quick value for our customers.
With the “fire out,” we were ready to start “tidying up the house” more calmly in the next steps.
Triple Track Agile is not a well-known term; the first time I heard about it was in a Masterclass by Mergo, and I became very interested in the topic. I then presented the idea to the team, and everyone was excited to adapt some concepts of the methodology and implement them in our routine, replacing Double Diamond with Triple Track in some cases.
The Triple Track Agile it’s a process that divides product development into three tracks:

In this track, which operates at its own pace, interviews are used to map out user needs and guiding principles, better understanding the audience to differentiate the product in the market.
In the Problem Space, learning happens gradually and is long-lasting. It isn’t disrupted by changes in technology because it’s not tied to any particular solution.”
- Renato Caliari
This stage explores, understands, and validates user and business opportunities, needs, and challenges, defining the product strategy. During this process, research, interviews, and market analysis are conducted to identify problems, opportunities, and insights that will guide the creation of solutions.
The Delivery track is the most common in companies, where all previous studies are executed.
To delve deeper into Triple Track Agile, I highly recommend Renato Caliari’s article “Triple Track Agile: a combination of Problem Space with Solution Space”.
We planned the Problem Space (research) by defining the methods that would be used and best suited to our team’s structure. The research involved the following steps:
After analyzing the data, we defined our key action points in a modular approach and identified the opportunities to be addressed in the Solution Space. This enabled us to plan faster, phased deliveries.
To prioritize these deliveries and determine which topics to tackle first, we aligned our efforts with the company’s strategic objectives. With priorities set, it was time to execute the Solution Space, leading us to the next methodology: Design Sprint.
The Design Sprint is a five-day process developed by Google where a team collaborates intensively to address critical business challenges through design, prototyping, and user testing in an agile manner. For more detailed insights, I recommend reading this page by Google Ventures.

None of the team members had prior experience with Design Sprints, so we started by studying the methodology together. Although several pre-made templates are available for the traditional five-day sprint, we customized the stages to fit our specific needs.
While Design Sprints are typically used to validate ideas, we adapted the model to execute the Solution Space, which accelerated our delivery, as our ideas had already been validated in the Problem Space.
Before each Design Sprint, we established clear objectives and determined whether a full five days or a shorter ‘mini-sprint’ — a term we used for our three-day sprints — would be more appropriate.
Throughout these development phases, we collaborated with various departments and individuals within the company, validating the new structures with stakeholders and key users. The insights gained from these sessions were reviewed by the entire team, including PMs, product designers, developers, and C-level executives.
Combining and adapting methodologies provided an effective approach to rethinking the user experience in the financial module, allowing us to gain a holistic view of the problem and tackle it in a modular and agile way. Cooperation between departments enriched the solutions, delivered quick wins, and maintained user satisfaction while we developed a more comprehensive solution.
I would like to thank my dream team (Pedro and Luan) for allowing me to share our experiences here, and to everyone who continuously collaborates with the product team to help us achieve the best possible results.
If you’d like to discuss this topic further, feel free to send me a message on LinkedIn. Let’s connect!