Wizeline Portfolio

Wizeline Portfolio provides a way to hear all voices and captures every idea across different company teams, all these data then can be organized by product managers to bring focus, accuracy, and speed to the strategic process.

Our users

Product managers use Wizeline Portfolio to gauge true market needs, prioritize feature requests, and deliver comprehensive strategic plans to cross-functional teams, engineers, and business leaders.

Goals and Features

When Wizeline Portfolio was launched, my team and our company needed to validate several assumptions to understand the problems at the aimed market.

That being said, our process was to ran sessions with our PM to define initial hypothesis that later we validated. Since we were offering a data-driven tool to our users to make decisions accordingly, our product was shaped with the following features.

Requests

This feature was specially conceived to allow sales teams to make request features to PMs instead of using different channels such as emails, meetings, calls, etc.

Surveys

Internal surveys to gather data and compare it and make decisions accordingly.

Features

A backlog where users were able to pick items called features and prioritize them. All this features could contain data from Salesforce and/or JIRA

Why Salesforce and JIRA integrations were important?

As said before putting data together from SFDC would help PMs to make intelligent decisions and JIRA helped to map and track features to track the progress of the projects.

Roadmap

Although, a rigid flow needed to be completed to be able to visualize company plans in a timeline manner. We discovered positive and negative things, but mainly we found this two big needs:

- Our users needed to communicate on time and with transparency their plans to stakeholders and executives.

- They wanted on create plans with less steps

Dashboard

I’d like to explain with more deatails in regards to the process to design this feature, since this was the last piece of functionality that was launched for Wizeline Portfolio.

The problem was clear, our PM had interviews with users with executives roles that provide enough context to start working on this. Those users were interested in having an easy way to consume small but informative pieces of data from their companies trough Wizeline Portofolio. That way, they would be able to know how the company was allocating their efforts. With all this context, this feature was meant to meet executives needs by let those users to consume in an effective way all this information coming from their companies. But more importantly, this solutions could help the to undestand the following questions.

How are the teams performing?

What did the plans change?

Why did the plans change?

When did the plans change?

Who the responsible for making those decisions was?  

First, I came up with several ideas and hypothesis on how this visualization should be, the amount and kind of data it  important to offer to this specific persona. How granular should data be?

I started to work on ideas that later we used to discuss with the people involved to develop this feature.

Sketches

[Add photo with notes]

First designs and testing

[Add photos and notes]

Iteration

[Add photos and reasons] 

Final Design

[Add mocks]

According to our records, this feature helped to fill the gap concerning transparency that allowed PMs to enable other ways to provide facts and context of their projects statuses to stakeholders and executive teams. 

Worth mentioning that the company didn't invest more efforts in this feature since we started to work in parallel with Wizeline Roadmap.

Takeaways

In general, my own opinion about Wizeline Portfolio is that it was designed to provide substantial value to our users. However, we found some pain points that made most of the users struggle to adopt a new workflow, ours. With all this context, the company determined to create a new product called Wizeline Roadmap that could eventually be flexible and close all the gaps we found along the way.

I can conclude saying that is not only about building features because at the end of the day the more features you build, the more complexity you add and the users will end up not using it.