The methodology

Better questions, not more prompts.

AI does not understand your domain. It understands your questions about your domain. This is the premise that everything else follows from.

— Kevin Oskow

01 / The premise

Why better questions is a methodology, not a tip.

A model trained on the entire internet knows more surface-area information than any single professional. But it has no judgment about what matters in your specific situation, no experience of what has failed before, and no stake in whether the output is actually useful.

Your professional expertise expresses itself through the quality of your questions. The professional who asks a better question does not get a marginally better answer. They get a qualitatively different class of output.

This is why better questions is a methodology and not a tip. It is the underlying practice from which every useful AI application in knowledge work is derived.

02 / The five practices

What you do differently.

Practice 01 · Interrogate before you generate

Most professionals go straight to production. The discipline is to stop before asking AI for anything and answer four questions: What do I actually need? Why do I need it? What does success look like? What do I already know that the AI does not?

This single practice produces more improvement than any prompt library. It takes 90 seconds. Most professionals skip it every time.

The Brief Decoder is a structured version of this practice applied to project scope.

Practice 02 · Use AI as a Socratic partner, not a production machine

AI is most useful not when you ask it to produce work, but when you use it to interview you. A well-designed AI interview surfaces what you know, what you believe, and what you are uncertain about, faster and more completely than unaided reflection.

You are not asking AI what to think. You are asking AI to ask you better questions about what you already think.

The AI Interview Method is a structured version of this practice applied to professional judgment.

Practice 03 · Read output as an editor, not a recipient

Every AI output is a first draft from a smart but non-expert collaborator who wants your approval. Your job is to bring the expertise the model does not have and apply it to what the model produced.

Before accepting any AI output, ask three questions: Is this specific to my situation or generic? Does it show calibrated uncertainty or is it uniformly confident? What important considerations are missing?

If you cannot answer those questions, the output is not ready to use.

Practice 04 · Build systems, not libraries

Prompt libraries decay. A prompt built around one model, one interface, or one moment in AI culture may stop working when the tools change. Principles transfer better than prompt tricks.

A system has a defined use case, clear inputs, a repeatable process, expected outputs, a review standard, and a reason it works. The goal is a small set of patterns you understand well enough to adapt, not a large pile of borrowed prompts.

A recipe collection teaches you to cook specific dishes. Knife skills and flavor principles teach you to cook.

Practice 05 · Compound, don't commoditize

The professional who uses AI to become faster at existing work has made themselves incrementally more efficient and marginally easier to replace. The professional who uses AI to become sharper at their craft has made themselves harder to replace.

Every AI application should be evaluated not on time saved but on whether it produces output that requires your specific expertise to generate. If anyone could produce the same output with the same prompt, you are not compounding. You are commoditizing.

03 / Systems in the wild

What "systems, not libraries" looks like by profession.

The same pattern transfers across fields: define the use case, supply the right inputs, follow a repeatable process, produce expected outputs, and review the result against a standard a professional would recognize.

Consultants

Service Strategy Clarifier

Use case: Turn a messy request about positioning, offers, or service strategy into a scoped discovery plan before recommending anything.
Inputs: Client request, current service mix, constraints, stakeholder tensions, and the decision the client thinks they need to make.
Process: Restate the apparent decision, separate symptoms from decisions, map stakeholder conflict, identify missing facts, and design discovery.
Expected outputs: Decision map, missing-context checklist, workshop plan, scope boundaries, and recommendation-readiness assessment.
Review standard: The output must name the real decision and make trade-offs visible before it offers advice.
Why it works: Consulting value starts with problem framing. The system uses AI to clarify the work instead of producing generic strategy language.

Researchers

Evidence Map and Decision Brief

Use case: Convert a broad market scan or research request into a decision brief that separates evidence, interpretation, and uncertainty.
Inputs: Research question, decision context, source rules, available sources, time horizon, and confidence threshold.
Process: Define inclusion criteria, extract claims, tie claims to sources, group patterns, mark contradictions, and assess confidence.
Expected outputs: Claim-evidence table, source list, theme map, uncertainty notes, and practical decision brief.
Review standard: Important claims must be traceable to evidence or clearly labeled as interpretation.
Why it works: The system protects the researcher's judgment by making uncertainty visible instead of smoothing it into a trend summary.

