ProductPlan strategic portfolio visualizations

ProductPlan

Redesigning enterprise roadmaps to close a $350k retention gap

ProductPlan is a roadmapping platform used by enterprise product teams to align strategy across portfolios. In late 2024, enterprise accounts began naming portfolio inflexibility in renewal conversations, putting contracts at risk. I led end-to-end design of a portfolio visualization suite over five months, from research through engineering handoff, as the sole product designer on the team.

54%

Improvement in month over month retention

34%

Increase in account adoption

20%

Decrease in time to first portfolio creation

350k

In at-risk ARR retained

My Role:

I was the sole product designer on this project, responsible for research, synthesis, concept direction, interaction design, and engineering handoff. The team included one product manager and four full-stack engineers.

Constraints:

In week three of discovery, feasibility checks with engineering revealed that the codebase coupled user permissions to data relationships, limiting which portfolio configurations could be exposed to which users.

ProductPlan strategic portfolio visualizations

ProductPlan

Redesigning enterprise roadmaps to close a $350k retention gap

54%

Improvement in month over month retention

34%

Increase in account adoption

20%

Decrease in time to first portfolio creation

350k

In at-risk ARR retained

My Role:

Constraints:

ProductPlan strategic portfolio visualizations

ProductPlan

Redesigning enterprise roadmaps to close a $350k retention gap

54%

Improvement in month over month retention

34%

Increase in account adoption

20%

Decrease in time to first portfolio creation

350k

In at-risk ARR retained

My Role:

Constraints:

THE PROBLEM

Legacy portfolio tools threatening enterprise customer retention

Enterprise product teams couldn’t make the portfolio view answer the question executives actually asked: how does this work ladder up to our goals? The legacy portfolio could only group by roadmap and only display progress as its legend, so teams fell back on manual workarounds to group data, customize views, and share with stakeholders.

Who it was failing

The primary users were product managers, project managers, and implementation managers at enterprise accounts, the people responsible for building portfolio views and keeping them current.

THE PROBLEM

Legacy portfolio tools threatening enterprise customer retention

Who it was failing

The primary users were product managers, project managers, and implementation managers at enterprise accounts, the people responsible for building portfolio views and keeping them current.

THE PROBLEM

Legacy portfolio tools threatening enterprise customer retention

Who it was failing

The primary users were product managers, project managers, and implementation managers at enterprise accounts, the people responsible for building portfolio views and keeping them current.

RESEARCH AND DISCOVERY

Nine interviews showed the portfolio failed at presenting, not planning

I conducted nine interviews over Zoom with product managers, project managers, and implementation managers across the US, UK, and Australia, in order to validate the churn signal against how people actually worked. Participants completed tasks in a prototype while I observed: customizing views, using presentation mode, and sharing with stakeholders.

Four findings shaped everything that followed. Users needed to group data by objectives, themes, and business lines, not just by roadmap. They needed different permissions for internal stakeholders versus external customers. They wanted a clutter-free way to present, inside and outside the app. And they needed to rearrange elements to reason about priorities and capacity.

The pattern across all four was the same: the portfolio held the right data but couldn’t reshape it for the audience in the room. That reframed the project from “make portfolios more flexible” to “make one portfolio answer many audiences.“

Legacy portfolios

Nine interviews revealed four workflow failures: grouping data beyond roadmaps; sharing portfolios without duplication; presenting cleanly to external audiences; rearranging elements by priority.

These weren’t feature requests. They were moments where the product actively blocked users from doing their jobs.

Legacy portfolios

Nine interviews revealed four workflow failures: grouping data beyond roadmaps; sharing portfolios without duplication; presenting cleanly to external audiences; rearranging elements by priority.

These weren’t feature requests. They were moments where the product actively blocked users from doing their jobs.

Legacy portfolios

Nine interviews revealed four workflow failures: grouping data beyond roadmaps; sharing portfolios without duplication; presenting cleanly to external audiences; rearranging elements by priority.

These weren’t feature requests. They were moments where the product actively blocked users from doing their jobs.

Early strategic portfolios

The solution was a configurable portfolio canvas: hide or move lanes, edit the legend, save named views, and pivot data within the existing permission structure.

Full drag-and-drop required architectural changes outside our scope, so the design focused on the flexible interactions the system could support.

Early strategic portfolios

The solution was a configurable portfolio canvas: hide or move lanes, edit the legend, save named views, and pivot data within the existing permission structure.

Full drag-and-drop required architectural changes outside our scope, so the design focused on the flexible interactions the system could support.

Early strategic portfolios

The solution was a configurable portfolio canvas: hide or move lanes, edit the legend, save named views, and pivot data within the existing permission structure.

Full drag-and-drop required architectural changes outside our scope, so the design focused on the flexible interactions the system could support.

