Portfolio
Upstream System
Product Discovery 3 times faster, done by the whole design team
I designed and built an AI system that takes a loose idea to a requirement ready for development, going through research backed by real evidence and a navigable prototype. It runs on its own or with a person approving each step.
- Sector
- B2B SaaS
- Period
- June to October 2026
- Role
- Originator and lead builder
- Scope
- Discovery, Prototype and orchestration · co-author of the architecture
- Team
- 3 product designers as users
Metrics
- Discovery, with human approval at every step
- 12 days → 4 days
- -67% in time. Source: Before the system, With the system
- From problem to ready for development, in the best real case
- 49 days → < 1 day
- -98% in time. Source: Before the system, Branch self-management
- Discovery in 100% autonomous mode
- 12 days → 14 to 27 min
- whole pipeline in 1 to 4 h. Source: Before the system, Autonomous mode
The problem: Figuring out what to build was slow, handcrafted and dependent on a few people
I measured the old process in the Jira history: researching a request took about 12 days, and getting the request to the development team took about 49 days.
Depended on a specialist
Crossing interviews, usage data, support tickets and competitors required knowing how to do research. Whoever didn't know how, didn't do it.
A conclusion without proof
Decisions came from impressions ("customers ask for this a lot"), with no number, no source and no "how many out of how many?".
Rules lost along the way
Design showed the screen, but business and interface rules got lost on the way to development.
The solution: Six chained stages, each with a specialized persona and an approval gate
An orchestrator opens each stage, reads the result and stops wherever the configuration says to stop. Nothing becomes an official record without a person approving it.
Idea
captures and prioritizes (RICE, roadmap)
Problem
becomes a hypothesis to test, not a truth
Discovery
validates or knocks down the hypothesis with evidence
Prototype
navigable flow with the rules on screen
Requirements
each requirement points to its evidence
Launch
prepares sales, support and marketing
Parallel research
AI specialists research at the same time across recorded interviews, usage data, on-screen behavior, support, the market and the product itself.
Triangulation
A conclusion only counts with two independent sources. If both come from the same customers, they count as one.
Devil's advocate
An agent tries to knock down the verdict before it reaches a person. It has already downgraded verdicts for lack of proof.
Learns from corrections
Each human correction at an approval gate becomes a candidate rule. After 3 independent occurrences, it becomes a pattern.
Result: Each point is a real Discovery, measured in Jira
In gray, the same team's Discoveries in the first half of 2026, without the system. In green, the ones completed with the pipeline, with a person approving each stage.
- Without the system (Jan to Jun 2026)
- With the system (Sep 2026)
- median
See the chart data as a table
| Who | Before (days) | With the system (days) |
|---|---|---|
| Designer A | 7, 18 | 1, 4 |
| Designer B | 6, 6, 12 | 6 |
| Designer C | 30, 62 | still in progress |
| Whole team | median 12 | median 4 |
- faster Discovery with a person following each step (median from 12 to 4 days). Source: With the system
- 3×
- from the problem written down to an epic ready for development, in a real case. Source: Branch self-management
- < 24 h
- numbered pieces of evidence in a single Discovery, in the same time a Discovery used to take before. Source: Inventory report
- 98
Adoption: All three designers on the team used the pipeline on real projects
The pipeline left a record on 10 epics between July and October 2026. Source: Adoption
Designer A
- Before
- Discovery in 7 and 18 days
- With the system
- Discovery in 1 and 4 days
Took a request from problem to "ready for development" in under a day. It is already in development. Source: Designer A
Designer B
- Before
- Discovery in 6, 6 and 12 days
- With the system
- Discovery in 6 days
Kept the time and greatly increased the depth: 11 hypotheses, 98 pieces of evidence and every item validated by her. Source: Designer B
Designer C
- Before
- Discovery in 30 and 62 days
- With the system
- evidence in 4 days, no approval yet
Started using it in September. Because no Discovery was completed, this one is left out of the gain calculation. Source: Designer C
| Request | Who | Stages used | Discovery | Status |
|---|---|---|---|---|
| Customer self-management of branches | Designer A | all six | 1 day | in development |
| Dashboard customization | Designer A | Problem → Requirements | 4 days | approved |
| Inventory report | Designer B | Problem → Prototype | 6 days | prototype in progress |
| Offline collection | Designer B | Discovery | done outside the record | in review |
| Field team productivity | Designer C | Discovery | in progress | open |
| 5 other requests | A, B and C | Problem only or Requirements only | no measurement | partial |
End-to-end case: Branch self-management: from problem to development in under a day
Designer A went through all six stages, with approval at each one. Before the system, reaching the development team took 49 days on average.
"Discovery doesn't prove you were right. It finds out whether you were."
- Discovery task opened on the epic
- Problem written as a hypothesis and recorded
- Discovery completed and approved
- Navigable prototype approved
- Requirements recorded; epic ready for development
- In development
Two modes: The same pipeline runs alone in minutes or with a person following along in days
In autonomous mode, the system itself times each stage. These are the machine times of four complete test runs.
- Discovery
- other stages
See the chart data as a table
| Run | Idea | Problem | Discovery | Prototype | Requirements | Total (min) | Run duration |
|---|---|---|---|---|---|---|---|
| Bulk registration | 10 | 4 | 14 | 19 | 22 | 69 | 4.1 h |
| Unify services | 4 | 21 | 20 | 16 | 9 | 70 | 1.1 h |
| Checklist backlog | 22 | 3 | 17 | not listed | 7 | 49 | 1.1 h |
| Maintenance | 48 | not listed | 27 | not listed | 6 | 81 | 3.0 h |
What I learned: Rigor became an automatic rule, not a good intention
The most dangerous error doesn't look like an error
A beautiful prototype with an invented screen or a number without a denominator slips by unnoticed. That is why the safeguards became automatic checks.
"I didn't find it" is not "it doesn't exist"
Several rules were born from searches that came back empty and were wrong.
Autonomy needs a safeguard
Two modes solved this: the same quality, with the person choosing how closely to follow along.
Admitting it doesn't know builds trust
The system became more trustworthy once "data is missing" became a valid result.
How to read these numbers: What the measurement shows and what it does not show yet
- The sample is small. That is 3 Discoveries completed with the system against 9 from the same team before it. The gain is an order of magnitude, not a stable average.
- The days are calendar days. They include the wait between approvals. Each person's working time was not measured separately.
- In the under-one-day case, the clock starts when the problem was written down. The idea had already been waiting in the backlog queue for weeks.
- The minute-level runs are tests. They show the speed ceiling. Investment decisions still go through a person.
How I measured
The calculation, method and limit behind each number. Open an item to read it.
Before the system
Discovery: 12 days
Median of the research task across 9 projects by the three designers, from November 2025 to July 2026 (from 2 to 30 days). A second sample, covering only the first half of 2026, gives a similar median, 15 days: 6, 6, 7, 12, 18, 30, 40 and 62 days.
Until development: 49 days
Median of 11 projects, from the request entering Discovery to leaving for the development queue: 11, 21, 21, 21, 30, 49, 52, 56, 73, 121 and 156 days. Without the two longest, the median is 30 days.
How I measured
Status change history of each item in Jira.
Limit
Tasks closed within minutes (record-keeping only) were left out. Some were closed in Jira after the real end of the work.
With the system
Calculation
Three Discoveries completed and approved with the pipeline: 1, 4 and 6 days. Median 4 days, against 12 before: 67% less time, about 3 times faster.
How I measured
A Jira search for the comments the pipeline writes at each stage, plus the creation and completion dates of the Discovery tasks.
Limit
Calendar days, with human waiting time included.
Branch self-management
Timeline
- Day 1, 11:31 a.m.: Discovery task created
- Day 1, 12:22 p.m.: problem recorded
- Day 2, 8:51 a.m.: Discovery completed
- Day 2, 8:57 a.m.: prototype approved
- Day 2, 8:59 a.m.: requirements recorded, epic marked as ready
Calculation
From the problem written down to the requirements: about 21 hours. Against a median of 49 days before, 98% less time.
Limit
The idea had already been in the backlog for weeks, just waiting in the queue. The clock starts when the problem was written down.
Autonomous mode
Calculation
Machine minutes per stage, recorded by the system itself at the start and end of each one:
- Bulk registration: Idea 10, Problem 4, Discovery 14, Prototype 19, Requirements 22 (4.1 h run)
- Unify services: 4, 21, 20, 16, 9 (1.1 h)
- Checklist backlog: Idea 22, Problem 3, Discovery 17, Requirements 7 (1.1 h)
- Maintenance: Idea 48, Discovery 27, Requirements 6 (3.0 h)
Limit
These are test runs. The record keeps only the last pass of each stage.
Inventory report
Calculation
11 hypotheses and 98 numbered pieces of evidence, verdict reformulated. Three approval gates approved by the designer over 4 consecutive days (problem, needs and solution proposal). The system's own audit fixed 15 problems, 12 of them blocking, before the work reached the designer.
How I measured
Discovery report and the run's evidence log.
Designer A
Before
7 and 18 days (creation to completion of the Discovery task, first half of 2026).
With the system
1 day (branch self-management) and 4 days (dashboard customization). She also used only the requirements stage on a third request.
Designer B
Before
6, 6 and 12 days.
With the system
6 days on the inventory report, with 98 pieces of evidence. She used the problem stage on three other requests and published the offline collection Discovery.
Designer C
Before
30 and 62 days (the second includes a prototype).
With the system
She wrote one problem with the pipeline (the request was dropped later) and started a Discovery: evidence published 4 days after the start, still without a report or approval.
Limit
Since no Discovery was completed, it does not enter the gain calculation.
Adoption
Calculation
10 epics with comments recorded by the pipeline between July and October 2026: Designer A, 3; Designer B, 5; Designer C, 2.
How I measured
A Jira search for the mark the pipeline leaves at each stage. The same search, filtered by person, finds the already known cases, which shows it finds what exists.
Upstream System · case by John Morais · data measured in October 2026 from the Jira history and the system's execution logs. Names of people, the company and the requests were changed for confidentiality.