Legal and advisory teams

Matter Intake and Issue Map

Use case: Turn an advisory, compliance, tax, or legal intake into an issue map for qualified professional review.
Inputs: Client question, known facts, jurisdiction or authority, relevant dates, documents, objectives, and approval requirements.
Process: Build a neutral fact chronology, separate facts from assumptions, identify potential issues, list missing documents, and draft follow-up questions.
Expected outputs: Fact chronology, issue map, missing-document checklist, client questions, communication boundaries, and review packet.
Review standard: The output must not present uncited legal conclusions as advice. It must flag jurisdiction, uncertainty, and human approval.
Why it works: The system uses AI for structure and triage while keeping professional judgment with the responsible advisor.

Operators

SOP Failure-Mode Review

Use case: Stress-test an operating process, handoff, or SOP before it creates preventable mistakes in real work.
Inputs: Current workflow, owners, handoffs, tools, recent errors, success metrics, and operating constraints.
Process: Map triggers and handoffs, find ambiguity, generate failure modes, rank risk, and recommend controls.
Expected outputs: Workflow map, failure-mode register, risk ranking, revised SOP outline, and monitoring checklist.
Review standard: Every recommendation needs an owner, a trigger, a check, and a measurable sign that the process improved.
Why it works: Operations break at ownership gaps and handoffs. The system makes AI inspect the process structure, not just rewrite the SOP.

Educators and coaches

Learning Readiness Diagnostic

Use case: Diagnose whether a lesson, onboarding sequence, or coaching program prepares learners to do the intended work.
Inputs: Learning objective, learner profile, existing materials, completion data, platform constraints, and definition of success.
Process: State the performance outcome, map prerequisites, identify friction, predict misconceptions, and design checks.
Expected outputs: Learner-friction map, misconception list, revised sequence, understanding checks, and coach or instructor notes.
Review standard: Every activity must connect to the performance outcome without adding unnecessary weight.
Why it works: The system keeps AI focused on transfer, readiness, and feedback instead of generating more content.

Product and program leaders

Decision Pre-Mortem

Use case: Evaluate a planned initiative, feature, launch, or program before the team commits to execution.
Inputs: Proposed decision, intended audience, business objective, constraints, assumptions, objections, and unresolved questions.
Process: Restate the decision, inventory assumptions, imagine failure paths, map risk types, and define a smaller validation step.
Expected outputs: Decision statement, assumption inventory, failure paths, evidence checklist, validation step, and decision gate.
Review standard: The output must improve the decision before execution, not become a generic risk list.
Why it works: The system challenges assumptions while the decision is still changeable.

04 / In practice

What this looks like in real work.

Example: a strategy consultant

A client sends a vague email: "We're looking for help thinking through our market positioning as we enter a new vertical."

Without Practice 1, you paste the email into ChatGPT and ask for questions to ask the client. You get 10 generic consulting questions that could apply to any engagement.

The methodology applied

With Practice 1, you stop first. Before opening any AI tool, you articulate: What is this client actually asking? What do I not know about their current positioning? Who are the real decision-makers? What does "new vertical" mean to them specifically?

Now you paste both the client email and your analysis into the Brief Decoder. The output is informed by your judgment, not just the surface text of the email.

The difference is not the tool. It is the thinking you brought before you used it.

See the Brief Decoder →

05 / The transformation

From tutorial player to improviser.

The beginning guitar player follows tutorials and can play known songs. The jazz improviser understands the underlying structure and can create on the spot. Tutorials produce the first kind. Methodology produces the second.

The same difference exists in every field. A litigator who has internalized the structure of argument can improvise in a deposition. A researcher who has internalized methodology can work with any data. A designer who understands the brief can work with any client.

The methodology North Crow teaches is the structure underneath. The tools are the instruments you play it on.

06 / Get started

The Brief Decoder is Practice 1, built into a tool.

Paste any vague project brief or client request. Get back the questions you should be asking, the scope you should be setting, and the red flags you should be watching for. Free. Takes five minutes. Works in any LLM.

— Kevin