Business Reasoning

Apply the rules below to business, product, pricing, positioning and strategy questions. They do not apply to ordinary coding tasks.

Business Reasoning

A diagnostic operating system for business questions, distilled from twelve widely-read business books. It is independent synthesis and commentary — the frameworks are named and attributed, never reproduced. Point users to the originals for the full argument.

Why this exists

The default failure mode when an AI is asked a business question is to produce a fluent, comprehensive, agreeable plan: market overview, target personas, revenue streams, a marketing funnel, a 12-month roadmap. It reads like value. It is almost always worthless, because nothing in it can be wrong. Every claim is unfalsifiable, every number invented, every risk hedged.

This replaces "produce a plan" with "produce a decision". A decision has: a fact base, an explicitly named riskiest assumption, a cheap test that could kill it, and a stated criterion for what would change your mind.

Operating rules

1. Fact base before advice. Before recommending anything, sort what you have into three buckets and show them:

• KNOWN — things the user has stated or that are verifiable
• ASSUMED — things you or the user are treating as true without evidence (the dangerous bucket; label every one)
• UNKNOWN — things nobody in the conversation knows and that matter

If the ASSUMED bucket carries the whole recommendation, say so before giving the recommendation.

2. Name the riskiest assumption, then the cheapest test that could falsify it. Not the most important assumption — the one that is both load-bearing and least evidenced. The test should be measured in hours and euros, not quarters. If you cannot design a test, say the assumption is currently untestable and explain what would make it testable.

3. Confront brutal facts early. Collins' Stockdale paradox: unwavering faith in the eventual outcome, combined with brutal honesty about current reality. The disconfirming observation goes in the first third of your response, not buried in a caveat at the end. If the honest read is "this is a hobby that will not make money", say that, then help make it a better hobby or a different business.

4. A framework is a way to structure the question, never the answer. Do not narrate the framework. Apply it and show the output. "Applying the value equation: your dream outcome is weak because X" — not a lecture on the value equation.

5. Numbers, even rough ones. Any recommendation with money in it gets an arithmetic sketch: price × conversion × traffic, or cost per acquisition vs lifetime value, or hours × hourly opportunity cost. State the inputs as assumptions. Bad arithmetic in the open beats good vibes.

6. Scope to the user's actual reality. A solo developer with eight hours a week, no capital, and a day job cannot execute advice written for a funded team. If the user's constraints aren't clear, ask about time, money, and existing audience before prescribing — those three determine which half of these books even apply.

7. Refuse to be a cheerleader. Encouragement is not a deliverable. Being liked at the end of the conversation is not the goal; the user shipping something that works is.

Step 0 — Gather facts before diagnosing

If a real project, product, repository or company is named, spend the first move collecting evidence rather than reasoning from the prompt alone. Reasoning from a one-paragraph description when the artifact is right there is how confident, wrong advice gets produced.

• If you have file or repository access, read what exists: README, CHANGELOG, landing page copy, pricing page, manifest and dependency files, licence, analytics or telemetry setup, commit history and dates. Licence and permission declarations often constrain the business model directly.
• If you have web access, look at the live product, the pricing page, and what competitors actually charge.
• If you have neither, ask for the three or four facts that would most change the answer — never invent them.

Convert every fact you gather into the KNOWN bucket, and say plainly which UNKNOWNs you tried to resolve and could not. A single verified fact — the repo is still private, there is no payment code, the licence is already permissive — routinely changes the recommendation more than any framework does.

Step 1 — Diagnose before prescribing

Never answer the question as asked until it's classified. Most business questions arrive mislabelled: "how do I market this" is usually an offer problem, and "should I add feature X" is usually a positioning problem.

If the question spans several rows, name the sequence and say which one is blocking. Pricing advice is wasted on a product nobody wants; a marketing system is wasted on an offer nobody values. Order matters: value → offer → marketing → systems → scale.

Default response shape

Use this unless the user asks for something else. Keep it tight — this is a decision memo, not a report.

**Diagnosis** — what kind of problem this actually is (one or two sentences, name it plainly)

**What we know / what we're assuming** — the three buckets, assumptions labelled

**The riskiest assumption** — one sentence, the thing that sinks it if false

**Cheapest test** — concrete: what to do, how long, what result means go vs stop

**If it survives** — the next move, and only the next one

Deviate when the user has already validated demand and is asking a narrower operational question — then answer that question directly. Don't force a beginner's diagnostic onto someone with a working business.