Every proposed feature mapped on two axes: user impact from research, technical feasibility from engineering. This session decided what shipped first and what waited.

COLLABORATIVE IDEATION

Impact versus feasibility: deciding what shipped first

The feature list was long and engineering capacity was fixed, so I facilitated a prioritization session with the PM to align the team on scope before any design work began. Without a clear must-have versus nice-to-have line, we risked building the wrong things first.

I mapped each proposed feature against two axes: user impact from the research and technical feasibility from engineering. Customizable grouping, distinct viewer and editor permissions, and export functionality shipped in the first release. Real-time presentation updates and private sharing links moved to a later phase.

That framework shaped our phasing, kept the team focused, and prevented scope creep from delaying the features users needed most.

Core Features Identified:

Title & Description
Sharing Capabilities
Present Mode
Flexible Lane Management
Data Filtering & Pivoting

Pivot, not rebuild. A different view takes two clicks because every grouping reuses existing data relationships.

DESIGN SOLUTION

Pivotable views instead of a custom builder

The obvious response to users want flexibility was a free-form portfolio builder, the direction Aha! takes. I rejected it because the permission architecture made user-built custom layouts prohibitively expensive, and the competitive analysis showed that heavy customization came with a learning curve enterprise buyers already complained about.

Pivot, not rebuild. A different view takes two clicks because every grouping reuses existing data relationships.

DESIGN SOLUTION

Pivotable views instead of a custom builder

Pivot, not rebuild. A different view takes two clicks because every grouping reuses existing data relationships.

DESIGN SOLUTION

Pivotable views instead of a custom builder

Before: the portfolio legend forced every roadmap to adopt it, and switching destroyed mapped values. After: legends are decoupled and values persist with the bar.

Decoupling legends from the roadmaps underneath them

The legend is how an executive reads a portfolio, and the legacy version could only display progress. Heads of product needed the legend keyed to whatever their stakeholders actually asked about, like strategic theme or investment category, which meant the legend had to pivot along with the view.

The blocker was structural. The legacy implementation forced every underlying roadmap to adopt the portfolio's legend, and switching legends destroyed the values already mapped to bars. Product ops managers told us they spent real time chasing PMs to re-enter lost legend data.

I designed pivotable legends so a portfolio owner can set any shared legend or custom dropdown as the view's legend without touching the roadmaps underneath, and legend values persist when items move between roadmaps. This was the decision engineering and I negotiated most closely, because it meant storing legend values with the bar rather than the view. It removed an entire category of data loss in the process.

Designing for the renewal meeting, not the planning session

The PowerPoint workaround told me where the product was losing its audience, so I designed presentation mode to meet users there. It strips UI chrome, reflects real-time data, and exports to PDF and PowerPoint, because forcing executives to abandon their existing habits would have killed adoption.

Designed for the renewal meeting. PDF and PowerPoint export, because executives already lived in slides.

Designing for the renewal meeting, not the planning session

Designed for the renewal meeting. PDF and PowerPoint export, because executives already lived in slides.

Designing for the renewal meeting, not the planning session

Designed for the renewal meeting. PDF and PowerPoint export, because executives already lived in slides.

Testing where flexibility becomes clutter

Drag-and-drop survived in one scoped form: reordering lanes and sublanes within a view. This was the part of the killed builder direction that the permission model could support, and it directly answered the finding about reordering priorities and capacity.

Drag-and-drop scoped to lanes and sublanes, the part of the builder direction the permission model could support.

Testing where flexibility becomes clutter

Drag-and-drop scoped to lanes and sublanes, the part of the builder direction the permission model could support.

Testing where flexibility becomes clutter

Drag-and-drop scoped to lanes and sublanes, the part of the builder direction the permission model could support.

Setup split into tabs so users complete and validate one step at a time.

DESIGN SOLUTION

Constraints that became interaction patterns

I worked with engineering throughout design rather than only at handoff, so technical constraints surfaced while there was still time to design around them. Two shipped as better interactions than the unconstrained versions would have been.

Setup split into tabs so users complete and validate one step at a time.

DESIGN SOLUTION

Constraints that became interaction patterns

Setup split into tabs so users complete and validate one step at a time.

DESIGN SOLUTION

Constraints that became interaction patterns

RETROSPECTIVE

Outcome

By six months post-launch, month over month account retention improved 54% among the enterprise accounts that had flagged portfolio flexibility during renewal conversations. Seat adoption, measured as the percentage of licensed seats actively using the portfolio view, increased 34%.

What I’d do differently

If I did this again, I’d have recruited executives into research earlier. The nine interviews were primarily with product managers, the people building portfolios. But executives were the ones presenting them to external stakeholders, and their mental model of what clear looks like was different.

RETROSPECTIVE