smithery/coowoolf

marginal-user-framework

Use when facing conversion plateaus, expanding to new markets, or when aggregate data fails to reveal growth bottlenecks, to identify high-leverage improvements by focusing on worst-case users

Installation

$ npx skills add smithery/coowoolf --skill marginal-user-framework

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from smithery/coowoolf · top by installs.

npx skills add smithery/coowoolf

Browse all from smithery/coowoolf

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 3,620 B
  • docs SUMMARY.md 223 B

History

  1. First recorded snapshot · 0 installs

SKILL.md

Marginal User Framework

Overview

A method for identifying high-leverage product improvements by focusing on the user "on the cusp" of conversion or the "worst-case scenario" user. Solving for the user with the most friction often resolves hidden issues for everyone.

Core principle: If you solve for the hardest user, you unlock growth for everyone.

When to Use

  • High traffic but low conversion
  • Expanding into new international markets
  • Data funnels not revealing friction points
  • Growth has plateaued unexpectedly

The Five-Step Process

┌─────────────────────────────────────────────────────────────────┐
│  1. IDENTIFY      →  Find "Worst Case" User                    │
│                      (bad device, slow network, language gap)  │
├─────────────────────────────────────────────────────────────────┤
│  2. OBSERVE       →  Watch them try to use it (qualitative)    │
│                      Don't rely solely on analytics            │
├─────────────────────────────────────────────────────────────────┤
│  3. INVENTORY     →  List ALL friction points encountered      │
│                      (latency, language, UI complexity)        │
├─────────────────────────────────────────────────────────────────┤
│  4. FILTER        →  Which fixes help the "marginal" user?     │
│                      (next-most-likely to convert)             │
├─────────────────────────────────────────────────────────────────┤
│  5. EXECUTE       →  Remove barriers for many by solving       │
│                      for the few                               │
└─────────────────────────────────────────────────────────────────┘

Quick Reference

Worst-Case Dimension What to Look For
Device Feature phones, low RAM
Network 2G/Edge, high latency
Language Non-primary language users
Tech Literacy First-time smartphone users
Accessibility Vision/motor impairments

Common Mistakes

  • Only using analytics → Observe users qualitatively
  • Optimizing for average → The "average" user doesn't reveal bottlenecks
  • Ignoring edge cases → Edge cases are the growth lever

Real-World Example

At Facebook, Adriel Frederick analyzed users on feature phones with Edge connections. He discovered the issues were language barriers and latency. Fixing latency for the "worst case" improved speed for the entire user base.


Source: Adriel Frederick (Reddit, Lyft, Facebook) via Lenny's Podcast