The Skills That Transfer
I expected to learn coding. Instead I discovered I'd been training for AI work my whole career — through every Business Requirements Document, every acceptance criterion, every backlog grooming session.
You don't need to learn to code. You need to use what you already know.
When I first started using AI to build tools, I braced myself for a steep learning curve.
I imagined weeks of tutorials. Courses on prompt engineering. Maybe finally learning JavaScript.
Instead, something unexpected happened: I already knew how to do this.
Not the coding part. AI handles that. But the thinking part — the part that actually matters — I'd been practicing it for years inside business analysis and product ownership work.
The 80/20 of AI Collaboration
Here's what surprised me: 80% of working effectively with AI is skills I already had.
- Breaking a big problem into smaller pieces? That's epic decomposition.
- Describing exactly what "done" looks like? That's acceptance criteria.
- Testing output and deciding what to fix next? That's sprint review.
- Knowing when something is good enough to ship? That's release planning.
- Killing a feature that doesn't work? That's backlog grooming.
The other 20% — learning how to phrase things for AI, understanding its limitations, knowing when to start over vs. iterate — that took a few weeks. Not months. Weeks.
Skill-by-Skill Mapping
Here's how specific business analysis and product delivery skills map directly to AI collaboration:
1. Problem Decomposition → AI Prompting
Delivery Skill: Breaking an epic into user stories. Taking a vague stakeholder request and turning it into specific, buildable pieces.
AI Application: Breaking a complex tool into specific components. Instead of saying "build me a stakeholder management tool," I say: "Build a form with fields for stakeholder name, power rating (1-5), interest rating (1-5)" → "Plot the data on a 2x2 matrix" → "Add communication recommendations for each quadrant" → "Make the output exportable to CSV"
Why it transfers: AI, like a development team, needs clear, specific instructions. The skill of decomposing vague requests into specific components is exactly the same.
2. Acceptance Criteria → Validation
Delivery Skill: Writing Given-When-Then statements that define exactly when a feature is complete.
AI Application: Knowing exactly what "working" looks like before you start building. When I built the User Story Slicer, my acceptance criteria were: Given a user story longer than 2 sentences, When I select the "workflow steps" splitting pattern, Then I should see 3-5 smaller stories that cover the original scope, And each story should be independently deliverable.
3. Iterative Development → AI Iteration
Delivery Skill: Running sprints. Building incrementally. Reviewing after each iteration.
AI Application: Build the simplest version first. Test it. Identify the biggest gap. Ask AI to fix that one thing. Test again. Repeat.
That's a sprint. A very short sprint. But the rhythm is identical.
4. User Testing → Prototype Validation
Delivery Skill: Showing work to users and watching their reaction. Not explaining. Just watching.
AI Application: Exactly the same. Build something with AI, show it to 3-5 people, watch where they get confused. The tool doesn't need to be perfect. It needs to be testable.
5. Stakeholder Management → AI Direction
Delivery Skill: Translating between business language and technical requirements.
AI Application: You are the stakeholder and the product owner at the same time. You know what you need. You describe it clearly. AI builds it. You validate. The bridge-building skill transfers directly.
6. Prioritization → Feature Selection
Delivery Skill: Deciding what to build first. Using RICE, MoSCoW, or similar frameworks.
AI Application: AI can build features fast. Which means the temptation is to build everything. The skill of saying "this feature first, that feature later, this feature never" is more important than ever.
7. Saying "No" → Scope Control
Delivery Skill: Protecting the team from scope creep.
AI Application: Protecting yourself from your own scope creep. AI makes it so easy to add things that you'll add things you don't need. I killed 3 projects because I couldn't stop adding features. The discipline of "no" is even more important when execution is fast.
What's Actually New (The 20%)
Here's what I had to learn that wasn't already in my delivery toolkit:
- How to describe visual layouts to AI — AI doesn't see mockups (yet). You need to describe layout in words: "Two columns, left side has the form, right side shows the output in real-time." This took practice.
- When to start over vs. iterate — Sometimes AI goes down a path that's fundamentally wrong. Iterating on a bad foundation wastes time. Knowing when to say "delete everything, let's start fresh" — that was new.
- Understanding AI limitations — AI is excellent at building forms, calculators, and interactive tools. It struggles with complex state management and real-time data. Knowing what to ask for and what not to ask for saves hours.
- Prompt specificity — Being specific helps. "Make it look professional" is useless. "Use a blue (#2563EB) header, white background, 16px body text, and 24px section headers" gives you what you want.
The Implication for Your Career
If your work spans business analysis or product ownership, you're not being replaced by AI.
You're being amplified by it.
The skills that made you good at your job — decomposition, prioritization, validation, stakeholder management, saying no — those are exactly the skills AI needs from you.
The only thing that changes is the speed of the feedback loop. Instead of writing requirements and waiting weeks, you describe what you want and see it in minutes.
That's not a threat to your career. That's a superpower.
Try It Yourself
This week's experiment:
- Pick one repetitive problem you face as a delivery practitioner
- Write acceptance criteria for a tool that would solve it
- Open Claude Code or Gemini AI Pro
- Describe the tool using your acceptance criteria
- Iterate 3-5 times
- Show it to a colleague
You'll be surprised how much you already know.
For delivery practitioners
The tools below were built using exactly the skills this article describes.
Every tool here started as a problem I kept running into on projects — and acceptance criteria I wrote for the solution. Free. No signup. No data collected. Use them, learn from how they were built, or use them as a model for your own experiments.
Specifically relevant to the skills mapped in this article:
Want to compare notes or share what you built? Connect on LinkedIn →