agentleFS
mypip-iomypip-io/skills/why-they-said-yes/SKILL.md

why-they-said-yes

Skill1 starsChanged 26 days agoMITView on GitHub

Studies a founder's wins (customers who paid, people who replied, posts that worked) to find out why they worked and rewrite the ideal customer profile from evidence. Use when a founder has a few customers or replies and wants to know who to look for next, asks for voice of customer analysis, wants to learn from early users, or says \"what do my customers have in common\".

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 5 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If possible, a few who said no or went quiet, for contrast.

    line 19
  2. Distinctive:

    Rewrite the profile: Keep what the evidence supports, delete what it doesn't, add what you didn't expect.

    line 36
  3. Distinctive:

    Don't flatter the original plan.

    line 66
  4. Distinctive:

    Keep the founder's direct relationship with these early customers.

    line 67
  5. Distinctive:

    When the MyPip MCP is live, this skill will be able to read who said yes, no, or nothing to your introductions across your MyPip account, …

    line 72

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Why they said yes

Study your wins harder than your flops.

When something fails, founders take it apart for weeks. When something works, they say "nice" and move on. That's backwards. Analysing a failure mostly tells you one way not to do it. Analysing a win, in detail, tells you something you can repeat on purpose.

This skill takes whatever early wins exist (three customers, a handful of good replies, one post that took off) and works out what those people and moments had in common. The answer usually overwrites the profile the founder started with. That's the point. The first ideal customer profile is a guess. Your customers correct it.

What you need

Anything real. More is better, but three examples beats none.

  1. The people who said yes: customers, paying users, people who replied warmly, people who asked to try it. For each: what you know about them, where they came from, what they said in their own words.
  2. If possible, a few who said no or went quiet, for contrast.
  3. The founder's current idea of who the customer is.

Steps

  1. Lay the wins out side by side. One row per person. Columns: where they found you or you found them, what they said first, how quickly they understood the product, what they'd tried before, anything personal you know.
  2. Look for soft traits first. Shared attitudes, habits, places they spend time, things they care about, how they write. These are usually the real pattern. Plastic Bank's planned buyer was a sustainability director at a mid-sized company; the people who actually signed up turned out to share a love of the ocean and a humble, well-travelled outlook, and had little to do with job title.
  3. Measure speed of getting it. Which people understood the product fastest, with the fewest questions? Speed is a stronger fit signal than enthusiasm. Slow conversations full of questions usually mean the wrong person or the wrong message.
  4. Find the moment. For each win, what was happening for them right before they said yes? A launch that flopped, a new job, a deadline, a tool that broke. That moment is what to look for in the next person.
  5. Collect their words. Pull the exact phrases they used for the problem. Group the ones that repeat.
  6. Contrast with the no's. What did the people who said no or went quiet have that the yeses didn't? Those become your warning signs.
  7. Rewrite the profile. Keep what the evidence supports, delete what it doesn't, add what you didn't expect. Be honest when the data is thin. Three people is a hint, not a law.

Output

What the yeses share (strongest first):
1. <trait>, seen in <n> of <n>: <evidence>

The moment before yes: <what was happening for them>

Their words for the problem:
- "<exact phrase>" (<n> people)

Fastest to get it: <who, and what they had in common>

What the no's had instead (new warning signs):
- <trait>

Profile changes:
Keep: ...
Drop: ...
Add: ...

Confidence: <low / medium / high>, because <how much data>
Next: <who to find next, and where>

Rules

  • Evidence over theory. Every claim cites the people it came from.
  • Don't flatter the original plan. If the data says the founder targeted the wrong person, say so plainly.
  • Keep the founder's direct relationship with these early customers. The people who said yes are also the people most worth calling for the next product decision.
  • Revisit this every time the number of wins doubles.

With MyPip (coming)

When the MyPip MCP is live, this skill will be able to read who said yes, no, or nothing to your introductions across your MyPip account, so the analysis runs on every reply instead of the few you remember.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.