Making AI useful for real work
Goose Group · 2026
Most teams are not living in the frontier demo reel.
They are doing real work in real systems: spreadsheets, tickets, file servers, meeting notes, dashboards, Slack threads, legacy apps, and customer exceptions.
That is not failure. That is the starting point.
Spend tokens in ways that create operating capability.
Not more AI usage for its own sake. Not a mandate. Not a productivity scoreboard.
The point is better work: clearer context, faster handoffs, stronger judgment, fewer avoidable loops, and tools people can actually use.
An oboe player shapes reeds. A chef sharpens knives. A studio builds templates, rigs, references, and working methods.
The tool-making is part of the craft.
AI becomes useful when you shape it around your work: your context, your standards, your constraints, your examples, your customers.
This is a practice. The first attempts are allowed to be rough.
Before choosing tools, map one repeated piece of work.
Task: Trigger: Inputs: What context does AI need? What should AI produce? Where does human judgment stay essential? What is the smallest safe experiment? How would we know it helped?
A good first use case is usually not dramatic. It is repeated, annoying, bounded, and close to real work.
Build the context.
If the model needs to know how your team thinks, what good looks like, which files matter, or how a workflow really runs, write that context down and make it available.
knowledge/ ├── team-principles.md ← what we believe ├── workflow-notes.md ← how the work actually happens ├── examples/ ← good and bad outputs ├── constraints.md ← what we will not do ├── customer-context.md ← who the work is for └── playbooks/ ← repeatable ways to act
This is context infrastructure. Portable. Curated. Useful with any tool.
A good AI talk should demonstrate the behavior it recommends.
Raw context - audience notes - meeting transcript - current workflows - examples and concerns - previous materials Structured understanding - audience brief - goals and non-goals - tone and risk notes - useful examples Useful outputs - talk outline - deck - speaker notes - field kit - follow-up prompts
The value is not the slide generator. The value is the context and judgment that shape what gets generated.
Three small capabilities — click one to see the shape:
Stop jumping to output before understanding the work.
"I wish it knew how we do this" -> write it down.
Turn scattered discussion into decisions, owners, and next steps.
capability 01
AI often jumps straight to the deliverable. That produces confident generic output.
Make "understand -> research -> clarify -> draft -> verify" the default workflow.
capability 02
A recurring task depends on unwritten context: audience, constraints, tone, source systems, examples, and quality bar.
The next person does not have to re-explain the workflow. The context travels with the work.
capability 03
Meetings produce useful context, but the value disappears into transcripts, notes, and memory.
A person still decides what matters. AI reduces the administrative drag around that judgment.
← Click a ticket to see the full spec
Small capabilities are easier to try, easier to govern, and easier to share.
The instinct is to build a system that solves a problem completely. A "platform."
Systems are expensive, brittle, and take forever. By the time they ship, the problem has evolved.
The better question: what capability would make your people faster and better at what they're already doing?
A capability doesn't replace what someone does. It amplifies it. It slots into the workflow and teaches the organization what should happen next.
Start with one useful capability before trying to build the whole system.
LLMs open up a new class of problems that aren't pass/fail.
When you download a file, there's one right answer. When you write an email, there are thousands of right answers.
The goal isn't to remove humans. It's to make humans faster, more informed, more responsive.
For low-risk, human-reviewed work, useful enough now often beats perfect too late.
People are already experimenting: prompts, scripts, spreadsheet helpers, meeting summaries, small dashboards, internal tools.
The answer is not a lockdown. The answer is visibility.
Governance gets better when it starts from real work.
If you want to double your output, don't look for one thing that makes you twice as good.
Find a hundred things that each make you 1% better.
Easier to find. Easier to implement. Less risk you'll get it wrong. And they compound.
1.01100 = 2.7x
Every workflow has a hundred small frictions. "Where's that file?" "What were the requirements on the last one?" "Did we do something like this before?"
Remove a hundred small frictions and you've transformed how work gets done.
A team close to the work builds a spreadsheet, script, dashboard, prompt, or small app because the official process cannot move fast enough.
Different teams have different needs. Different constraints. Different workflows.
This is usually not rebellion. It is user research with artifacts.
This is bottom-up software development. It's happening now.
The question for leadership isn't "how do we stop this?" It's "how do we enable it?"
Traditional software development optimizes for reliability at the cost of responsiveness.
The promise: wait long enough and you'll get something stable that works for everyone.
The reality: by the time it ships, requirements have changed, and people find workarounds anyway.
The right standard depends on the risk of the workflow.
If a tool is local, human-reviewed, and has a backup plan, it can be useful before it is fully hardened. If it becomes operationally important, it earns the next layer of infrastructure.
Imagine a small senior team that moves through the organization and helps people build useful things from real workflow pressure.
Not a generic training program. Not a pile of policies. Just: understand the problem, build something, see if it works.
The learnings feed back to leadership, product, IT, and operations. Instead of guessing what people need, the organization sees validated work from the field.
Corporate defines → Teams implement → Users adapt
Users need → Small team builds → Corporate decides what to scale
Building used to be expensive. So you'd plan carefully, review thoroughly, commit reluctantly.
Building is cheaper now. Rebuilding is cheaper now.
That changes the first move. You can build a rough version to learn before committing to the full architecture.
Stop being precious about code. Start being precious about outcomes.
The question isn't "how long will this take?" — it's:
What's the smallest useful thing? Ship something rough that works. Learn what "fast" feels like.
Room for iteration. Build → show → refine. Still ruthlessly scoped.
Closer to a real deliverable. Multiple iterations. Polish starts to matter.
Sprint-scale. End-to-end: understand the problem, build it, deliver value.
A 1-day build that proves something is feasible is worth more than a 6-month plan that never ships.
The path usually starts simple: notes, templates, context cards, prompts, then small tools, then internal systems.
Each step makes the next one easier. Models improve. Team skill improves. The context compounds.
This is the practical path:
AI can help produce. Humans still handle the work that matters most:
The human is a critical input to this process. Judgment is the direction.
This is not just prompting. It is building capability around real work.
This week, pick one recurring task. Spend 30 minutes trying to make it easier with AI.
Do not try to build a system. Pick a small, safe, repeated piece of work.
What I tried: What context I gave it: What worked: What failed: What I would change: Who else might benefit:
Keep the output. Share what worked and what did not. That is how practice becomes organizational learning.
What is one recurring piece of work you wish took less effort, less searching, or less re-explaining?
That is your starting point.