--- title: "Product management proof of work" description: "Ayush Rai on product management: a RevenueRoles case study that separates the live job product from hypotheses, proposed requirements, and unmeasured outcomes." canonical: "https://www.ayushrai.site/pow/product-management/" last-updated: "2026-10-19" --- # Product management proof of work Source: https://www.ayushrai.site/pow/product-management/ Markdown: https://www.ayushrai.site/pow/product-management.md Ayush Rai on product management: a RevenueRoles case study that separates the live job product from hypotheses, proposed requirements, and unmeasured outcomes. I turn ambiguous problems into products people can use. I work across problem discovery, product strategy, prioritization, engineering, and measurement to build products that solve practical problems. Start with the problem. Make the trade-offs explicit. Ship the smallest useful solution. Measure what happens. Improve from evidence. This page is a notebook about RevenueRoles. It is not a claim of product-management leadership, and it reports no user or revenue outcomes. ## Verified facts - On 19 October 2026 the homepage at revenueroles.in titled itself “The job board that knows GTM Engineer isn't Sales Ops.” It says RevenueRoles discovers roles from supported ATS and career sources, extracts complete descriptions, verifies publishing eligibility, and classifies them into a Revenue-Technical taxonomy. - That same homepage reported 71 verified roles currently published, updated 23 September 2026, 10:29. It also reported 41 jobs with compensation fields, 58% compensation coverage, and 0 categories with at least 5 salary samples. It says tiny samples are not shown as averages. These are the site's inventory counts, not user or revenue numbers. - The homepage names the pipeline as discover, extract, verify, classify, publish. Verify is described as checking source availability, application status, freshness, and publishing eligibility. Publish is described as showing verified, searchable roles with complete descriptions and direct application paths. - Public browse, as the homepage states it, shows only active, verified, canonical jobs. Application destinations are resolved and closed roles disable Apply. Search tips on the page include terms such as GTM Engineer, Salesforce, Remote, or Bengaluru, and say a salary phrase such as $150k is parsed into a minimum compensation filter when possible. - The homepage lists taxonomy families with live counts, including Forward Deployed Engineer (35), AI Sales Engineer (17), and Revenue Architect (7). Conversational AI Engineer and Demand Gen Engineer showed no live examples. It names candidates exploring specialized revenue-technical work, and recruiters who need accurate classification. It explicitly does not claim 45,000 live ATS endpoints, H-1B cross-referencing, or talent alerts. - This site's product record, written from the repository, names the stack as Next.js, a Python FastAPI classification worker, Supabase Postgres with pgvector, Inngest, and Vercel, and names Greenhouse, Lever, Ashby, and RemoteOK as source connectors. The homepage itself says “supported ATS and career sources” and does not list those four names. I did not re-read the repository source while writing this page. - The same product record says the homepage and the jobs API had production deploys recorded in July 2026. Sign-in, profiles, resume parsing, and admin screens are implemented but not all verified in production. Saved jobs, applications, and notifications are not built. There are no user or revenue numbers. ## Hypotheses - Relevant revenue-technical openings are scattered across employer boards, so a title search misses roles whose titles do not match the work. - The same opening can appear more than once, and a person cannot tell which copy is the one to trust. - A description and a taxonomy label may still leave the apply-or-skip decision under-specified. - Listings go stale, and a date on a card is not enough unless the reader knows what the date means. - Evaluating and tracking opportunities is fragmented once the person leaves the listing. - The useful outcome is a better decision about where to spend application time, not a larger pile of titles. ## Open questions - What does the date on a listing card refer to: the employer posting date, the last verification, or the ingest time? - Which fields the duplicate rule compares, and how often two sources disagree. - Whether a candidate uses the taxonomy to reject a poor match, or only to browse. - Whether recruiters are a real second user, or a sentence on the homepage. - How often a published listing is closed, relocated, or rewritten at the source after it is shown. - Whether anyone returns to a listing. Saved jobs are not built, and no return visit is measured. ## Scoring formula Score = ((user value × 0.60) + (strategic alignment × 0.40)) × (confidence ÷ 5) ÷ (effort × (1 + 0.15 × (risk − 1) ÷ 4)). - The 1–5 inputs are ordinal judgments, not interval measurements. A five is not “five times” a one. - Confidence is my uncertainty about the evidence. It is not a statistical confidence interval. - Dividing by effort punishes large work even when that work is the right work. The rank is a prompt for a conversation, not a decision by itself. - The risk penalty is mild and linear. A single unacceptable risk, such as dropping apply links, should veto a design even if the score is high. - None of the scores come from user research, a revenue model, or measured adoption. ## Experiment The freshness-label experiment is proposed. It has not been run. No statistical significance is claimed. ## Analytics The funnel counts on the HTML page are synthetic demonstration data. They are not RevenueRoles performance. Baseline not yet measured. Live product: https://revenueroles.in Repository: https://github.com/ayushrai-hub/RevenueRoles _Unverified award metrics are omitted. Wording matches the public site._