Share Dialog
Based on Richard Rumelt's strategic frameworks and the comprehensive analysis of protocols versus platforms, this methodology provides a structured approach for determining when to solve problems at the protocol level versus the platform level across leadership, technical, and community contexts.
The Strategic Kernel Foundation
At the core of this methodology lies Rumelt's strategic kernel, which consists of three essential elements that must be applied to every technological decision[1][2]:
This kernel serves as the foundation for determining whether protocol-level or platform-level solutions are most appropriate for addressing specific challenges and opportunities.
The Cynefin-Enhanced Decision Framework
Building on Rumelt's approach, we integrate the Cynefin Framework to categorize problems by their complexity and predictability, which directly informs whether protocol or platform solutions are most suitable[3][4][5]:
Domain Classification
Clear Domain: When cause-and-effect relationships are obvious and best practices exist, platform-based solutions with established patterns are typically most appropriate[6][5]
Complicated Domain: When cause-and-effect relationships exist but require expert analysis, hybrid approaches combining protocol standards with platform implementations often work best[6][5]
Complex Domain: When cause-and-effect can only be understood in retrospect and emergent patterns dominate, protocol-first approaches that enable experimentation and adaptation are usually more suitable[6][5]
Chaotic Domain: In crisis situations requiring immediate action, temporary platform solutions may be needed to establish order before transitioning to protocol-based approaches[6][5]
Leadership Level Decision-Making
Phase 1: Strategic Diagnosis
Step 1: Identify the Crux
Ask: "What is the hardest part of this challenge that, if solved, would make the biggest difference?"[7][8]
Determine whether the fundamental barrier is at the infrastructure level (protocol) or application level (platform)
Assess whether the challenge requires network-wide coordination or localized optimization[5][9]
Step 2: Power Source Analysis
Identify available sources of strategic power including leverage, reputation, specialized knowledge, and growth opportunities[10][11]
Evaluate whether power can be better harnessed through protocol-level standardization or platform-level optimization[10][5]
Consider whether the solution requires distributed consensus (protocol) or centralized decision-making (platform)[5][9]
Step 3: Context Assessment
Phase 2: Strategic Policy Formation
Step 4: Proximate Objective Setting
Define objectives that are close enough at hand to be feasible while addressing the core challenge[8][13]
Ensure objectives can be reasonably achieved with available resources and capabilities[8][13]
Align objectives with either protocol-level infrastructure building or platform-level user experience optimization[5][9]
Step 5: Resource Allocation Decision
Determine whether resources should focus on lower-level infrastructure (protocol) or higher-level abstraction (platform)[5][9]
Consider scalability requirements: network-level (protocol) vs. application-level (platform)[5][9]
Evaluate governance model preferences: decentralized community governance (protocol) or centralized decision-making (platform)[5][9]
Phase 3: Strategic Implementation
Step 6: Coherent Action Planning
Technical Level Decision-Making
Phase 1: Technical Architecture Assessment
Step 1: Abstraction Level Analysis
Determine whether the solution requires foundational infrastructure (protocol) or user-facing applications (platform)[5][9]
Assess technical complexity and whether it fits in the Clear, Complicated, Complex, or Chaotic domain[6][14]
Evaluate interoperability requirements and cross-system communication needs[5][9]
Step 2: Scalability and Performance Evaluation
Analyze whether scalability challenges exist at the network level (protocol solution) or application level (platform solution)[5][9]
Consider consensus mechanism requirements and security model preferences[5][9]
Evaluate development velocity needs: rapid iteration (platform) vs. network-wide coordination (protocol)[5][9]
Phase 2: Technical Solution Design
Step 3: Security and Trust Model Selection
Step 4: Development Methodology Choice
For Clear/Complicated domains: Apply established development practices appropriate to the chosen approach[6][14]
For Complex domains: Implement experimental approaches with safe-to-fail experiments[6][14]
For Chaotic domains: Focus on rapid stabilization before transitioning to more structured approaches[6][14]
Phase 3: Implementation Strategy
Step 5: Deployment Model Definition
Step 6: Technical Risk Management
Community Level Decision-Making
Phase 1: Stakeholder Analysis
Step 1: Community Mapping
Step 2: Governance Model Assessment
Phase 2: Community Engagement Strategy
Step 3: Communication Framework Design
Step 4: Participation Mechanism Creation
Phase 3: Community Implementation
Step 5: Adoption Strategy
Step 6: Community Sustainability
Integrated Decision Matrix
To synthesize these three levels, use this decision matrix to evaluate each major factor:
Factor | Protocol Indicator | Platform Indicator | Decision Weight |
Technical Architecture | Lower abstraction needs | Higher abstraction needs | High |
Scalability Requirements | Network-level scaling | Application-level scaling | High |
Governance Model | Decentralized community | Centralized efficiency | Medium |
Economic Model | Infrastructure value capture | Application value capture | High |
User Experience | Developer-focused | End-user focused | Medium |
Security Model | Network-wide guarantees | Application-specific | High |
Development Model | Network coordination | Rapid iteration | Medium |
Implementation Guidelines
For Leadership Teams
Begin every strategic decision with Rumelt's diagnostic process[1][2]
Use the Cynefin Framework to avoid applying wrong solutions to problems[3][4]
Set proximate objectives that create momentum toward larger goals[8][13]
Regularly reassess whether the chosen approach remains appropriate as conditions change[7][2]
For Technical Teams
Match technical architecture decisions to problem complexity using Cynefin domains[6][14]
Prioritize interoperability and composability when choosing protocol approaches[5][9]
Focus on user experience optimization when selecting platform approaches[5][9]
Build in measurement and feedback mechanisms regardless of the chosen approach[5][9]
For Community Teams
This methodology provides a structured yet flexible approach to making strategic decisions about protocol versus platform solutions, ensuring that technological choices align with broader organizational objectives while serving the needs of all stakeholders involved.
⁂
https://www.lennysnewsletter.com/p/good-strategy-bad-strategy-richard
https://www.alexmurrell.co.uk/summaries/richard-rumelt-good-strategy-bad-strategy
Sensemaking-Approaches-for-Platform-and-Protocol-Decision-Making.docx
https://www.startuphughes.com/good-strategy-importance-proximate-goals/
Web3-Platforms-vs-Protocols-A-Comprehensive-Analysis-of-Distinguishing-Factors.docx
https://jlzych.com/2018/06/27/notes-from-good-strategy-bad-strategy/
https://www.strategykiln.com/post/bad-strategy-good-strategy-how-to-tell-the-difference
https://www.linkedin.com/pulse/first-step-making-decision-understand-context-cynefin-vyborov
https://admiredleadership.com/book-summaries/good-strategy-bad-strategy/
https://dev.to/teamcamp/cynefin-framework-for-technical-decision-making-a-developers-guide-2amd
Web3-Platforms-vs-Protocols-A-Framework-for-Understanding-Decentralized-Ecosystems.docx
https://aaronhall.com/unlocking-competitive-advantage-the-power-of-stretch-and-leverage/
Protocols-vs-Platforms-A-Comprehensive-Analysis-of-Digital-Infrastructure-Philosophy-and-Spirit.docx
Regis Chapman
Support dialog