Unscalable Tactics

---
name: unscalable-tactics
description: Identify specific unscalable actions that can accelerate early traction for a product or startup.
license: MIT
metadata:
  version: 1.0.5251
  author: sethmblack
repository: https://github.com/sethmblack/paks-skills
keywords:
- absurdist
- unscalable-tactics
- writing
---

# Unscalable Tactics

Identify specific unscalable actions that can accelerate early traction for a product or startup.

---

## When to Use

- Launching a new product and need early users
- Stuck at low usage and don't know how to grow
- Have a product but no organic traction yet
- Deciding where to focus limited early-stage resources
- User asks "How do I get my first users?" or "What should I do that doesn't scale?"

---

## Inputs

| Input | Required | Description |
|-------|----------|-------------|
| product | Yes | What you're building/selling |
| current_state | No | How many users/customers now, any traction |
| target_user | No | Who you're trying to reach |
| constraints | No | Time, money, location, or other limits |

---

## Paul Graham's Philosophy

### The Core Insight
"A lot of startup founders think their job is to build something great and then let it grow organically. But startups take off because the founders make them take off."

"The most common unscalable thing founders have to do at the start is recruit users manually. Nearly all startups have to. You can't wait for users to come to you. You have to go out and get them."

### Why Unscalable Works
1. **You learn faster** - Direct contact reveals what users actually need
2. **You create superfans** - Personal attention creates loyalty that scales
3. **You prove demand** - Manual growth validates before you invest in automation
4. **Competitors won't** - They think it's beneath them

### The Danger of Premature Scaling
Founders want to scale because:
- It feels more "startup-like"
- It's more impressive to talk about
- Manual work feels like drudgery

But premature scaling means:
- You don't know if the product is right yet
- You're amplifying something that might not work
- You miss the insights from direct user contact

---

## Categories of Unscalable Tactics

### 1. Manual User Recruitment
Go find users one by one. Knock on doors (literally or metaphorically).

**Examples:**
- Stripe: Patrick Collison would grab people's laptops and install Stripe for them
- Airbnb: Founders went door-to-door in NYC signing up hosts
- DoorDash: Founders delivered food themselves
- Pinterest: Ben Silbermann approached strangers in coffee shops

**Questions to answer:**
- Where do your target users physically or digitally gather?
- Can you reach them directly without intermediaries?
- What would make someone say yes to a stranger?

### 2. Concierge Service
Do for users manually what your product will eventually automate.

**Examples:**
- Food on the Table: Manually created meal plans before building automation
- Zapier: Founders did integrations by hand initially
- Legaltech startups: Lawyers manually reviewing before ML takes over

**Questions to answer:**
- What process will your product automate?
- Can you do that process manually for early users?
- What will you learn by doing it yourself?

### 3. Extreme Customer Service
Provide service levels that large companies can't match.

**Examples:**
- Wufoo: Sent handwritten thank-you notes to customers
- Zappos: Famous customer service stories (flowers to customers, etc.)
- Early Slack: Founders answered every support ticket personally

**Questions to answer:**
- What would "absurdly good" service look like?
- What surprises could you add to the experience?
- How can you make users feel individually valued?

### 4. Doing the Hardware Part
If software is easy but hardware/logistics is hard, do the hard part manually.

**Examples:**
- Instacart: Founders did the shopping and delivery
- Webvan survivors: Started with manual operations, didn't over-automate
- Flexport: Manually coordinated shipments before building software

**Questions to answer:**
- What's the unsexy operational part of your business?
- Can you do it yourself before hiring/automating?
- What would you learn by touching the physical process?

### 5. Focused Niche Domination
Be everything to a tiny group before expanding.

**Examples:**
- Facebook: Harvard only, then Ivy League, then colleges, then everyone
- Yelp: San Francisco only, then city by city
- PayPal: eBay power sellers, then broader e-commerce

**Questions to answer:**
- What's the smallest viable market you could dominate?
- Who are the 100 users who would be devastated if you disappeared?
- Can you be the obvious choice for a narrow niche?

### 6. Content/Community Creation
Build the audience before or alongside the product.

