> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dacard.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Team Operations (function view)
> How the six operational functions and 27 dimensions read team capability.
Same framework, different lens. The function view groups the 27 dimensions into the 6 operational functions (Strategy, Design, Development, Operations, GTM, Intelligence) so you can read capability function by function.
# Team Operations (function view)
Team Operations measures your team's operational capability across 6 functions and 27 dimensions. This page works the operational lens: how your team's actual workflows operate, not just the product you ship.
A product can't outpace the team building it. Teams that show strong product capability but weak operational maturity will eventually stall, because the team becomes the bottleneck, not the technology.
## Why operational maturity matters
The most common pattern is product capability running ahead of team operational maturity. The product looks impressive; the team is still building, managing, and iterating with traditional processes. That creates fragility: the product looks great but can't sustain its lead.
The function view tells you whether your team is actually working in modern ways, or just shipping modern features with conventional processes.
## Six operational functions
Each function maps to a team discipline and carries a slice of the 27 dimensions.
| Function | Owned by | What we read |
| ---------------- | ------------------ | ----------------------------------------------------------------------------------- |
| **Strategy** | Product Management | Market intelligence, decision quality, roadmap discipline, competitive positioning |
| **Design** | Design | Research, prototyping speed, experience design, design-to-dev handoff |
| **Development** | Engineering | Architecture, spec quality, build vs buy, delivery velocity |
| **Operations** | Ops / Data | Customer signal synthesis, product analytics, data flywheel, feedback loop quality |
| **GTM** | Product GTM | Positioning, launch execution, adoption, pricing |
| **Intelligence** | Cross-functional | Quality and experimentation, team orchestration, process iteration, cost management |
## Maturity stages on the operations lens
The same five stages apply, read through the operational lens.
| Stage | Range | What operations look like |
| --------------- | ------- | -------------------------------------------------------------------------------------------------------------------------------- |
| **Foundation** | 27-48 | No tooling in team workflows. Everything manual: spreadsheets, status meetings, gut-feel calls. |
| **Building** | 49-70 | Individual team members use tools (Claude, Copilot) but no organizational adoption. Each person on their own. |
| **Scaling** | 71-91 | Standardized tools across functions. Shared playbooks, measured productivity gains, consistent practice. |
| **Leading** | 92-113 | Tooling embedded in core workflows. Team can't operate efficiently without it. Cross-function coordination is assisted. |
| **Compounding** | 114-135 | Workflows orchestrate themselves across functions. Routine operations run on autopilot. People focus on judgment, not execution. |
## Function-level scoring
Reads whether product management is making better, faster decisions with the tools at hand.
**Four dimensions:** market intelligence, decision quality, roadmap discipline, competitive positioning.
**Foundation:** Roadmap driven by stakeholder requests. Market read is occasional and manual. Competitive tracking is informal.
**Leading:** Continuous market intelligence pipelines. Decision briefs before major calls. Roadmap tied to measured outcomes with automated tracking.
Reads whether design workflows go faster and produce better outcomes with current tooling.
**Four dimensions:** research and discovery, prototyping speed, experience design, design-dev handoff.
**Foundation:** Research is quarterly or less. Prototypes take weeks. Handoff is manual with high information loss.
**Leading:** Research synthesis in hours. Wireframes generated as starting points. Design system coverage tracked automatically.
Reads whether engineering workflows are modernized, not just the code shipped.
**Four dimensions:** architecture and systems, spec and context quality, build vs buy, delivery velocity.
**Foundation:** Specs are vague tickets. Architecture decisions are informal. Deployment is manual and infrequent.
**Leading:** Generated PRDs with acceptance criteria. Deployment multiple times per day. Build vs buy decisions tracked and reviewed quarterly.
Reads whether the team is closing the signal loop between users and product.
**Four dimensions:** customer signal synthesis, product analytics, data flywheel, feedback loop quality.
**Foundation:** Support tickets are the primary feedback mechanism. Analytics are reporting dashboards, not decision tools. No data flywheel.
**Leading:** Synthesis across support, reviews, and usage data. Anomaly alerts surfaced automatically. Every user interaction improves the product.
Reads whether the team takes products to market in modern ways.
**Four dimensions:** positioning and messaging, launch execution, adoption and expansion, pricing and packaging.
**Foundation:** Launches are ad hoc. Messaging is feature-based. Pricing is traditional seat licenses.
**Leading:** Launch checklist runs itself. Usage-based pricing with expansion triggers. Onboarding personalized and instrumented.
Reads the team's capacity to learn and improve its own ways of working.
**Four dimensions:** quality and experimentation, team orchestration, process iteration, cost and token economics.
**Foundation:** Testing is manual. Retros happen but nothing changes. Costs aren't tracked.
**Leading:** Eval pipelines run on every merge. Cost per feature tracked and optimized. Processes improve measurably quarter over quarter.
## Product vs. operations gap
The most valuable read from this lens comes from comparing product maturity (captured in the URL score) against operational maturity (captured in adapter signal).
| Pattern | What it means | Move |
| ------------------------------- | ----------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| **Product ahead of operations** | Building modern features with traditional processes. Sustainability risk as the product scales. | Invest in team adoption and workflow modernization before adding more product capability. |
| **Operations ahead of product** | Capable team that hasn't yet channeled capability into the product. Opportunity. | Use the strong operational base to ship aggressively. |
| **Both high** | Aligned and compounding. Advantage widens over time. | Maintain and extend. Focus on the highest-leverage dimensions to reinforce the flywheel. |
| **Both low** | Starting point. Don't try to fix everything at once. | Start with Operations (faster payback through tool adoption) to build muscle. |
## Using function scores
If Design lands a 3 but GTM lands a 1, your team builds well but markets with legacy methods. Fix the bottleneck function before raising already-strong ones.
Re-score operations every quarter. Unlike product maturity (which depends on shipped features), operations maturity can move in weeks through tool adoption and process change.
Use the portfolio view to compare function scores across product teams. High-scoring teams in a particular function are your internal best-practice source.
## Related
Full 27-dimension breakdown with scoring rubric.
How the three frameworks fit together.
Adapter signal materially tightens scoring accuracy.