Skip to main content

​
How We Ship and Enable: The Fiddler Product-to-Field Process

This doc describes the end-to-end loop from engineering work to field readiness. It covers who owns what, when things happen, and where to look. Everyone at Fiddler should read this — engineering, product, and field teams alike.

​
The One Rule

The GitHub Project board is the single source of truth for what we’re building and where it stands.Board: Product Roadmap | VOC / Intake view: Intake ViewIf a conversation happens in Slack, a customer call, or a meeting and it results in a commitment or decision — it must be documented in a GitHub issue on this board, or it doesn’t count. No exceptions. Slack is where we talk; GitHub is where we plan.

​
The Bi-Weekly Heartbeat

Everything runs on a two-week cycle anchored to Tuesdays. The pattern alternates:
WeekTuesday EventWhat Happens
Week 1Release TuesdayBranch is cut at 9:00 AM PT. Code in main by EOD Monday or it waits two weeks.
Week 2Deploy TuesdayRelease goes live to SaaS customers. On-prem customers get every other release (monthly).
This cadence drives everything else — planning, enablement, and communication all sync to it.

​
Who Owns What

You own your tickets. This means:
  1. Keep your issues updated on the GitHub Project board — status, notes, blockers. At minimum, update weekly. If EPD leadership reviews your ticket on Tuesday morning and the status is stale, that’s on you.
  2. Write release notes when you merge. When your feature PR merges, add release notes in the docs/ folder as part of the same PR (or a companion PR merged at the same time). Don’t wait. The goal: when we cut the release branch, a draft of the release notes already exists. Our docs editor should be editing your words, not chasing you down to find out what shipped.
  3. Own your feature end-to-end through production — testing, documentation, feature flags, alerts, runbooks, upgrade plans. You are delivering working software, not just code.
  4. Hit the Monday deadline. All completed code must be merged to main by end of day Monday before Release Tuesday. Nightly tests run overnight; the branch cuts at 9:00 AM PT. Miss it, and your work ships in two weeks.

​
The Weekly and Bi-Weekly Rhythm

Here’s how a typical two-week cycle flows:
DayWhatWho
MondayCode freeze — all feature code merged to main by EODEngineers
Tuesday AMRelease branch cut at 9:00 AM PTEngineering (automated)
Tuesday (pre-noon)EPD leadership pre-screens new intake issuesEPD Leadership
Tuesday noonVOC Tracker meeting — review new intake with fieldEPD + Field
Thu / Fri”What’s Coming When” digest sent to fieldPM
Thu / FriDocs added to GitBook (not yet public)Docs Editor

​
The “What’s Coming When” Digest

This is a short, field-facing summary updated monthly aligned with the on-prem release schedule. It answers three questions SEs need for customer and prospect conversations: What just shipped? — SEs can demo and reference these features now. What’s coming in the next 30-60 days? — Committed items SEs can mention in trials and conversations, with appropriate caveats. What is NOT on the near-term roadmap? — The most important section. Prevents over-promising. If a prospect asks about something in this bucket, SEs know to set expectations honestly. The digest maps directly to the GitHub Project statuses defined in the VOC Tracker section below:
Board StatusDigest Section
Done✅ Just Shipped
In Progress / In Review🔨 Coming in ~30 days
Ready🔨 Coming in ~30 days
Backlog📅 On the Horizon (60-90 days)
Intake / No status🚫 Not Near-Term
Activation: Each digest is accompanied by a 15-minute standup — don’t just drop a doc in Slack and expect people to read it.

​
Release Notes: The Handoff Chain

This is the sequence that ensures release notes exist without anyone chasing anyone:
1

Engineer merges feature PR

Includes draft release notes in docs/ in the same PR.
2

Release branch is cut (Tuesday 9 AM PT)

All draft notes for this release already exist in the branch.
3

Docs editor polishes

The drafts are refined into final release notes and added to GitBook.
4

Docs go live

Available on site on Release Tuesday, made default once deploys are ~halfway through SaaS customers.
If you’re an engineer and you’re wondering “what should I write?” — describe what the feature does, who it’s for, and any breaking changes or migration steps. Two to three sentences is fine. The docs editor will handle tone and formatting.

​
VOC Tracker Meeting

