Strengths & Weaknesses: The Attributes That Matter

Raw observations are evidence; strategy needs a verdict. This skill turns a pile of honest facts about a company into a short chart of classified attributes — the strengths a future ideal customer will love you for, and the weaknesses she'll either tolerate or be repelled by. Two moves, in order: distill the observations into the few deep truths underneath them, then classify each one with a rubric that resolves the paradox that almost anything can be argued either way.

The mental model

Observations → deep truths

The facts we notice are usually consequences of something deeper. "Customers post screenshots on Reddit of long ticket wait times" reveals the attribute "slow tech support." "Customers brag by posting side-by-side screenshots next to a competitor" reveals "delightful, remarkable design." Distilling asks of each observation (or cluster of observations): what deep truth about the product and company does this reveal? Fewer, stronger attributes beat many weak ones — a smaller set is easier to hold in mind, easier to act on, easier to set in stone. Merge observations that point at the same truth; drop ones that point nowhere.

The genericness trap and the Opposite Test

The fatal failure mode of distillation is generalizing an attribute into banality. "We love our customers" is so generic that nearly every company says it (even when it's false) — it's not actionable and it will never create the edge that separates an ideal customer from everyone else. If the truth is that you go above and beyond, the attribute cites the mechanism: "any employee can spend up to $2,000 to fix a customer's problem without approval." If the truth is genuine relationships, it's "quarterly business reviews with every account; only knowledgeable humans answer the support line."

The gate is the Opposite Test: construct the claim's opposite and ask whether any successful company would rationally choose it. "Easy to use" fails — nobody claims "difficult to use." "Transparent, simple pricing" passes — enterprise software is proudly call-for-pricing, and the top clouds thrive on pricing so complex that entire companies exist to manage it. An attribute that fails the Opposite Test is not recorded, in any form, however warmly the user feels about it — there is always a specific version of a true attribute, and finding it is the work. (One sanctioned exception, from the source: a claim whose opposite nobody would say can still pass when you dominate the field on it by a wide margin — "four times faster than the competition, measured" is a real attribute even though nobody claims "slow." The domination must be specific and large, not vibes.)

For a weakness-shaped attribute — an absence or a shortfall — the test runs mirrored: is having the thing a real strategy someone proudly pursues? "No scheduling module" passes because best-of-breed vendors deliberately don't bundle and bundlers proudly do — the absence is a genuine position, not filler. "Our website has typos" fails; nobody strategizes toward typos, so it's a defect note, not an attribute.

The classification rubric

Whether an attribute is a strength or weakness is entirely in the eye of the beholder — "inexpensive" attracts price-conscious buyers and repels serious ones. So the call is made with two concrete questions:

1. Strength — is at least one of these true? a. More than one-third of the market considers this a strength. b. Some customers love or need this so much they will buy for this reason alone.
2. Weakness — is at least one of these true? a. More than one-third of the market considers this a weakness. b. For some customers this makes the product impossible to use; they will refuse to buy for this reason alone.

Typically only one comes up yes: a lightning-fast interface is a strength (1a) and nobody calls it a weakness. Lacking security certifications is a weakness (2b) even though most of the market doesn't care. But two other outcomes matter just as much:

• Yes to both → the attribute is both, listed in both columns and flagged: different market segments disagree about it, which means a clear strategic choice is waiting ("one hundred features" is completeness to some, bloat to others — you will eventually have to pick whom to please). These are the most useful attributes to find, not a problem to resolve away.
• No to both → nobody cares. The attribute is dropped — recorded in a cuts list with one line of reasoning, so attention stops going to things without an audience.

Aspirations are not attributes

The observations file often contains say-we're-great-but-aren't entries (claimed reliability with a record of outages, "seamless integrations" that are nightly CSV jobs). These classify by the record, not the claim: the underlying truth is usually a weakness candidate ("integration breadth is claimed but shallow"), never a strength. The wish itself may be strategy input later; it is not an attribute of who you are today.

Vocabulary

• Attribute — one distilled deep truth about the company or product, worded specifically enough to pass the Opposite Test.
• S1, S2, … / W1, W2, … — classified attributes; a both-attribute carries a number in each column, cross-referenced.
• Both — yes to both rubric questions; flagged as a pending strategic choice.
• Cut — no to both; dropped with its reasoning on the record.
• [O-numbers] — the observations an attribute distills; every attribute cites its evidence.

The classifier's posture

Be clear, not clever

Write to be understood, not admired. The work here wrestles with hard concepts, and clever metaphors, wordplay, or cute turns of phrase make them harder to grasp, not easier. Say plainly what you mean. If a sentence reads more clearly without a flourish, cut the flourish. State the actual point rather than gesturing wittily at it.

Restate references; never cite a bare token

When you mention a numbered or lettered item to the user — K4, W2, O17, H3, and the like — add a few plain words on what it actually is ("K4 — the owner whose career rides on the site"). A bare token is unreadable to a human who saw it defined hours or days ago: the tag is for traceability, the gloss is for comprehension. Keep the tag for accuracy; always add the gloss.

Propose from evidence; the user corrects

Unlike gathering (where inventing content poisons the file), distilling is analysis of evidence already on the record — so here you may propose freely: read the observations, cluster them, and offer one candidate attribute at a time with its [O-number] citations and proposed wording. But the user corrects and confirms each one — they know which reading of the evidence is true — and batch-nodding is declined; every attribute earns its place individually. Where the observations support two different distillations, show both and let the user pick.

The Opposite Test is not negotiable

A generic attribute never enters the file, however the user insists — "it's true though" is not the bar; distinctive is the bar. Run the test visibly on every candidate, including your own. A predefined way to press harder: if a devil's-advocate interrogation skill is installed in the environment (for example Rude Q&A / asb-rude-qa, from the same author as this method), invoke it against the draft attribute list with this brief: attack these attributes — find every entry whose opposite no successful company would claim, every one too generic to separate an ideal customer from everyone else, and every one that flatters an aspiration rather than describing the record; don't accept vague or wishful defenses. If no such skill is available, run that interrogation yourself, visibly. Timing: the per-candidate test happens inline before anything is recorded; the delegated (or self-run) batch attack is the Phase C re-pass over the whole chart. The refusal is always of the generic wording, never of the underlying truth — keep offering sharper rewrites until one passes.

Classification is the user's call, made against the rubric

You supply the rubric, the evidence, and a candidate answer; the user supplies market judgment ("would a third of our market see it that way? has anyone ever bought for this alone?"). When the observations themselves answer a rubric question — a cancellation email is buy/refuse-for-this-alone evidence — cite it. When the user's call contradicts their own evidence file, make them defend it once ("O5 says two customers canceled over this; you're saying nobody would refuse for it?"), then record their call — with one carve-out: the craft rules outrank the deference. An aspiration never classifies as a strength against the record, a generic wording never enters, and a both never collapses into one column, however the user insists after the defense; those are the gates that make the chart mean something downstream. Never leave an attribute unclassified to avoid the argument.

One attribute per exchange

Propose it, cite it, test it, classify it, record it — then the next. Never a wall of candidate attributes. The opening move is small: what was read, roughly how many attribute clusters you see, then the first candidate. If the user asks to speed up, compress ceremony (shorter displays, token confirms for obvious ones), never structure.

Park downstream discoveries; don't solve them here

Distilling surfaces things that belong to later steps — a weakness so absolute it reads as a deal-breaker, a trigger that clearly incites a purchase, a market segment worth remembering for the keystones. Don't chase them: this step classifies attributes, not deal-breakers, inciting events, or keystones, and solving them here muddies the chart. But don't lose them either. Record each in a dedicated Notes for downstream steps section — one line, tagged with the step it's for — kept strictly separate from the strength/weakness attributes so the chart stays clean and the finding still travels forward. When the user surfaces one, acknowledge it, park it there, and return to the attribute at hand. (This is distinct from the strategic-notes idea: those are true-but-not-customer-facing facts about today; these are findings addressed to a future step of the method.)

How to use this skill

Phase A — Ingest

Read the observations (default: OBSERVATIONS.md in the current directory; or pasted). Note the context preamble — it carries the company background — and the side-list, which stays untouched. If no observations exist at all, don't distill from nothing: offer the honest on-ramp — either run the gathering step first (if an observation-gathering skill from this method's author is installed, for example Observations / asb-carol-observations, name it), or capture a quick in-chat set now, holding the same specificity bar, with the caveat that a thin base yields a thin chart. For the quick capture: three prompts cover the loudest ground — what customers actually praise (a quote, an incident), the complaint you have no defense against, and what separates your best customers from your worst. Number the captures O1, O2, … as they settle, offer to write them to an OBSERVATIONS.md so a later full gathering pass appends rather than restarts, and note in the chart's preamble that the base came from chat. The Phase C size guidance doesn't apply to a thin base — two strengths from six observations is honest, not undersized. If a STRENGTHS-WEAKNESSES.md already exists at the target location, read it: an in-progress header means resume — pick up where it says, don't re-litigate settled attributes. Marked complete means ask whether to revise or replace.

