Skip to content
Gustavo Ravagnani

01Porto2026

GDO Acceleration Plan

An open sales question turned into an operable opportunity model

GDO Acceleration Plan — project cover

From

How can GDO help brokers sell more?

To

Which opportunities exist, how do we compare them, and what decides the order?

Role
Lead Product Designer
Scope
Product model · prioritization · UX architecture · functional prototype
Team
Coordination as sponsor; a peer Product Designer supported the initiative
Period
Late May 2026 — present

Current state

Work in progress. No prioritization decision has been made through it yet.

Context, problem and intervention

Context

GDO is Porto's opportunity-management product for insurance brokers. Coordination arrived with a business question rather than a feature request: how could the product help brokers sell more? The work started by examining the opportunity structure behind that question, before deciding what GDO should build.

Problem

There was no scoped problem and no shared inventory of what the product could plausibly do about the question. Nothing could be prioritized while the opportunity space itself was undefined.

Intervention

I built the opportunity space as a structured object: a taxonomy linking frictions, proposals, opportunities and initiatives, a prioritization logic, and a functional React application that makes the model operable.

Question, model, prioritization, tool

Three decisions, with the evidence behind each and what it produced.

Decision 01

Treat an open question as a portfolio problem

The request could have been answered with a feature list or a dashboard mockup.

Evidence
Nothing could be prioritized while the opportunity space itself remained undefined and unshared.
Decision
Run the strategic analysis first — Product Value Chain work, an agnostic sales-journey analysis, product-correlation mapping, process analysis and friction mapping — then classify the results into a portfolio.
Trade-off
Weeks passed before anything visible existed for stakeholders to react to.
Consequence
The team gained a structured object to argue about rather than a list of opinions.
Decision 02

Make the evaluation criteria explicit

Prioritization arguments in this space usually resolve by seniority or urgency.

Evidence
Kano and an impact-versus-complexity assessment applied to the real proposal set produced distinctions the room could inspect.
Decision
Encode friction, proposal, opportunity and initiative as related entities with defined evaluation criteria and decision states.
Trade-off
Explicit criteria constrain the sponsor's freedom to reorder the list.
Consequence
The model is auditable — a decision made through it can be traced back to its inputs.
Decision 03

Ship a working application instead of a diagram

A prioritization model presented as slides is evaluated as an opinion.

Evidence
The decision states, filters and comparisons only demonstrate their value when someone can operate them.
Decision
Use AI-assisted development to build a functional React, TypeScript and Vite application carrying the real initiative dataset, with technical fields left for Technology to complete.
Trade-off
It is an internal decision prototype — there is no collaboration layer and no production hardening.
Consequence
The initiative was approved for presentation to Business and Design as a working tool.

AI-assisted build workflow

The application exists because the model was specific enough to be built. AI covered implementation; the product logic did not come from it.

  1. 01 · Define

    • Product model
    • Structured context
    • PACEF prompt architecture

  2. 02 · Constrain

    • Requirements & constraints as acceptance criteria

  3. 03 · Build

    • Figma Make
    • AI-assisted prototyping

  4. 04 · Review

    • Critical review & manual correction
    • Iteration

  5. 05 · Output

    • Functional React application
    • React · TypeScript · Vite

The taxonomy, prioritization logic and design decisions were mine. AI shortened the distance between the model and something operable.

Evidence

Reserved slots for the project artifacts.

Constraints and trade-offs

  • AI accelerated implementation; it did not produce the strategy, the taxonomy or the prioritization logic.
  • I own the strategic approach, decision model, taxonomy, application architecture and dashboard behavior; a peer Product Designer supported the initiative.
  • This front is separate from the lead-distribution engine squad, where I hold design responsibility on a different initiative.

Outcome

The model, the prioritization logic and the application exist and hold the real initiative dataset. What remains is a technology evaluation once the technical fields are completed, and the first prioritization decisions actually taken through it.

The case will carry a stronger claim then. For now it stands on the model and the working tool.

Delivered

  • Complete opportunity model, taxonomy and prioritization logic.
  • Functional React application carrying the real initiative dataset.
  • An AI-assisted build workflow that produced a working tool rather than a proposal.

Not measured

  • Organizational adoption — the tool is not yet in use by Business, Technology or Design.
  • Any backlog or prioritization decision produced through the application.
  • Productivity or sales impact of any kind.

Next case

Chance of Success
All projects