/translate

name: translate
description: "Use this skill when the user is a domain expert (lawyer, doctor, contractor, accountant, etc.) who wants to turn their professional knowledge into a software product. Also use when the user says 'I have an idea for my industry,' 'I know this problem exists,' 'I want to build something for [profession],' or is struggling to describe what they want the software to do. Helps identify which professional pain is worth building for, then translates it into requirements AI tools can execute."

Translate Your Expertise Into a Product

You've spent years mastering your field. You know exactly which parts of the job suck. This skill helps you go from "I know this problem exists" to "here's what the software needs to do" — in language AI tools can build from.

Core Principles

• You don't need to learn to think like a developer. You need to describe the pain clearly. AI handles the rest.
• After 20 years, your daily workflow is already efficient. The opportunity isn't in your routine — it's in the pain you've learned to live with.
• The best SaaS products don't automate everything. They eliminate the one step that makes professionals say "I hate this part."
• Your domain expertise is the product spec. The hard part isn't building — it's knowing what to build. You already know.
• If you can't explain why it's painful to a stranger in 30 seconds, the pain isn't sharp enough to build a business on.

---

Step 1: Find the Pain Worth Building For

Don't catalog your workflow. Go straight to the pain.

Answer these five questions. Write one sentence for each — don't overthink it.

1. What task do you put off or dread, even though you've done it hundreds of times?
2. What takes way too long relative to the value it produces?
3. What makes you think "there has to be a better way" at least once a month?
4. What do you see junior people in your field struggle with that a tool could fix?
5. What would you pay $100/month to never do again?

**Tell AI:**

I'm a [your profession] with [X] years of experience. Here are my top pain points:

1. [Pain — what you dread or avoid]
2. [Pain — what takes too long]
3. [Pain — "there has to be a better way"]
4. [Pain — what juniors struggle with]
5. [Pain — what you'd pay to eliminate]

For each one, evaluate:
- How often does this pain occur? (daily, weekly, monthly)
- How many other [professionals in my field] have this same pain?
- Do existing tools solve this? If so, what's wrong with them?
- Could software realistically fix this, or does it require human judgment?
- What's the current workaround? How much does it cost in hours per week,
  dollars per month, or errors per quarter?

Rank them by: frequency × pain intensity × market size × buildability.
Tell me which one is the strongest SaaS opportunity and why.

> **"Everyone in my field needs this"** usually means you can't find anyone specific. Name one person — a real colleague with a real name — who has this pain. If you can't, keep looking.

What Makes a Pain SaaS-Worthy

| Signal | Strong | Weak | |--------|--------|------| | Frequency | Weekly or more | Once a year | | Who has it | Everyone in the profession | Just you | | Current solution | Manual, spreadsheets, or broken tools | Good tool already exists | | Willingness to pay | "I'd pay right now" | "That would be nice" | | Buildability | Data in, decision out | Requires deep human judgment |

**Kill the idea early if:**

• Only you have this pain (it's a personal annoyance, not a market)
• A good tool already exists and people know about it (you're late)
• The pain is infrequent (annual tax filing isn't a SaaS business)
• It fundamentally requires human judgment at every step (can't automate)

---

Step 2: Describe the Pain, Not the Solution

The most common mistake domain experts make: jumping straight to "I want an app that does X." Describe the problem first. Let the solution emerge.

**Bad:** "I want a platform with a document management system, automated filing, and client portal."

**Good:** "Every time I close a real estate deal, I spend 3 hours tracking down documents from 6 different parties, checking that everything is signed, and uploading them to the county recorder's system. Half the time something is missing and I have to chase someone down."

The second version tells AI tools exactly what to build. The first version is a feature list that might not solve the actual problem.

**Tell AI:**

Here's the pain I want to solve:

WHO has this pain: [profession, role, experience level]
WHAT the painful task is: [describe what they do, step by step — only the painful part]
HOW OFTEN it happens: [daily/weekly/monthly]
HOW LONG it takes: [time per occurrence]
WHAT GOES WRONG: [the specific failure modes, errors, frustrations]
WHAT THEY DO NOW: [current tools, spreadsheets, manual processes, workarounds]
WHAT "DONE WELL" LOOKS LIKE: [how do they know the task was completed successfully?]

Based on this, what should the software do? Describe it as a workflow the user
would go through — not a list of features. What do they see when they open the app?
What do they click? What happens automatically vs. what requires their input?

---

Step 3: Separate "I Need This" from "The Market Needs This"

You are the expert, but you're also one person. Your preferences aren't the market.

The Expert's Blind Spots

| Trap | Reality | Fix | |------|---------|-----| | "I'd use every feature" | You're a power user. Most people need 20% of what you'd build | Build the 20% first | | "It needs to handle edge case X" | You've seen edge case X because you've done this 5,000 times. Most users haven't | Ship without it, add when someone hits it | | "The existing tools are all terrible" | They might be good enough for 80% of people. YOUR bar is higher | Validate that others share your frustration | | "I know exactly what this should look like" | You know YOUR workflow. Others in your field may do it diff