R&D Interlock

The R&D Interlock Process is used to align Product Management, User Experience, and Engineering teams on roadmap planning and coordinating execution. The interlock consists of three major components:

• The Resource Allocation Framework provides a structure to map product and engineering driven efforts to the available engineering resources.
• The Roadmap Structure describes the planning artifacts (roadmaps) used for alignment and defines their ownership, purpose and audience.
• The R&D Alignment Process provides a process and timeline to create alignment for the next execution quarters.

The alignment process outlines a joint approach across product-driven and engineering-driven initiatives while ensuring clear communication channels with various stakeholders.

Resource Allocation Framework

We’re establishing a balanced approach between product-led and engineering-driven initiatives that prioritizes customer needs, quality standards, and long-term product sustainability. This balance serves as the foundation for ongoing dialogue between Product Management and Engineering teams, with the flexibility to adjust ratios as needed for each team’s specific context.

Every initiative is going to be tracked as a separate slide in the R&D Execution Roadmap and (after alignment) represented in the R&D Investment Roadmap, the Internal Roadmap and the Public Roadmap.

• P1/P2/P3: Product-Driven Initiatives

  • Prioritization Levels
    • P1: 100% Eng Confidence that the complete initiative will be delivered at the committed date
    • P2: 80% Eng Confidence that the complete initiative will be delivered at the committed date
    • P3: 50% Eng Confidence, can be stopped if a P1-2 or E1-2 is at risk.
  • Some but not all P1/P2/P3 projects will be added to the Public Roadmap (owned by GTM) and will be labeled with the GTM tiers T1/T2/T3 (reference: definition of GTM tiers).
    • It’s possible that T and P priorities do not strictly match. For example, a contractual customer commitment might be a P1 for Product but a T3 for GTM. Similarly, a competitive gap might be a P2 for Product but a T3 for GTM. It is expected that this divergence of priorities will happen frequently.
    • GTM priorities T1-3 can never be higher (only ever be equal or lower) than Product priorities P1-P3, else we’ll run into priority inversion. Exceptions need PLT/ELT/MLT approval.
    • T priorities are externally communicated to stakeholders via Public Roadmap
    • P priorities are externally communicated to stakeholders via Internal Roadmap

• E1/E2/E3: Engineering-Driven Initiatives

  • Prioritization Levels:
    • E1: 100% Eng Confidence that the complete initiative will be delivered at the committed date
    • E2: 80% Eng Confidence that the complete initiative will be delivered at the committed date
    • E3: 50% Eng Confidence, can be stopped if a P1-2 or E1-2 is at risk.
  • Internal visibility only
  • Not externally communicated

Unless approved by the respective VP of Product and/or Engineering, there is a maximum limit of 1 x (P1 or E1) and 2 x (P2 or E2) per 20 engineers with a minimum of 1 x P2 per key investment areas (e.g. SCM, CI, Security, Compliance, Planning, Duo).

Creating a clean alignment (“interlock”) between Product and Engineering requires a structured planning methodology that integrates user requirements with focused quality improvements and essential technical efforts. This framework establishes a dual-track system where product-driven initiatives (P1/P2/P3) operate with explicit resource allocation parameters—P1 receiving engineering capacity to deliver 100% of planned scope with 100% certainty and full visibility in external communications, P2 allocated engineering resources to deliver 100% of planned scope with 80% certainty, both with defined acceptance criteria. P3 efforts are implemented through iterative development cycles when capacity permits with a target of 50% confidence. This systematic approach ensures proper resource allocation while creating a traceable relationship between committed functionality and execution.

Parallel to these requirement-driven developments, the framework implements a technical sustainability track (E1/E2/E3) with equivalent resource allocation metrics but isolated from external dependencies and release communications. This structure enables critical refactoring, dependency upgrades, test automation improvements, and infrastructure optimization to proceed with appropriate prioritization without external scheduling constraints.

The configurable ratio between P-track and E-track allocations provides implementation flexibility across different system components and architectural layers, allowing teams to adapt the framework based on technical debt accumulation, system stability metrics, and component lifecycle phases—ultimately producing systems that satisfy functional requirements while maintaining architectural integrity.

