ProductOS — decisions that leave a trail.

01 — The problem

Engineering has Git. What about product decisions?

In engineering, almost every important change leaves a trail. A commit shows what changed. A pull request shows the context. History makes it possible to see who changed it, when and why.

In Product, the picture is often different. A decision may start in a meeting, on Slack, in an interview, in Analytics, in a support ticket or in a sales request.

Months later, the team finds the same decision and cannot answer the essential question:

Why did we do this?

That pile-up of lost context is the problem I call Decision Debt.

03 — The idea

A continuous causal graph for the product

The core hypothesis of ProductOS is that a decision must stay connected to the context that produced it.

Continuous Causal Graph

That chain is the Continuous Causal Graph of ProductOS. Each element answers a different question — and stays linked to the others.

04 — The Product Loop

The product cycle does not end at delivery

The full flow was structured so learning returns and becomes part of the context of the next decisions.

1. Discovery→
2. Signals→
3. Insights→
4. Opportunities→
5. Prioritization→
6. Hypothesis→
7. Experiment→
8. Result→
9. Decision→
10. Learning
11. ↺learning feeds the cycle again

07 — Finding the problem

The problem did not come from a single source

Onboarding telemetry showed a significant drop at the bank-setup step.

Crossing that metric with support tickets revealed a pattern: new customers were struggling to import and interpret bank files.

The problem was identified by triangulating quantitative and qualitative data — not from a single source.

08 — From evidence to opportunity

Turning an observation into a work object

From the signals, the PM can create a structured Opportunity.

Direct bank connection via Open Finance

That turns an observation into a Product work object.

09 — Prioritization

An explicit criterion makes the decision transparent

ProductOS uses an ICE matrix to structure prioritization: Impact × Confidence ÷ Effort.

The opportunity then sits first among those evaluated in the scenario. The point is not to claim ICE is the only method — it is to show how an explicit criterion makes the decision more transparent.

10 — Hypothesis

A hypothesis has to be testable

If we connect bank accounts via Open Finance, for new customers during onboarding, we expect bank-setup completion to rise from 42% to over 60%, because the data indicate that a relevant share of drop-off is tied to importing and reading OFX files.

11 — Experimentation

The hypothesis becomes an experiment

A/B test

12 — Result

The experiment produces evidence — not just an opinion

These numbers belong to the case's demonstrative dataset, used to simulate the full decision loop.

13 — Decision Log

Git Blame for Product

SCALE

The decision records outcome, rationale, owner, next steps, evidence and learning — and stays attached to the context that originated it.

• What did we decide?
• Why?
• Based on what?
• What happened next?

The decision history works like Git Blame for Product: not to track code, but to answer those four questions.

19 — Technical architecture

A working web app, not a mock

ProductOS was built as a navigable product, with domain rules and local-first persistence.

20 — An important technical decision

Product state cannot skip steps

One principle was to block inconsistent transitions. An opportunity should not be marked Resolved without a formal decision attached.

1. Opportunity→
2. Investigating→
3. Prioritized→
4. Experiment→
5. Resolved

That rule is enforced by the persistence engine. Technology does not only store information — it helps preserve product logic.

21 — Internal structure

Components aligned with the domain

The component architecture follows the product's core concepts, instead of being organized only as generic screens.

src/
├── main.tsx
├── App.tsx
├── types.ts
├── data/
│   ├── nuvemdesk-seed.ts
│   └── storage.ts
└── components/
    ├── Navigation
    ├── DashboardView
    ├── OpportunitiesView
    ├── OpportunityDetailModal
    ├── InsightsView
    ├── ExperimentsView
    ├── DecisionsLogView
    ├── AICopilotDrawer
    ├── PortfolioCaseModal
    ├── NewOpportunityModal
    └── GuidedTourBanner

22 — MVP

Scope meant to prove a core hypothesis

Can the full product decision loop live in a single, traceable experience?

That is why the first scope focused on what was essential to walk the loop.

Broader features can come later. The MVP exists to prove the concept, not to exhaust it.

23 — Guided Tour

The product itself demonstrates the case

Because the product was created as a portfolio case, there is a guided tour. The goal is for someone who has never used the platform to grasp the concept quickly.

Signal → Insight → Opportunity → Hypothesis → Experiment → Result → Decision