Getting startedSet up integrationsCreate your first initiativeInvite your teamPlan today's workShare your first update
Pilot GuidePitch GuideDesktop appSDK
DocsAPI Reference

Main

  • Home
  • About
  • Pricing
  • Vault
  • Changelog
  • Docs

Features

  • Roadmaps
  • Planning
  • Standups
  • Status updates
  • Insights
  • AI assistant / MCP
  • Integrations

Solutions

  • Startups
  • Dev shops / agencies
  • Software teams
  • Internal IT & platform teams

Alternatives

  • vs Jira
  • vs Linear
  • vs Asana
  • vs Monday.com
  • vs ClickUp
  • vs Notion

Company

  • Blog
  • Security
  • Log in
  • Sign up
  • Terms of Use
  • Privacy Policy

Resources

  • Docs
  • Community
  • API reference
  • CLI
  • Desktop app
  • SDK

© 2026 One Horizon. All rights reserved

FacebookInstagramThreadsXRedditTikTokYouTubeMedium


Pilot Guide

A pilot tests the workflow with one or two teams before a broader rollout. A good pilot runs for 1 to 2 weeks and compares the current reporting process against work captured from connected tools.

Define success before the pilot starts. Most teams measure reporting time, visibility into progress, blocker discovery, and whether developers feel less pressure to rewrite status by hand.

This guide walks through team selection, baseline questions, tool setup, the pilot window, and the evidence to bring back to leadership.


Pick your pilot team

Start with teams that feel the cost of manual reporting and can influence the larger organization. Good candidates spend visible time preparing standups, writing status updates, collecting progress from tools, or answering repeated status questions.

Prioritize a team that uses connected systems consistently. The pilot works best when commits, pull requests, issues, calendar events, and team communication already reflect the work.

After you identify the first team, agree on the pilot dates, the tools they will connect, and how feedback will be collected.


Create a baseline survey

Use a short baseline survey before changing the workflow. The goal is to capture how reporting works today, where information is missing, and how much time the team spends creating status manually.

Adapt these sample topics to your organization's language and goals.

Reporting overhead

Manual reporting adds friction, and friction usually creates incomplete data. Ask questions that reveal how much work becomes visible and how much time the team spends making it visible.

How much time do you spend per week on status updates?
What percent of your work is reflected in status updates?

Visibility and clarity

Visibility questions show whether leaders can understand progress without asking the team to restate work that already happened in connected tools.

On a scale of 1 to 5 (select all that apply):

Developer experience

Developer experience questions show where status work interrupts focus or creates repeated context switching.

On a scale of 1 to 5 (select all that apply):

Set up integrations

Connect the apps the pilot team already uses daily:

  • GitHub or GitLab for commits, pull requests, merge requests, and reviews
  • Linear or Jira for issues, status, ownership, and project work
  • Google Calendar for meetings, events, and standup schedules
  • Slack for recaps, standup prompts, and team updates

Run the pilot

After setup, run the pilot for 1 to 2 weeks. During the pilot:

  • Developers review their daily recaps
  • Team leads check progress without asking for manual updates
  • Teams skip or shorten standups
  • No one writes manual status updates

If your team needs help during setup or rollout, contact support before the pilot window starts so the pilot period measures product usage instead of unresolved setup work.


Send a post-pilot survey

Reuse the baseline topics after the pilot, then compare the before and after responses. Add open text fields so people can explain what changed, where the product helped, and where the workflow still needs adjustment.

Request feedback by a specific date at least one week before a leadership review. That gives you time to compile results and follow up on unclear answers.

Sample questions:

How much time do you spend per week on status updates now?
On a scale of 1 to 5 (select all that apply):

Compile your data and present your case

Leadership needs a clear comparison, not a long list of anecdotes. Pull out the 4 to 5 strongest quantitative changes and place them beside the baseline. Add one short quote when it helps explain the metric.

Sample metrics to track:

Reporting time

Compare hours spent on status updates before and after. Show the reduction in reporting overhead.

Visibility improvement

Compare visibility scores before and after. Show how team leads gained real-time clarity.

Developer satisfaction

Compare developer experience scores before and after. Show how flow time increased.

Active use

Track how many team members actively use it. High adoption gives leadership useful evidence for rollout.


Make the switch

Pilot evidence should decide the next rollout step. Many teams expand to adjacent teams first, then move toward a wider workspace rollout once integrations, roles, and reporting routines are clear.

For broader rollout, continue with Getting started, Invite your team, and Set up integrations.

Sign up and exploreBook a demo

PreviousContactNextPitch Guide

Pitch Guide

Help your team evaluate One Horizon with clear messages for executives, engineering leads, developers, and external stakeholders.

Case Studies

Customer stories and examples of teams using One Horizon in real engineering workflows.

Community

Join the One Horizon community for product questions, workflow ideas, and peer support.

  • Pick your pilot team
  • Create a baseline survey
  • Set up integrations
  • Run the pilot
  • Send a post-pilot survey
  • Compile your data and present your case
  • Make the switch
  • Back to top