Having recently concluded a detailed evaluation of goal-tracking methodologies across Salesforce, HubSpot, and Pipedrive, I found all three lacking in their native capacity for a transparent, cross-functional OKR (Objectives and Key Results) process. Salesforce requires excessive customization, HubSpot's goals are too campaign-centric, and Pipedrive simply isn't built for it. This led me to conduct a structured build within Runway to determine if its database and visualization layers could effectively fill this common revenue operations gap.
The core architecture hinges on three interconnected tables: `Objectives`, `Key Results`, and `Check-ins`. The critical relational design is as follows:
* **Objectives Table**: Contains high-level quarterly objectives (e.g., "Increase Enterprise Market Penetration"). Fields include `Owner (Person)`, `Quarter (Single Select)`, `Confidence (Progress Bar)`, and a rollup field calculating average Key Result completion.
* **Key Results Table**: Houses the measurable outcomes (e.g., "Close 5 new Enterprise deals >$100k ARR"). Each KR is linked to a parent Objective via a relation. Essential fields are `Target Value (Number)`, `Current Value (Number)`, `Percentage Complete (Formula: Current Value / Target Value)`, and `Status (Single Select)`.
* **Check-ins Table**: A log for weekly or bi-weekly updates on each Key Result. Linked to its parent Key Result, it records `Current Value Update (Number)`, `Comment (Long Text)`, and `Date`. This creates a historical audit trail of progress.
The true operational value emerges in the view layer. I constructed a dedicated board view grouped by parent Objective, with each card representing a Key Result. Cards display the percentage complete, current value, and a visual status indicator. More importantly, the "Check-in" process is facilitated by a side panel form that updates the `Current Value` on the KR and simultaneously creates a linked Check-in record with commentary, all within a single action.
For leadership visibility, I created a dashboard using multiple visualization components:
* A bar chart showing `Percentage Complete` for each Key Result.
* A number chart aggregating the average `Confidence` score from all Objectives.
* A timeline view of all `Check-ins` to monitor update frequency and engagement.
* A filtered list of all `Key Results` flagged as "At Risk."
The primary limitations encountered are native to Runway's current feature set. There is no built-in weighting system for Key Results within an Objective, so the rollup is a simple average. Furthermore, automated reminders for check-in deadlines require external calendar integration or manual oversight. Compared to dedicated OKR platforms, this build lacks peer commenting features and advanced analytics on historical OKR performance. However, for teams already operating within Runway and seeking a single source of truth for quarterly goals without introducing another SaaS tool, this construct provides a methodical, auditable, and visually clear tracking system. I am now monitoring its usage across the current quarter to gather data on adoption friction and planning a comparative analysis against a dedicated tool like Perdoo or Ally.io in the next cycle.
That three-table structure is spot on. We tried a flatter setup at first, just Objectives with KRs as repeating fields, and updating progress became a nightmare. The separate `Check-ins` table is clutch for auditability.
How are you handling the `Current Value` field for KRs? We hit a snag when a KR was "Launch feature X" - not numeric. We ended up using a single select (Not Started, In Progress, Complete) and a formula to convert that to a 0-100% for the rollup.
stay automated
Good call on separate tables. The relational model is the only way to keep sanity later.
>How are you handling the `Current Value` field
We use a formula field to handle that. It checks if the KR type is "binary" (like your feature launch) and maps the status to a 0 or 1, else it calculates progress from the numeric current/target. Lets you mix metric types in one objective, which is messy but real.
Watch out for rollup lag on the objective confidence score. Had to add a manual "recalculate" button trigger sometimes.
Good start with the three-table model. You mentioned the `Confidence` field is a progress bar. Is that a manual entry or a formula rollup from the KRs? If it's manual, you're introducing drift between the reported state and actual KR progress.
I'd make that a calculated field, even if it's a simple average of KR completion percentages. Otherwise, you've built another system where the data can be out of sync, which defeats the purpose.
Also, link your `Check-ins` table to the specific KR, not just the Objective. You need that granular history to see which result is stalling.
plan before apply