When: Every Tuesday at noon | Who: EPD leadership + field teams | Purpose: Review incoming customer/prospect requests and ensure they’re captured and prioritized. How it works:
  • Field team brings requests with context (customer, use case, urgency).
  • EPD leadership has already pre-screened new issues that morning.
  • Every request discussed must result in a GitHub issue on the board, or a clear decision not to pursue (with reasoning noted).
  • This is not a roadmap negotiation meeting — it’s a triage meeting. Prioritization decisions happen in EPD planning.

​
VOC Tracker Statuses

Every issue on the Intake View has one of the following statuses. If you’re a field team member checking the board, here’s what each one means:
StatusWhat It Means
IntakeEPD is considering this request or gathering/waiting for more information. It has not been committed to yet.
BacklogAgreed — we will do this, but it has not been prioritized or scheduled yet.
ReadyEPD has the details it needs and has prioritized it into an engineering sprint. Work will begin soon.
In ProgressActively being built.
In ReviewThe work is in the process of getting into the product, or is already in the product but is waiting for feedback from at least one customer before being considered complete.
DoneShipped and complete.
These statuses flow left to right: Intake → Backlog → Ready → In Progress → In Review → Done. TLs are responsible for moving their tickets through these stages and keeping them current (at minimum, weekly).

​
On-Prem Cadence

On-prem customers receive every other release (monthly). The enablement digest is aligned to this monthly cadence so SEs have a single, predictable source of truth for both SaaS and on-prem customer conversations.

​
Where Things Live

WhatWhere
Product roadmap (source of truth)GitHub Project — Roadmap View
VOC / Intake trackingGitHub Project — Intake View
Draft release notesdocs/ folder in the repo (written by engineers at merge time)
Published docsGitBook (syncs with GitHub)
“What’s Coming When” digestPinned in Slack + linked from enablement hub
Enablement assets (later)Notion or Confluence (TBD)

​
Definition of Ready (DoR)

The DoR is the gate into development. A ticket cannot move from Design to Ready for Dev unless it meets all of the following.
  • User Story: Clear value statement — As a [persona], I want [action], so that [benefit].
  • Acceptance Criteria (AC): A bulleted list of functional requirements that define “done” for this feature.
  • Success Metrics: (Optional but recommended) How will we measure the impact of this change?
  • Figma Link: A direct link to finalized, high-fidelity designs or prototypes.
  • Edge Cases: Designs must account for empty states, error states, and loading states.
  • Assets: All necessary icons, images, or specialized fonts are available for export.
  • Technical Grooming: The engineering lead or pod has reviewed the ticket and confirmed it is technically feasible as described.
  • Dependencies: Any third-party APIs or internal service dependencies are identified and accessible.
  • Estimation: The ticket has been pointed or estimated to ensure it fits within a standard sprint cycle.

​
Definition of Done (DoD)

The DoD is the gate out of development. An item cannot move to Done unless it checks every box below.
  • Code Review: At least one peer has approved the Pull Request.
  • Testing: Unit tests are passing and automated regression tests haven’t failed.
  • Staging: The code is deployed to a staging/UAT environment and verified.
  • Documentation: Any new API endpoints or logic changes are updated in the README or Wiki. Release notes are written in docs/ as part of the merge PR.
  • Operational Metrics: Alerts, dashboards, and runbooks are in place.
  • Acceptance Criteria Met: All bullet points from the original ticket are functional.
  • Design QA: The designer has reviewed the UI in a staging environment to ensure spacing, colors, and interactions match the Figma.
  • Analytics: Event tracking (if required) is firing correctly.
  • Merged: The branch is merged into main.
  • Clean Up: The feature flag is toggled ON (if applicable) and the temporary branch is deleted.
If any of these are missing, the feature is not done and should not be communicated to the field.

​
Guiding Principles

  • The board is the plan. If it’s not on GitHub, it’s not happening.
  • Releases are time-based, not feature-based. The train leaves on Tuesday whether your feature is on it or not.
  • Engineers own delivery, not just code. Testing, docs, flags, runbooks — all of it.
  • Write it when you ship it. Release notes at merge time, not after the fact.
  • Communicate early, communicate honestly. The field would rather hear “not yet” than find out a promise can’t be kept.
Last modified on March 23, 2026