| name | multi-surface-strategy |
| description | Design a coherent multi-surface strategy where desktop, mobile, and web each have unique complementary roles. Use when planning multiple surfaces or adding a new platform. Trigger phrases: 'design the multi-surface strategy', 'map surfaces to contexts not devices', 'what is each surface uniquely good at', 'define the handoffs between surfaces'. |
OpenClaw Integration: This skill is invoked by the Dojo Genesis plugin via /dojo run multi-surface-strategy.
The agent receives project context automatically via the before_agent_start hook.
Use dojo_get_context for full state, dojo_save_artifact to persist outputs,
and dojo_update_state to record phase transitions and decisions.
Multi-Surface Product Strategy Skill
Version: 1.1
Created: 2026-02-07
Updated: 2026-02-07
Author: Manus AI
Purpose: To guide the design of a coherent multi-surface product strategy where each surface (e.g., desktop, mobile, web) has a unique, complementary role.
I. The Philosophy: Complement, Don't Compete
In a multi-surface world, the biggest mistake is to build the same product on every device. A desktop app, a mobile app, and a web app should not be clones of each other. They should be complementary surfaces, each optimized for the unique context in which it will be used.
This skill is about designing a product strategy where the whole is greater than the sum of its parts. We will define the unique "job-to-be-done" for each surface and then design a seamless experience for users as they move between them.
The core principle: Surfaces are for contexts, not devices.
II. When to Use This Skill
- When planning a new product that will exist on multiple surfaces
- When adding a new surface (e.g., a mobile app) to an existing product
- When a multi-surface product feels fragmented or confusing
- During a strategic review of a product line
- After using
/product-positioning to identify unique value propositions
III. The Workflow
This is a 5-step workflow for designing a multi-surface product strategy.
Step 1: Identify the Surfaces
Goal: List all current and potential product surfaces.
Actions:
- List the existing surfaces (e.g., web app)
- Brainstorm potential new surfaces (e.g., desktop app, mobile app, browser extension)
- Consider unconventional surfaces (e.g., CLI, API, voice interface)
Output: A complete list of all surfaces to consider
Step 2: Define the Core Job-to-be-Done for Each Surface
Goal: For each surface, define the primary job that users will hire it to do, based on its unique context.
Actions:
- For Desktop, define the job as "deep work, complex orchestration, sustained focus"
- For Mobile, define the job as "on-the-go quick capture, lightweight orchestration, glanceable status"
- For Web, define the job as "discovery, onboarding, cross-platform access without installation"
- For each surface, ask: "What is this uniquely good at that the others aren't?"
Output: A clear job-to-be-done statement for each surface
Step 3: Map Features to Surfaces
Goal: Map existing and potential features to the surface where they best fit, based on the core job-to-be-done.
Actions:
- Create a table with surfaces as columns and features as rows
- For each feature, decide which surface is its primary home
- Identify features that should exist on multiple surfaces (with different implementations)
- Identify features that should be surface-exclusive
Output: A feature-to-surface mapping table
Example:
| Feature | Desktop | Mobile | Web |
|---|
| Complex multi-agent orchestration | Primary | - | - |
| Quick task capture | Secondary | Primary | Secondary |
| Status monitoring | Secondary | Primary | - |
| Deep configuration | Primary | - | Secondary |
| Onboarding tutorial | - | - | Primary |
Step 4: Design the Handoffs
Goal: Design the mechanisms for seamless handoffs between surfaces.
Actions:
- Define the sync architecture (e.g., cloud-based, real-time, eventual consistency)
- Design the user experience for handoffs (e.g., "Continue on Desktop" button on mobile)
- Identify handoff triggers (e.g., "This task is too complex for mobile, switch to desktop")
- Design the visual/notification system for cross-surface awareness
Output: A handoff design document with sync architecture and UX patterns
Step 5: Define the Business Model
Goal: Define the business model for the multi-surface strategy.
Actions:
- Decide which surfaces are free, paid, or part of a subscription
- Define the pricing tiers and what's included in each
- Consider surface-specific pricing (e.g., desktop is core, mobile is premium add-on)
- Plan the rollout timeline (e.g., desktop first, mobile 4-6 weeks later)
Output: A business model document with pricing and rollout plan
IV. Best Practices
1. Surfaces are for Contexts, Not Devices
Why: Users don't think "I need the mobile version." They think "I need to capture this idea quickly while I'm walking."
How: Frame each surface by its context of use, not by its device type.
2. The Handoff is the Feature
Why: The most magical part of a multi-surface strategy is the seamless handoff between surfaces. This is what makes the whole greater than the sum of its parts.
How: Invest heavily in sync architecture and handoff UX. Make it feel like one product, not three separate apps.
3. Simplicity Sells
Why: Each surface should be ruthlessly simple, focused on its core job-to-be-done. Feature bloat kills the magic.
How: Resist the temptation to add every feature to every surface. Say no to features that don't align with the surface's core job.
4. Start with One Surface, Expand Strategically
Why: Building multiple surfaces simultaneously is expensive and risky. Start with the core surface, prove the value, then expand.
How: Launch desktop first (for deep work), then add mobile (for on-the-go) once desktop is stable.
5. Design for Asymmetry
Why: Symmetrical multi-surface strategies (same features everywhere) are boring and wasteful.
How: Embrace asymmetry. Make each surface uniquely valuable. Users should want both, not just one.
V. Quality Checklist
Before delivering the strategy, ensure you can answer "yes" to all of the following questions:
VI. Example: Dojo Genesis Desktop + Mobile Strategy
The Problem: We had a web app but needed to decide whether to build desktop, mobile, or both.
The Process:
- Identified Surfaces: Desktop (Electron), Mobile (PWA/Native), Web (existing)
- Defined Jobs:
- Desktop: Deep work, complex multi-agent orchestration, sustained focus sessions
- Mobile: On-the-go task capture, quick status checks, lightweight orchestration
- Web: Discovery, onboarding, lightweight access without installation
- Mapped Features:
- Complex orchestration → Desktop primary
- Quick capture → Mobile primary
- Onboarding → Web primary
- Designed Handoffs:
- Cloud sync via backend API
- "Continue on Desktop" button in mobile app
- Real-time status updates across surfaces
- Defined Business Model:
- Desktop: Core product ($20/month)
- Mobile: Premium tier (separate subscription, launched 4-6 weeks after desktop)
- Web: Free tier for discovery
The Outcome: A clear, asymmetric multi-surface strategy where each surface has a unique value proposition. Desktop for deep work, mobile for on-the-go.
Key Decision: We chose Route 4 (Hybrid - PWA now, native later) to de-risk mobile development while shipping desktop first.
VII. Common Pitfalls to Avoid
Pitfall 1: Building the Same Product on Every Surface
Problem: Users don't see the value in having multiple surfaces if they're all the same.
Solution: Define unique jobs-to-be-done for each surface and map features accordingly.
Pitfall 2: Ignoring the Handoff Experience
Problem: Users get frustrated when they can't seamlessly move between surfaces.
Solution: Invest in sync architecture and handoff UX from day one.
Pitfall 3: Feature Bloat on Every Surface
Problem: Trying to add every feature to every surface leads to complexity and confusion.
Solution: Be ruthlessly simple. Each surface should focus on its core job-to-be-done.
Pitfall 4: Building All Surfaces Simultaneously
Problem: Building multiple surfaces at once is expensive, risky, and dilutes focus.
Solution: Start with one core surface, prove the value, then expand strategically.
Pitfall 5: Symmetrical Pricing
Problem: Charging the same for all surfaces doesn't reflect their different value propositions.
Solution: Consider surface-specific pricing (e.g., desktop as core, mobile as premium add-on).
VIII. Related Skills
product-positioning - Use this first to identify the unique value of each surfacestrategic-scout - Use this to explore multiple routes for multi-surface strategyiterative-scouting - Use this to refine the strategy based on feedbackrelease-specification - Use this to write detailed specs for each surfaceparallel-tracks - Use this to build multiple surfaces in parallel (if needed)
IX. Skill Metadata
Token Savings: ~5,000-8,000 tokens per multi-surface strategy session
Quality Impact: Ensures coherent, complementary multi-surface strategies
Maintenance: Update when new surface types emerge (e.g., AR/VR, voice)
When to Update This Skill:
- After completing 2-3 multi-surface strategies (to incorporate new patterns)
- When a new surface type becomes mainstream (e.g., AR glasses)
- When handoff patterns evolve (e.g., new sync technologies)
Last Updated: 2026-02-07
Maintained By: Manus AI
Status: Active
OpenClaw Tool Integration
When running inside the Dojo Genesis plugin:
- Start by calling
dojo_get_context to retrieve full project state, history, and artifacts
- During the skill, follow the workflow steps documented above
- Save outputs using
dojo_save_artifact with the artifacts output directory
- Update project state by calling
dojo_update_state to record skill completion and any phase transitions
