Skip to content

Operating system for engineering teams · Product dossier · 2025 ed.

Five chapters on how Zilzul helps your team ship more without one more meeting.

A skeptical, deep-dive walkthrough of the velocity-first workspace built by two former Stripe and Asana engineering managers: the async standup engine, auto-generated release notes, cycle-time analytics validated by Google Cloud's DORA research team, a public roadmap that ships 1,847 community requests since 2021, and the Linear-class performance that holds up at 50,000 tickets per workspace. Written for engineering managers who don't have time for fluff.

  • 01 Async standup engine
  • 02 Auto release notes
  • 03 Cycle-time analytics
  • 04 Public roadmap
  • 05 Linear-class speed
Start a free sprint

14 days. No credit card. Work email only · Median first sprint in 11 minutes.

Flat editorial screenshot of the Zilzul sprint board with tickets grouped by status column.
fig. 00 — sprint board, today, 09:14 PT
  • 3,400+teams
  • 71countries
  • 38%more story pts
  • 4.2fewer mtgs/wk

Chapter 01 · Async standup engine

Replace the daily standup with a written update your team will actually read.

Zilzul's standup engine reads commits, ticket transitions, and PR activity between yesterday 5pm and today 9am, then drafts a per-person update in the voice of your team. No bots to ping. No Slack threads to scroll. No "yesterday: standup; today: standup" entries. The 91% number below is the share of daily syncs our customers formally cancelled in the first 60 days.

Generated async standup digest grouped by team member with blockers and progress.
fig. 01 — async standup engine, output for Tue, 09:00

What it actually does

Written updates, pulled from the work — not from a meeting.

The engine watches your ticket activity and merged PRs, then assembles a per-person summary with three fields: shipped, in flight, blocked on. It learns your team's vocabulary over the first two sprints, so the output reads like a teammate wrote it — not a parser.

  • i.

    Pulls from where the work already lives

    GitHub, GitLab, Bitbucket commits and PRs. Linear, Jira, GitHub Issues tickets. Optional Figma comments for design work. No new place to type into.

  • ii.

    Posts where engineers already read

    One digest per team at 09:00 in the timezone you set, posted to a Slack channel you choose. Engineers can mark items done with a single emoji react — no login required.

  • iii.

    Escalates blockers to a human, not a thread

    If three or more updates flag the same dependency, Zilzul opens a single triage ticket assigned to the EM with all three blocks inlined — not another Slack DM to forget about.

Average customer reports 4.2 fewer meetings per engineer per week and 91% of daily syncs cancelled within the first 60 days (Forrester TEI study, 2024).

Chapter 02 · Auto release notes

From merged PR to customer-facing changelog in one click.

Release notes are the write-up ritual nobody owns. Zilzul drafts them from the same source of truth the standup engine watches — merged pull requests, shipped tickets, and accepted Linear/Jira issues — and publishes them to a branded changelog and a Slack announcement in one click. Editors stay in the loop, but the first draft is already done by Tuesday morning.

  1. 01

    Pick a window

    Choose a release tag, a sprint, a merge-to-main branch, or an arbitrary date range. The engine scopes itself to the work that actually shipped in that window.

  2. 02

    Review the draft

    PR titles become user-facing bullets, grouped by product area with the right verb tense. Editor rewrites any line in place — the AI learns your phrasing for next time.

  3. 03

    Publish once, broadcast twice

    One click pushes to your branded /changelog, posts a Markdown announcement to a Slack channel, and notifies the customers who upvoted those features on your public roadmap.

Teams reclaim an average of 3.1 hours per release previously spent writing notes from memory (Forrester TEI study, 2024).

Release notes editor with grouped changelog entries ready to publish to changelog and Slack.
fig. 02 — release notes draft for v2.14.0 · grouped by area

Chapter 03 · Cycle-time analytics · A measurement discipline

Cycle time, measured to ±6% — and why that number is the only one that matters.

Every "engineering velocity dashboard" in the market lies to some degree. They conflate story points (a relative guess) with throughput (a count), report on incomplete work, or — most commonly — sample from the tickets engineers happened to remember to close. The result: a graph that goes up and to the right every quarter, regardless of whether the team is getting faster.

