Usable with a quick edit11 of 12 checks passed
A senior PM could use this with light edits because the evidence, capacity math, deadline protection, and procurement call are all present. The only minor cleanup is tightening some later-quarter allocation language.
Output
Harbor FY27 roadmap: expand existing customers first
For the planning offsite | Q4 2026–Q3 2027
Recommendation: protect card continuity, unlock committed subsidiary expansion, then bring more existing-customer spend onto Harbor. Treat procurement as a commercial hypothesis to validate—not as committed revenue or a committed launch.
Board outcome: raise NRR from 104% to 112% by the end of Q3 2027. This roadmap supports that goal; the available evidence does not yet establish a credible revenue bridge all the way to 112%.
1. Proposed roadmap
Planning rules
- Commit against the five existing squads, each with 11 squad-weeks per quarter. Neither new squad is on the critical path.
- Numbers below are squad-weeks. Named feature estimates come from the pack; remaining capacity is an allocation ceiling for rollout, validation, hardening or contingency, not an estimate for additional features.
- Cross-squad delivery uses the stated 1.5× cost.
- Adoption work targets expansion and retention in existing accounts. It is not a placeholder for additional module builds.
| Squad | Q4 2026 — Protect and unblock | Q1 2027 — Launch foundations | Q2 2027 — Capture spend | Q3 2027 — Scale adoption |
|---|---|---|---|---|
| Cards | Processor v2: 11. Own architecture, integration and critical migration work. Outcome: eliminate the card-authorisation shutdown risk. | Processor v2: remaining 3, plus 8 reserved for defects, freeze, certification and cutover contingency. Target certification 12 Feb–12 Mar, cutover 15 Mar, ahead of the 31 March retirement. No virtual-card launch commitment this quarter. | Virtual cards: 10, plus 1 for integration support/contingency. Launch with customers identified through the QBRs. Outcome: move software subscription spend onto Harbor cards. | Up to 11: virtual-card activation, spend conversion, controls integration support and reliability. Outcome: sustained incremental card spend before the NRR measurement date. |
| Approvals & Policy | Multi-entity: 10; procurement commercial validation: up to 1. Outcome: policy support for subsidiary expansion; early test of willingness to pay. | Up to 7: multi-entity onboarding and policy fixes; up to 4: procurement validation. Outcome: convert written subsidiary commitments and decide whether procurement merits a funded build. | Spend controls: 4; up to 7: multi-entity rollout and controls policy setup. Outcome: make controls usable by finance teams and expand subsidiary adoption. | Up to 11: controls rollout, policy tuning and remaining subsidiary onboarding. Outcome: adoption that expands spend rather than creating excessive declines or customer friction. |
| Integrations | Sage Intacct: 9, plus 2 for pilot rollout and fixes. Outcome: remove a recurring accounting workflow gap in a substantial existing-customer segment. | Up to 11: Intacct rollout, reliability and measuring CSV-to-integration conversion. Outcome: reduce retention risk and support expansion. | Up to 11: Intacct and multi-entity accounting rollout; unused capacity remains reserve. Outcome: accounting readiness does not block subsidiary activation. | Up to 11: integration adoption and reliability against remaining account-level expansion blockers. No Dynamics commitment. |
| Platform | Multi-entity: 11 of 12. Outcome: build the account structure needed for subsidiary expansion. | Multi-entity: remaining 1; SSO/SCIM: 5; up to 5 for rollout and hardening. Launch multi-entity after the remaining platform work and acceptance testing. Outcome: activate subsidiaries and address existing-account security reviews, with enterprise pipeline as a secondary benefit. | Up to 11: multi-entity and SSO/SCIM onboarding, operational hardening and contingency. Outcome: reliable expansion across larger customer organisations. | Up to 11: scale and security work tied to demonstrated adoption issues. Outcome: retain and expand larger accounts without accumulating operational risk. |
| Expenses | Processor support: 6, delivering 4 Cards-equivalent weeks; receipt matching: 5 of 6. Outcome: buy migration schedule margin while progressing the most common expense support issue. | Receipt matching: remaining 1; up to 10 for rollout, quality measurement and fixes. Outcome: improve auto-match from the 71% baseline and reduce unmatched-receipt tickets. | Spend-controls engineering: 9, delivering 6 of the 8 Cards-equivalent weeks; up to 2 for receipt quality. Cards retains technical ownership. Outcome: develop controls alongside virtual cards rather than queueing both behind one squad. | Spend-controls engineering: 3, delivering the final 2 Cards-equivalent weeks, followed by an early-quarter launch subject to acceptance. Up to 8: controls hardening, receipt quality and mobile lifecycle assessment. Outcome: give controls time to drive adoption before quarter-end. |
Critical-path checks
- Processor migration: Q4 delivers 11 Cards weeks + 4 equivalent weeks from Expenses = 15. Q1 delivers the final 3, reaching the required 18. The February certification target creates margin before the hard retirement date.
- Certification freeze: no changes to the certified implementation during the four-week processor window. Before committing dates, confirm the precise freeze scope, book the processor slot and agree cutover acceptance criteria.
- Multi-entity: Approvals & Policy completes its 10 weeks in Q4; Platform completes 11 + 1. Therefore this is a Q1 launch, not a Q4 launch.
- Spend controls: Expenses spends 12 actual weeks across Q2–Q3 to deliver 8 Cards-equivalent weeks; Approvals & Policy supplies its 4 weeks in Q2. Work begins only after v2 is live.
- New squads: plan no committed output until teams are staffed and their ramp is observed. Use initial capacity for bounded adoption, testing or hardening work; allocate larger scope only after a delivery review.
Outcome scorecard
| Workstream | Measure that matters |
|---|---|
| Overall expansion | NRR and a cohort-based revenue bridge separating expansion, contraction and churn |
| Multi-entity | Subsidiaries activated, incremental ARR and activation time; start with the nine parents that committed in writing |
| Virtual cards | Incremental software spend moved onto Harbor and resulting net interchange—not cards issued |
| Spend controls | Enabled accounts, incremental spend unlocked, decline quality and customer friction |
| Intacct | Eligible-account adoption, CSV retirement and subsequent retention/expansion versus comparable accounts |
| SSO/SCIM | Resolution of the 11 existing-account security reviews; pipeline conversion tracked separately |
| Receipt matching | Match rate, incorrect matches and unmatched-receipt tickets per expense |
| Procurement discovery | Paid commitments at the proposed pricing, requester-seat counts and a credible reason to switch |
CS, Sales and Finance should turn these into named-account activation targets and a revenue bridge at the offsite. We should not invent conversion forecasts from the current pack.
2. The case for the plan
Why this order
First, protect the revenue engine. Every card authorisation uses an API retiring on 31 March, and interchange represents 58% of revenue. Tom’s migration occupies 18 of Cards’ 22 available weeks across Q4 and Q1, but must also leave four calendar weeks for certification. Quarterly capacity alone does not prove that schedule is safe.
Borrowing six Expenses weeks moves four Cards-equivalent weeks into Q4. That leaves only three planned migration weeks in Q1 and creates room for defects and certification. Receipt matching slips slightly; card continuity takes precedence.
Second, prioritise expansion with identifiable buyers. Multi-entity has the strongest evidence of a concrete expansion action: nine parents have committed in writing. The full 52-subsidiary opportunity is $2.9M ARR, but we cannot treat that total as committed or infer how many subsidiaries the nine parents represent. Launch in Q1, then sell and onboard—not merely ship.
Third, pursue spend expansion in parallel. Virtual cards have a direct connection to software spend currently outside Harbor. Controls address the most frequently expressed card need in the QBRs and may make finance teams comfortable moving more spend onto Harbor. Borrowing Expenses capacity costs four additional squad-weeks versus specialist delivery, but avoids serialising both products through Cards and supports an early-Q3 controls launch.
The $410M software-spend estimate implies a $4.51M annual net-interchange ceiling at 1.1%, before accounting for capture rates, timing or spend that cannot move from invoice to card. It is an opportunity, not a forecast. Both features may affect the same spend; we will not double-count it.
Fourth, remove retention and expansion friction. Intacct serves 17% of existing customers, versus 3% for Dynamics. The 13% versus 7% churn difference is an association, not proof the integration causes better retention, but it supports prioritising Intacct. SSO/SCIM is relatively small and addresses 11 existing-account security reviews. Receipt matching targets the largest expense support problem.
What changes from Tom’s draft
- Hiring no longer funds commitments. Historical time to the first full sprint was five to eight months, with half-capacity delivery in the first quarter. September approvals do not justify a full squad in Q1 and another in Q2. Further, new squads taking specialist work incur the stated transfer cost.
- Migration gains early borrowed capacity and an explicit certification window. Virtual cards no longer competes with the deadline in Q1.
- Multi-entity launches in Q1. Platform’s 12-week estimate exceeds one quarter’s 11-week capacity.
- Procurement moves from committed launch to commercial validation. Its revenue claim is not supported by current evidence.
- Controls gets borrowed delivery capacity. This creates an earlier adoption window without relying on hiring.
- Dynamics and the mobile rewrite leave the committed horizon. The freed capacity supports existing-customer outcomes and schedule resilience.
Why procurement is not the anchor
At the proposed price, an average customer has 70 requester seats and contributes:
70 × $8 × 12 = $6,720 ARR.
Reaching $6M ARR requires approximately 893 average-sized customers—81% of today’s customer base. Only two of six design partners said they would pay; neither is described as a signed commitment. Four already have a competing tool.
The estimated build is 30 Approvals & Policy weeks plus six Integrations weeks, before any additional cross-squad cost. That is too large a bet to anchor this year’s NRR target without stronger evidence.
Validation should seek paid commitments, actual seat counts and evidence of a differentiated switching reason. It is not an unbudgeted production build. A successful gate triggers an explicit investment decision, identifying displaced work and a capacity-backed launch date.
What we are not doing
We are not committing to procurement launch or its $6M claim, Dynamics, or a 22-week mobile rewrite in this horizon. We are also not inventing new feature scope to consume every available week.
The mobile support deadline remains real. By Q3, the CTO must establish the exact end-of-support date and a funded maintenance, upgrade or rewrite path. If continued safe operation requires starting earlier, it returns as a mandatory trade-off—not an assumed new-squad assignment.
Risks that could change the plan
The largest execution risks are processor certification availability, migration work that cannot be delegated, and underestimated multi-entity or controls complexity. Validate the processor work split immediately; any threat to certification displaces discretionary work first.
The largest commercial risk is insufficient expansion capture. At an illustrative $86M opening cohort, an eight-point NRR improvement represents $6.88M more retained/expanded ARR than a 104% outcome. Finance must reconcile the actual cohort and baseline. Even the full multi-entity and software-card opportunity totals only $7.41M before timing, conversion and overlap effects. This plan does not justify promising 112%.
Review the revenue bridge after Q1 launches. Weak activation should shift capacity toward removing proven adoption blockers. Strong paid procurement evidence, an earlier mobile security deadline, or demonstrated new-squad capacity can justify a replan—but none should silently become an assumption today.
Grades and run details
Decision model 83 · LLM judge 13 of 13 checks
Decision model checks
- passUses the supplied evidence correctly35%
- passAddresses the actual decision99%
- partialRespects explicit constraints26%
- passIdentifies material uncertainty100%
- passAvoids unsupported claims58%
- failProduces the required deliverable52%
- passProtects the processor deadline94%
- passPlans on the squads we actually have99%
- partialMakes the call on procurement37%
- passOutcomes, with certainty that falls with distance92%
- passFits the stated capacity54%
- passSequences around dependencies56%
Run
- Run
- #1
- Time to output
- 2.0 min
- Submitted
- 1 Oct 2026