Write the Role Before You Fill It

You have probably already decided you need this person. Most leaders I talk to do, and fast, the moment they see what the AI Product Partner actually is: the one who decides whether AI ever becomes real inside the company. The trouble starts when you sit down to write the job. The cursor blinks. There is nothing to copy, no posting from a peer company, no line on last year’s org chart. So the job that was going to change everything becomes the job nobody can describe, and it waits.

The stall is not really about hiring. It is that the job was never written down. You cannot hire a job you have not written. You cannot grow your head of ops into it, and you cannot hand your chief of staff a fifth of their week to run it, until someone has put on one page what this person owns on Monday, what they answer for by the quarter, and what they are not. Hire it, grow it, or name a fractional owner. Every one of those runs through a page that does not exist yet.

Writing it down is the decision

The page is not the paperwork after the decision. It is the decision. A blank document asks you the questions the excitement lets you skip. Whose work should change first, the regulatory writers or the clinical operations team? What counts as a win in ninety days, one tool that shipped, or three people who stopped doing a task by hand? What can this person change without asking, and who do they call when quality says no? A box on the org chart lets you dodge all of it. A written job makes you answer, which is exactly why the writing comes before the budget instead of after it.

Do not borrow the wrong job

The fast way to get this wrong is to reach for the nearest template and paste. Drop in a data-scientist req, the one that wants a PhD and publications and models shipped, and you will screen out everyone who could do this and hire the one who cannot, because the job is translation and trust, not modeling. Harvard Business Review made the same case years ago about the “analytics translator,” the person who bridges the technical team and the business: you do not have to be a data scientist to fill it, and screening for one gets you the wrong hire. The qualification is deep knowledge of the work, not the modeling. Borrow a product manager’s description built around a single product and you miss the whole point, which is a portfolio of small wins across every function at once. This job is defined by its edges more than its middle. Say what it owns and say what it is not, then set the level to your size. At fifty people it is a fraction of someone you already employ. At five hundred it anchors a team. The work is the same at both, which is why you can write it once and cut it to fit.

Monday morning

Do not open a search this week. Open a document. Write three lines: the function whose work should change first, the one thing you want to be true in ninety days, and the name of the person already on your team with the right shape. Then take the template and cut it down, or hand that fractional owner a fifth of their week and get out of their way. A job you cannot describe is not a hire you are ready to make. Write the page first, and everything after it has something to be.

Cheers,
-Titus