Making a product team AI-native: write down the unwritten rules, then automate the right admin

The problem

On a complex product with many business customers, many configurations and many kinds of work, keeping tickets and documentation presentable is a constant drain. Tickets need the right type, owner, fields, labels and links at each stage of their life. Finished work has to be described well enough for customers to read. Documentation has to keep up with every release.

None of it is hard. All of it takes time, and it is always the first thing to slip when a team is busy. Once the developers started building faster with AI, product owners writing tickets became the bottleneck.

Picking what to build

There was no shortage of ideas. Before building anything, I scored each one for effort and value, and asked a third question that matters more than either: would it still be used once I had moved on? A clever tool that only its author can run is a cost, not a saving.

The winners clustered in the same corner: the paperwork around tickets and documentation, which every product owner did every sprint. The two ticket tools also needed the same missing piece, a written definition of what a good ticket looks like. That made the first job obvious, and it wasn’t a tool.

Writing down the unwritten rules

Every organisation runs on context that lives in people’s heads: how teams are split, what a ticket needs before it can move on, which words customers should never see. That works until you ask AI to do the jobs people used to do. Then every unwritten rule becomes a mistake, and every mistake costs time and trust.

I asked leaders across the organisation for context dumps, written or by interview, and turned them into a shared set of pages: how we work, team structures, operating practices, and what each kind of ticket needs at each point in its life. The pages are kept up to date as things change.

1. 1 Ask Leaders write a context dump, or are interviewed
2. 2 Write down Shared pages: how we work, team structures, what each ticket needs at each stage
3. 3 Assist Skills that create, check and document tickets, reading those pages
4. 4 Approve A person agrees each change in the chat before it is made

Every assistant that followed reads from those pages, so none of them has the company’s rules pasted into it. That made the assistants smaller, cheaper to run and easier to keep up to date. It also improved everyone’s everyday use of AI, because any chat could be pointed at the same pages.

Don’t make your AI reinvent the wheel of what your business is every time.

One design, any assistant

Every tool that followed was built the same way, in three parts that can each be changed without touching the others.

1. 1 Skill Plain written instructions, readable by anyone, run in Claude or Cursor
2. 2 Rules Read from the wiki: how we work, what each ticket needs
3. 3 Live data Read from Jira: the tickets the job is about
4. 4 Write back Agreed changes saved to Jira and the wiki

• The skill is a set of plain written instructions. Anyone can read it and see what it does, and it isn’t tied to one product: the same skill runs in Claude or Cursor, whichever a person prefers.
• The rules live in the wiki, so every skill reads the same version and a change to a rule reaches every tool at once.
• The data stays where it already was, in Jira and the wiki. Every read and write goes through Atlassian’s Rovo MCP server, a standard connection that any of those assistants can use with the person’s own permissions.

The upshot: people kept the AI assistant they liked, nobody had to maintain a separate app, and the company wasn’t locked in to one AI vendor.

Microsoft 365 Copilot couldn’t load skills like these at the time. Microsoft began rolling skills out to Copilot Chat in October 2026, so a business that lives in Microsoft 365 should soon be able to use the same pattern there.

What the rules made possible

With the rules written down, the admin could be handed over. Two pieces of work came out of it, each written up in full:

• Tickets from anything. A ticket creator that turns a recording, an email or a note into finished tickets, and a checker that tidies each sprint’s finished work. Ticket admin fell by about 80%, roughly three hours a week for each of 15 product owners.
• Documentation that keeps up. An agent that wrote the missing documentation three times faster until the whole product was covered, then an assistant that proposes updates from each sprint’s finished work.

Big ideas, broken down

Larger ideas got their own skill. Given a brief, it reads the shared pages, the product documentation and the web, then questions the idea: does a feature already solve this, is another team doing something similar, what are the phases?

The common trap with this kind of tool is getting stuck on details nobody knows yet. Any question can be skipped, and unanswered ones are written into the high-level tickets it creates, so the work can start while they are answered.

If I built it again

The context layer worked, and it’s the part I’d keep. How I’d build it has changed.

What I did thenWhat I'd do now

Where the rules live

What I did thenMany wiki pages with an index page pointing to them, all searched live by every tool each time it ran.

What I'd do nowStill in the wiki, where anyone in the company can edit them. A sync condenses them into one compact copy whenever a page changes, and the tools read that: one quick read instead of a dozen searches.

Gathering them

What I did thenLeaders wrote context dumps or I interviewed them, then I turned the notes into pages. Most people weren't yet comfortable enough with AI to sit down with an AI interviewer.

What I'd do nowAn AI interviewer runs the conversation and drafts the page; the leader corrects it. Less of everyone's time, mine included.

Keeping them right

What I did thenA rule was fixed when someone noticed it was wrong.

What I'd do nowEvery time a person overrides an assistant, it is logged. Overrides that keep coming back point at a rule that needs rewriting.

The thread through all three: keep the rules where the people who own them can change them, and make it cheap both for the tools to read them and for people to correct them.

What carries into your business

None of this needed new software. It used tools the company already paid for, set up around how the team already worked. The lessons apply to any team with paperwork that follows rules:

1. Score the ideas first, and ask what will still be used once the person who built it has moved on.
2. Write down the unwritten rules, once, where every AI tool can read them.
3. Look at your backlog again. Jobs that never get done because they’re too much effort may now be cheap.
4. Keep a person approving the changes, in a conversation, before anything is written.