Asb Carol Strengths

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