← Back

CLADE · PRODUCT QUALITY & AUTOMATION

Turning customer friction into faster product fixes.

Built routines to observe enterprise trials, turn product issues into actionable engineering stories, and expand end-to-end test coverage at approximately one-fifth of the previous solution's cost.

Enterprise trials · Observability · Workflow automation · E2E testing

AI Senior Product Manager · Jul 2025 – Sep 2026 · New York / Remote

CUSTOMER EXPERIENCE → PRODUCT QUALITY

  1. Observe

    Trial activity

  2. Investigate

    Session and error evidence

  3. Fix

    Engineering story

  4. Verify

    E2E and CI checks

Clade builds AI-powered software for institutional investment research and diligence. My work focused on understanding how trial teams experienced the product and shortening the path from friction to investigation, engineering follow-up and release.

Understand what trial teams actually experienced

Enterprise trials typically lasted around two weeks, making it important to see where users were progressing and where they were getting stuck. I created recurring monitoring routines and a Trial Watch dashboard that combined activity data, qualitative observations and LogRocket session and error evidence.

The goal was to connect what a client was trying to achieve with the behavior and issues visible in the product.

  1. OBSERVE ACTIVITY

    Review sessions, usage and attempted workflows.

  2. INSPECT FRICTION

    Bring together errors, captured product states and qualitative observations.

  3. IDENTIFY FOLLOW-UP

    Turn those findings into a clear picture of what needed investigation or a fix.

ANONYMIZED SCREENSHOTTrial Watch combined trial activity and user-level observations to focus investigation. Session evidence came from LogRocket exports; names, emails, locations and institution are masked.
Anonymized Trial Watch dashboard showing activity totals and a user activity table.

Turn observations into engineering follow-through

Visibility mattered when it led to action. I automated the creation of engineering stories from trial findings and routed issues to engineers so the team could investigate and ship fixes quickly. I coordinated end-of-day cherry-picks for ready fixes.

ANONYMIZED SCREENSHOTSession observations connected what a trial user attempted with a specific issue requiring investigation. Names, fund and company references are masked.
Anonymized Trial Watch session summary with observations and a highlighted issue to investigate.

  1. 01

    Trial activity

  2. 02

    Session and error evidence

  3. 03

    Issue investigation

  4. 04

    Automated engineering story

  5. 05

    Engineering fix

  6. 06

    Validation and release follow-up

Automation supported the monitoring and handoff; engineering still owned investigation, implementation and the release checks. The aim was fast follow-through during trials, not an unattended production-release pipeline.

Expand regression coverage at a lower cost

Alongside the trial-feedback loop, I built an internal end-to-end testing approach to check important product journeys repeatedly. Playwright tests and nightly runs provided a complementary signal to customer observations, while AI-assisted triage supported failure investigation and proposed repairs.

~1/5 the previous solution costINCREASED E2E COVERAGE

  1. 01

    Playwright runs in CI

    Nightly and on-demand Playwright runs execute in GitHub and send their results onward.

    NIGHTLY CI RUNILLUSTRATIVE
    Check out the repositorySTEP 1
    Run Playwright testsSTEP 2
    Send results to the reporting dashboardSTEP 3

  2. 02

    Results land in a dashboard

    TestDino collects each run, keeping retries, history and error details per test.

    TEST REPORT DASHBOARDILLUSTRATIVE
    Passed
    Flaky
    Failed

    Each test keeps its history, retries, traces and error details.

  3. 03

    A routine reads and summarizes

    A scheduled Claude routine pulls the results and posts a summary to Slack: passed, flaky, not recovered and failed.

    NIGHTLY E2E SUMMARY · TEAM CHANNELILLUSTRATIVE

    Posted by the scheduled routine

    Example journeys that passed cleanlyPASSED
    Failed once, passed on retryFLAKY
    Still open for human reviewNOT RECOVERED
    Failed on every attempt · story linkedFAILED

  4. 04

    Stories are created for real failures

    Tests that keep failing across retries get a Shortcut story with the test link and reproduction steps, assigned to an engineer. Stories often arrive with a suggested fix as a pull request from Claude.

    ENGINEERING STORY · CREATED AUTOMATICALLYILLUSTRATIVE

    Example journey failing after 3 attempts

    OWNER
    Assigned to an engineer
    EVIDENCE
    Link to the failing test, error and trace
    REPRO
    Steps to reproduce the failure
    FIX
    Suggested pull request drafted with Claude

  5. 05

    A person stays in the loop

    Failed tests come first, then flaky ones. Someone reproduces the issue, an engineer reviews the suggested fix, and the test re-runs before it counts as fixed.

    HUMAN REVIEWILLUSTRATIVE
    Reproduce the failure and check the report
    Engineer reviews the suggested fix
    Fix keeps the intended assertion, not just a passing run
    CI re-runs the test before merge

Illustrative mockups of each step, built without real data. They show the shape of the workflow, not actual test results or customer information.

A failing test needed to be investigated: it could reflect a product defect, an outdated test or an environment problem. Repairs needed to preserve the intended behavior being tested, rather than simply make the run pass.

What I owned and what changed

TRIAL VISIBILITY

Created monitoring routines and a dashboard connecting quantitative activity with qualitative feedback and session evidence.

ENGINEERING FOLLOW-THROUGH

Automated story creation and coordinated rapid fixes and release follow-up during trials.

REGRESSION COVERAGE

Built the internal E2E approach and supporting investigation workflow, increasing coverage at approximately one-fifth of the previous solution's cost.

These efforts gave the team two complementary views of quality: what customers experienced in practice and what repeatable tests could check before the same workflows regressed.

Product quality depends on a repeatable path from evidence to action—and checks that help the team maintain that progress.