The working definition of the person who makes AI adoption stick. What they own, how they spend a week, what to screen for, and how the job scales from a fractional owner to a Head of AI Enablement.
The one idea
An AI Product Partner turns AI from something your company talks about into something it runs on. Not by building models, and not by buying more tools, but by sitting where your people meet the technology and making the two connect. They teach the parts of your company that can learn, and they build the parts that cannot. Get this one person right and every other AI decision gets easier, because someone finally owns the distance between what is now possible and what your company actually does.
This is the working definition. Copy it, cut it to your company, and put a name next to it. Everything below is written to be edited.
What this person owns
Six areas. In a small company one person holds all six at a fraction of a week. In a larger one they anchor a team that does. Keep the shape, scale the scope.
Teach first, because most of the transformation is teaching. The majority of the value never reaches an engineer. It comes from a scientist or an operator learning to do their own work a different way. So run the unglamorous enablement: recurring hands-on training, weekly office hours, a network of champions inside each team, a short note of wins and how-tos. Give people a plain way to name their own skill, from novice to fluent, so a team can see where it stands and what the next rung is.
Find the work worth changing, then reframe it. Sit with a team and watch how the work actually moves, not how the process doc says it does. People will ask for a faster version of what they already do. The job is to find the need underneath the request and reframe it before anyone builds. A clinical operations lead asks for a dashboard; an hour of watching shows the real problem is the chasing, not the charting, and that is a cheaper and better thing to fix.
Build the small tools, or spec them and hand them off. When teaching is not enough and something has to be built, this person builds it. A morning briefing, a tracker, a drafting tool, an agent, a reusable template. Write down what good looks like first, build so other people can reuse it instead of depending on you, and ship it rough enough to learn from real use instead of polishing in private.
Set the rhythm that keeps adoption from becoming chaos. Left alone, a hundred small experiments turn into a graveyard of half-built tools and stale tickets. Put in the light process that prevents it: a simple intake for new ideas, one place to see what is in flight, a short weekly review, and guardrails that are specific and humane about what data is fair game and what is not. Keep the systems small enough that people actually use them.
Translate between the work and the leadership. Own a couple of the company’s real AI bets and their outcomes, and stand in the doorway between the C-suite and the bench. Turn “the discovery team wants to try a tool” into two board-ready lines about what it would change and what it would cost, and turn executive intent into something a team can act on Monday. Make the trade-offs visible before they become surprises.
Handle the vendors so no one gets sold. Front the relationships with model and platform vendors, shape the pilots, and pressure-test cost against value before anyone signs. Run a two-week trial on your own data, not the vendor’s demo. This is the same discipline as Buy the Record. Build the Intelligence.: buy the commodity, build the edge.
A week in the life
The rhythm is what makes the job real, and it holds at any level.
Every morning, they run their own automations before anything else: a briefing that has already read their inbox, calendar, and yesterday’s transcripts and handed back one screen of what changed and who owes what. They live the habit they ask everyone else to build.
Every week, the work is people and discovery. An hour beside one person watching how they really work, a couple of coaching sessions, open office hours, a standup or two, and one honest sync with leadership so intent and execution stay the same story.
Every month, the work widens: a bigger training push, a short roundup of wins so progress is seen and not just felt, two lines in the board deck, and a check-in with the outside vendors.
What to screen for
Hire for range, not pedigree. The tool fluency is the easy half, and you can teach it. What you cannot teach is the rest: the product judgment to tell a real problem from a stated one, the teacher’s instinct that makes a nervous colleague feel capable, the operational rigor that turns one win into a repeatable process, and the nerve to work with no template to inherit. They should be as comfortable coaching a bench scientist in the morning as briefing the board in the afternoon.
The fastest read in an interview is to ask them to show you something they built for themselves in the last month. The right person always has one, and they cannot help lighting up when they show you. The person who only talks about AI in the abstract is not the one.
How you will know it is working
Judge the company, not the calendar. A full schedule is easy to fake. A more capable company is not. Watch four things: how many teams run their own AI workflows without being told to, how many people moved from “I tried it once” to shipping their own automations, how much time the tools they built actually take out of the week, and how many small requests stopped landing on engineering because teams handle them now. If those are moving, the job is working, whatever the week looked like.
What it is not
A new job gets defined by its edges. This is not a data scientist; it does not build the models. It is not an IT help desk; it does not wait for tickets. It is not a single-product product manager; it runs a portfolio of small wins across every function. And it is not a trainer who only teaches and never builds, or a builder who never teaches. Take those four away and what is left is the real job: one person accountable for turning capability into changed work.
How it scales
The job is defined by its mandate, not its level, so scale the title to your company. At the smallest size it is one embedded person, a builder and teacher working with a function or two, often at a fraction of a week. In the middle it is a senior player-coach who owns the strategy and the leadership relationships, still builds, and guides a few champions. That is the most common shape for a first hire. At the top it is a Head of AI Enablement who sets company-wide strategy and runs a team. The mandate is identical at every size: teach, build, translate, and make the whole thing compound.
Adapting this for a clinical-stage biotech
It works in any industry, which is exactly why it needs adapting. For a company under a hundred people with runway to protect, change four things.
Point it at the science’s overhead, not at moonshots. The value is in the administrative and documentation load that pulls expensive scientists off the bench, not in a flashy model project.
Bring quality and regulatory in from day one. They are stakeholders, not obstacles. Set the guardrails with them, and check any records or validation question with your own quality function before you build, not after.
Give them standing, not just a title. This only works with real authority across Permission, People, and Programs, not a seat buried in a backlog.
Monday morning
Do not post this as a job yet. Copy it into a document, cut everything that does not fit your company, and write one real name in the margin: the person already on your team with the shape for this. Write the job down, and you have something to hire, grow, or grow into. Leave it blank, and you are recruiting against a role that does not exist.
Sources and further reading
Marty Cagan, Inspired: How to Create Tech Products Customers Love (2nd ed., Wiley, 2018), and Silicon Valley Product Group, on the difference between a team that builds capability and one that ships a single feature, the basis for the “portfolio of small wins” framing
Teresa Torres, Continuous Discovery Habits (Product Talk, 2021), on interviewing to find the real problem behind the stated request, the discovery-and-reframe move
Everett Rogers, Diffusion of Innovations (5th ed., Free Press, 2003), on why capability spreads through respected peers rather than mandates, the basis for the champion network
## The one idea
An AI Product Partner turns AI from something your company talks about into something it runs on. Not by building models, and not by buying more tools, but by sitting where your people meet the technology and making the two connect. They teach the parts of your company that can learn, and they build the parts that cannot. Get this one person right and every other AI decision gets easier, because someone finally owns the distance between what is now possible and what your company actually does.
This is the working definition. Copy it, cut it to your company, and put a name next to it. Everything below is written to be edited.
## What this person owns
Six areas. In a small company one person holds all six at a fraction of a week. In a larger one they anchor a team that does. Keep the shape, scale the scope.
- **Teach first, because most of the transformation is teaching.** The majority of the value never reaches an engineer. It comes from a scientist or an operator learning to do their own work a different way. So run the unglamorous enablement: recurring hands-on training, weekly office hours, a network of champions inside each team, a short note of wins and how-tos. Give people a plain way to name their own skill, from novice to fluent, so a team can see where it stands and what the next rung is.
- **Find the work worth changing, then reframe it.** Sit with a team and watch how the work actually moves, not how the process doc says it does. People will ask for a faster version of what they already do. The job is to find the need underneath the request and reframe it before anyone builds. A clinical operations lead asks for a dashboard; an hour of watching shows the real problem is the chasing, not the charting, and that is a cheaper and better thing to fix.
- **Build the small tools, or spec them and hand them off.** When teaching is not enough and something has to be built, this person builds it. A morning briefing, a tracker, a drafting tool, an agent, a reusable template. Write down what good looks like first, build so other people can reuse it instead of depending on you, and ship it rough enough to learn from real use instead of polishing in private.
- **Set the rhythm that keeps adoption from becoming chaos.** Left alone, a hundred small experiments turn into a graveyard of half-built tools and stale tickets. Put in the light process that prevents it: a simple intake for new ideas, one place to see what is in flight, a short weekly review, and guardrails that are specific and humane about what data is fair game and what is not. Keep the systems small enough that people actually use them.
- **Translate between the work and the leadership.** Own a couple of the company's real AI bets and their outcomes, and stand in the doorway between the C-suite and the bench. Turn "the discovery team wants to try a tool" into two board-ready lines about what it would change and what it would cost, and turn executive intent into something a team can act on Monday. Make the trade-offs visible before they become surprises.
- **Handle the vendors so no one gets sold.** Front the relationships with model and platform vendors, shape the pilots, and pressure-test cost against value before anyone signs. Run a two-week trial on your own data, not the vendor's demo. This is the same discipline as [Buy the Record. Build the Intelligence.](/buy-record-build-intelligence/): buy the commodity, build the edge.
## A week in the life
The rhythm is what makes the job real, and it holds at any level.
- **Every morning,** they run their own automations before anything else: a briefing that has already read their inbox, calendar, and yesterday's transcripts and handed back one screen of what changed and who owes what. They live the habit they ask everyone else to build.
- **Every week,** the work is people and discovery. An hour beside one person watching how they really work, a couple of coaching sessions, open office hours, a standup or two, and one honest sync with leadership so intent and execution stay the same story.
- **Every month,** the work widens: a bigger training push, a short roundup of wins so progress is seen and not just felt, two lines in the board deck, and a check-in with the outside vendors.
## What to screen for
Hire for range, not pedigree. The tool fluency is the easy half, and you can teach it. What you cannot teach is the rest: the product judgment to tell a real problem from a stated one, the teacher's instinct that makes a nervous colleague feel capable, the operational rigor that turns one win into a repeatable process, and the nerve to work with no template to inherit. They should be as comfortable coaching a bench scientist in the morning as briefing the board in the afternoon.
The fastest read in an interview is to ask them to show you something they built for themselves in the last month. The right person always has one, and they cannot help lighting up when they show you. The person who only talks about AI in the abstract is not the one.
## How you will know it is working
Judge the company, not the calendar. A full schedule is easy to fake. A more capable company is not. Watch four things: how many teams run their own AI workflows without being told to, how many people moved from "I tried it once" to shipping their own automations, how much time the tools they built actually take out of the week, and how many small requests stopped landing on engineering because teams handle them now. If those are moving, the job is working, whatever the week looked like.
## What it is not
A new job gets defined by its edges. This is not a data scientist; it does not build the models. It is not an IT help desk; it does not wait for tickets. It is not a single-product product manager; it runs a portfolio of small wins across every function. And it is not a trainer who only teaches and never builds, or a builder who never teaches. Take those four away and what is left is the real job: one person accountable for turning capability into changed work.
## How it scales
The job is defined by its mandate, not its level, so scale the title to your company. At the smallest size it is one embedded person, a builder and teacher working with a function or two, often at a fraction of a week. In the middle it is a senior player-coach who owns the strategy and the leadership relationships, still builds, and guides a few champions. That is the most common shape for a first hire. At the top it is a Head of AI Enablement who sets company-wide strategy and runs a team. The mandate is identical at every size: teach, build, translate, and make the whole thing compound.
## Adapting this for a clinical-stage biotech
It works in any industry, which is exactly why it needs adapting. For a company under a hundred people with runway to protect, change four things.
- **Point it at the science's overhead, not at moonshots.** The value is in the administrative and documentation load that pulls expensive scientists off the bench, not in a flashy model project.
- **Bring quality and regulatory in from day one.** They are stakeholders, not obstacles. Set the guardrails with them, and check any records or validation question with your own quality function before you build, not after.
- **Do not hire this yet.** At your size it is a job worth about a fifth of someone you already employ. Name that owner and let the role earn its way to a full seat. See [The Small-Team Operating Model](/artifacts/small-team-operating-model/), and on hire-versus-grow, [Do I hire an AI Product Partner, or grow one?](/faqs/hire-or-grow-ai-product-partner/)
- **Give them standing, not just a title.** This only works with real authority across [Permission, People, and Programs](/permission-people-programs/), not a seat buried in a backlog.
## Monday morning
Do not post this as a job yet. Copy it into a document, cut everything that does not fit your company, and write one real name in the margin: the person already on your team with the shape for this. Write the job down, and you have something to hire, grow, or grow into. Leave it blank, and you are recruiting against a role that does not exist.
<div class="ti-sources">
## Sources and further reading
- Marty Cagan, *Inspired: How to Create Tech Products Customers Love* (2nd ed., Wiley, 2018), and [Silicon Valley Product Group](https://www.svpg.com/), on the difference between a team that builds capability and one that ships a single feature, the basis for the "portfolio of small wins" framing
- Teresa Torres, *Continuous Discovery Habits* (Product Talk, 2021), on interviewing to find the real problem behind the stated request, the discovery-and-reframe move
- Everett Rogers, *Diffusion of Innovations* (5th ed., Free Press, 2003), on why capability spreads through respected peers rather than mandates, the basis for the champion network
</div>