Roadmap Structure

R&D Execution Roadmap

• Content: All P1/P2/P3 and E1/E2/E3 initiatives
• Cadence: Quarterly updates, 4-quarter rolling window
• Audience: Product and Engineering leadership
• Owner: Eng VP in alignment with Product
• Purpose: Readiness, Feasibility, and Execution Planning
• Format: One deck per section (template), one roadmap overview for customer and engineering driven initiatives per stage, Individual alignment slides for each initiative

R&D Investment Roadmap

• Content: P1/P2 and E1/E2 initiatives (80%+ confidence)
• Cadence: Quarterly updates, 4-quarter rolling window
• Audience: Board level
• Owner: CPO and CTO Purpose: Strategic investment overview

Internal Roadmap

• Content: All P1/P2/P3 features
• Cadence: Quarterly updates, 4-quarter rolling window
• Audience: Select customers
• Owner: PM VP in alignment with Eng and UX
• Purpose: Product evolution and feature planning

Public Roadmap

• Content: A subset of P1/P2/P3 product-driven features will be labeled as T1/T2/T3 for GTM. N.b. that GTM priority T1/T2 can never be higher than product priority to avoid priority inversion.
• Cadence: Quarterly updates, 4-quarter rolling window
• Audience: Customers
• Owner: GTM in alignment with Product
• Purpose: External commitment tracking

---
config:
  look: handDrawn
  theme: neutral
