The Team Operations Framework
This one reads how your team works. It asks 27 questions, grouped into six areas, and puts each answer on a five-step ladder. You end up with a picture of where the team is strong and a short list of what to work on next. It is written for the person who has to make that call.
Foundation, the basics are not in place. The team ships features and hopes. The loudest escalation wins the week.
Building, a few practices are written down. Someone watches the numbers. The tools are ahead of the habits.
Scaling, the team decides from evidence. Other teams can see the work. Progress shows up month to month.
Leading, the practices hold under pressure. Improving the way you work is part of the week, not a side project.
Compounding, this week makes next week easier. What the team learns gets reused instead of relearned.
Strategy
Questions 1–4Strategy is where the money goes, and why. You read the market, you make the call, you hold the roadmap to it, and you check later whether the call was right. When this area is weak, the team builds the wrong things well.
Design
Questions 5–8Design is the trip from a customer problem to a solution you trust. Research feeds the prototype. The prototype moves faster when designers and engineers work from the same notes. Skip the research and you get a good demo on top of a guess.
Development
Questions 9–12Development sets the ceiling on what the team can build. The architecture limits everything above it. A clear spec is what makes the output match the intent. Build-or-buy calls decide what you own. Shipping speed multiplies the rest.
Intelligence
Questions 13–17Intelligence is how the team learns. What customers tell you feeds the numbers. The numbers decide what data is worth keeping. What you learn gets written down where the next person finds it, instead of leaving with the person who learned it.
Operations
Questions 18–23Operations decides whether the team can carry what it builds. Quality checks catch regressions. Shared plans keep two teams from building the same thing twice. Unit economics protect the margin. Security and uptime protect trust. Most teams ignore this area until it becomes the constraint.
GTM
Questions 24–27Go to market decides whether the work reaches anyone. Positioning sets what buyers think you are. Launches buy attention. Onboarding turns a signup into a customer. Pricing decides how much of the value you keep. A good product with weak go to market leaves the money on the table.
Foundation
27 – 48Product operations are reactive. The team ships features without systematic measurement of impact. Decisions are driven by intuition, executive requests, or customer escalations. No cross-functional visibility into team effectiveness.
Treating operational improvement as a luxury for later. Every quarter without measurement is a quarter of learning lost. The gap compounds over time.
Assuming operational practices can be bolted on to an existing team when the time comes. The habits, data models, and workflows all need to be built deliberately.
Running retrospectives or off-sites that generate action items but never change how the team actually works. Creates the illusion of progress while practices remain unchanged.
- Customer churn that nobody can explain with data
- Leadership explicitly asks for better visibility into team effectiveness
- At least one team member is experimenting with better tooling and processes on their own
- A competitor ships faster and with more consistency, creating visible market pressure
Building
49 – 70Emerging operational practices. Some processes are documented and followed. Basic analytics provide retrospective visibility. Team roles are defined but handoffs are mostly manual. Individual contributors may use modern tooling, but organizational practices haven't caught up.
Adopting tools and processes that look good on paper but create no proprietary value. The practices you copied can be replicated by anyone.
Building features because the demo looks impressive to investors, not because customers are pulling for them. Optimizing for "wow" over retention.
Investing in building and shipping while ignoring the data infrastructure that would create learning loops. Measurement infrastructure takes time to build. Starting late compounds the deficit.
- Customers building workflows around your features, not just trying them once
- Infrastructure costs becoming material enough to track per customer
- Multiple teams requesting shared tooling and standardized processes
- Competitors shipping comparable capabilities faster than you can respond
Scaling
71 – 91Systematic operations across the product team. Cross-functional visibility exists. Decisions are evidence-based. Processes are documented, followed, and regularly improved. The team can measure its own performance and identify gaps.
Stopping investment once processes are in place and customers aren't complaining. The gap between Scaling and Leading widens every quarter you don't invest in architecture, data, and team structure.
Keeping operational expertise in a separate team that builds processes and throws them over the wall. Leading requires operational literacy embedded in every PM, designer, and engineer.
Working around legacy architecture constraints instead of confronting them. Every workaround adds complexity and slows iteration. The rewrite gets harder the longer you wait.
- Architecture is the primary bottleneck for improvement, not process or tooling
- Costs are growing faster than revenue contribution from new capabilities
- Competitors building proprietary data advantages while you iterate on surface-level improvements
- Team members across functions asking for tooling the current structure cannot provide
Leading
92 – 113Integrated operations where continuous improvement is embedded in how the team works. Cross-function feedback loops are fast. The team measures its own effectiveness and acts on the data. Experimentation and learning are cultural, not just procedural.
Overvaluing tooling sophistication while underinvesting in data quality and process coverage. The best tools applied to mediocre processes lose to decent tools applied to excellent processes.
Building proprietary solutions for commodity capabilities that existing tools handle well. Spend engineering time on what differentiates, not what is generic.
Collecting feedback data but not closing the loop back to product improvement. The flywheel only works if every stage connects: collection, evaluation, improvement, deployment.
- Data flywheel generating measurable improvement with each new customer
- Quality metrics directly correlated with retention and expansion revenue
- Category creation opportunity emerging from your operational positioning
- Competitors have stopped trying to match your capabilities and are differentiating elsewhere
Compounding
114 – 135Self-improving operations. The team's practices, data, and decisions compound over time. Organizational learning accelerates with every cycle. Tooling and automation (including AI) amplify proven processes rather than replacing judgment.
Assuming the data flywheel is permanent. Platform shifts, new architectures, or regulatory changes can erode advantages. The moat needs active investment, not maintenance mode.
Spending engineering time optimizing existing capabilities when the bottleneck is data breadth and market expansion. More optimization on the same surface yields diminishing returns.
Having a genuine Compounding-stage team and architecture but failing to make it visible to customers, investors, and talent. If the market does not understand your advantage, it cannot properly value it.
- Invest in data breadth: new integrations, new input modalities, new customer segments feeding the flywheel
- Define the category narrative: naming, positioning, analyst education, thought leadership
- Build platform leverage: let other products build on your capabilities through APIs and SDKs
- Recruit on Compounding-stage identity: your team and architecture are a talent magnet, make it public