**Examples:**
- Indie Hackers: Community first, product second
- ConvertKit: Nathan Barry blogged his way to customers
- Buffer: Transparency blog built massive goodwill

**Questions to answer:**
- What could you teach or share that would attract your target users?
- Is there a community your users lack?
- Can you be known for something before you're known for your product?

---

## Workflow

### Step 1: Gather and Review Inputs

Collect all relevant information:
- Review the provided data and context
- Identify key parameters and constraints
- Clarify any ambiguities or missing information
- Establish success criteria

### Step 2: Analyze the Situation

Perform systematic analysis:
- Identify patterns and relationships
- Evaluate against established frameworks
- Consider multiple perspectives
- Document key findings

### Step 3: Generate Recommendations

Create actionable outputs:
- Synthesize insights from analysis
- Prioritize recommendations by impact
- Ensure recommendations are specific and measurable
- Consider implementation feasibility

## Outputs
```markdown
## Unscalable Tactics for [Product]

### Product Summary
[One-line description of what you're building]

### Current State
**Users:** [X]
**Traction:** [None / Some / Growing]
**Biggest challenge:** [What's blocking growth?]

### Recommended Unscalable Tactics

#### 1. [Tactic Name]
**Category:** [Manual Recruitment / Concierge / etc.]
**What to do:** [Specific, concrete actions]
**Where to find users:** [Specific places/channels]
**Target:** [How many users/interactions to aim for]
**Time investment:** [Hours per week]
**Why it works for you:** [Specific reasoning]

#### 2. [Tactic Name]
[Same structure]

#### 3. [Tactic Name]
[Same structure]

### Your Unscalable To-Do List
- [ ] [Specific action with deadline]
- [ ] [Another action]
- [ ] [Continue...]

### What You'll Learn
[What insights should you be looking for while doing these unscalable things?]

### When to Scale
[Signals that indicate you're ready to stop being unscalable]

### Warning Signs
[How to tell if you're doing unscalable things that won't lead to scale]
```

---

## Outputs

**Primary Output:** A structured analysis document that identifies and articulates patterns, insights, and actionable recommendations based on the input data.

**Format:**
```markdown
## Analysis: [Topic]

### Key Findings
- [Finding 1]
- [Finding 2]
- [Finding 3]

### Recommendations
1. [Action 1]
2. [Action 2]
3. [Action 3]
```

**Example output:** See the Example section below for a complete demonstration.

## Constraints

- Do not use this analysis as the sole basis for critical decisions
- Do not apply this framework to situations outside its intended scope
- Acknowledge that analysis is based on available data, which may be incomplete
- Honor the complexity of real-world situations that resist simple categorization
- Present findings with appropriate confidence levels
- Recognize the limits of the methodology

## Additional Notes

**Best practices:**
- Use this skill when the situation clearly matches its intended use cases
- Combine with related skills for comprehensive analysis
- Iterate on outputs if initial results don't fully meet requirements

**Common variations:**
- Adjust the depth of analysis based on available time and information
- Scale the approach for different levels of complexity
- Adapt the output format to audience needs

**When to skip this skill:**
- The situation doesn't match the core use cases
- Simpler approaches would be more appropriate
- Time constraints require faster methods

## Example

**Input:** "I'm building a tool that helps developers write better documentation. I have a working product but only 12 users, all friends. How do I get to 100?"

**Output:**



**Why this works:**

This example demonstrates the key principles of the skill in action. The approach is effective because:
- It follows the systematic workflow outlined above
- It shows concrete application of the framework
- It produces actionable, specific outputs rather than vague generalizations
- The analysis is grounded in observable details
- The recommendations are prioritized and implementable

**Alternative applications:**

This same approach can be applied to:
- Different contexts within the same domain
- Related but distinct problem types
- Scaled up or down depending on scope
- Combined with complementary analytical frameworks


## Unscalable Tactics for Developer Documentation Tool

### Product Summary
Tool helping developers write better documentation.

### Current State
**Users:** 12 (all friends/network)
**Traction:** None outside personal network
**Biggest challenge:** Getting in front of developers who don't know you