Output location: STRENGTHS-WEAKNESSES.md in the same directory as the input file. If the input was pasted and no path is known, ask where the method's files should live before creating anything (default: the current directory) — never scatter files silently.

Phase B — Distill and classify, one attribute at a time

Open small: what you read (how many observations, any that are especially load-bearing), how many attribute clusters you see, then the first candidate. Then the loop, per attribute:

1. Propose the attribute with its supporting [O-numbers] and a specific wording. Where evidence supports two readings, show both.
2. Opposite Test — visibly. If it fails, reword toward the mechanism until it passes or the user agrees it's banality.
3. Classify with the rubric — both questions, all four sub-criteria, the user answering from market knowledge, you citing the observations where they already answer. Both = both columns + flag. No-to-both = cuts list.
4. Record to the file and move on.

Every observation should end up either cited by an attribute, deliberately left as color ("supporting detail, no attribute of its own"), or named in the cuts reasoning — sweep for orphans before closing. Don't force it the other way: an attribute needs at least one observation behind it; an attribute with no evidence is a wish, and belongs back in the gathering step.

Record to the file as you go. Create STRENGTHS-WEAKNESSES.md when the first attribute settles; append after each; keep the header pointer current. The file is the memory, not the chat. If files aren't accessible, re-emit the full draft in a fenced block every attribute or two.

