Stakeholder Collaboration Key Points
Shipping Solana software is only half the tech lead job. The other half is collaborating with product and a wider stakeholder set: executives, auditors, community, token holders, and vendors. That collaboration is not soft skill theater. It is the discipline of turning ambiguous asks into buildable designs, sizing risk honestly, adapting process to mainnet realities, funding platform work, shaping the roadmap, and communicating under pressure.
This page is the conceptual map for Product & Stakeholder Collaboration: requirements to technical specs, estimation and risk, process (Scrum / Kanban / SAFe), platform and tech debt prioritization, roadmap contributions, and stakeholder communication.
Summary
- Stakeholder collaboration is the continuous loop that converts business outcomes into Solana technical specs, attaches honest ranges and risks, prioritizes features against harden work, and communicates status without false certainty.
- Insight: Code that compiles and deploys still fails the product if it solves the wrong problem, lands after a surprise audit delay, or ships on brittle RPC and upgrade paths nobody funded.
- Key Concepts: requirement, technical spec, non-goals, acceptance criteria, three-point estimate, risk register, Definition of Done, debt as risk, roadmap themes (grow / harden / scale), facts-impact-actions-unknowns.
- When to Use This Model: Any feature that touches funds, authorities, tokenomics, CPI integrations, or mainnet dates; any planning cycle where product needs a ship date before engineering has a written design.
- Limitations/Trade-offs: Specs, ranges, and ceremony cost calendar time. Lightweight verbal agreement is fine for tiny reversible tickets; full rigor earns its cost when money, security, or public commitments are involved.
- Related Topics: Requirements to Technical Specs, Estimation & Risk, Prioritizing Platform & Tech Debt, Roadmap Contributions, Stakeholder Communication, Making the Process Work (Scrum/Kanban/SAFe).
Foundations
A requirement states a business outcome: "users stake SOL and earn pool yield." It does not name PDAs, CPI graphs, pause authorities, or IDL clients, and it should not. Product owns the outcome and success metric; engineering owns the on-chain state change and safety floor.
A technical spec is the engineering translation: accounts and ownership, instructions and error codes, CPIs, client and indexer impact, authority model for any tokenomics change, non-goals for this phase, and acceptance criteria that are testable (LiteSVM cases, simulation failures, confirmed-before-toast UX). Without that document, product and engineering can both believe they agreed while holding different pictures of "done."
The gap between requirement and spec is where judgment lives. Solana adds specific ambiguity that web CRUD rarely surfaces:
requirement: "users stake and earn yield"
open questions engineering must force into the open
-> which token standard and decimals?
-> vault authority: PDA seeds vs multisig vs governance?
-> pause / emergency path and who can invoke it?
-> read path: RPC getAccountInfo vs indexer event stream?
-> launch gate: devnet-only, audit sign-off, mainnet multisig?Product ambiguity is any open question about intended behavior that no amount of cargo test or Anchor constraints can resolve. Writing non-goals ("auto-compound is v2," "no mobile wallet this phase") is not avoidance; it is a checkable boundary that keeps mid-sprint scope from expanding quietly.
Stakeholders in this section are broader than "the PM." Executives care about risk and dates. Auditors need diffs and repro steps. Community and token holders care about launch honesty and fund safety. RPC and wallet vendors care about traffic and breakages. Tech leads translate one internal truth into audience-appropriate language without inventing a second truth for each channel.
Mechanics & Interactions
Collaboration is a pipeline, not a single meeting. Each step catches a different failure mode.
requirement (outcome + metric)
-> discovery (volume, funds at risk, compliance, peak load, failure tolerance)
-> scope + non-goals (this phase vs later)
-> tech spec (accounts, ix, CPI, authorities, read path)
-> acceptance criteria (tests, sim, UX errors)
-> estimate range + risk register (not a single heroic date)
-> process commit (sprint/PI cards with DoD gates)
-> roadmap placement (grow / harden / scale + dependencies)
-> ongoing status and incident comms (facts, impact, actions, unknowns)Specs before commitment
Sprint or PI commitment without a written design is how teams invent dates that audits and multisig windows later destroy. Even a one-pager is enough for small work. Fund-touching features deserve design review with product present so trade-offs (scope vs safety vs date) are chosen deliberately. Specs link to an ADR when architecture forks (for example Borsh account vs zero-copy book, or native vs Anchor path).
Estimation and risk
Solana estimates fail when treated like simple CRUD. CPI integrations, auditor queues, Squads or other multisig lead time, fee markets and landing reliability, IDL and client release trains, and indexer backfills all add variance. Use three-point estimates (optimistic / likely / pessimistic) with explicit assumptions, and put audit and deploy buffers outside the feature line so product does not confuse "code complete" with "mainnet live."
A risk register names likelihood, impact, and mitigation separately from the task list. CPI oracle staleness, regulatory classification of a token, or "audit Critical blocks launch" are plan inputs, not mid-launch surprises. Spikes time-box a named unknown with a binary pass/fail outcome before commitment; they do not replace the spec.
Process that respects the chain
Scrum, Kanban, and SAFe all work if process serves delivery instead of certification theater. Practical adaptations:
| Mechanism | Solana-shaped practice |
|---|---|
| Definition of Done | Tests green, IDL published if program changed, devnet deploy tx linked, runbook/monitor if ops impact |
| Board columns | Spec/RFC → In Dev → Review → Devnet → Ready for Mainnet → Done |
| WIP limits | Program PRs are heavy; limit concurrent in-dev work |
| Expedite | Sev-1 and audit Critical only; single incident commander pulls the lane |
| Capacity | Reserve ~20% for incidents, reviews, and harden; do not point 100% of calendar time |
Mainnet deploy is not a Friday afternoon checkbox. Stories that only reach "merged" without devnet evidence should roll automatically. SAFe PI planning should treat ecosystem enablers (Agave, Anchor, kit upgrades) as first-class, not afterthoughts.
Tech debt and platform work
Debt framed as "cleanup" loses every prioritization fight. Debt framed as risk dollars, MTTR, change-fail rate, or "repeat of last Sev-1 class" can win a sponsored epic. Categories that recur on Solana teams: security (constraints, audit backlog, pause drills), delivery (verifiable builds, deploy automation, IDL sync), runtime (RPC failover, landing policy, indexer lag), and ecosystem (Agave SIMD impact, Anchor upgrades, @solana/kit migrations).
Continuous capacity (often ~20%, sometimes 10% with an explicit payback plan) beats big-bang "debt quarters" that trigger feature freezes and backlash. Each debt epic needs one measurable outcome and a named product sponsor.
Roadmap contributions
Product roadmaps naturally showcase user-facing wins. Engineering must inject grow / harden / scale themes or launches ship on brittle foundations. Engineering proposes technical strategy, security milestones, and upgrade calendars; product prioritizes outcomes with trade-offs visible. Keep a public-facing roadmap separate from the internal dependency graph so community dates are not invented from marketing slides.
Internal critical path example:
audit_signoff --> multisig_deploy --> withdraw_v2_mainnet
kit_migration --> mobile_client --> withdraw_v2_UXCommunication under stress
Status and bad news follow one order: facts, impact, actions, unknowns. Executives get decision asks and risk. Community gets shorter versions of the same facts. Auditors get diffs and repro, not vibes. During Sev-1, a single incident commander voice prevents contradictory timelines. Never speculate publicly on attacker identity, and do not promise compensation before policy review. Engineers avoid ad-hoc token price commentary; redirect to product or counsel.
Advanced Considerations & Applications
At scale, the same loop must survive requirement change, multi-squad dependencies, and public tokenholder scrutiny.
Requirement change mid-flight. Amend the spec and re-estimate explicitly. Silent scope absorption looks like delivery failure and burns trust twice: once with product when the date slips without explanation, and once with engineers who learned that honesty is punished.
Safety veto vs product bet. Product owns the user outcome bet; the tech lead owns the safety floor. Document disagree-and-commit: if engineering will not ship a design without a pause path or audit gate, write the risk memo so an exec can choose date versus safety with eyes open, not via hallway pressure.
Audience matrix (condensed):
| Audience | Needs | Failure mode if mishandled |
|---|---|---|
| PM / product | Outcome, metric, trade-offs | Scope thrash, false dates |
| Exec / board | Risk, money, timeline | Surprised by audit or incident cost |
| Auditors | Diffs, scope, repro | Escalation to leadership, blocked launch |
| Community / holders | Honest status, fund safety | Rumor, panic, broken trust |
| Vendors (RPC, wallet) | Traffic, break windows | Silent outages mid-launch |
DAO and open governance add a public RFC surface. Treat governance proposals as requirements that still need technical specs and authority models; "community decides" without a named upgrade path is not a design.
Honest limitation: This model manages known unknowns well. It cannot invent the question nobody thought to ask. Discovery workshops and spikes reduce that residual risk; they do not eliminate it. Over-process on reversible tickets is also a failure mode: match rigor to irreversible fund and reputation risk.
| Approach | Strength | Weakness | Best fit |
|---|---|---|---|
| Verbal only | Fastest start | No shared acceptance | Tiny reversible tickets |
| One-page spec + range | Low overhead, forces non-goals | Light risk register | Small features with known patterns |
| Full spec + design review + risks | Shared truth before code | Calendar cost before first commit | Fund paths, authorities, CPI |
| PI / quarterly themes with scorecard | Portfolio view of debt and features | Ceremony if team is tiny | Multi-squad or enterprise delivery |
Common Misconceptions
- "If tests pass, the feature is correctly specified." Tests check the code against the spec; they do not check that the spec matches the business outcome.
- "A single ship date shows confidence." A single date without range, assumptions, or audit buffer is false precision. Ranges with named risks are more credible.
- "Rust and Anchor safety mean less product risk." Memory and account constraints reduce classes of code bugs. They do not decide the right product, authority model, or launch gate.
- "Tech debt is optional polish." Missing regression suites, single RPC URLs, and stale IDL clients become incident cost. Frame debt as risk and throughput.
- "Process is overhead; just ship." Unadapted process is overhead. Adapted DoD, WIP limits, and expedite rules protect review time and mainnet safety.
- "Engineers should not touch the roadmap." Without harden and scale themes, product only plans features. Engineering must propose; product still prioritizes.
- "Community updates need less accuracy than exec updates." Same facts, shorter form. Different truth per audience destroys trust when screenshots compare.
- "Non-goals are refusing work." Non-goals protect this phase and almost always pair with a follow-up ticket for the deferred slice.
FAQs
What is the difference between a requirement and a technical spec?
A requirement states the business outcome and success metric. A technical spec states accounts, instructions, CPIs, authorities, non-goals, and testable acceptance criteria. Product confirms the criteria still match the outcome before the team commits.
Who should write the technical spec?
Engineering writes it because it encodes system internals. Product reviews acceptance criteria and scope. Security-sensitive paths may add a design review before estimates freeze.
Why three-point estimates instead of one number?
Optimistic, likely, and pessimistic scenarios expose variance from CPI work, audits, and deploy gates. Product can plan with uncertainty instead of treating a midpoint as a promise.
What belongs outside the feature estimate?
Audit queue time, multisig signing windows, and mainnet deploy buffers. Label them separately so "devnet done" is not confused with "mainnet live."
How should Scrum or Kanban change for Solana?
Include devnet deploy and IDL publication in Definition of Done, split mainnet readiness from merge, reserve capacity for incidents, and make "waiting audit / waiting multisig" visible blocked states.
How do I get product to fund tech debt?
Attach one metric (MTTR, change-fail rate, exploit class regression), a risk if deferred, a clear cost, and a feature trade-off. Name a product sponsor per epic.
What themes should engineering put on the roadmap?
Grow (user outcomes), harden (security, audits, multisig, pause drills), and scale (RPC, indexer, kit/runtime upgrades). Show dependencies so critical path dates are negotiable with eyes open.
How should bad news be structured?
Facts, user or business impact, actions taken or proposed, and unknowns with a next update time. Same facts for every audience; adjust length and jargon, not substance.
What happens when requirements change after commitment?
Amend the spec, re-estimate, and renegotiate scope or date in the open. Quietly absorbing change turns a requirements decision into a fake execution failure.
When is a full process overkill?
Trivial, fully reversible work with a single owner. Use verbal agreement or a half-page note. Escalate rigor when funds, authorities, public dates, or multi-team dependencies appear.
Who owns the roadmap date for mainnet?
Product may own marketing narrative, but mainnet dates should not commit without an engineering gate such as devnet-done plus agreed audit or multisig criteria. Safety gates are not optional polish.
How do spikes fit this model?
A spike answers one named risk-register question in a time box with a pass/fail result. It feeds a better estimate; it is not a substitute for writing non-goals and acceptance criteria.
Related
- Requirements to Technical Specs - accounts, instructions, non-goals, and acceptance criteria
- Estimation & Risk - three-point ranges, buffers, and risk registers
- Prioritizing Platform & Tech Debt - debt as risk metrics and sponsored epics
- Roadmap Contributions - grow, harden, scale themes and dependency graphs
- Stakeholder Communication - status templates, incidents, and audience matrix
- Making the Process Work (Scrum/Kanban/SAFe) - DoD, WIP, expedite, and PI enablers
- Product Collaboration Best Practices - condensed checklist for eng and product
Stack versions: This page is conceptual and not tied to a specific runtime version. Sibling how-tos may reference current Agave, Anchor, LiteSVM, Surfpool, and
@solana/kitversions where tooling matters.