### Recommended Unscalable Tactics

#### 1. Documentation Makeovers
**Category:** Concierge Service
**What to do:** Find open-source projects with bad documentation. Email maintainers offering to rewrite their docs using your tool, for free. Show the before/after.
**Where to find users:**
- GitHub trending repos with sparse READMEs
- "documentation needed" issues on popular projects
- Projects with great code but complaints about docs
**Target:** 10 documentation makeovers in 30 days
**Time investment:** 15-20 hours/week
**Why it works:** You're providing massive value (free docs), demonstrating your tool, and reaching developers with proven need (their docs are bad). Maintainers talk to each other.

#### 2. Dev Community Presence
**Category:** Manual Recruitment
**What to do:** Find every place developers complain about writing docs. Answer questions, share tips, be helpful first. Mention your tool only when directly relevant.
**Where to find users:**
- r/programming, r/learnprogramming threads about documentation
- Twitter/X searches for "writing documentation is hard"
- Hacker News threads about docs
- Dev.to and Hashnode posts about documentation
**Target:** 20 genuine interactions per week, 5 users from this channel in first month
**Time investment:** 5-7 hours/week
**Why it works:** Developers respect other developers who help. Cold outreach fails; being helpful in public builds trust.

#### 3. Founder-Driven Support
**Category:** Extreme Customer Service
**What to do:** Personally onboard every new user. Get on a Zoom call, watch them use the product, fix their specific documentation. Make them successful.
**Where to find users:** Every new signup
**Target:** Zoom onboarding for 100% of new users until you hit 100 users
**Time investment:** 30-60 min per user (12-30 hours to reach 100)
**Why it works:** You'll learn exactly where users get stuck, what features matter, and what language they use. These users will become advocates because no one does this.

#### 4. Niche Domination: One Framework
**Category:** Focused Niche
**What to do:** Pick one framework/language (e.g., "documentation for Python packages" or "docs for React component libraries") and become THE tool for that niche.
**Where to find users:**
- Framework-specific Discord servers
- Subreddits for specific technologies
- Conference Slack/Discord for that framework
**Target:** Be known as "the docs tool for X" within one community
**Time investment:** Focus of messaging and outreach
**Why it works:** "Great for everyone" means "mediocre for everyone." "Great for React libraries" is a specific promise you can prove.

### Your Unscalable To-Do List
- [ ] Today: Identify 20 open-source projects with bad docs
- [ ] This week: Email 10 maintainers offering free doc rewrites
- [ ] This week: Set up saved searches for "documentation" in dev communities
- [ ] This week: Personally call every existing user, learn what's working
- [ ] Week 2: Complete first open-source makeover, share it publicly
- [ ] Ongoing: Zoom onboard every new user

### What You'll Learn
- Where do developers get stuck writing docs? (Product insight)
- What language do they use to describe their problem? (Marketing insight)
- What's the "aha moment" when the tool clicks? (Onboarding insight)
- Why do some users love it and others bounce? (Product-market fit insight)

### When to Scale
- 100 users and NPS > 50
- Clear pattern in what makes users successful
- Repeatable onboarding process you could hand to someone else
- Users referring other users without prompting

### Warning Signs
- If users from open-source makeovers don't convert, the product might not solve what you think it solves
- If Zoom calls feel like convincing rather than enabling, the product isn't ready
- If community presence gets lots of "cool" but no signups, you might be in the wrong community

---

## The Mindset Shift

Remember: "The unscalable stuff is not just something you have to endure in order to get to the part where you scale. It's the most valuable part."

The companies that skip unscalable tactics:
- Don't know their customers deeply
- Automate the wrong things
- Scale something that doesn't quite work
- Lose to competitors who did the manual work first

The companies that do unscalable things:
- Have unfair customer insight
- Build what users actually want
- Create superfans who do marketing for them
- Scale something that actually works

---

## Integration

This skill is part of the **Paul Graham** expert persona. Use it to generate specific, actionable tactics for early-stage growth when scalable channels aren't working yet.