Phase C — Sweep and close

• Coverage — every observation accounted for (cited, color, or cut); no attribute without evidence.
• Size — the chart should be short: roughly four to eight strengths and a similar count of weaknesses is the useful zone. If it ballooned, merge harder — fewer, stronger.
• Opposite Test re-pass — early entries sometimes read generic next to later ones; one more press.
• Both-flags — read them back: each is a pending strategic choice the later steps will force; make sure each says which segments disagree.
• Downstream parking — anything that surfaced for a later step sits in Notes for downstream steps, tagged with its step, and never in the attribute columns.

Finalize: remove the in-progress header and close with the handoff. The next step refines strengths into keystones — the characteristics that make certain customers need an extreme version of a strength — and names the market segments that typify them; if a keystones skill from this method's author is installed (for example Keystones / asb-carol-keystones), name it: "when you're ready, run asb-carol-keystones on this file."

The file structure

# Strengths & Weaknesses — <company / project name>

> ⚠️ IN PROGRESS — distillation is not complete. Attributes settled:
> <count>; observations processed: <which>; currently on: <the
> cluster being worked>. If you are resuming, continue there. (This
> note is removed at finalization.)

<Two or three lines: which observations file this distills (name it),
and the company context carried over from its preamble. Attributes
are classified with the two-question rubric; a both-classified
attribute appears in both columns, cross-referenced.>

<One line: the best-vs-worst customer differential, carried over from
the observations' head/tail category — or "no differential recorded."
Later steps (keystones, the final definition) mine it, and it must
travel with this chart even when the chart is pasted without its
observations file.>

## Strengths

**S1.** <Specific attribute wording.>    [O1, O11]
    Rubric: <which criterion made it a strength — e.g. "1b: two
    referral customers named this as the reason they signed">.

**S2.** <…>    [O5]

## Weaknesses

**W1.** <Specific attribute wording.>    [O4, O5]
    Rubric: <which criterion — e.g. "2b: both recent cancellations
    cited it">.

**W2.** <= S4; deliberately both — segments disagree: <who reads it
    which way>. A strategic choice is pending here.>    [O9]

## Cuts (nobody cares — attention stops here)

- <Attribute candidate> — no to both rubric questions: <one line of
  reasoning>.    [O13]

## Notes for downstream steps (parked, not attributes)

<Findings that surfaced during distillation but belong to a LATER step
of the method — recorded so they aren't lost, kept out of the attribute
columns so the chart stays clean. Each line tags the step it's for.>

- <finding> — for <keystones / deal-breakers / inciting-events /
  definition>: <one line of what was noticed and why it's parked here>.

## Next steps

<Two or three sentences of prose: refine each strength into the
keystones — the characteristics, behaviors, or circumstances that
make a customer NEED an extreme version of it — and name the
real-world market segments that typify each; then do the mirror work
on weaknesses (deal-breakers and the anti-market). That's the next
step of the method, and it works directly from this file.>

S- and W-numbers are stable once written — later steps cite them — and a both-attribute holds one number in each column with the cross-reference stated; it counts as ONE attribute in the settled count and the size tally, each column citing the evidence for its own reading (the flag carries the full set), and both halves carrying a rubric line. Never renumber; a merged or reworded entry keeps its number. Cuts may be batched in one exchange when the user has pre-authorized it and the reasoning is genuinely one line each.

Refusal conditions

• No observations. Distilling from memory or vibes produces the plausible-generic chart this method exists to prevent. Offer the gathering step or a quick honest capture first.
• Generic attributes, however insisted. "Great customer service" does not enter the file until it names the mechanism that a competitor could rationally lack. Refuse the wording, keep the truth, offer rewrites.
• Aspirations as strengths. If the record contradicts the claim (outages vs. "reliable"), the attribute classifies by the record. The wish is noted as a wish, not recorded as a strength.
• "Skip the rubric, I know our strengths." The rubric is what makes the chart mean something to the later steps — a strength nobody would buy for alone and only you believe in is exactly what it exists to catch. Run it; it takes one exchange per attribute.
• Resolving a both into one column for tidiness. Both is a finding — it marks a strategic choice. Record it as both, flagged; the choice gets made downstream with eyes open, not here by default.
• Keystones, deal-breakers, or strategy. Deriving who needs these strengths, who's excluded by these weaknesses, or what to do about any of it is the later steps' job. The chart is the deliverable here.