For teams running EOS. The AI install pack goes into the AI you already use, then paste in a Rock and ask whether it is any good. It coaches on the thing the average AI misses: what the Rock is actually meant to change.
EOS gets the rhythm right. A shared operating cadence, a Level 10 meeting, and the discipline of a few 90-day priorities with clear owners are good ideas, and thousands of teams run better because of them. The cadence is not the problem.
The average LLM treats a Rock as a task with a due date. It rarely asks what outcome the Rock is meant to move, or what obstacle will stop it. So Rocks get marked done while the number they were supposed to change sits still. The upgrade adds the missing question: done for the sake of what?
A Rock is a bet that doing X moves Y. If Y is not named, "done" means nothing but effort spent. Write the outcome above the Rock: "so that trial-to-paid rises from 8% to 12%". Now completion and success are two different questions, which is exactly what you want.
Most Rocks fail on something the team already suspected in week one. Say it out loud when the Rock is set. Naming what is in the way is what turns a 90-day intention into a plan, because the plan now has to route around a real thing.
A "build" Rock ships a thing and is done when it exists. A "habit" Rock changes how people work and is only done when the behaviour sticks. An "experiment" Rock tests a belief and is done when you have the answer, even if the answer is no. They need different definitions of done, and lumping them together is why some Rocks feel permanently half-finished.
The before is a "build" Rock that can be fully done while nothing improves. The after names the outcome (a trustworthy pipeline), the real definition of done, and the obstacle (distrust) that a CRM alone will not fix.
Not affiliated with, endorsed by, or sponsored by EOS Worldwide. EOS®, the Entrepreneurial Operating System® and Traction® are trademarks of EOS Worldwide, LLC. We refer to them only to help teams who already run EOS.
Same files, three tools. Pick yours. It really is about two minutes.
Before you install, ask your AI to review one real goal and screenshot the answer. Install, ask again, screenshot the difference. That gap is the point. Try: Paste a Rock and ask: is this a good Rock, what outcome is it really trying to change, and what obstacle will stop it?
The AI install pack comes with From Trading to Scaling: an hour to read, five working templates, the instructions and knowledge files for Claude, ChatGPT or Copilot, and a conversation with Matt about any of it.
Free things get downloaded, not installed. A hundred pounds is the smallest number that makes somebody open the file, and this is the only place the pack is available.
The pack carries the principles and the working templates: the book, the strategy one-pager, the OKR template, the idea sheet and the bonus calculator, plus the knowledge files that make your AI coach against a method rather than the internet average. That is yours to keep, and it is enough to install all six things without us.
What it is not is the whole machinery. The playbooks, scoring scales and the 140-plus linked concepts, installed into your own tools and kept current, are the licensed layer above this. And the human work, the training, facilitation, coaching and mentoring that gets a company past its first messy quarter, is our people. Knowledge does not install courage, or referee a hard conversation. We would rather say that here than let you find out.
// one install, or the whole companyOne install helps one person. The advantage is your whole company running on a shared operating system: the same method in the AI everyone already uses, at every level, with routines and automations carrying the repeatable work, and your people freed to find and compound the knowledge and IP only you have.
One install at a time does not create that. Building the operating system does, and that is what ZOKRI does. See the method we install and the platform it runs on.
Usually because they are written as tasks with due dates, not as bets on an outcome. The Rock gets done and the number it was meant to move does not budge. Naming the outcome above each Rock, and the obstacle in front of it, fixes most of this without changing your EOS cadence at all.
One that names the outcome it is meant to move, has a definition of done matched to its type (build, habit or experiment), a single owner, and the obstacle stated up front. If you cannot say what number a Rock should change, it is a task, not a priority.
Yes. Keep the EOS rhythm you like and borrow the OKR habit of tying each Rock to a measurable outcome. Many teams run EOS as their operating system and use OKR thinking to sharpen what a Rock is really for.