Skip to main content
강홍재/ James

Product Lab

Experiments in motion.

Experiments I'm running while building on the side. Each card's Next experiment is one line on what to try next and what it would falsify. This is a board of moving hypotheses, not a list of wins.

  • Buildingsolo build, top priority this quarter

    DocuStory - accuracy validation

    Problem
    DocuStory exists, but until I shake the accuracy out against real data, I can't decide whether to push it as the top business candidate.
    Target user
    People involved in Korean real-estate transactions (B2C → B2B candidate)
    Next experiment
    Run the analyzer over 100 real documents and measure accuracy. Interview one real-estate practitioner on whether the score is something they'd actually use in a decision.
  • Idearevive candidate

    Jira dedup - revive as a consulting tool

    Problem
    In orgs running large Jira instances, the cost of "the same issue being filed over and over" piles up invisibly. The embedding-based CLI exists but has been idle for almost a year - without a PoC inside my own network, it stays buried.
    Target user
    QA leads and PMs with multi-thousand-issue backlogs
    Next experiment
    Run a PoC at 1-2 companies in my network - "I'll run it against your Jira and hand you a dedup report." Based on the response, decide whether to package it as an Atlassian Marketplace App.
  • Buildingsolo build

    ReleaseGate v2 - keep the decision trail

    Problem
    GO/HOLD calls made in a release meeting become "why did we go that way?" months later. The decision and the reasoning aren't preserved together.
    Target user
    Whoever owns the release call - PO/PM, QA leads, EMs
    Next experiment
    Show 5 users a "release decision log" prototype that captures the score, the comments, and the dissent on one card.
  • Iteratingopen source, alpha

    Frameboard - keep the debate next to the score

    Problem
    Priority scores look like consensus, but the conversation that led to them vanishes. The result stays; the thinking evaporates.
    Target user
    PO/PM running team-level prioritization workshops
    Next experiment
    Force a one-line "why this score?" into every cell, then measure whether meeting time goes down or whether the spread on scores narrows.
  • Ideawriting first

    QA → PO/PM transition content

    Problem
    People moving from QA engineering into PO/PM don't have a clear map of "what carries over and what has to be left behind."
    Target user
    5-10 year QA engineers looking to get closer to product decisions
    Next experiment
    Write a single piece - "10 assets a QA engineer carries into a PO role" - and see which items resonate the most.
  • Buildingpersonal experiment

    A time OS for solo builders

    Problem
    Anyone building solo has to decide every morning how to split the day between "product / discovery / recovery." Without a system, the most urgent thing wins by default.
    Target user
    Me (n=1), running a job and a side build in parallel
    Next experiment
    Every week, record the ratio of "hours I got pulled into" vs "hours I intended" as one line. Compare patterns after 4 weeks.