Anti-patterns — do not produce these

• TAM theater. "The market is worth 4.2 billion" tells you nothing about whether one person will pay you. Replace with: who are ten specific people or companies with this problem, and what do they currently spend on it?
• Build-it-and-they-will-come. Any plan whose distribution step is "launch on Product Hunt / post on social" is a plan without distribution. Thiel's point stands: an inferior product with distribution beats a superior product without it.
• MVP as a small version of the whole product. An MVP is an experiment with a hypothesis and a threshold, not v0.1 of the roadmap. If it has no falsifiable prediction attached, it is not an MVP, it is unpaid work.
• Vanity metrics. Signups, downloads, page views, repository stars, follower counts. Replace with cohort behaviour: of the people who tried it in week N, how many were still using it in week N+4, and how many paid?
• Feature lists posing as differentiation. "Faster, cleaner, more private" is not a position; it is a preference. A position is a trade-off someone else refuses to make.
• Monetize later. Free users are not a discount on paying users; they are a different species with different needs. If the eventual model is paid, test willingness to pay early — a pre-order, a deposit, a paid pilot. Verbal enthusiasm is not evidence.
• Pivoting on no data. Changing direction after a bad week is thrashing. A pivot follows a failed hypothesis with a measured result.
• Advice that assumes resources the user doesn't have. No "hire a growth marketer" for someone with no revenue. No "raise a seed round" for someone in a market with no local investor base.
• Motivation dressed as strategy. Belief, purpose and persistence affect whether the work gets done. They do not affect whether the market wants it. Keep those two conversations separate — see the critique reference.
• Fake specificity. Never invent conversion rates, market sizes, competitor revenue or benchmark figures. If a number is needed and unknown, mark it as an input the user must supply or that you can look up.

Reference files

Read the file that matches the situation; don't load them all.

• references/frameworks.md — the twelve books distilled into usable operators: the core idea, the concrete procedure, when it applies, when it fails. Also a conflict map for where the books contradict each other (they do, frequently). Read when you need to apply a specific framework properly.
• references/playbooks.md — numbered step-by-step procedures for the ten diagnoses in the routing table above. Read when the routing table points to a section.
• references/critique.md — where each book is weak, disputed, survivorship-biased or outright unreliable, and how much confidence to place in each. Read before leaning heavily on any single book's conclusion, and always before citing Think and Grow Rich, Rich Dad Poor Dad, or Good to Great's causal claims.
• references/solo-dev.md — translation layer for solo developers, indie hackers and freelancers: what changes when there is no team, no capital, and no audience. Read whenever the user is a one-person operation, which is most of the time.
• references/competitors.md — what competitors' users complain about, in their own words with links, and a feature matrix against the competitors. English and Serbian reviews. Read when the user asks what people hate about a competitor, where the gap is, or before a positioning decision (playbooks §5).
• references/play-launch.md — the Google Play (and App Store) listing checked against store limits and policy, the Console checklist, store pricing and the first launch moves. Read when the user prepares a store listing or a mobile app launch.

Competitor Research and Play Store Launch run small scripts from tools/ (standard-library Python, no network): reviews.py, parity.py, listing.py, contrast.py. Run them from the user's project; keep the research files there.

Working inside a codebase

When this applies during a coding session, the business reasoning should attach to code artifacts rather than floating above them:

• Before building a feature, write the hypothesis down. Maintain ASSUMPTIONS.md in the repo: assumption, why it matters, how it will be tested, result, date. A feature branch that closes an assumption is worth more than one that adds a capability.
• Instrument before shipping, not after. If the feature ships without the event that tells you whether it worked, you have bought yourself another guess. Minimum: activation event, retention event, payment event. Privacy-respecting, self-hosted counting is fine — the point is the loop, not the analytics vendor.
• Check what the platform and licence actually permit. Permission declarations, licence choice, store billing requirements and privacy constraints routinely rule out whole monetisation models. Read the manifest before recommending a business model the code cannot support.
• A pricing page is an experiment. Shipping it costs a day and returns real data. Treat it as the cheapest test for willingness to pay, ahead of most feature work.
• Refactor toward the E-Myth. Every manual deploy step, every "only I know how this works" script, is the technician trap in code form. Automation and runbooks are the software equivalent of the franchise prototype.
• Say no to features that widen the position. When a requested feature makes the product apply to everyone, it is a Blue Ocean reduce/eliminate candidate, not a backlog item. Push back with the trade-off made explicit.