Experience is a path of judgment
After years in export sales, I usually have several dozen customers under active follow-up.
Consider a familiar inquiry. An email arrives with one sentence: “Can I get your price list?”
No specifications. No quantity. No intended application.
A newcomer may immediately send a quotation, believing that speed is what matters most.
I pause to ask a few questions. Who is this person? Does the company have a website? Which country is it in? What certifications does that market require? Is this a genuine purchasing project, or one of several price comparisons? What would make my offer memorable?
Some of these judgments come from general business knowledge. Others come from individual emails, quotations that went wrong and opportunities that I failed to follow through.
That is why I increasingly see experience as a path of judgment, not simply a store of knowledge.
What should I look at first? What comes next? When should I ask another question, and when can I quote? When should I decline the opportunity altogether?
Experience also includes boundaries: which unverified specification must stay out of the email, which delivery date must not be promised casually, and when to stop and consult someone who knows more.
Often, the valuable part is something we act on before we can fully explain it.
More of that judgment can now be made explicit
A great deal of this knowledge used to travel through observation, working alongside someone and mentoring.
You followed an experienced colleague, watched what happened and gradually understood the reasoning. How much you learned varied. When that colleague left, much of the knowledge could leave with them.
The idea often called Polanyi's paradox captures the difficulty: we know more than we can readily explain. An experienced driver may struggle to describe every judgment behind driving. I cannot always reconstruct all the questions that pass through my mind when I read an inquiry.
Knowledge that is hard to describe is also hard to pass on. Three changes are making parts of that problem easier to address.
First, rules can be supplemented with contrasting examples. Show a case that was handled well, one that was handled badly, and explain the difference. This can help an AI tool apply the method within the current task. Rules, examples and human review still matter.
Second, many tools can read business cards, emails, meeting notes and differently formatted spreadsheets. That can reduce preliminary data entry. Recognition errors remain possible, so sources and key fields need checking.
Third, suitable assistants can perform actions: read files, retrieve information and prepare drafts. Parts of a method can be connected to the work itself, rather than remaining only a written description.
One technical distinction matters: installing a Skill does not train your experience into the model.
It provides methods and materials for the assistant to consult while working. The underlying experience and its source files remain in your hands.
The practical change is that some judgments previously passed on mainly through conversation can now be organized as files, examples and tool-assisted procedures. Someone else can try them, inspect the result and suggest revisions.
Why I built this website
The website is an attempt to make that useful in practice. It organizes company context, customer research, outreach planning and English email replies into tutorials, templates, Skills and toolkits.
You can read the instructions, choose a product for a specific task and use the files in your own AI assistant and working folder.
The archive exercise on the website uses a fixed template and fictional sample information to illustrate what an output looks like. The exercise itself does not call a language model or perform real customer research.
Availability, file lists and versions are defined by each current product page. If you need further adaptation to your company, tools or process, the scope of consulting, training or implementation is agreed separately.
The products still need work
This part is candid.
Early products are still being refined, and different products have their own versions. The original article incorrectly described every product as V0.1.0. Use the version on the relevant product page and the package manifest when downloading or providing feedback.
The methods came from my own work, but relatively few other people had used these products when I wrote the original article. They were not as polished as I wanted.
Why release them at that stage?
Because one step cannot be skipped: let someone else use them, record the failure points and revise the method. Using something a hundred times myself only shows that it fits me. A reader's specific difficulty reveals something I might otherwise miss.
Releasing an imperfect early product can be part of that learning process, provided its scope and limitations are clear.
Export sales is full of success stories: one prospecting email led to an order for a container of goods.
But an order following an email does not prove that the wording caused the order. The customer may already have intended to buy, or may have chosen on price.
That is why I value failure records: a wrong specification, an unanswered message, a customer judgment that proved mistaken. Those are concrete things a method can improve.
Where lasting value might come from
My working view is that, as models develop, general knowledge and common templates become easier to obtain. A product consisting only of a familiar prompt will have less to distinguish it. That view still needs to be tested against actual use and market feedback.
Some important context is not available to a general model: where the last conversation with this customer ended, who may approve a price, what counts as an acceptable result, and who takes responsibility if something goes wrong.
Understanding a specific business, providing complete instructions, producing inspectable outputs and maintaining the method may matter more than the generic template itself.
So what can an ordinary practitioner accumulate in the AI era?
One practical answer is to take a part of their own work and organize it so that someone else can use it. Document it once, then improve it through repeated use.
A file does not become valuable simply because it has been packaged. Long-term value is possible only if people can actually use it to reduce repeated work or improve their results.
For me, the worthwhile accumulation is not the number of tools I can operate. It is the amount of experience I have made understandable, usable, inspectable and improvable by others.
Ask yourself: which part of your work do you perform almost automatically, but still struggle to explain?
Write down one task's inputs, steps, judgments and completion criteria. Then give it to another person to try. The point where they get stuck is where the next revision begins.