Pitch Guide
This guide helps frame why the product is worth trying, which concerns to address first, and how to move the conversation toward a focused pilot.
One Horizon helps engineering teams capture progress from the tools they already use, turn that activity into reviewable updates, and reduce the time spent restating status by hand.
Core message
Lead with the workflow change, not the feature list:
- Teams keep using GitHub, GitLab, Linear, Jira, Slack, Google Calendar, and their existing delivery tools.
- Connected work activity becomes recaps, standups, planning views, release notes, and measurement.
- Developers review recaps before sharing. We do not use keystroke monitoring, screenshots, or time tracking.
- Admins can review security practices, privacy terms, and connected tool access before rollout.
For pricing context, see pricing. For proof, run the pilot guide with one or two teams.
Pitch to executives
Executives usually care about reporting quality, delivery visibility, and the cost of coordination. Keep the case concrete:
Current reporting is expensive
Status updates, standup notes, sprint summaries, and executive reports take time to assemble. They also miss work that happens across commits, pull requests, issues, meetings, and Slack.
Create a shared work record
Work activity flows into one work graph. Leaders can review planned work, completed work, blockers, roadmap progress, and release notes without asking each team to rebuild the story from scratch.
The pilot proves the value
The pilot should measure hours spent on status work, visibility into current progress, blocker discovery, and stakeholder confidence before and after rollout.
Pitch to engineering leads
Engineering leads usually care about security, rollout friction, and whether the product adds process. Address those concerns directly.
Access follows existing permissions
We respect permissions from connected tools. A person who cannot access a repository, channel, issue, or calendar event in the source system does not gain access here.
Setup starts with the tools the team already uses
Start with the highest-signal integrations: GitHub or GitLab, Linear or Jira, Slack, and Google Calendar.
The lead moves from collection to unblocking
Instead of spending leadership time gathering status, use Recaps, Standups, and Blockers to find what needs a decision.
Pitch to developers
Developers usually care about whether the rollout creates extra work or watches them too closely. Be precise.
Developers stay in control
Reviewable recaps come from work activity. Developers can review what is shared, and admins decide which workspace and team workflows are enabled.
No keystrokes, screenshots, or time tracking
We use signals from connected tools, such as commits, pull requests, issues, calendar events, and selected communication context. The goal is to give developers credit for work already happening, not to create a parallel reporting chore.
Fewer repeated status questions
When the work record is current, developers spend less time rewriting the same update for standup, Slack, planning, and stakeholder reporting.
Pitch to portfolio teams and agencies
Portfolio teams, agencies, and engineering partners usually need trusted progress evidence across multiple teams or clients.
Better evidence than manual summaries
Work activity can connect to initiatives, release notes, stakeholder updates, and taxonomy. That gives external stakeholders a clearer view of what moved, what is blocked, and where support is needed.
Client-facing updates stay grounded in work
Use Release Notes, Stakeholder Updates, and Taxonomy Analytics when a customer, investor, or partner needs progress summarized by product, goal, customer, or workstream.
Start with a pilot
Do not ask the organization to decide from a slide deck. Pick one or two teams, connect their core apps, run a pilot for 1 to 2 weeks, and compare the results with the baseline.
Read the pilot guide to structure the rollout.