Zilzul's cycle-time engine was designed the other way around. We start from the strictest definition we could defend: the wall-clock time from a ticket's first commit-attached event (a branch, a PR draft, a commit referencing the key) to its transition to a terminal "shipped" state. We exclude anything that was re-opened, anything that sat in a "waiting on customer" column for more than 48 hours, and any ticket the engineering manager manually flags as a vacation day or incident.

The result is a per-ticket cycle time accurate to ±6%, validated against manual audits by the DORA research team at Google Cloud in 2023. That number is the floor, not the ceiling — it means you can compare this quarter to last quarter and trust the difference isn't noise. We publish the methodology, the exclusion rules, and the validation paper on our docs site. Read it before you buy.

"If the chart isn't reproducible from a query you can paste into the docs, it isn't a metric — it's a postcard." — Zilzul engineering team

Cycle-time data ships in three surfaces: a per-engineer histogram (with the median, p75, and p95 lines), a per-team control chart that surfaces regressions within a sprint, and a CSV export that plugs straight into the rest of your observability stack. There is no gamification layer. There is no leaderboard.

  • Per-engineer: distribution histogram with median, p75, p95 lines drawn in.
  • Per-team: control chart with 3-σ bands, regressions flagged within the same sprint they happen.
  • Per-program: rolled-up view across squads with weighted averages so a single slow project doesn't poison the number.

Chapters 04 – 06 · Supporting capabilities

Four more things that round out the workspace.

Deeper than a feature list, shorter than a full chapter. The four capabilities below are why teams stay after the trial — not why they sign up.

04

Public roadmap, where customers can watch their idea ship.

Any customer can submit, upvote, and comment on roadmap entries. When a feature ships, the people who upvoted get a Slack DM and an email — automatically, pulled from the same release-notes engine. 1,847 features have shipped from community requests since 2021. The roadmap is a public URL you can paste into a sales email.

  • Public read-only view at yourcompany.zilzul.com/roadmap
  • Upvote-weighted prioritization surfaced inside the workspace
  • "Shipped to me" notifications on release day, no manual exporting

05

Integrations that earn their place.

GitHub, GitLab, Bitbucket, Linear, Jira, Shortcut, Figma, Slack, MS Teams, Notion, Datadog, Sentry, PagerDuty, OpenAI, Anthropic, and an open API for the rest. Two-way sync on every connector — your ticks in Jira show up in Zilzul, and status changes here move tickets there.

06

Security posture you'd put in front of a CISO.

SOC 2 Type II certified and GDPR-compliant, audited by Drata. We passed our 2023 audit with zero exceptions. SAML SSO and SCIM provisioning are included on every plan — no Enterprise paywall to gate them behind.

07

Linear-class speed at Jira-class depth.

47ms p95 page load, zero jank at 50,000 tickets per workspace. The performance budget is enforced in CI for every PR — the build fails if a route regresses. Speed isn't a marketing angle here; it's a non-negotiable engineering constraint.

p95 page load latency chart comparing Zilzul, Linear, and Jira at 50k tickets.
fig. 03 — p95 page load (ms), 50k tickets / workspace

Proof · The numbers behind the dossier

Four numbers. Quoted often. Verified independently.

The Forrester TEI study, the Google Cloud DORA validation, and our own 2024 status page archive — the four figures below appear in every Zilzul contract for a reason.

47ms

p95 page load

Measured at 50,000 tickets per workspace, 12-month rolling average from our status page.

38%

more story points / sprint

Average team-level delta in the 90 days before vs. after switching, across 1,140 deployments.

4.2/wk

fewer meetings per engineer

Self-reported in onboarding surveys; cross-checked against calendar-event volume via Google/Outlook APIs.

11min

median first sprint

From signup to first committed sprint board. Industry average for PM tools: 2.5 days.

Read the dossier yourself. The dossier doesn't end here — it begins when your team installs Zilzul.

Start a free sprint

14-day trial · No credit card · Work email only

  • NPS 74 — top 1% of B2B SaaS, Customer Gauge
  • G2 #1 for Ease of Doing Business With, Q1 2024 · 9.4 / 10
  • Cycle-time methodology validated by the DORA research team at Google Cloud
  • Forrester TEI study: $184,000 reclaimed engineering hours per 100-person team / year