Current GTM product roadmap

Raw source preview

Raw, unprocessed file text shown below. Preview truncated for readability.

export type ProductRoadmapHorizon = "now" | "next" | "later";

// Stable IDs join roadmap items to planning/roadmap-evidence-links.json.
export type ProductRoadmapItem = {
  id: string;
  title: string;
  fullWidth?: boolean;
  initiativeType?: string;
  effort?: "Small" | "Medium" | "Large";
  layoutOrder?: number;
  layoutSpan?: "Tall";
  layoutWidth?: "Wide";
  problem: string;
  currentUnderstanding: string;
  target: string;
  status?: string;
  completion?: number;
  closedIn?: string;
  closedNote?: string;
  caution?: string;
  whatWeKnow: string[];
  evidence: {
    source: string;
    note: string;
  }[];
  openQuestions: string[];
};

export type ProductRoadmapColumn = {
  horizon: ProductRoadmapHorizon;
  label: string;
  target: string;
  summary: string;
  items: ProductRoadmapItem[];
};

const productRoadmapSource: ProductRoadmapColumn[] = [
  {
    horizon: "now",
    label: "Now",
    target: "August-October 2026",
    summary:
      "Committed delivery work is ordered by its card-level target, from the end-of-August tranche through the end of October, including the Stripe purchase sprint targeted for the end of September.",
    items: [
      {
        id: "RM-001",
        title: "Multi-language translation functionality",
        initiativeType: "New Functionality",
        effort: "Medium",
        target: "End of June 2026",
        status: "Done",
        completion: 100,
        closedIn: "June 2026",
        closedNote: "Closed from the June launch-readiness tranche.",
        problem:
          "Researchers need to run multi-market studies in multiple languages while keeping all responses in one coherent dataset.",
        currentUnderstanding:
          "V1 supports multi-language surveys, Excel translation import/export, staggered market launches, translator access, and reporting filters by language or market. AI translation and automatic retranslation tracking are later.",
        whatWeKnow: [
          "Market and language are distinct, using locale-style codes such as fr-FR and fr-CA.",
          "Each market can launch independently as translations are ready.",
          "Translation QA includes real-time question-level preview and topline/crosstab filtering.",
          "Translator role support is part of the June roles work.",
        ],
        evidence: [
          {
            source: "Quantitative Research Platform / Survey Design",
            note:
              "Existing portfolio spec says translation support should reduce manual spreadsheet coordination and let teams review translations in context without repeated live survey tests.",
          },
          {
            source: "Roles and Permissions",
            note: "The Translator role exists as a defined platform role for translation-only access.",
          },
        ],
        openQuestions: [
          "What exact QA checklist confirms a translated market is ready to launch?",
          "How should outdated translations be handled when English source text changes after June?",
        ],
      },
      {
        id: "RM-002",
        title: "Trust Centre",
        initiativeType: "New Functionality",
        effort: "Medium",
        target: "End of June 2026",
        completion: 100,
        closedIn: "July 2026",
        closedNote: "Closed at the end-of-July roadmap cleanup.",
        problem:
          "Teams need to know whether survey data is real, unique, and engaged while fieldwork is still live, before poor-quality responses enter reporting.",
        currentUnderstanding:
          "June scope includes Real and Unique signals plus Engaged checks for open-end gibberish/relevance, adaptive speeding, attention checks, and carousel attention. Respondents are flagged for human review, not automatically removed.",
        whatWeKnow: [
          "Signals roll up into Real, Engaged, and Unique ratings.",
          "Critical respondents are those failing the Real / Engaged / Unique thresholds.",
          "Review decisions happen at respondent level.",
          "Rejecting a respondent removes them as a complete and updates quotas automatically.",
          "There are no daily review prompts in June scope.",
        ],
        evidence: [
          {
            source: "Survey Deployment / Trust Centre",
            note:
              "Portfolio materials frame Trust Centre as the live respondent-quality review layer for survey fieldwork.",
          },
          {
            source: "Trust Centre competitive analysis",
            note:
              "Competitive work positions the differentiator as transparent, human-reviewable data-quality control rather than a black-box quality score.",
          },
        ],
        openQuestions: [
          "What exact UI language should be used for respondent-level accept/reject?",
          "Which review states should be visible in toplines and fieldwork monitoring?",
        ],
      },
      {
        id: "RM-003",
        title: "Survey Redirect Question Type",
        initiativeType: "Existing Tool Improvement",
        effort: "Small",
        layoutOrder: 3,
        target: "End of August 2026",
        completion: 95,
        problem:
          "Researchers need to send participants into specialist external tasks without breaking completion, attribution, or respondent flow.",
        currentUnderstanding:
          "V1 is leave-and-return safely: redirect from a fixed survey point, pass configured URL parameters, return to the next question, and capture returned URL variables plus the exact outbound URL used.",
        whatWeKnow: [
          "Participant ID identifies the respondent across the redirect.",
          "Only complete-and-return is in scope for V1.",
          "There is no external completion validation in V1.",
          "The respondent returns to the next question after the redirect question.",
          "Complex data exchange is future scope; V1 is URL variable based.",
        ],
        evidence: [
          {
            source: "Quantitative Research Platform / Survey Design",
            note: "Survey Redirect Question Type already exists as a portfolio item marked near-term.",
          },
          {
            source: "Survey Deployment",
            note: "Existing deployment notes already mention routing and URL-variable capture patterns.",
          },
        ],
        openQuestions: [
          "How should researchers configure outbound and inbound parameters without making the setup feel technical?",
          "What troubleshooting surface shows the exact link delivered to each respondent?",
        ],
      },
      {
        id: "RM-004",
        title: "PureSpectrum sample provider integration",
        initiativeType: "New Functionality",
        effort: "Medium",
        layoutOrder: 2,
        target: "End of August 2026",
        completion: 95,
        problem:
          "Survey launch is slowed by external sample-provider coordination, project-manager handoffs, feasibility checks, and cross-platform setup.",
        currentUnderstanding:
          "V1 is in final implementation and QA for delivery by the end of August. It is a full PureSpectrum integration excluding sample boost and automated bad-sample reconciliation. Project Managers and above will configure sample, check feasibility, approve quotes, launch, soft launch/pause, close, and use respondent exclusions.",
        whatWeKnow: [
          "Quote approval is an explicit human step.",
          "Soft launch is included.",
          "Each PureSpectrum audience has one quota group.",
          "PureSpectrum respondent exclusion IDs prevent duplicate invitations across added audiences.",
          "Trust Centre quota updates happen in-platform, while PureSpectrum reconciliation remains manual for now.",
        ],
        evidence: [
          {
            source: "Survey Deployment / Direct Third Party Sample Integration",
            note:
              "Portfolio materials describe direct third-party sample integration as a way to deploy sample without leaving the survey platform.",
          },
          {
            source: "Ideas Log / survey-platform differentiation",
            note: "Native PureSpectrum integration is named as part of the platform's launch-control story.",
          },
          {
            source: "User roadmap update, 18 August 2026",
            note:
              "Desmond confirmed that implementation is finishing today and will move immediately into QA.",
          },
        ],
        openQuestions: [
          "What commercial/payment model should be used: pass-through, customer card, or connected PureSpectrum account?",
          "When should automated bad-sample reconciliation be added?",
        ],
      },
      {
        id: "RM-005",
        title: "Stripe purchase workflow",
        initiativeType: "Commercial Infrastructure",
        effort: "Medium",
        layoutOrder: 2,
        layoutWidth: "Wide",
        target: "End of September 2026",
        status: "Sprint planning",
        completion: 10,
        problem:
          "Prospective customers cannot yet buy the platform directly from the website and move cleanly from payment into account setup.",
        currentUnderstanding:
          "The sprint will put a Stripe-backed purchase path behind the website offer. It should let a customer choose the agreed subscription, pay by card, receive billing confirmation and continue into the correct organisation and administrator-account setup flow.",
        whatWeKnow: [
          "The selected commercial direction is a card-backed Research Workspace for one to five active builders, with a EUR 30 dormant workspace state between projects. Its checkout and entitlement controls remain launch work.",
          "Customers need online access to invoices, payment management and cancellation.",
          "A successful purchase must hand off reliably to tenant and administrator provisioning rather than ending at payment confirmation.",
          "The initial workflow should stay aligned with the approved public offer and the entitlements the platform can enforce.",
        ],
        evidence: [
          {
            source: "Founder GTM launch plan",
            note:
              "The launch plan names Stripe setup and end-to-end testing from website purchase through account setup, sign-in and first use as remaining launch work.",
          },
          {
            source: "Billing, Entitlements & Commercial Access",
            note:
              "The platform shared-services plan identifies payment methods, subscription lifecycle, invoices and runtime entitlements as the commercial foundation behind customer access.",
          },
        ],
        openQuestions: [
          "How should the EUR 260 active-builder price, EUR 30 dormant-workspace state, and Founder Research Cohort be represented in the first checkout?",
          "Which Stripe event should become the source of truth for tenant provisioning and entitlement activation?",
          "What recovery path is needed when payment succeeds but account or tenant setup does not?",
        ],
      },
      {
        id: "RM-006",
        title: "Email invitation workflow and test sends",
        initiativeType: "Platform Communications",
        effort: "Medium",
        target: "End of July 2026",
        status: "Done",
        completion: 100,
        closedIn: "July 2026",
        closedNote: "Closed as part of the end-of-July roadmap tranche.",
        problem:
          "Project teams need tighter control over audience-level invitations, reminders, email content, and test emails so launch checks do not depend on manual workarounds.",
        currentUnderstanding:
          "The completed slice covers per-audience invitation sending, per-audience email content editing, baseline reminder behaviour, invite-status capture for later reporting, and repeatable test sends to one or more preview recipients.",