Giving visibility to trade-offs is essential to show alignment, especially when a PM is surrounded by stakeholders with different goals and doesn't talk to each other daily.

Before saying "yes," the PM must analyze the problem, looking for relevant data and information to make the decision most assertive. If necessary, the PM will postpone some initiatives.

Some stakeholders don't like that. Hence the need to be transparent and inform what is being done and why. When stakeholders look at a single issue, they lose track of the big picture. At this moment, the need for a roadmap becomes more present.

Roadmap is a communication tool used to align product teams and leaders. Making sure everyone understands the goals and strategy of the product.

A good roadmap should answer 3 questions: "where are we?", "where do we want to go?" and "how do we get there?" However, a roadmap can go beyond a team's internal alignment.

In the 2016 Label Insight survey, nearly 94% of consumers interviewed revealed that they are more likely to be loyal to a business that offers complete transparency, and 73% are willing to pay more for products that guarantee full transparency. That includes being open about your company's ongoing efforts and areas of ​​focus.

In addition, according to a study by Bain and Company in collaboration with the Harvard Business School, it was pointed out that acquiring a new customer is 5 to 25 times more expensive than maintaining an existing one and that increasing customer retention rates by 5 % increases profits by 25% to 95%.

That's when sharing your plans with your customers via a public roadmap is handy.

As a company, you can publish a roadmap for your customers to view, suggest ideas, and even comment on your recent and future product evolutions.

Okay, but what does Product Gears have to do with it?

My brother and I faced many challenges aligning what is currently being focused on in our work, me as a Designer and him as a Product Manager.

In addition, we would like to increase transparency with our clients by seeing the advantages this can bring and how it aligns with our work values.

From this need, I started the discovery process for the birth of Product Gears.

Process

Discover

Desk Research

As a starting point, I carried out a survey to understand the main pain points when creating a roadmap and identify whether there is a need in the market for a product that increases the transparency of these roadmaps.

In addition, I used as a basis the experiences I lived as a Product Designer at Resolvvi and my partner as a Product Manager at Agenda Edu.

The fruits of this research were seen in the introduction of this project as pain points and, mainly, the advantages of increasing transparency in a company.

CSD Matrix

After the desk research, some certainties, assumptions, and doubts emerged, which were organized and based on a matrix.

Benchmarking

I looked for which competitors existed in the market, comparing their services and using Nielsen's 10 Heuristics as qualitative validation.

In addition to evaluating the experiences in competing products, I also sought to understand the sales methods and the product test format, whether trial or demo.

Interview

We identified a good market for what would become Product Gears from the collected data. Now, it has become necessary to collect data from Product Managers and Product Designers to create a map of the main pain points of these personas.

The interviews were carried out remotely through google meet. I interviewed selected PMs and PDs in product groups on whatsapp, telegram and also invited technology colleagues.

This information was essential for us to identify which features would be crucial when launching the product, what would be interesting if it could be developed, and what would be done in the future.

Define

Persona and Empathy Map

According to the insights generated after the surveys, we created a persona that conveys and reflects Product Gears users. From its creation, we verified the possible journey that it would take within the product, thus understanding its pains and motivations, and therefore, we were able to reflect on our opportunities.

MoSCoW

As previously mentioned, the interview with PMs and PDs was essential for us to define the Must have, Should have, and Could have. So we clarified what would be needed for the launch and what was less priority that could be done later.

References

Some of the platforms that appear in the benchmarking were our main inspirations. But we also looked for references in other SaaS products, considering the general concept of Product Gears.

Wireframe

After collecting references, I started working on the Wireframe, where we put all the planning into action and made the layout of elements on the screens.

Visual Identity

When we saw references for visual identity, the color palette and typography were defined. We focused on conveying creativity and innovation.

Also, after the insights from the interviews and an analysis focused on SEO, the name “Product Gears” was defined, with the intention of being a HUB of tools for people who work with product management.

Deliver

Interface Creation

Producing the final interface of the product after the wireframe and style guide was ready was a task much more focused on creating the text contents, contrasts, and hierarchy that each page would propose.

Some changes were raised during usability testing, where we found some buttons and helper texts that could get more attention using different terms.

Usability Test

With the design of the screens ready, we created a prototype and started testing, a fundamental step to validate the operation of our product. First, we defined two test scripts, where script A explored the Admins interface and script B focused on the end customer.

In script A, we asked the user to simulate registration in the product, look for a suggestion card on the dashboard with the label Bug, called “error when recovering the password,” check the team notes on the card and create an internal label called Usability Issue.

In route B, the user should access the Product Gears feedback page and create a suggestion with a brief description and at least one label.

The objective of the test was to evaluate the quality of the information architecture, especially in the admin area, how the navigation would take place in a more realistic environment, and if any of the features that we decided to leave to develop after the launch of MVP would not be something essential.

Test Results

When analyzing the usability tests, it became clear that some of the points we had planned to implement in the product after the launch would have to be advanced, the main one being the possibility for the admin to merge suggestions.

There was a fear among the participants that, because any client can create suggestions, this could generate extra work to be managed. Deleting them one by one could make the user look for another more optimized tool.

In addition, we also advanced the development of the feature that allows customers to be notified when a feature is released. The notification didn't become essential for the release, but its priority rose to the top as it aligned with the feedback from most of the tests.

In general, the test went as expected, and the product had no navigation problems.