---
flowchart LR
    Execution_Roadmap("
        ⚙ **R&D Execution Roadmap**<br>
        *Purpose*: Readiness, Feasibility and Execution Planning<br>
        **P1/P2/P3 and E1/E2/E3 Initiatives**<br>
        *Audience*: PM, UX and Engineering Leadership
        *Owner*: Env VP in alignment with PM and UX
    ")

    Product_Roadmap("
        🧁 **Product Roadmap**<br>
        *Purpose*: Product Evolution and Features<br>
        **P1/P2/P3 Initiatives**<br>
        *Audience*: Select Customers
        *Owner*: PM VP in alignment with Eng and UX
    ")

    Investment_Roadmap("
        💰 **R&D Investment Roadmap**<br>
        *Purpose*: Strategic investment overview<br>
        **P1/P2 and E1/E2 Initiatives**<br>
        *Audience*: Board level
        *Owner*: CPO and CTO
    ")

    Public_Roadmap("
        📢 **Public Roadmap**<br>
        *Purpose*: Strategic investment overview<br>
        **P1/P2/P3 Initiatives**<br>
        *Audience*: Select Customers
        *Owner*: PM VP in alignment with Eng and UX
    ")

    Execution_Roadmap --> Product_Roadmap
    Execution_Roadmap --> Investment_Roadmap
    Product_Roadmap --> Public_Roadmap

R&D Alignment Process

The R&D Alignment process produces a generally agreed on R&D Execution Roadmap (and all derivative roadmaps) one quarter ahead of the planning window. If we’re planning for Q_n to Q_n+3, the planning quarter is prior to execution and marked as Q_n-1 to provide a clear planning timeline. The alignment process runs in Q_n-1 Week 7-12.

---
config:
  look: handDrawn
  theme: neutral
---
gantt
    dateFormat YYYY-MM-DD
    axisFormat End of Week %W
    tickInterval 1week

    title Quarterly Planning Timeline

    Feature Alignment : 2025-02-16, 7d
    R&D Alignment     :             7d
    GTM Alignment     :             7d
    Commitment        :             7d
    Comms             :             7d
    Retrospective     :             7d

Feature Alignment Timeline: Qn-1 Week 8	Goal: Create PM/EM alignment on full set of P1-3/E1-3 features Content: Discuss P1/P2/P3 and E1/E2/E3 initial draft ideas Identify ownership, dependencies and conflicts Initial assessment of: Business value Technical feasibility Engineering bandwidth and timeline Resource requirements and Dependencies Strategic alignment Customer Zero requirements and enablement Improvements (Quality, stability, security etc.) should be mapped as either P or E driven initiatives Artifact: Stage-level alignment slides in R&D Execution Roadmap Owner: PLT/ELT Participants: Group PM/PD/EM for each capability under consideration Format: Sync or async, as preferred by group-level teams
R&D Alignment Discussion Timeline: Qn-1 Week 9	Goal: Align Product & Engineering leadership on: Scope and importance of capability to customer, quality and needs Ability to commit to proposed E/P priority ranking Content: Discussion to align on: Customer Problem and Business Value Proposed solution and Definition of Good: Clear success and landing criteria Proposed priority Resource requirements Initial timeline estimates Dependencies identification Risk assessment Topic Granularity: Minimum threshold of 1 FTE quarter Smaller initiatives are aggregated as milestones into thematic features Artifact: R&D Execution Roadmap with one joint alignment slide per feature (template) Owner: PLT/ELT Participants: E-track: EM responsible for capability P-track: PM & EM responsible for capability
GTM Alignment Discussion Timeline: Qn-1 Week 10	Goal: Align R&D and GTM leadership on: Scope and importance of capability to GTM considerations Ability to commit to proposed T priority ranking Content: Pre-read: R&D joint alignment slide in R&D Execution Roadmap Discussion artifact: Proposed T priorities from GTM Owner: MLT Participants: ELT, PLT & MLT
Final Prioritization and Commitment Timeline: Qn-1 Week 11	Goal: Document outcome of alignment discussions in R&D Execution Roadmap Content: Final T/P/E assignments Delivery timeline commitment Resource allocation confirmation Identification of dependencies Documentation of risks Owner: E-track: EM responsible for capability, Eng VP signoff P-track: PM & EM responsible for capability, PM and Eng VP signoff Format: Async
Upstream Communication Timeline: Qn-1 Week 12	Aligned P1-3 initiatives integrated into Internal Roadmap P1/P2 and E1/E2 initiatives integrated into R&D Investment Roadmap Select P1/P2 initiatives integrated into Public Roadmap as T1/T2, n.b. that GTM priority T1/T2 can never be higher than product priority to avoid priority inversion.
Retrospective Timeline: Qn Week 1	Goal: Learn from prior planning cycle and identify any changes that need to be implemented going forward. Content: Collect, discuss and incorporate feedback from prior planning iteration Artifact: Qn-2 Planning Retrospective. Owners: PLT/ELT Participants: Planners at Section and Stage Level

Success Metrics

• Roadmap alignment with company goals
• Planning efficiency (time spent planning and aligning, effort sizing, customer / quality / sustainability balance)
• Planning and execution accuracy (Delivery against commitments in time)

Commitment Change Requests

Any major changes to the timeline, scope, cost, priority, quality or risk for a committed feature of priorities P1/E1 and P2/E2 should be raised to respective PLT and ELT members as well as CPO and CTO via a Commitment Change Request to get explicit approval and keep all stakeholders in the loop:

1. Project DRIs update the alignment slide in the R&D Execution Roadmap and post a proposed update to #r-and-d-roadmap-changes, @’ing in the respective stakeholders. The post should follow a standardized format, so decision makers can quickly respond / act:

   Proposing change to feature: [$FEATURE](https://direct-link-to-execution-slide)
   
   Change Type: [select: Timeline / Scope / Cost / Priority / Quality / Risk]
   
   What’s changing: <Priority from XX to YY>, <Delivery Milestone from YY.Y to ZZ.Z>, …
   
   Background: [2-3 sentences describing the decision]
   
   Impact: [optional, further detail on impact to customers / cost / list of projects that are dependent on this project + @ mentions of DRIs for those projects]
   
   Proposed by: [Name of Product and Engineering DRI]
   
   Approvers: [specific PLT, ELT members], CPO, CTO
   
   <more narrative / details of change, motivation, impact>
   

2. Free form discussion on the thread, optional meeting

3. Approval to commit to change from CPO and CTO

Any change that constitutes a slip in deadline, a significant reduction in scope, or anything else that would make us miss customer expectations constitutes a major change. If in doubt, go through the change management process.