# Translational Intelligence Knowledge Bundle Version: 2026-09-15 Source: https://translationalintelligence.com/ Author: Alexander Titus (author of record; this publication is AI-assisted human work product). Career: Pandemic response at Google. The genotype-to-phenotype engineering team at Colossal. Enterprise AI transformation at Avidity. The same charge now at Alloy, through Vigilance. And a Commissioner advising Congress on the future of emerging biotech. Translational Intelligence. The organizational operating system for building an AI-native biotech. An open, evidence-backed field guide for building an AI-native biotech. From Alexander Titus. This file contains the full text of every published Issue, FAQ, Artifact, and Case Study, with diagrams summarized in prose. The five core frameworks are maintained as living pages on the site and are summarized throughout this corpus: - Translational Intelligence: https://translationalintelligence.com/translational-intelligence/ - Permission, People, Programs: https://translationalintelligence.com/permission-people-programs/ - Buy the Record. Build the Intelligence.: https://translationalintelligence.com/buy-record-build-intelligence/ - The AI Product Partner: https://translationalintelligence.com/ai-product-partner/ - The AI Product Partner: https://translationalintelligence.com/ai-product-partner/ - The Innovation Engineering Team: https://translationalintelligence.com/innovation-engineering-team/ - The AI-Native Biotech: https://translationalintelligence.com/ai-native-biotech/ - The Scope Ladder: https://translationalintelligence.com/scope-ladder/ Each section below names its type, canonical URL, and date. When citing, cite the canonical URL. --- ## [Artifact] A Lightweight AI Use Policy Canonical URL: https://translationalintelligence.com/artifacts/ai-use-policy/ Date: 2026-07-02 Summary: One page. Two tiers of data and one ethos, that there is no AI work product, only AI-assisted human work product, and a human is accountable for all of it. ## The one idea There is no such thing as an AI work product. There is only AI-assisted human work product. Whoever puts their name on a piece of work owns all of it, every fact, every number, every claim, no matter whether they, a colleague, or a chatbot produced the first draft. That single principle is the whole policy. Everything below is how to live it. ## Why this frees you Once accountability sits squarely with the human author of record, the usual fears lose their grip. Hallucinations, uneven quality, a confident wrong answer, these are not new risks that AI introduced. They are the ordinary risks of any draft from any source, and you already know how to manage them, because you check the work before it leaves your hands. A chatbot is a fast, tireless, sometimes-wrong colleague. You would not forward a junior analyst's memo to the board without reading it. Treat AI output the same way and you can use it for far more, far faster, because you are the backstop. ## The two tiers of data Most of what people call an AI policy is a data policy in disguise. Keep it simple enough to hold in your head. The sensitivity of the information decides the environment it is allowed to enter. - **Tier 1, Confidential.** Anything business-confidential: unpublished results, program data, sequences, patient information, financials, legal matters, anything under an NDA or partner agreement, anything not yet public. Tier 1 information goes only into contracted, enterprise-secure environments that [Company] has approved for that class of data. Never a personal or consumer account. - **Tier 2, Open.** Public or non-confidential information: published literature, general knowledge, marketing copy, anything already public or that safely could be. Use any approved tool freely, and explore. The risk is low and the upside is high, so the default here is yes. If a person cannot say cleanly which tier a piece of information belongs to, that is a classification question to resolve first, not a reason to freeze. ## On trusting your contracts The hardest Tier 1 question is whether an enterprise agreement is really enough to protect your data. It is a fair question, and it deserves to be settled once, deliberately, up front, not relitigated on every use. Responsible innovation means not reopening settled debates out of principle. If [Company] has done the diligence and holds an enterprise agreement that a vendor will not train on or retain your data, then decide, and let people work. But be honest that a contract is one control, not the whole story. The full picture is the control environment around it: access controls, retention and residency, subprocessors, incident response, and monitoring. Frameworks like the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) exist to map that terrain, and for regulated records the standards below govern. If you do not trust the arrangement, you do not have a tooling problem, you have a Permission problem, and the work is on the front end, choosing vendors, terms, and controls you can stand behind. Do that once, then get out of your people's way. ## What you still owe the work Accountability is total, so a few duties come with it. - **Verify before it leaves you.** Facts, figures, citations, and quotes are yours to confirm. AI is a strong first draft, never a source of record. - **Name the human on consequential work.** For anything that becomes part of an official record, a regulatory submission, a clinical judgment, a legal position, a published result, a specific person owns the decision and a human reviews before it ships. Higher stakes, more review. - **Disclose where it is material, not everywhere.** You do not caveat every email. But where the origin of the work matters to the reader, the scientific record, a regulatory filing, be transparent about AI assistance. - **When in doubt, ask.** [Name or role] is the person to ask before, not after. Asking early is always the right call, and it is never held against you. ## What this policy is not It is not a surveillance program and it is not a ban. It is a one-page employee quick guide, the layer people actually read, and it sits inside a fuller governance architecture your quality, security, and legal functions own: provenance, access controls, retention, subprocessors, validation, incident response, and monitoring. This page makes people accountable and fast; it does not replace that control standard. The goal is more capable people doing better work, and accountable for all of it. --- *Adapt the bracketed items for [Company], approve your environments and your point of contact, and this is ready to use. Keep it to a page. If it grows, it stops getting read. And a policy that gets read still has to be understood, which is a job of its own: see [Fifteen Minutes at a Time](/case-studies/fifteen-minutes-at-a-time/).* ## Sources and further reading - NIST, [AI Risk Management Framework (AI RMF 1.0)](https://www.nist.gov/itl/ai-risk-management-framework) (2023), for the fuller govern/map/measure/manage control model - FDA, [21 CFR Part 11, Electronic Records; Electronic Signatures](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11), where AI touches regulated records - EMA, [Reflection paper on the use of AI in the medicinal product lifecycle](https://www.ema.europa.eu/en/use-artificial-intelligence-ai-medicinal-product-lifecycle-scientific-guideline) (2024) --- ## [Artifact] The Think-Harder Writing Workflow Canonical URL: https://translationalintelligence.com/artifacts/think-harder-workflow/ Date: 2026-07-05 Summary: An eight-step method for writing with AI that sharpens your thinking instead of replacing it. Expand before you compress, decide what you believe, and keep the judgment yours. ## The principle Use AI to reach the hard part of thinking more often, not to skip it. The struggle to work out what you actually mean is the part that has to stay yours. Everything that gets you to that struggle sooner is fair game. Run a piece through these eight steps and you spend AI on friction, not on avoiding it. ## The eight steps 1. **Originate.** Start with something only you could have produced: an observation from experience, an unresolved contradiction, a voice memo from a walk, a paragraph that does not quite work, a claim you suspect is true but cannot yet defend. It should be rough. The roughness is evidence of your thinking. 2. **Interrogate.** Before you ask AI to write a word, ask it to make the problem harder. What am I assuming? What is the strongest counterargument? Where would an expert call this naïve? Which parts are genuinely mine, and which are familiar ideas in new language? What is the most uncomfortable implication if it is true? What would change my mind? These are thinking prompts, not drafting prompts. 3. **Decide.** State the thesis in your own words, before drafting. Be able to say what you believe, why, what would make it false, why it matters, and what you are asking the reader to see differently. AI can compare theses. It cannot choose the one you are willing to stand behind. 4. **Structure.** Now bring AI back in. Ask it to organize the argument, compare a few possible architectures, and flag where an example or a piece of evidence is missing. You are choosing the road; it is helping you lay it. 5. **Draft.** Write directly, collaborate paragraph by paragraph, or have AI produce a draft from the decisions you already made. The order does not matter. What matters is that the thinking happened first. 6. **De-synthesize.** Strip the tells. Not forbidden words, structural habits: the sweeping opener, the tidy rule of three, the false binary, the transition that only transitions, the uplifting abstraction where a concrete point belongs. Ask of every draft: could any competent person with the same prompt have written this? 7. **Reclaim.** Rewrite the passages that carry the most judgment yourself, the opening, the central claim, the decisive transitions, the conclusion. These are where your voice has to be unmistakable. 8. **Defend.** The test. Could you explain every major claim to a skeptical expert, name its weak points, and say where your thinking changed, without leaning on the generated text? If yes, AI accelerated your reasoning. If no, it stood in for it, and you have work to redo. --- *The blank page was never sacred. The struggle to decide what you mean is. Use this to reach that struggle more often, and never to automate it.* --- ## [Artifact] How to Write With AI Without Sounding Like It Canonical URL: https://translationalintelligence.com/artifacts/ai-writing-style-guide/ Date: 2026-07-06 Summary: A house style guide for writing with AI. Derive your voice from evidence, state the rules worth stating, and cut the structural tells that make prose sound machine-made. ## The principle AI can make any draft sound finished. That is the danger, not the promise. A style guide is not decoration; it is how you make your taste explicit, so that you, an editor, and a model all know what "good" and "sounds like us" actually mean. Written down, judgment becomes something you can repeat, delegate, and defend. ## Voice is a pattern of decisions, not a list of adjectives Everyone wants to sound clear, smart, and concise, so those words tell a model nothing. Your voice is the set of decisions you make: what you notice first, how you build an argument, where you place tension, how long you stay abstract before an example, which metaphors you reach for, what you refuse to exaggerate, and what kinds of sentences feel dishonest coming from you. So do not describe your voice from memory. Derive it from evidence. Give the model several things you actually wrote, from different contexts, and have it find the recurring patterns. Then correct it, because its first read will fixate on the surface. Your corrections are the training, even when no model is technically being trained. ## The rules worth stating, mostly negative The most useful house rules are the "do nots," because they name the defaults you want to override. Ours, adapt your own: - Do not flatter the reader. - Do not inflate an ordinary observation into a civilizational revelation. - Do not use corporate throat-clearing. - Do not manufacture false balance when the argument supports a clear conclusion. - Do not resolve every productive tension into something tidy. - Do not end every section like a keynote. - Do not explain a sentence right after writing it. - No em-dashes. Emphasis is italic, never bold. ## The tells to cut AI prose is recognizable not by a secret set of forbidden words but by structural repetition. No single habit is fatal; the accumulation is. Cut for it: - the sweeping opener about a fast-changing world; - the tidy rule of three; - the false binary, "this is not merely X, it is Y"; - headings that just restate the thesis; - "critical," "transformative," "profound," on repeat; - the uplifting abstraction where a concrete conclusion belongs; - disagreement flattened into a list of equally reasonable perspectives; - every tension closed too cleanly. The cure is texture, not a banned-word list. Human writing lingers in some places and moves abruptly through others, trusts the reader to infer, and lets a sentence stand without a gloss. ## The one test Ask it of every draft: could any competent person with the same prompt have written this? A piece can be excellent and still be generic. If it could have come from anyone, reclaim the passages that carry the most judgment, the opening, the central claim, the decisive transitions, the conclusion, and write those yourself. ## Keep exercising the taste A style guide is not a substitute for taste; it is how you scale it. So keep the muscle alive. Write the first ugly paragraph yourself. Read the primary source before the summary. The guide keeps AI on the rails. Your hand keeps the writing yours. --- *Adapt every rule to your house. The point is not this exact list. It is that you wrote one down, so that "sounds like us" stops being a feeling and becomes a standard you can hold.* --- ## [Artifact] The Build-vs-Buy Decision Framework Canonical URL: https://translationalintelligence.com/artifacts/build-vs-buy/ Date: 2026-07-12 Summary: Route any AI request through five honest options, why the line now leans toward build, the five-year promise that comes with it, and how the smallest builds win the adoption that unlocks the big ones. ## The one rule, and how it moved Buy the system of record. Build the system of intelligence. The system of record is the infrastructure everyone in your industry shares and no one wins on, so buy it. The system of intelligence is the layer that turns your data and your particular way of working into advantage, so build that. But know that the line has moved, hard, toward build. AI has made building faster and cheaper than it has ever been, so the honest default now leans toward build more than the old procurement wisdom allowed. When you catch yourself reaching for a vendor out of habit, stop and ask whether a small, sharp build would be faster than the buying cycle. ## The five routes Every AI request comes down to one of five moves. Most of the discipline is routing each request to the right one, on purpose. - **Self-serve.** Give people secure access to general-purpose tools, with education and accountability. This is where [the AI Product Partner](/ai-product-partner/) earns their keep: train for self-service, because most of the work lives here Operator heuristic (call it roughly 70%; the point is the majority, not the decimal), and a surprising amount of value arrives with no project at all. - **Buy.** License a mature capability the market already builds well, the commodity infrastructure everyone shares. This is a system of record. - **Build.** Create the capability only you can, on your data and your workflows. This is a system of intelligence, and in this era you will build more of it than you used to. - **Redesign.** Change the workflow or decision structure itself. Automate a broken process and all you get is the same breakage, faster. - **Do nothing.** Decline the weak requests. Not every problem needs AI, and saying no protects your attention and your credibility. ## Route the request Ask these in order, and stop at the first yes. 1. **Can people already do this with tools you have?** Self-serve. Train them and set guardrails, not a project. Most requests end here. 2. **Is the honest fix a different workflow, not a tool?** Redesign first. Do not automate the old shape. 3. **Is there a strong, ready vendor for a capability everyone shares?** Buy it. It is a system of record. 4. **Is it yours to build, and can you own it for five years?** Build only if both are yes. See the five-year test below. 5. **Is the value thin or the problem not real?** Do nothing, for now. ## Build what you can't or won't buy You build for two reasons, and the bar for both has dropped. - **You can't buy it.** The capability is genuinely unavailable, or your proprietary data and your particular workflow are the whole point and no vendor has them. This is the system of intelligence. - **You won't buy it.** It is bespoke and tailored enough that a vendor implementation would take more work, cost, and compromise than building it yourself. With AI in hand, a focused build is often faster than the procurement it replaces. The old caution was drift toward build, rebuilding commodity you should have licensed. That is still true for the system of record, so do not write your own cloud or your own lab notebook. Past that line, build more freely than you used to. ## Build is a five-year promise Here is the caveat the build-more era needs, because it is where the enthusiasm gets people hurt. Building a demo and owning a production system are not the same act, and AI has collapsed the first while barely touching the second. A weekend prototype that dazzles the room still has to become something your company can run for years. Time to demo is now trivial. Time to validated production is not, and the total cost of ownership lives almost entirely on the far side of the demo. So before you build anything, answer one question honestly, and treat a no as disqualifying: > **Are we willing and able to own, operate, secure, validate, support, and eventually retire this capability for the next five years?** That is not one question but a checklist wearing a single sentence. Each verb is a standing cost: - **Own and operate.** Someone is accountable for it running, not just for shipping it. - **Secure.** Access control, data handling, and a real security review, revisited as the threats change. - **Validate.** In regulated work, computerized-system validation and change control on every meaningful update, on the risk-based terms your quality function sets (see the FDA's [Computer Software Assurance guidance](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/computer-software-assurance-production-and-quality-management-system-software), and check with your own quality and regulatory function). - **Support.** Monitoring for model and data drift, a path for when it breaks, and documentation that lets someone other than the author keep it alive. - **Retire.** A plan for the day it is replaced, including the data and the dependencies it leaves behind. If no one will own that list, you have not decided to build. You have decided to accumulate a liability that looks like an asset. **A fast prototype is evidence that building is now cheap. It is not evidence that your company should own the production system.** When you cannot own the operation, buy the capability and spend your scarce engineering on the part you can. ## Solve small, and they will bring you big Here is the part most frameworks miss. The temptation is to reserve "build" for the big strategic bets, to only swing for the fences. In an AI-native company that is exactly backwards, because adoption and change are the whole game. Solve one person's real problem, however small, and they come back with bigger ideas than they had before. A small build that makes a scientist's Tuesday better is not a distraction from the strategic work. It is how you earn the trust and the momentum to do the strategic work at all. Solve for the individual, and you unlock the institutional. ## Revisit the line The line is not fixed. What is a differentiating build this year can become a commodity you should buy in two, once the vendors catch up, and what was too expensive to build last year is a weekend now. Put a date on the calendar to re-route your biggest builds and your oldest buys alike. --- *Run your three loudest AI requests through this once, out loud, with the people who own them. Then run your three smallest, the ones you have been ignoring. The small ones are where adoption is won.* --- ## [Artifact] The Permission, People, Programs Scorecard Canonical URL: https://translationalintelligence.com/artifacts/ppp-scorecard/ Date: 2026-07-13 Summary: One page. Grade your company on the three pillars that decide whether AI changes how you work, and find the one to fix first. ## How to use this One rule. Score your company from 0 to 3 on each of the three pillars, using the tables below. Do it with the people who own the work, not alone at your desk, and score the company you have, not the one on the strategy slide. Then read your result by your *lowest* pillar, not your average, because [Permission, People, and Programs](/permission-people-programs/) grow together or none of them grows. ## Permission: the space to move | Score | What it looks like | | --- | --- | | **0 · Absent** | No usable policy, or a blanket ban people quietly route around. Nobody can say cleanly which data goes in which tool. | | **1 · Stated** | A policy exists on paper, but it is a data policy in disguise, and your people cannot answer the Tier 1 versus Tier 2 question without checking. | | **2 · Practiced** | Two data tiers are clear, approved environments exist for each, and accountability and decision rights are named. People know where they are allowed to move. | | **3 · Native** | You revisit permission as the capability changes. Governance creates speed instead of braking it, and you review each gate for its shape rather than freezing it. | ## People: the capacity to move | Score | What it looks like | | --- | --- | | **0 · Absent** | Access without adoption. A handful of enthusiasts, and everyone else works exactly the way they did last year. | | **1 · Stated** | Training happened, a rollout or a webinar or a license, but behavior has not moved and there is no peer anyone is copying. | | **2 · Practiced** | Respected people use it in view of others, the examples look like real work, and adoption is spreading by imitation. | | **3 · Native** | Changing how the work is done is normal. People bring their own AI ideas, and new capability turns into new habits without a program pushing it. | ## Programs: the capability itself | Score | What it looks like | | --- | --- | | **0 · Absent** | No programs, or scattered pilots that never change how the institution operates. | | **1 · Stated** | Tools get shipped, but every request defaults to the same reflex, a pilot or a purchase or a custom build, whatever the room reaches for. | | **2 · Practiced** | Requests get [routed on purpose](/buy-record-build-intelligence/), and the smallest builds are winning the adoption that unlocks the bigger ones. The learning is kept. | | **3 · Native** | You keep re-routing your builds and your buys as the line moves. The institution operates measurably differently than it did a year ago, on purpose. | ## Read your score | Pillar | Your score (0-3) | | --- | --- | | Permission | | | People | | | Programs | | Your true level is your lowest pillar. Two things are almost always true when leaders score themselves honestly. Permission comes in high, because writing a policy feels like progress and it threatens no one. People comes in low, because behavior is the hardest and least visible thing to change. If Permission is your highest score and People is your lowest, you are not behind, you are *normal*, and you now know exactly where the work is. ## The move Take your lowest pillar and raise it one level this quarter. Operator heuristic One level per quarter is a healthy default pace, not a law; a higher-risk or earlier-stage company should set its own target. Not all three, and not the one you like to show off. One level, on the pillar you are worst at. The question of [which pillar to fix first](/faqs/which-pillar-first/) has its own answer, and the full model is on [Permission, People, Programs](/permission-people-programs/). --- *Score it in the next exec meeting, out loud, before anyone has time to round themselves up. Then put a date on the calendar ninety days out, and score again.* --- ## [Artifact] The Small-Team Operating Model Canonical URL: https://translationalintelligence.com/artifacts/small-team-operating-model/ Date: 2026-07-16 Summary: How a sub-100-person biotech runs an AI transformation without a Head of AI, a platform, or a committee. The fractional version of every role and program. ## The one idea At fifty people with runway to protect, you cannot open a requisition for [an AI Product Partner](/ai-product-partner/), and you should not try. The role is a *function* before it is a job. Someone has to own permission, own adoption, and route the programs, but that someone is already on your team, at about 20% of their time. Operator heuristic The 20% is a starting figure, not a measurement; size it to your company, and watch for the trigger where the function outgrows the fraction. Naming them is the whole move. ## Give it an owner, not a hire The function has to exist. The full-time body does not, until the function outgrows a fraction of one. So do not post a job. Take one person who already has the trust of the room and a real curiosity about the tools, and give them a fifth of their week and a clear mandate. A named owner at 20% beats an unfilled requisition every quarter of the year, and it beats a committee every day of the week. ## Which of your people is the right shape The right owner is T-shaped. Deep enough in one part of the work to be respected, broad enough to see across the whole company, and genuinely curious about what the tools can now do. In practice that is often a chief of staff, a head of operations, or a sharp program lead. It is usually *not* your most technical person, because the job is translation and trust, not engineering. And it is almost never an outside hire, because the hardest part of the work is [changing how respected colleagues do their jobs](/permission-people-programs/), and that trust does not arrive with a contract. Look for the shape, not the title. You are looking for the person other people already listen to. ## What the 20% does - Runs the [Permission, People, Programs Scorecard](/artifacts/ppp-scorecard/) and names the weakest pillar. - Owns the one-page [AI Use Policy](/artifacts/ai-use-policy/), so permission is settled and out of the way. - Finds the one workflow worth changing, and makes the win visible. - Trains people to self-serve, because most of the value lives there and needs no project. - Routes every new request through the [five moves](/artifacts/build-vs-buy/) instead of defaulting to a purchase. - Recruits the ambassadors that everyone else copies. ## What not to do at your size - **Don't hire a Head of AI.** Name the function first, and hire only once the 20% is visibly, provably full. - **Don't buy a platform before you have shipped a workflow.** You have not earned the signal that tells you which one. - **Don't stand up a committee.** A committee is how a small company simulates progress. One owner outruns it. - **Don't build what you can buy, or buy what your people can already self-serve.** - **Don't wait for a strategy.** [Run a quarter](/artifacts/first-90-days/), and let the strategy be the pattern you find. ## The minimum viable institution You do not need a transformation office. You need the smallest working version of all three pillars: one page of Permission, one visible win under People, one workflow routed on purpose under Programs. That is a complete operating model, and it fits on a company under a hundred people without adding a single full-time head. --- *Before you post the job, look around the room. The person who should own this is probably already in it, doing something you value, and one honest conversation away from spending a fifth of their time on the thing that will change the other four.* --- ## [Artifact] Where AI Touches a Clinical-Stage Biotech Canonical URL: https://translationalintelligence.com/artifacts/clinical-stage-ai-map/ Date: 2026-07-17 Summary: A practical map for the company whose science is at the CROs. Where AI helps across clinical ops, regulatory, medical writing, and vendor oversight, and where the validated-environment line sits. ## Read this if your bench is outsourced Regulatory This map names where AI touches a clinical-ops company and where the validated-environment line sits, with the controlling regulations linked below. It is the shape of the constraint, not legal advice; confirm the specifics with your own quality and regulatory function. Most AI-in-biotech advice pictures a discovery lab: assay data on your servers, models trained on your own experiments. If you run a clinical-stage company, that is not your company. Your science is largely at the CROs. The part with your employees and your deadlines is clinical operations, regulatory, medical writing, safety, and vendor oversight. This map is where AI touches that work, and where the validated-environment line sits. ## Where AI helps today | Function | Where AI helps today | | --- | --- | | Medical writing and clinical study reports | First-draft narratives and summaries from structured data, consistency and style checks across a document set | | Protocol and regulatory documents | Drafting and harmonizing protocols, consent forms, and submission summaries against templates and prior filings | | Safety and pharmacovigilance narratives | Drafting case narratives from structured case data at volume, for human review before anything is filed | | Regulatory submissions | Summarizing, drafting, and QC-ing content across submission modules, checking cross-references | | CRO and vendor oversight | Synthesizing monitoring reports, surfacing signals across vendor deliverables, drafting oversight questions | | Clinical operations | Drafting queries, summarizing site performance, preparing for monitoring visits | | Medical information and literature | Searching, summarizing, and drafting responses from public and licensed sources | ## The two lines that decide the environment Two questions govern every use above, and neither is about the model. *First, what class of data.* Patient data and results you have not yet filed are Tier 1, and they belong only in a contracted, enterprise-secure environment approved for that class, exactly as your [AI Use Policy](/artifacts/ai-use-policy/) says. Public and non-confidential inputs are Tier 2, where you should push people to explore. *Second, is AI touching a validated record.* There is a real difference between AI drafting a document a qualified human owns and reviews, and AI becoming part of a system that creates or maintains a GxP record. The first is mostly a People and Programs question: the human is the author of record, and your normal quality review still applies. The second is a computer-system-validation and 21 CFR Part 11 question, and it is your quality and regulatory function's call, not something to route around. Most of the early value sits on the near side of both lines: drafting and synthesis, on non-patient data or inside your approved environment, with a human who owns the output. There is more of it than you think. ## Don't relitigate the gates. Reconsider their shape. The validated processes and review gates in a clinical-stage company were rational answers to a world where information was expensive to move and slow to trust. AI does not delete the judgment those gates protect, which is patient safety and data integrity, and you should not try. Do the Permission work once, choose controls you can stand behind, and stop relitigating settled safety debates out of principle. But do ask the [AI-native](/ai-native-biotech/) question. Is the current shape of a gate still the best way to protect what it guards, or is it a manual step that survived only because the old systems could not see each other. That is a question for you and your quality function together, answered deliberately, not a reason to wait. --- *Start where neither line bites: a first-draft narrative, a summarized monitoring report, a submission section a qualified human will own and check. Win there, bring your quality and regulatory function in early, and move the harder lines on purpose.* ## Sources - FDA and EMA, [Guiding Principles of Good AI Practice in Drug Development](https://www.fda.gov/media/189581/download) (January 2026), ten joint principles spanning the medicine lifecycle, from research through manufacturing and safety monitoring ([EMA announcement](https://www.ema.europa.eu/en/news/ema-fda-set-common-principles-ai-medicine-development-0)) - FDA, [21 CFR Part 11, Electronic Records; Electronic Signatures](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11) (eCFR, current) - FDA, [Considerations for the Use of AI to Support Regulatory Decision-Making for Drug and Biological Products](https://www.federalregister.gov/documents/2025/01/07/2024-31542/considerations-for-the-use-of-artificial-intelligence-to-support-regulatory-decision-making-for-drug) (draft guidance, Federal Register, January 2025) - ICH, [E6(R3) Good Clinical Practice](https://www.ema.europa.eu/en/documents/scientific-guideline/ich-e6-r3-guideline-good-clinical-practice-gcp-step-5_en.pdf) (Step 4 reached January 2025; linked here as EMA's Step 5 implementation), on computerised systems and data integrity in trials - EMA, [Reflection paper on the use of AI in the medicinal product lifecycle](https://www.ema.europa.eu/en/use-artificial-intelligence-ai-medicinal-product-lifecycle-scientific-guideline) (2024) --- ## [Artifact] The Day-One Target Safety Triage Canonical URL: https://translationalintelligence.com/artifacts/target-safety-triage/ Date: 2026-07-20 Summary: How to use AI to pull a first-pass target safety read in a day. Not to replace the expert assessment, but to surface a disqualifying signal, for a human to verify, before you spend a scientist's month on a doomed target. ## What a target safety assessment is, and why day one matters Before a program commits real money to a target, someone has to ask the safety question the whole thing rides on. If we antagonise or attenuate this target, what breaks. A target safety assessment (TSA) answers it at target nomination, by pulling together the target's biology, its gene and protein expression across tissues, human and animal genetic evidence, and what happened to competitors who touched it. Done well, it is expert, slow, and decisive: it confirms unavoidable on-target liabilities and surfaces the ones you could design around, so a program goes forward, pivots, or dies before it burns a preclinical budget. The cost of getting it late is enormous, and the cost of getting a *first read* early is now almost nothing. That gap is the opportunity. ## The one idea AI can give you a first-pass target safety read on day one. Not the assessment. A first pass: the collection, the summarization, and the initial analysis, assembled in a day instead of the weeks it takes a human to gather it by hand. The value is not that the machine writes your TSA. It is that a scientist's judgment is the most expensive input in discovery, and you should not spend a month of it on a target that a day of automated collection would have flagged. If AI surfaces an embryonic-lethal knockout, a broad and essential expression profile, or a human genetic association with exactly the adverse phenotype you fear, you have a high-priority lead to verify before the expert deep-dive starts. You did not replace the assessment. You made sure the expensive one only ever runs on targets not yet ruled out. > [Diagram: The day-one target-safety triage, end to end] ## State the perturbation hypothesis first "Is this target safe" is not yet a question a machine, or a person, can answer. Safe *how*, and against *what* intervention? A target that is dangerous to knock out constitutively in an embryo may be perfectly tractable to inhibit partially, reversibly, in one adult tissue, for a fixed course. Before you run the pass, write down the perturbation you actually intend, because every signal below has to be read against it: - **Direction.** Are you inhibiting, activating, degrading, or replacing the target? - **Modality.** Small molecule, antibody, oligonucleotide, gene therapy? Each engages the target differently, and the genetics map onto each differently. - **Magnitude and reversibility.** Full or partial knockdown, and does it reverse when the drug stops, or is it permanent? - **Tissue and exposure.** Systemic, or restricted to the diseased tissue? Where will the drug actually reach the target? - **Population and duration.** Who is dosed, how sick, and for how long? An eight-week course in late-stage disease and a lifelong prophylactic carry different safety bars. - **Developmental versus adult biology.** Most knockout evidence is constitutive and developmental. Your drug almost never is. You are not answering these yet. You are stating them, so that when the pass returns a signal, you can ask the only question that matters: *does this signal apply to what I actually plan to do?* ## What the day-one pass collects The raw material of a TSA already lives in public, machine-readable knowledge bases. The work AI removes is the retrieval and the reading, not the interpreting. A day-one pass pulls, for the target: - **Expression breadth.** Where is it expressed, and how broadly, from [GTEx](https://gtexportal.org/home/) and the Expression Atlas. A target restricted to the diseased tissue is a very different safety story than one expressed everywhere and essentially. - **Loss-of-function tolerance.** How constrained is the gene in humans, from [gnomAD](https://gnomad.broadinstitute.org/) (LOEUF and pLI). A gene humans cannot tolerate losing is a warning about attenuating it with a drug. - **Knockout phenotypes.** What happens when you delete it in a mouse, from the [International Mouse Phenotyping Consortium](https://www.mousephenotype.org/). Lethal or severe phenotypes are the loudest early signal there is. - **Human genetic associations.** Do variants that reduce the target's function associate with adverse phenotypes, or with the protection you are hoping for. Genetic support cuts both ways, and it is among the strongest early predictors available: mechanisms with human genetic support are more than twice as likely to reach approval, about 2.6-fold in the refined estimate ([Nelson et al., *Nature Genetics*, 2015](https://www.nature.com/articles/ng.3314); refined by [King et al., *PLOS Genetics*, 2019](https://journals.plos.org/plosgenetics/article?id=10.1371/journal.pgen.1008489) and [Minikel et al., *Nature*, 2024](https://www.nature.com/articles/s41586-024-07316-0)), with the effect varying by therapy area, development phase, and confidence in the causal gene. - **Precedence and prior liabilities.** Known drugs against the target, known on-target toxicities, and competitor programs that failed on safety. Most of this is already integrated and scored in one place, the [Open Targets Platform](https://academic.oup.com/nar/article/53/D1/D1467/7917960), which aggregates genetics, expression, mouse phenotypes, tractability, and safety into a single target view. Buy the record: the databases are the shared infrastructure, and you win nothing by rebuilding them. Build the intelligence: the day-one pass is your prompt, your retrieval-and-verify workflow, and your target-specific judgment on top. ## Read every signal in context Every signal above is a lead, not a verdict, and each one is context-dependent in a way the machine will not caveat for you. Read each against the perturbation hypothesis you wrote down. - **A lethal knockout is not automatically a dead target.** Most knockout evidence is constitutive and developmental. An embryonic-lethal gene deletion says little, on its own, about inhibiting the same target partially and reversibly in an adult tissue for a fixed course. It is a reason to look hard, not a reason to stop by itself. - **Broad RNA expression is not broad risk.** Transcript abundance across tissues is not the same as protein abundance, target engagement, or toxicity. Where the drug actually reaches the target matters more than where the message is transcribed. - **Loss-of-function constraint depends on your modality.** A high pLI or a low LOEUF warns against removing the protein fully and permanently. It reads differently for a partial, reversible inhibitor than for a knockdown or a gene therapy, and differently again for agonism versus antagonism. - **Genetic support raises the odds; it does not prove safety.** It is the most predictive early signal you have, but it speaks to probability of *success*, not to a clean safety bill, and its size varies by therapy area, by phase, and by how confident you are in the causal gene. Powerful evidence, not a context-free decision rule. The pattern is the same every time: the pass tells you where to look; your hypothesis and a human tell you what it means. ## What it flags The day-one pass is not scored to bless a target. It is scored to *surface a reason to stop*, cheaply. It reads the collected evidence for the disqualifying signals: broad and essential expression, a lethal or severe knockout phenotype, strong human loss-of-function constraint, a genetic association pointing at the toxicity you are worried about, or a graveyard of competitor programs that died on the same on-target liability. Any one of those, surfaced on day one, is worth more than a beautiful summary, because it changes what you do next. ## What it does not do This is the line, and in a safety context it is not negotiable. The day-one pass is not the target safety assessment, and it is never the decision. A human safety scientist is the author of record and owns every claim in the final TSA, exactly as [there is no AI work product](/there-is-no-ai-work-product/), only AI-assisted human work product. A confident, fluent, wrong summary of a knockout phenotype is not a small error here; it is a safety liability, so every extracted fact is verified against its source before it informs anything. The AI cleared the collection so the scientist could spend their scarce attention on interpretation, which is the whole point of [not automating the struggle](/dont-automate-the-struggle/): you reach the hard judgment sooner, you do not skip it. And the evidence has limits the machine will not caveat for you. Genetic support raises the odds; it does not guarantee safety or success. Absence of a mouse phenotype is not absence of human risk. A first pass built from public databases is exactly that, a first pass, and it does not replace the expert assessment, the bespoke de-risking assays, or the nonclinical safety package that regulators will expect. Treat the day-one read as triage, and confirm the safety strategy with your own toxicology and regulatory functions. ## Monday morning Take the next target on your list and run the day-one pass before you schedule the expert TSA. Pull its expression breadth, its constraint, its knockout phenotype, its genetic associations, and its precedent, have AI assemble the first-pass memo, and then verify every line against the source. If a disqualifying signal is sitting there, you found it in a day and saved a month. If nothing is, your safety scientist starts their real assessment already past the grind, on a target that still requires the full assessment. ## Sources and further reading - apcOnix, [Target Safety Assessments and their role in de-risking drug discovery](https://www.apconix.com/target-safety-assessments-and-their-role-in-de-risking-drug-discovery-nav1-7-as-an-example/), on TSA scope and inputs (target biology, expression, human and animal genetics, competitor intelligence) - Drug Target Review, [Target safety assessments: identifying risk early](https://www.drugtargetreview.com/article/99566/target-safety-assessments-identifying-risk-early/) - Nelson et al., [The support of human genetic evidence for approved drug indications](https://www.nature.com/articles/ng.3314) (*Nature Genetics*, 2015), with [King et al.](https://journals.plos.org/plosgenetics/article?id=10.1371/journal.pgen.1008489) (*PLOS Genetics*, 2019) and [Minikel et al.](https://www.nature.com/articles/s41586-024-07316-0) (*Nature*, 2024), on genetic support, its roughly 2.6-fold effect on probability of approval, and how that effect varies by therapy area, development phase, and confidence in the causal gene - [Open Targets Platform](https://academic.oup.com/nar/article/53/D1/D1467/7917960) (*Nucleic Acids Research*, 2025), integrating genetics, expression, mouse phenotypes, tractability, and safety - Primary data: [GTEx](https://gtexportal.org/home/) (tissue expression), [gnomAD](https://gnomad.broadinstitute.org/) (loss-of-function constraint), [IMPC](https://www.mousephenotype.org/) (mouse knockout phenotypes) --- ## [Artifact] The Value Map Canonical URL: https://translationalintelligence.com/artifacts/value-map/ Date: 2026-07-20 Summary: A one-page way to decide where to point AI. Sort your team's work by two values, what the business needs and what only your best people should do, and aim automation at the corner that frees your scarcest talent. ## Two questions, not one Every task carries two values, and they are not the same. Confusing them is the mistake that sends AI at the wrong work. Ask both: - **Enterprise value.** Does the business genuinely need this done? - **Expert-judgment intensity.** How much does it draw on scarce expert judgment, taste, and hard-won expertise, as opposed to merely time? This is about the *task*, not the person. Low intensity does not make the person low-value. ## Sort the work Place each recurring task in the grid. | | Low judgment | High judgment | | --- | --- | --- | | **High enterprise value** | **Point AI here first.** The grind the business needs but your best people should not be doing. | **Your best people.** AI assists, a human owns every call. Protect this. | | **Low enterprise value** | Let it go. Automating it just makes noise cheaper. | Ask why your best people are spending here at all. | ## The corners - **High enterprise, low judgment.** Your first target. Automation buys the most here, not because the task matters, but because the person does. This is where a routine first-draft section, a standard report, or the analyst's vendor email lives. - **High enterprise, high judgment.** The work only your experts can carry, a BLA narrative and its equivalents. AI can clear the blank page, but a human is the author of record and owns the judgment. Do not hand this over to save time; you have better places to save it. - **Low enterprise, low judgment.** Stop doing it. AI is not the answer to work that should not exist. - **Low enterprise, high judgment.** A misallocation to fix at the source. Your scarcest people are on work the business does not need. AI is a distraction from the real question. ## The second-order test The value of clearing low-judgment work is not the hours saved on it. It is where the freed bandwidth goes. So for every task you hand to AI, name the redirect out loud. If the freed time flows back into more low-value work, you saved hours and gained nothing. If it flows into the work only your best people can do, you multiplied your scarcest resource. That redirect is the whole return, and it is the number to manage. ## Run it 1. List your team's recurring work for a normal month. 2. Break the big, important items into parts. A submission is not one point on the grid; its sections, tables, and narratives land in different corners. 3. Place each task on the two axes, honestly. 4. Aim AI at the high-enterprise, low-judgment corner first. 5. For every task you automate, name where the freed time goes, and hold that. 6. Revisit quarterly. Work moves between corners as tools and people change. --- *The argument behind the map is [Don't Point AI at Your Best Work](/dont-point-ai-at-your-best-work/). Point AI at the grind, on purpose, so your genius lands only where genius is required.* --- ## [Artifact] The People-First Playbook Canonical URL: https://translationalintelligence.com/artifacts/people-first-playbook/ Date: 2026-08-04 Summary: You cannot deploy a culture. You lead one. The concrete moves for the human side of an AI transformation, the part that actually decides whether it holds. ## The one idea AI transformation usually stalls on the people, not the technology. A company can deploy every tool and change nothing, because deploying a tool is not the same as changing how a person works. That change is behavioral, social, and slow, and it is the whole job. You cannot buy it, install it, or announce it. You lead it, deliberately, and you lead it people-first. This is the playbook for that work. Not the tools. The people. ## The moves Run them in this order. Each is cheap. Together they are how a culture actually moves. - **Name it as a culture change, out loud.** Before anything else, say the quiet part: the hard, slow work here is changing how people work, not standing up software. Naming it sets the expectation that a rollout is not a transformation, and it stops your team from mistaking motion for progress. - **Start with the individual, not the org chart.** Find one respected person with one real, small friction, and solve it with them, in the room. Belief travels through people, not licenses. A single credible peer who has felt what is possible does more than any all-hands slide. - **Find the ambassador and give them a role.** The person that first win converts is your most valuable asset. Name them, back them, and let them carry capability into their own function. A respected colleague who has done it is social proof no central team can manufacture. [The Avidity case](/case-studies/fifteen-minutes-at-a-time/) is this move at company scale. - **Teach in person, in small doses.** Behavior change is personal, so a memo will not do it. Someone senior sitting with a team for fifteen minutes, answering the real question to their face, changes more than a recorded module ever will. The time you spend is itself the message that this matters. - **Make responsible experimentation safe.** Handed a new capability, good people default to the most cautious reading and freeze, to be safe. That looks like caution and is really just slow. The freeze breaks when people understand not only the rules but the reasoning: where the real risk lives, and where it does not. - **Measure adoption, not deployment.** Licenses issued, tools launched, and pilots counted are vanity metrics. They measure your activity, not your company's. The number that matters is whether behavior changed, and whether the person who would not touch the tool in week one is rethinking their work by week six. - **Let the questions refine the rules.** The questions people ask when you teach are a map of where your policy is unclear and where the real fear lives. Collect them, answer them, and carry them back to sharpen the policy. A rule you have to explain out loud to a skeptical room is a rule whose weak spots you find fast. ## What it is not This is not a change-management binder, and it is not a slogan. "People first" is not a value on a wall; it is a sequence of concrete, unglamorous acts that a leader does personally. It does not replace the [operating model](/permission-people-programs/) or the [tools](/artifacts/) you route work through. It is the human layer those things exist to serve, the layer where a transformation is actually won or lost. ## Monday morning Pick one person, one small friction, and one week. Solve it with them. Then, when it works, ask them to help the next person, and get out of the way. Teach the next group yourself, in fifteen minutes. Do not measure how many licenses you bought. Measure whether anyone works differently than they did last month. That is the whole game, and it starts with one person. ## Sources and further reading - McKinsey, [Common pitfalls in transformations](https://www.mckinsey.com/capabilities/transformation/our-insights/common-pitfalls-in-transformations-a-conversation-with-jon-garcia), on transformations stalling on the organizational and human side rather than the technology - Everett Rogers, *Diffusion of Innovations* (5th ed., Free Press, 2003), on why change spreads through respected peers and social proof rather than mandates, the basis for the ambassador move - The worked example: [Fifteen Minutes at a Time](/case-studies/fifteen-minutes-at-a-time/), an enterprise AI policy taught into behavior, one fifteen-minute session at a time --- ## [Artifact] The AI Product Partner Role Definition Canonical URL: https://translationalintelligence.com/artifacts/ai-product-partner-role-definition/ Date: 2026-09-01 Summary: 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-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. ## 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 --- ## [Artifact] The First 90 Days Canonical URL: https://translationalintelligence.com/artifacts/first-90-days/ Date: 2026-09-15 Summary: The starter plan for a sub-100-person biotech. Not a roadmap, one quarter you can run that raises your weakest pillar a level, then repeats. ## Before you start This is the quarter that follows the first move, not a replacement for it. If you have not yet picked one workflow, one owner, and two questions, [start there](/faqs/where-do-i-start/) and come back. This plan assumes you are ready to make that first move real and build a few more around it. Two rules hold the whole thing together. Give the work one owner, not a committee. And aim to raise your *weakest* pillar one level, not to touch all three. Ninety days is enough for exactly that, and no more, and that is the point. ## Days 1 to 15: Name the owner and score yourself Do not launch anything yet. Spend the first two weeks getting honest and getting an owner. - **Give it one owner.** Not a new hire. One person who already has the trust of the room and is curious about the tools, at roughly 20% of their time. The role is [a function before it is a job](/artifacts/small-team-operating-model/). - **Score the company.** Run the [Permission, People, Programs Scorecard](/artifacts/ppp-scorecard/) with your exec team, out loud. Your lowest pillar is your target for the quarter. - **Write the one page.** Put the [AI Use Policy](/artifacts/ai-use-policy/) in place: two data tiers, a few duties. Permission should take an afternoon, not a task force. ## Days 16 to 45: Ship one workflow Now make the first move real, where people can see it. - **Pick the workflow a respected person would change their Tuesday over.** Not the biggest problem. The one where a win will be noticed and believed. - **One owner, two questions.** Is this the workflow that matters, and did it actually get better. Keep it that simple. - **Open the safe door.** Give everyone secure self-serve access for Tier 2 work, with education, not a project. A surprising amount of value arrives with no program at all. ## Days 46 to 75: Turn one into a few The first win earns the next. Spend this stretch on adoption, not on scope. - **Let the person you helped bring their bigger idea.** [Solve small, and they bring you big.](/artifacts/build-vs-buy/) This is how momentum compounds. - **Recruit two ambassadors.** The respected peers in other functions who will do it in front of their teams. Behavior spreads by imitation, not by memo. - **Route new requests on purpose.** As they arrive, run each through the [five moves](/artifacts/build-vs-buy/). Resist the platform purchase. You have not earned it yet, and you may never need it. ## Days 76 to 90: Score again and set the next quarter Close the loop, then open the next one. - **Re-run the scorecard.** Did your weakest pillar move a level? If yes, the quarter worked. If no, you now know where the resistance really lives. - **Pick the next pillar.** Whichever is lowest now. Not the one you like to show off. - **Put the next 90 days on the calendar.** This is not a one-time sprint. It is the cadence, and the company that keeps running it is the one that stays [AI-native](/ai-native-biotech/). --- *Ninety days from now you will not be finished, and that is correct. You will be one level higher on the pillar that was holding you back, with an owner, a few wins, and a habit. Then you run it again.* --- ## [Issue] The Biotech of Tomorrow Canonical URL: https://translationalintelligence.com/the-biotech-of-tomorrow/ Date: 2026-07-01 Summary: You cannot build the biotech of tomorrow by making the biotech of yesterday slightly more efficient. The founding argument of Translational Intelligence. Picture the biotech that did everything right. It bought the licenses. It wrote the responsible-use policy. It ran the pilots, counted the hours saved, and put the numbers in a board deck. A year later it was faster. It was also the same company it had been the year before. Faster at the same documents. Faster at the same meetings. Faster at the same decisions, in the same order, for the same reasons. That is not transformation. That is efficiency wearing transformation's clothes. Almost everyone is in this trap. The reason is the question they started with: how can AI help us do our existing work faster? Reasonable question. It also guarantees you rebuild the past at a discount. This publication starts from a different one. What would we build if today's capabilities had existed when this company, this function, this workflow was first designed? That swap is the whole game. It is the line between an AI-enabled biotech and an AI-native one. ## The wrong debate Walk into most strategy rooms and you will hear an argument about models. Which foundation model. Which vendor. Build or buy the copilot. The choices matter. But they do not decide your future, and pretending they do has a cost. It lets everyone feel busy while the company stands still. The model is not the transformation. The organization is the transformation. And an organization is its people: their habits, their incentives, and their willingness to work a new way. So this is a cultural change before it is a technical one, and it is won or lost [people-first](/people-first/). A frontier model behind a login is not a new company. A thousand licenses are not a new company. Three hundred pilots are not a new company. Those are inputs. The output is an institution that spots a new capability, decides where it changes the work, gives people permission to act, redesigns the workflow around it, and can do it again next quarter. That chain, from raw capability to real advantage, is the product. Everything else is a demo. > [Diagram: Inputs are not the transformation] ## Why efficiency is a dead end Efficiency is seductive because it is safe. Hours saved is a clean number. It fits in a deck. It threatens no one. That last part is why leaders reach for it. Redesigning work changes who does what, who decides, and whose job was built around a limit that no longer exists. Efficiency changes the numbers without changing the powerful. So the powerful pick efficiency, call it transformation, and wonder a year later why nothing feels different. There is a deeper problem. When you automate a process, you freeze it. You take a workflow shaped by the limits of an older technology and pour concrete around it. Faster concrete. Still concrete. The handoffs, the review gates, the separations of duty that existed because information used to be expensive to move, are now fixed in place. You made yesterday permanent and called it progress. Automating a broken process does not fix it. It gives you a faster broken process. ## The honest counterargument The sharpest person in the room will push back here, and they are half right. Efficiency and transformation are not opposites, they will say. Efficiency *funds* transformation. The hours you save pay for the redesign, and the early, visible wins buy the political capital to attempt something harder. My own [People pillar](/permission-people-programs/) concedes the point: small wins build the habit that larger change stands on. All of that is true, and none of it rescues efficiency as a destination. Efficiency is the on-ramp. The mistake is never *starting* there. The mistake is *stopping* there, banking the hours, and reporting the destination as reached. Efficiency that funds a redesign is the first move of a transformation. Efficiency that funds next year's slightly faster version of the same company is a dead end with good margins. The test is not whether you took the efficiency win. Take it. The test is what you spend it on. [Naming the size of the change](/scope-ladder/) is how you tell the two apart: a faster workflow is one honest rung, and mistaking that rung for the whole climb is the trap this whole publication is trying to help you avoid. ## What AI-native means Not a company where machines do everything. That is a boring fantasy. An AI-native biotech is built on an honest read of what people do well, what machines do well, what software can now carry, and how freely information can move when moving it costs almost nothing. It keeps asking hard questions about its own design. Should this workflow exist as it does, or only because it always has? What still needs to be separate now that one system can hold all of it at once? Which decisions could happen earlier, with better evidence, if the right person saw the right thing in time? Where does human judgment matter more, not less? None of those are questions about a model. They are questions about the institution, which is to say its people. The technology is the catalyst. The people are what change, and a culture that keeps changing is what makes it hold. So here is Monday morning. Pick one workflow that matters. Not the easy one. Not the one with the loudest AI request. One that carries real weight for the science or the business. Ask two questions. If we designed this today, knowing what these systems can do, what would we build? And what is actually stopping us, a hard constraint or a habit we inherited? The gap between those answers is your transformation. Everything else is a purchase order. ## The map [Translational Intelligence](/translational-intelligence/) is the capacity to turn new capability into durable advantage, again and again, as the technology keeps moving. That is the whole idea in one line. This publication builds it out. The system that creates the capacity is [Permission, People, and Programs](/permission-people-programs/). Permission is knowing where you are allowed to move. People is behavior change, the hardest and most decisive part. Programs is what you self-serve, buy, build, or redesign. The role that makes it real is the [AI Product Partner](/ai-product-partner/), the person who sits where capability meets the work and turns one into the other. The destination is the [AI-native biotech](/ai-native-biotech/), the company that never stops translating, with no final form to reach. Over the coming weeks I will take each of these apart, one issue at a time, with the frameworks and the language to use them. This is the argument the rest is built on. ## Why I am doing this I have spent more than a decade in AI, most of it back when biotech saw it as a lab tool and nothing more. That era is over: an AI-discovered, AI-designed drug has now [read out a positive randomized Phase 2 trial in patients](https://www.nature.com/articles/s41591-025-03743-2). The last five years I have spent inside organizations, rebuilding them to meet the technology of today with an operating model built for tomorrow. Pandemic response at Google. A genotype-to-phenotype engineering team at Colossal. Enterprise AI transformation at Avidity. The same charge now at Alloy, through Vigilance. Different missions. Same work. And the same lesson every time: the technology is the easy part, and the human part is most of the job, by a wide margin. People call my strategies surprisingly practical. The first time, it was a small dig, a way of saying they sounded too simple to matter. The next conversation, that person had tried it, and they had learned how hard simple is. Now we talk all the time about the human part, because that is where transformation is won or lost. I get asked how to start almost every day. I want to help all of you, but I cannot sit with everyone. So this is my answer at scale. Nothing held back, nothing confidential. The gig is up. The edge was never a secret formula. It was the willingness to do the hard, human work of change, and then to do it again. I called this translational intelligence on purpose. Because the more intelligently we all operate, the faster we translate science into therapies. --- ## [Issue] There Is No AI Work Product Canonical URL: https://translationalintelligence.com/there-is-no-ai-work-product/ Date: 2026-07-02 Summary: The first thing every leader asks is what their AI policy should be. The whole answer fits in one sentence, and it moves accountability to exactly one place. The first thing almost everyone asks me is a version of the same question. What should our AI policy be? They are bracing for a long document, a committee, a quarter of legal review before anyone is allowed to touch a tool. Here is the whole thing in one sentence. There is no such thing as an AI work product. There is only AI-assisted human work product. ## It does not matter who drafted it Read that again, because it decides everything else. The person whose name is on the work owns all of it. Every fact, every number, every claim. It does not matter whether they wrote it, a colleague wrote it, or a chatbot wrote it. The author of record is accountable, completely, for what they hand over. A federal court has already put this in writing. In *Mata v. Avianca*, sanctioning lawyers who filed a brief full of AI-invented case citations, Judge P. Kevin Castel [drew exactly this line](https://reason.com/volokh/2023/06/22/sanctions-issued-in-case-where-lawyers-cited-chatgpt-hallucinated-precedents/): there is nothing improper about using a reliable AI tool for assistance, but the rules "impose a gatekeeping role" on the human "to ensure the accuracy" of the filing. The tool was fine. The accountability never moved. > [Diagram: One accountable human] ## The fear that melts This is the part that moves mountains. The moment accountability sits with the human, the fears that freeze companies lose their grip. Hallucinations. Uneven quality. A confident, fluent, wrong answer. None of these are new. They are the ordinary hazards of any first draft from any source, and you already know how to handle them, because you read the work before it leaves your hands. A chatbot is a fast, tireless, sometimes-wrong colleague. You would not send a junior analyst's memo to the board unread. Treat the machine's output the same way, and suddenly you can use it for far more, far faster, because you are the backstop, and you always were. ## Two tiers of data Everything else is logistics. Most of what people call an AI policy is really a data policy, so keep it simple enough to hold in your head. The sensitivity of the information decides the environment it is allowed to enter. Tier 1 is confidential: unpublished results, program data, patient information, anything not yet public. It goes only into contracted, enterprise-secure environments you have approved for that class of data. Tier 2 is open: anything public, or that safely could be. There the default is yes, so explore. That is the whole model, and if someone cannot say which tier a thing belongs to, that is a classification question to answer first, not a reason to freeze. To see all of this wired into a single tool, both the author-of-record rule and the data tiers, read [The 72-Hour Transcript](/case-studies/the-72-hour-transcript/). ## The question you have to answer The hardest part hides inside Tier 1, and it is not technical. It is whether you trust your own contracts. If you hold an enterprise agreement that a vendor will not train on or keep your data, then you have already made the decision. Trust it, and let people work. Reopening that debate on every single use is not caution. It is paralysis dressed as diligence. Responsible innovation means you do not relitigate settled questions out of principle. And if you genuinely do not trust the agreement, then be honest with yourself: you do not have a tooling problem, you have a [Permission](/permission-people-programs/) problem, and the work is on the front end, choosing terms you can stand behind. Do that once. Then get out of the way. ## Write it on one page So write your policy, and write it short. The few duties that come with total accountability are simple: verify before it leaves you, name the human on consequential work, disclose where it is material, and ask early when unsure. You do not have to start from a blank page. > Artifact: [A Lightweight AI Use Policy](https://translationalintelligence.com/artifacts/ai-use-policy/) Here is Monday morning. Do not commission a policy. Write the sentence at the top of a blank page, there is no AI work product, only AI-assisted human work product, and then add only what you need underneath it: which data goes where, and who to ask when in doubt. If your draft runs past a page, you are writing to cover yourself, not to help your people. The shortest honest policy is the one that gets read, and the only one that lets the work move. --- ## [Issue] Stop Swinging for the Fences Canonical URL: https://translationalintelligence.com/stop-swinging-for-the-fences/ Date: 2026-07-03 Summary: In the AI era the build-versus-buy line leans toward build, and the temptation is to only build big. But adoption is the game, and the smallest builds are how you win it. You have been in the meeting. The one where a team debates a big AI platform for a year while the small, obvious win, the thing that would make one scientist's week better, sits unbuilt because it is not strategic enough to bother with. That instinct is expensive, and in the age of AI it is backwards. ## The line moved toward build Start with what changed. For most of software history the safe money said buy. Building was slow, expensive, and risky, so you bought the commodity and reserved building for the few bets that would define the company. That wisdom has not vanished, but the line it drew has moved, hard, toward build. AI made building faster and cheaper than it has ever been. A focused tool that used to be a two-quarter project is now a week. So when you reach for a vendor out of habit, stop and ask whether a small, sharp build would be faster than the buying cycle it would replace. ## The trap is only building big Here is the subtle part. Once people accept that they can build, they only want to build big. They swing for the fences. The platform. The flagship. The strategic bet that will look good in a board deck. And while they spend a year designing it, the hundred small problems people have every day go unsolved. In an AI-native company, adoption and change are the entire game. A brilliant platform nobody adopts changed nothing. A tiny tool a scientist reaches for every morning changed how the work happens. [Permission, People, Programs](/permission-people-programs/) already told you the hardest part is behavior, not deployment. This is that same truth, pointed at your build list. It is Ethan Mollick's finding as well: in his account of what actually moves an organization, the gains come from ["The Crowd,"](https://www.oneusefulthing.org/p/making-ai-work-leadership-lab-and) the employees who figure out how to use AI on their own everyday work, not from the flagship platform. ## Solve for one, unlock the institution > [Diagram: Solve small, unlock the institution] So solve small, on purpose. Take the unglamorous problem one person has and fix it this week. Then something happens that no roadmap predicts. That person trusts the tool, and they trust you, and they come back with a bigger idea than they ever would have raised before, because now they believe it is possible. Solve for one individual's real need, and you unlock the larger thinking that solves the institution's. The small build is not a distraction from the strategic work. It is how you earn the trust and the momentum to do the strategic work at all. ## Which is which None of this means build everything. You still buy the commodity, the system of record no one wins on, and you do not write your own cloud or your own lab notebook. The discipline is knowing which is which, and where the line sits this year. I put it on one page. > Artifact: [The Build-vs-Buy Decision Framework](https://translationalintelligence.com/artifacts/build-vs-buy/) Forget your AI strategy for a week. Find the smallest real problem a good person on your team keeps hitting, the one too small to have made any roadmap, and solve it this week. Then watch what they bring you next. That is not a detour from transformation. That is where it starts. --- ## [Issue] Don't Automate the Struggle Canonical URL: https://translationalintelligence.com/dont-automate-the-struggle/ Date: 2026-07-05 Summary: The fear that AI will atrophy how we think is real, but only if you use it to replace the struggle. Update your mental model instead, and the same tool makes you think harder, not just write faster. I was talking with a group of academics about how I use AI to write, and their worry was not plagiarism, or disclosure, or whether the prose can be detected. It was deeper. If we let AI help us write, will we slowly lose the ability to think? It is a fair fear, and it deserves a real answer. Writing is not the packaging around a finished idea. Often, writing is how the idea comes to exist. You start with an intuition, try to explain it, find it does not quite hold, revise, hit a contradiction, and arrive somewhere you could not have named when you began. The friction is the work. An AI can erase that friction in seconds. Hand it a half-formed thought and it returns a clean thesis, three tidy arguments, and a conclusion that gestures confidently at the future. That can feel like progress. Sometimes it is. Sometimes it is only *premature coherence*, an idea made to sound finished before it has earned it. ## The fear is real, but it aims at the wrong thing Here is what the fear gets right. If you use AI to replace the struggle, the struggle atrophies. Outsource the part where you work out what you actually mean, and that muscle weakens, exactly as the academics worry. Cognitive scientists have a name for what they are protecting: [desirable difficulties](https://bjorklab.psych.ucla.edu/wp-content/uploads/sites/13/2016/04/EBjork_RBjork_2011.pdf), the finding that the conditions which slow apparent progress are often the ones that build durable understanding. But that is a fact about a mental model, not about the tool. The atrophy comes from replacing how you think. It does not come from updating how you think. Change the model, and the same machine does the opposite. Used to finish your thought, AI makes you lazier. Used to make your thought *harder to finish badly*, it makes you sharper. The goal was never to have the machine complete your idea. It is to keep your idea from closing too soon. ## Expand the problem before you compress the answer Most people ask AI to synthesize far too early. They want the outline, the argument, the draft, before they have walked the whole terrain of the idea. That is the move that hollows out thinking. Do the opposite. Before you ask AI to write a word, ask it to make the problem harder. > [Diagram: Expand, then decide] What am I assuming? What is the strongest case against this? Where would an expert call it naïve? Which parts are genuinely mine, and which are familiar ideas in new clothes? What is the most uncomfortable implication if it is true? What would change my mind? Those are not drafting prompts. They are thinking prompts. A good model will hold several competing readings at once, generate objection after objection without getting defensive, and pull in a field you would not have thought to check, long after a human colleague would have gone home. That does not make it wiser than a person. It makes it fast, available, and relentlessly patient. Point those traits at friction instead of away from it, and you leave the conversation with a more complicated understanding than you arrived with, and a sharper claim because of the complication. ## Then choose what you believe After the terrain, one decision cannot be delegated. What do I actually believe? AI can lay out theses and tell you which is most defensible or most provocative. It cannot tell you which one you are willing to stand behind. Before you draft, say the claim in your own words: what you believe, why, what would make it false, and why it matters. Only then is drafting useful, because now the machine is building the road, not choosing the destination. ## Keep the tells out, and keep some work by hand When you do draft with AI, strip the tells. Not a list of forbidden words, the structural habits: the sweeping opener about a fast-changing world, the tidy rule of three, the false binary, the transition that only transitions, the uplifting abstraction where a concrete conclusion belongs. AI prose feels synthetic because every sentence performs its job too visibly. The cure is texture and judgment, not a banned-word list. Ask one thing of every draft: could any competent person with the same prompt have written this? A piece can be clean and still be nobody's. And keep some of the work manual, on purpose. Write the first ugly paragraph yourself. Sit with a contradiction before asking the model to resolve it. Read the primary source before you request the summary. Calculators did not end arithmetic and GPS did not end knowing where you are, but the more powerful the tool, the more deliberately you have to keep the capacity to judge what it hands you. Call it cognitive maintenance. ## The one test There is a single test for whether AI accelerated your thinking or replaced it. Could you defend every major claim to a skeptical expert, explain where the idea came from, name its weak points, and say where your thinking changed, without leaning on the generated text? If yes, the tool sharpened you. If no, it stood in for you. That is the same standard as everything else here: [there is no AI work product, only AI-assisted human work product](/there-is-no-ai-work-product/), and you own all of it. > Artifact: [The Think-Harder Writing Workflow](https://translationalintelligence.com/artifacts/think-harder-workflow/) ## Update the model, not just the tools This is the cognitive version of being [AI-native](/ai-native-biotech/). The AI-native company does not run its old assumptions faster, it asks which assumptions still deserve to exist. The AI-native thinker does the same with their own mind. Do not hand AI the struggle to work out what you mean. Hand it everything that gets you to that struggle sooner, and more often, and you will not lose your capacity to think. You will have more of it. Take an idea you have been circling, and do not ask AI to write it up. Ask it to attack it. Make it list your assumptions, argue the other side, and name the implication you have been avoiding. Then close the laptop and write the first paragraph yourself. The blank page was never sacred. The struggle to decide what you mean is. Automate your way to more of that struggle, and guard the struggle itself. --- ## [Issue] Excellent and Generic Canonical URL: https://translationalintelligence.com/excellent-and-generic/ Date: 2026-07-06 Summary: You can think hard, land a real argument, and still produce prose that sounds like a machine made it. Polish is one thing. Whether the writing could only have come from you is another. You can do everything right. Start with your own idea, think it through, pressure-test it, land an argument that is genuinely yours. And the writing can still come out sounding like a machine made it. Not wrong. Not clumsy. Just generic. Nobody's. That is the failure most people do not see coming, because it does not look like failure. It looks like a clean, competent, publishable draft. Thinking hard about what you mean is the first half of the job, and I have written about [not automating that struggle](/dont-automate-the-struggle/). This is the second half. Even when the idea is unmistakably yours, the prose can still belong to no one. ## Excellent and generic Here is the uncomfortable pair. A piece can be excellent and still be generic. Those are not opposites. Polish measures one thing. Whether the writing could only have come from you measures another entirely. > [Diagram: Excellent and generic are two different axes] The trap is the top-left corner: excellent and generic. Fluent, well-organized, and completely interchangeable with what any competent person would have produced from the same prompt. The convergence is measurable: in a controlled study, [generative AI raised individual creativity but reduced the collective diversity](https://doi.org/10.1126/sciadv.adn5290) of what people wrote, each piece drifting toward the same middle. The goal is the opposite corner, and getting there is not about writing better. It is about writing like *someone*. ## Why it all sounds the same AI prose is recognizable, but not because it reaches for a secret set of forbidden words. The tell is structural. The sweeping opener about a fast-changing world. The tidy rule of three. The false binary, this is not merely X, it is Y. The heading that just restates the thesis. The uplifting abstraction where a concrete conclusion belonged. Every tension resolved a little too cleanly. No one of those is a crime, and human writers use all of them. The problem is accumulation. AI prose feels synthetic because every sentence performs its job too visibly. The transitions transition. The emphasis emphasizes. The conclusion concludes. Real writing has more variance. It lingers in some places and moves abruptly through others, and it trusts you to fill a gap now and then. ## Voice is a pattern of decisions The usual fix makes it worse. People hand the model a list of adjectives, clear, smart, conversational, concise, and wonder why the output sounds like everyone else who wanted to sound clear, smart, conversational, and concise. Voice is not an aspiration. It is a pattern of decisions. What you notice first. How you build an argument. Where you place the tension and how long you hold it. Which comparisons you reach for, and which you would never make. What you refuse to exaggerate. Which sentences feel dishonest coming from you. You cannot describe that from memory and expect a model to reproduce it. You *derive* it from evidence. Feed it several things you wrote yourself, from different rooms, and have it find the patterns. Then correct what it finds, because it will grab the surface first. Every correction, "I would never say that," "cleaner, but less true," is you making your taste explicit. That accumulated judgment is worth more than any prompt. ## The one test There is a single question that catches all of it. Could any competent person with the same prompt have written this? If the honest answer is yes, the piece is generic however polished, and the fix is not more editing. It is to reclaim the passages that carry your judgment, the opening, the central claim, the turns, the ending, and write those in your own hand. I put the rest of it, the negative rules, the tells, the way to derive a voice from evidence, on one page. > Artifact: [How to Write With AI Without Sounding Like It](https://translationalintelligence.com/artifacts/ai-writing-style-guide/) Run the one test on something you are proud of. Take a piece AI helped you write, read it, and ask whether anyone with your prompt would have produced the same thing. Where the answer is yes, that paragraph is not yours yet. Rewrite it until it could only have come from you. That is the whole difference between using the tool and being replaced by it, and it usually lives in about four paragraphs a piece. --- ## [Issue] Your Edge Was Never the Model Canonical URL: https://translationalintelligence.com/your-edge-was-never-the-model/ Date: 2026-07-07 Summary: Whichever model leads this quarter, you rent. The thing worth owning sits underneath it, the capacity to turn whatever arrives into how your company works. Every few months a new model takes the lead, and every few months a wave of companies rebuilds its AI strategy around it. Both moves are a mistake. The model that is ahead today will not be ahead for long. If your advantage is the model, you rent your advantage, and the rent resets every quarter. Whoever is on top next quarter, you will be renting from them instead. The independent analyst Benedict Evans makes the same case about where advantage really sits. [Every week there is a new model](https://www.ben-evans.com/benedictevans/2025/1/the-problem-with-better-models), he writes, and a better base model is not itself the edge. The durable differentiation lives in the tooling, the process, and the product you wrap around it, not in the model you happen to be renting this quarter. The thing worth owning is underneath. It is the capacity to take whatever new capability arrives and turn it into how your company actually works. That capacity has a name. > [Diagram: The model is rented; the capacity is owned] The capacity is [translational intelligence](/translational-intelligence/): the institutional ability to convert emerging capability into durable advantage, again and again. Read that word institutional twice. It is not a skill one brilliant person has, and it is not a team you stand up in a corner of the org chart. It is something your company can do, as a company, and keep doing as the ground shifts under everyone. The advantage is not the model. It is the capacity to keep translating. ## Why this reframes the whole conversation A frontier model behind a login is not transformation. A thousand licenses are not transformation. Between what becomes newly possible and what your institution can actually do sits a gap, and that gap is where most transformation dies. Closing it, over and over, is the entire job. The model is a catalyst. The organization is what changes. That is also why the buying question, which vendor, which model, matters less than the room thinks. You can buy every input on the market and be the same company next year, only with a larger software bill. What you cannot buy, and what compounds, is the capacity itself. ## Where it breaks The work runs along a chain, from raw capability to permission to behavior to workflow to decision to advantage. Each link is a place the translation can fail. And experience keeps teaching the same lesson: most companies break at behavior and workflow, not at capability. They have the tools. They do not have the habits or the redesigned work. So they pour money into the first link and wonder why nothing moves at the last. Stop asking which model. Take the chain and walk your own organization along it until you find the link that breaks. It is almost never the one you are spending on. Fix the real link, not the visible one. The full argument, and the whole chain, is on [Translational Intelligence](/translational-intelligence/). --- ## [Issue] The One-Lever Mistake Canonical URL: https://translationalintelligence.com/the-one-lever-mistake/ Date: 2026-07-08 Summary: A company gets serious about AI and reaches for one lever. A year later the lever moved and the company did not. It takes three pillars, and they grow together or not at all. A company decides to get serious about AI, and it reaches for one lever. It buys the licenses. Or it writes the policy. Or it ships a tool. A year later, the lever moved and the company did not. The mistake is not the lever. Each one is fine. The mistake is thinking any one of them is a strategy. > [Diagram: One lever versus three pillars] The system that builds the capacity is [Permission, People, and Programs](/permission-people-programs/). Permission is the space to move: knowing where you are allowed to act, with which data, under whose accountability. People is the capacity to move: whether anyone actually changes how they work. Programs is the capability itself: what you self-serve, buy, build, or redesign. ## They are not phases The three are easy to say in order, so people run them in order. Finish the policy, then train the people, then start the programs. That sequence fails, because these are not phases. They are dimensions of the same thing, and they mature together. Better Permission lets your people move faster and with more confidence. More capable people find and adopt better Programs, because they can see the openings in their own work. Programs surface new risks that send you back to sharpen Permission. You never finish one. You grow all three, and you grade yourself on all three. ## The pillar that decides it If you have to start somewhere, start where you are weakest, not where you like to show off. And the weak one is almost always People, because behavior is the hardest and least visible part of the whole enterprise. A license is not adoption. Someone can have the tool, the training, and the policy in front of them and still work exactly the way they did last year. That is why a clean policy on top of unchanged behavior has transformed nothing. The model is a catalyst. The organization is the transformation, and the organization is people. Independent research lands in the same place. Analyzing where AI value actually comes from, [BCG puts it at ten, twenty, seventy](https://www.bcg.com/publications/2025/closing-the-ai-impact-gap): roughly ten percent of the work is the algorithms, twenty percent the data and technology, and seventy percent the people and process. The lever everyone reaches for is the ten. Grade yourself this week, honestly. Score your company on Permission, People, and Programs, and start on the one you scored worst, not the one that would look best in a deck. The full operating system is on [Permission, People, Programs](/permission-people-programs/). --- ## [Issue] Audit Yourself in Public Canonical URL: https://translationalintelligence.com/audit-yourself-in-public/ Date: 2026-07-11 Summary: The strongest test of a system is whether its author will use it, in the open, with the gaps left in. So I ran this publication against its own rules. The strongest test of a system is not whether it sounds good in a deck. It is whether its author will use it, on their own work, in public, where the gaps show. Most companies fail that test quietly, and for one reason: they never wrote their rules down. A rule you have not written is a rule you cannot be held to. It is a preference, and preferences bend under pressure. > [Diagram: Written rules make gaps small and findable] This publication was built on its own written rules, so I did the honest thing and audited it against them before I recommended you do the same. I found real gaps. The founding piece had no signature diagram, though the standard says every Issue carries one. And for a publication about using AI well, there was no disclosure anywhere that the work is AI-assisted, though I preach disclosing exactly that where it is material. Neither was a catastrophe. That is the point. When you hold yourself to a standard you wrote down, the gaps come out small and findable, instead of large and hidden. A company that never audits itself does not have fewer gaps. It just has not looked, and the gaps it is not looking at are the large ones. ## What a real audit looks like Take the work you are proudest of, the AI strategy you would put in front of your board, and check it against your rules, line by line. Where did you break your own standard? Then close the gap, because a rule only means something if the gaps get fixed, not just noted. And do it in the open. A case study that shows only the wins is exactly the premature coherence worth distrusting. The willingness to publish the gaps is the whole signal that the system is real. I wrote the full accounting up as the first case study, the system applied to the thing you are reading. Here is Monday morning. Write your rules down, if they are not already. Then run your loudest AI work against them and fix the smallest gap you find this week. The full self-audit is [Built by Its Own Rules](/case-studies/built-by-its-own-rules/). --- ## [Issue] There Are Only Five Moves Canonical URL: https://translationalintelligence.com/only-five-moves/ Date: 2026-07-12 Summary: Every AI request feels unique. It is not. There are only five things you can do with any of them, and most of the discipline is routing each to the right one on purpose. Every AI request that lands on your desk feels like its own special problem. It is not. Strip away the framing and there are only five things you can do with any of them. Self-serve it. Buy it. Build it. Redesign around it. Or do nothing. That is the whole menu. Most of the discipline is not deciding whether to act. It is routing each request to the right one of the five, on purpose, instead of defaulting to whichever move your culture reaches for by reflex. > [Diagram: Route each request through five moves, in order] The order matters, because it runs from the lightest touch to the heaviest commitment, and the honest answer is usually lighter than the move you reach for by reflex. Can people already do this with tools you have? Self-serve it, with training and guardrails, not a project. This is the cheapest real intervention there is, and a surprising amount of value arrives right here, with no project at all. Is the real fix a different workflow rather than a tool? Redesign it, because speeding up a broken workflow just gets you to the wrong place sooner. Is there a strong vendor for a capability the whole market shares? Buy it, and do not rebuild a commodity out of pride. Is it genuinely yours, on your data and your workflow? Then build it, the heaviest commitment on the list, and the one that has to be earned. And if the value is thin or the problem is not real, do nothing. That is the escape hatch, not part of the ramp: it costs the least of anything here, and choosing it on purpose is how you protect your attention and your credibility. Most requests never reach build. That is the point. Build is the last stop, not the first reflex, and routing on purpose is what keeps a company from pouring its scarce engineering into the wrong four moves out of five. The logic is older than AI. Geoffrey Moore, who coined the distinction, calls it [core versus context](https://hbr.org/2004/07/darwin-and-the-demon-innovating-within-established-enterprises): put your scarce resources into the core, the work that differentiates you, and standardize, outsource, or automate the context, which is everything else. Build is for your core. The other four moves are how you refuse to spend it on context. The failure is rarely choosing wrong. It is not choosing at all: letting every request default to a pilot, or a purchase, or a custom build, because that is what the room always does. Say the five out loud, for each request, in front of the people who own the work. > Artifact: [The Build-vs-Buy Decision Framework](https://translationalintelligence.com/artifacts/build-vs-buy/) What is the loudest AI request in your queue right now? Route it out loud through the five, in order, in front of the person who owns it. Notice how far down the list the honest answer sits. It is rarely where you started. The full discipline is on [Buy the Record. Build the Intelligence.](/buy-record-build-intelligence/) --- ## [Issue] An Afternoon, or a Restructure Canonical URL: https://translationalintelligence.com/an-afternoon-or-a-restructure/ Date: 2026-07-13 Summary: The word transformation hides five different sizes of change, from a habit you can build before lunch to a company you have to take apart and rebuild. Naming the size is most of the work. Someone tells you they are transforming their company with AI, and you have no idea what they mean. They might mean they built a habit last Tuesday that gives them back an hour a day. They might mean they took their whole org chart apart and rebuilt it around how the work actually happens now. Those are not the same project. They do not share a budget, a timeline, a risk profile, or even the same person's signature. But we file both under one word, *transformation*, and the word does most of the damage. It lets a drawer full of clever habits pass for a strategy, and it lets a strategy deck stand in for a drawer full of habits nobody has built yet. There are five sizes. Each one is roughly an order of magnitude more scope, more time, and more risk than the size below it. The smallest fits in an afternoon. The largest is a restructuring you will live inside for the better part of a year. > [Diagram: The five scopes nest inside each other] ## The five sizes **One. The Personal Practice.** You, one habit, one afternoon. You find a way to use a model that quietly changes how you spend an hour of your day. The productivity is almost beside the point. The real product is *belief*: you, or a respected colleague, doing the thing in front of everyone else, which is how adoption has always actually spread. A century of research on how new practices move through a group says the same thing, that it starts with a few credible people and their social proof, not with a mandate ([Rogers, *Diffusion of Innovations*](https://open.ncl.ac.uk/theories/8/diffusion-of-innovations/)). This rung looks trivial. It is the one everything else stands on. **Two. The Workflow.** One process, re-run a different way. Days to weeks. Here is the first real trap. The temptation is to bolt a model onto the process you already have and call the faster version a transformation. Michael Hammer named the mistake more than thirty years ago and it has not aged a day: [don't automate, obliterate](https://hbr.org/1990/07/reengineering-work-dont-automate-obliterate). Speeding up a broken workflow only gets you to the wrong place sooner. The move is to ask what you would build if you designed the process today, knowing what these systems can now do, and then close the gap to that. **Three. The Amplified Role.** One person's whole responsibility stack. Weeks to months. Not one of their tasks, all of them: the regulatory lead, the head of clinical operations, the founder wearing four hats. You go deep on everything one person owns until the role itself works differently. This is the vertical move, and it is often where a small company gets its first real leverage, because in a small company one amplified role is a meaningful fraction of the whole. **Four. The Re-formed Function.** A whole team's work, all at once. A quarter. The horizontal twin of the amplified role: not one person going deep, but a function changing across the board. The entire regulatory group, all of clinical operations. This is where it stops being personal and starts being an operating decision, because now other people's work depends on the change holding. **Five. The Re-Aligned Enterprise.** The company rebuilt around how the work is actually done now. Multiple quarters. New reporting lines, new decision rights, new definitions of whose job is what. This is the rung everyone points at when they say the word, and it is the rung almost nobody reaches, because most companies announce it before they have built a single one of the rungs below it. The data is blunt: across a large annual survey, only around seven percent of organizations report AI that is fully scaled, and the blockers are not the models, they are workflow rigidity and operating-model inertia ([McKinsey, *The state of AI*](https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai)). ## They are not five buckets. They nest. Look at the diagram again. These are not five separate options on a menu. Each one is *built out of* the one inside it. A workflow is a bundle of habits. A role is a bundle of workflows. A function is a bundle of roles. The enterprise is a bundle of functions. The ladder is not five different projects. It is the same unit of change, composed upward. That is why the order is not optional. Rung five is *literally made of* rung four, which is made of rung three, and so on down. A re-aligned enterprise with no re-formed functions inside it is an org chart with nothing running in it. You cannot restructure your way to habits nobody has built. You compose your way up. ## The two ways to get it wrong Almost every company gets the scope wrong in one of two directions. They think too *small*: a drawer full of clever personal practices, a team that is quietly good at prompting, and nothing that has changed at the level of a process or a role. Real, useful, and invisible on any measure the board cares about. Or they think too *big*: a rung-five announcement, a transformation office, a slide that says the company will be AI-native by a date, and underneath it not one workflow that runs a new way. That is how a strategy becomes a pilot in purgatory. The discipline is to name the rung honestly, pick the largest one you can actually make real this quarter, and then climb. It is the same lesson as [solving small to unlock the institutional](/stop-swinging-for-the-fences/): the point of the small rung is not the small rung, it is that it is the only honest way to reach the big one. ## Scope is one axis of three The ladder tells you *how much* has to change. That is one axis, and it is silent on two others that matter as much, so the case studies against this ladder are tagged on all three. *Scope* is the rung, from individual to enterprise. *Intervention* is how you did it: enablement, governance, automation, workflow redesign, a product, infrastructure, or organizational redesign. *Outcome* is the win, and there is more than one: efficiency, risk reduction, decision quality, new capability, or translational capacity, the rate at which the whole institution turns science into therapies. The outcome axis has more than two values because the cases forced it. Squeezing every one into efficiency or new capability distorted the evidence: a policy taught to a whole company is enablement whose payoff is translational capacity, not an hours-saved efficiency play, and a trivial automation whose real result was belief is not measured in hours. For a biotech the outcome that matters most is the last one. Efficiency gives you back hours. New capability and translational capacity give you science you could not otherwise do, which is the only kind of win that reaches a patient. One honest caveat for clinical-stage readers. Every rung here lives *inside* your company, and yet [most of your science lives outside it](/artifacts/clinical-stage-ai-map/), across your CROs and CDMOs. Changing how work flows across that boundary is a scope of its own, above the enterprise and harder than all of it, because you do not control the people on the other side. We will get there. Build the rungs inside your walls first. ## Monday morning Take the loudest AI initiative in your company right now, the one with a name and a champion. Say out loud which rung it actually is. Not which rung it was announced as, which rung it *is*: a habit, a workflow, a role, a function, or the whole company. Then ask the only question that matters. Is the rung below it real yet? If you are aiming at a re-formed function but no single role inside it has been amplified, you have found your real starting point, and it is one rung lower than you thought. Start there. That is not a retreat. That is how you build something that holds. The full framework, the five rungs and the two axes, lives on [The Scope Ladder](/scope-ladder/). --- ## [Issue] You Can't Fix What You Won't Grade Canonical URL: https://translationalintelligence.com/cant-fix-what-you-wont-grade/ Date: 2026-07-13 Summary: Most leaders run their AI transformation on anecdote and vibes. The fix is a one-page scorecard, and the hard part is not the scoring. It is being honest about the pillar that flatters you. Ask a leadership team how their AI transformation is going and you will hear a story. A pilot that went well. A team that loves the new tool. A policy that finally got signed. What you will almost never hear is a number, because most companies are running the whole thing on anecdote and vibes, and anecdote always flatters the teller. You cannot fix what you will not grade. So grade it. Not the whole sprawling thing at once, but the three pillars that decide whether AI changes how you work: [Permission, People, and Programs](/permission-people-programs/). Score each one from zero to three, in a room, with the people who own the work. It takes fifteen minutes, and it ends the storytelling. > [Diagram: You are only as native as your weakest pillar] Here is the rule that makes the score honest. You do not average the three. Your true level is your *lowest* pillar, because the three grow together or none of them grows. A company with a signed policy and a shelf of licenses and no one changing how they work is not two-thirds transformed. It is stuck, with good governance on top. The tallest pillars do not carry the short one. The short one sets the ceiling. And the scoring is where the honesty gets tested, because two mistakes are almost universal. Leaders over-score Permission, because writing a policy feels like progress and it threatens no one. And they under-score nothing so reliably as People, because behavior is the hardest and least visible thing in the building to change. If your Permission score comes in high and your People score comes in low, you are not behind. You are *normal*. You have just found where the work is, which is the entire point of grading. The move after that is small on purpose. You do not launch a program against all three pillars. You take the lowest one and raise it a single level this quarter. Then you put a date on the calendar and grade again, and now you are running a transformation on evidence instead of on the best story someone told in the last meeting. > Artifact: [The Permission, People, Programs Scorecard](https://translationalintelligence.com/artifacts/ppp-scorecard/) Here is Monday morning. Put the three pillars on a whiteboard and have each of your leaders score the company privately, zero to three, before anyone speaks. Then compare. The spread between your highest scorer and your lowest is its own diagnosis, and the pillar you argue about most is usually the one you have been avoiding. Start there. The full model, and where to point the first move, is on [Permission, People, Programs](/permission-people-programs/). --- ## [Issue] You Already Employ Your AI Product Partner Canonical URL: https://translationalintelligence.com/already-on-your-team/ Date: 2026-07-16 Summary: Every small-company leader hits the same wall. The role sounds essential and sounds like a hire they cannot make. It is not a headcount. It is a function, and the person with the right shape is already in the building. Every small-company leader who reads about [the AI Product Partner](/ai-product-partner/) arrives at the same wall. It sounds essential, and it sounds like a hire they cannot make. Fifty people, clinical-stage, runway to protect, and no room on the org chart for a new senior role whose value they cannot yet prove to a board. So they file the idea under later, and later never comes. The wall is built from a single wrong assumption: that the AI Product Partner is a headcount. It is not. It is a function, and a function does not need its own full-time body until it outgrows a fraction of one. At your size the whole role is about 20% of a person you already employ, and the move that matters is not posting a job. It is naming the person. > [Diagram: The right owner is already on your team] The person has a shape, and the shape is not a title. They are trusted by their peers, curious about what the tools can now do, and broad enough to see across the whole company rather than down into one function. That is often a chief of staff or a head of operations, usually not your most technical person, because the job is translation and trust rather than engineering. And it is almost never an outside hire, because the hardest part of this work is changing how respected colleagues do their jobs, and that kind of trust does not transfer with an offer letter. What the 20% does is not mysterious. They score the company, own the one-page policy, find the one workflow worth changing, route new requests instead of defaulting to a purchase, and recruit the peers everyone copies. What they do *not* do matters just as much. They do not stand up a committee, buy a platform before shipping a workflow, or wait for a strategy to arrive from somewhere else. Hiring feels like commitment, and commitment feels like seriousness. But at fifty people, the serious move is the small one. Name the function, give it a fifth of the right person's week, and let it earn its way to a full-time job by outgrowing the fraction. Most companies at this size never need the hire. They need the *owner*. > Artifact: [The Small-Team Operating Model](https://translationalintelligence.com/artifacts/small-team-operating-model/) Skip the requisition. Write down the three people on your team with the right shape, and have the honest conversation with the first one this week. Give them a fifth of their time and the [scorecard](/artifacts/ppp-scorecard/) to start with. You are not adding a head. You are naming an owner who was in the building the whole time. --- ## [Issue] When Your Science Is Outsourced Canonical URL: https://translationalintelligence.com/when-your-science-is-outsourced/ Date: 2026-07-17 Summary: Most AI-in-biotech advice pictures a discovery lab. If you run a clinical-stage company, your bench is at the CROs, and your real surface area is writing, reviewing, submitting, and oversight, under rules written to protect patients. Most writing about AI in biotech, some of mine included, pictures a company with its science in the building. Assay data on the servers, models trained on your own experiments, a discovery engine to make faster. If you run a clinical-stage company, that picture is not yours. Your bench is at the CROs. Your molecule is in trials you monitor rather than run. And your company, the part with employees and deadlines and risk, is something else entirely. It is clinical operations, regulatory, medical writing, safety, and vendor oversight. That is where your people spend their days, and it is where AI actually touches your company. So the question is not how AI changes your lab. It is how AI changes a company that mostly writes, reviews, submits, and oversees, under rules written to protect patients. And that runs straight into the validated environment, which is exactly where most leaders assume AI cannot go. > [Diagram: Two lines decide where AI can help in a clinical-stage company] Two lines decide where AI can help, and neither is the wall people imagine. The first is the data class you already know from your [AI Use Policy](/artifacts/ai-use-policy/): patient data and unfiled results are Tier 1 and live only in an approved, enterprise-secure environment. The second is subtler and matters more. It is whether AI is drafting something a qualified human owns and reviews, or becoming part of a system that creates or maintains a regulated record. The first is a question about your people and your programs. The second is a computer-system-validation and [Part 11](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11) question for your quality function. ([FDA's 2024 guidance](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/electronic-systems-electronic-records-and-electronic-signatures-clinical-investigations-questions) is explicit that Part 11 reaches the CROs and IT service providers who create or maintain those records, while the sponsor stays responsible, so settle it with your own quality and regulatory function.) Most of the early value sits where neither line bites, and there is a great deal of it. The validated gate is not there to keep AI out. It is there to protect patient safety and data integrity, and those do not get cheaper to ignore because intelligence got cheaper. So you do not relitigate the gate. You do the Permission work once, choose controls you can stand behind, and then ask the only interesting question left. Is the current shape of this gate still the best way to protect what it guards, or is it a manual step that survived because the old systems could not see each other. That question belongs to you and your quality function together, and it gets answered on purpose, not by waiting. > Artifact: [Where AI Touches a Clinical-Stage Biotech](https://translationalintelligence.com/artifacts/clinical-stage-ai-map/) Here is Monday morning. Take one document your team writes by hand every week, a safety narrative, a monitoring summary, a submission section, and place it against the two lines. If it is a human-owned draft on data you already control, you can start this week. For everything past that line, bring your quality function in early and move it deliberately. The full map is [the artifact above](/artifacts/clinical-stage-ai-map/), and the destination it rests on is [the AI-Native Biotech](/ai-native-biotech/). --- ## [Issue] Don't Point AI at Your Best Work Canonical URL: https://translationalintelligence.com/dont-point-ai-at-your-best-work/ Date: 2026-07-20 Summary: The instinct is to aim AI at your hardest, most important work. Often backwards. Point it at the work that is high value to the business and low value as a use of your best people, and spend the bandwidth you free on the work only they can do. The first thing most teams do with AI is aim it at the crown jewels. The most important document, the hardest analysis, the work that matters most. Draft the BLA with it. It is the obvious move, and in a resource-constrained company it is often exactly backwards. ## Every task has two dimensions, not one Every task sits on two separate dimensions, and confusing them is the mistake. There is its value to the *enterprise*, which is simply whether the business needs it done. And there is its *expert-judgment intensity*, how much it actually draws on a skilled person's judgment, their taste, their years of hard-won expertise, as opposed to merely their time. These come apart constantly. A junior analyst re-typing the same vendor-onboarding email is doing work of real enterprise value, the business needs it, but of almost no judgment intensity, because nothing about it needs that particular person's mind. Notice what that does not say. The person is not low-value; the *task* is. A regulatory scientist crafting a BLA narrative is doing work that is high on both at once. ## Point AI at the high-enterprise, low-judgment corner > [Diagram: Point AI at high-enterprise, low-human-value work] The corner to aim AI at first is the one the business needs done but that is beneath your scarce talent. High enterprise value, low expert-judgment intensity. That is where automation buys you the most, not because the task is important, but because the person is. Consider your regulatory workload. It is tempting to sort it by document type: point AI at the INDs, protect the BLAs. That is too coarse, and it will mislead you. Plenty of IND work is the highest-judgment work you have, the first-in-human risk argument, the nonclinical justification, the protocol design. And plenty of a BLA is structured, repetitive drafting that consumes an expert's time without truly needing their judgment. The dividing line is not the submission. It is the section, the table, the narrative, the review step. The economists who first measured AI exposure found the same unit: it is a property of [tasks, not whole jobs](https://arxiv.org/abs/2303.10130), which is exactly why sorting by document type misleads you and sorting by task does not. So do not start with your highest-judgment work. Decompose the important work until you find the portions that consume expertise without requiring it, and aim AI there, on purpose. You did not lower your standard on the work that matters. You stopped spending your rarest people on the parts that did not need them. ## The value is second-order Here is what makes this a discipline and not just task automation. The value of clearing low-judgment work is not the hours saved on that work. It is what the freed bandwidth gets redirected to. Automate the analyst's vendor email and you saved him twenty minutes a week, which is nothing. But [that same small win freed him, and what he became was an AI Ambassador](/case-studies/the-task-was-never-the-point/) who changed how his whole function thought. That is the return, and it is second-order. If you free your best people's time and it flows straight back into more low-value work, you saved hours and gained nothing. If it flows into the work only they can do, you multiplied your scarcest resource. So the question is never "what can AI do here." It is "what would this free my best people to do instead, and is that better." Point AI at the grind, on purpose, so your genius lands only where genius is required. It is the same discipline as [buying the commodity and building only what is yours](/buy-record-build-intelligence/), turned on your people instead of your stack: spend the scarce thing only where it compounds. Take your team's work and sort it on two axes, how much the business needs it and how much it needs *this person's* judgment. Aim AI at the high-need, low-judgment corner first. Then name, out loud, where the freed hours are going. If you cannot name it, you have not found a use for AI. You have found a way to be busy faster. --- ## [Issue] The Fast No Canonical URL: https://translationalintelligence.com/the-fast-no/ Date: 2026-07-20 Summary: Everyone asks AI to find the next drug. Wrong question. Its highest-value job in discovery is to find you a reason to stop before you spend a scientist's year, and to know that its silence is never a reason to go. Ask a room of scientists what AI will do for drug discovery and you will hear the same answer. It will find the next blockbuster. It will surface the target no one saw, the molecule that works, the hypothesis that pays off. Maybe. Someday. But that is the rare event, and betting your program on AI producing a rare positive is a poor use of a powerful tool. The common event, the one that happens every week, is that a promising idea is quietly doomed and nobody knows it yet. That is where AI earns its keep. ## AI is a triage tool The most valuable thing AI does in research is not find you the yes. It is find you the no, fast and cheap, before you have spent the expensive thing, which is a scientist's months. Think of it the way you were taught to think about experiments. You do not prove a hypothesis. You fail to disprove it. Every good experiment is an attempt to kill the idea, and the ones that survive are worth pursuing not because they are proven, but because you tried hard to falsify them and could not. AI accelerates the first half of that loop enormously. It can assemble in a day the evidence it would take a person weeks to gather, and it can surface the disqualifying signal, the one that says stop, faster than any human reading one paper at a time. That reframes the whole value. AI does not make your scientists smarter. It lets them spend more of their finite time on the work more likely to pay off, by clearing the doomed work off the table cheaply. The [target safety read that flags an embryonic-lethal knockout on day one](/artifacts/target-safety-triage/), once a scientist confirms it, did not discover a drug. It saved you a year chasing a target that was never going to survive. ## The asymmetry that matters Here is the part that is easy to get catastrophically wrong. A no and a yes are not symmetric, but the asymmetry is not that the machine is trustworthy on the no. It is that only a *verified* signal can act, and only in one direction. When AI surfaces a disqualifying signal, you do not yet have a no. You have a high-value lead. A model can misread its source, confuse a gene with its protein, miss the direction of an effect, collapse a developmental knockout into an adult drug, or simply invent the finding. So verify it at the primary source, interpret it against your modality and your therapeutic hypothesis, and only then decide whether it earns a no. Trust the evidence, not the model. And when AI finds nothing, you do not even have a lead. Its silence means one thing only, that it did not find a reason to stop in what it happened to look at. It does not mean no reason exists. Absence of evidence is not evidence of absence, and a model that swept the public databases and came back clean has told you where it looked, not what is true. Derek Lowe, who has chronicled drug discovery for two decades in Science's *In the Pipeline*, [puts the skepticism plainly](https://www.the-geyser.com/interview-derek-lowe/): a language model is "extruding an optimized slurry of words into answer-shaped chunks," fluent, confident, and no substitute for the evidence itself. > [Diagram: A verified signal can stop a program; silence never starts one] So verify the signal, then act on the evidence. Never act on the silence. The day-one read that surfaces no red flag is not a target cleared; it is a target that has earned the expensive human assessment, which now begins, not ends. The failure mode that will burn a program is reading a clean AI pass as a green light and skipping the real work. That is not acceleration. That is automating your way to false confidence. ## Point it at the null So point your AI at the null. Ask it, first, for every reason this idea might be dead, and make it work to falsify before you let it help you believe. When it finds a killer you can verify, you have saved a fortune. When it does not, you have earned the right to spend real human judgment, and you spend it knowing the machine's silence proved nothing. Take your most promising current hypothesis, the one everyone is excited about, and give AI one job: find the reason it will not work. If it finds one, you just saved months. If it does not, hand it to the person whose judgment you were about to spend, and let them start the real assessment, clear-eyed that a fast no is a gift and a slow silence is not a yes. > Artifact: [The Day-One Target Safety Triage](https://translationalintelligence.com/artifacts/target-safety-triage/) The point was never that AI would think for you. It is that it can rule things out faster than you can, and ruling things out, cheaply and early, is most of what makes a scarce scientist's year pay off. --- ## [Issue] A Policy Is Only as Good as It Is Understood Canonical URL: https://translationalintelligence.com/a-policy-is-only-as-good-as-it-is-understood/ Date: 2026-07-21 Summary: Writing an AI policy is the part everyone expects to be hard. It is not. The hard part is teaching it, in person, until a company understands it well enough to act, and can eventually teach it to itself. A policy that cannot be understood is functionally not a policy. It is a document. Most AI policies are documents: written carefully, filed on a shared drive, linked in an all-hands deck, and then left to sit while people quietly decide on their own what is and is not allowed. The policy exists. It just does not do anything. If [deployment is not adoption](/people-first/) is the principle, this is the mechanism: the unglamorous, expensive work of turning a written rule into a thing people actually understand well enough to use. At Avidity, where I was the VP of AI, that turned out to be most of the job. MIT Sloan Management Review's editor in chief, Abbie Lundberg, [draws the same lesson](https://sloanreview.mit.edu/article/ai-wont-fix-this/) from decades of technology rollouts: organizations "fail at digital transformation not because their technology is weak but because they haven't prepared their people to use it well." ## The part everyone expects to be hard Between Legal, IT, and my team, we wrote an AI policy we believed in: the data tiers and where each was allowed to go, our position that [there is no AI work product](/there-is-no-ai-work-product/), only AI-assisted human work product, and practical guidance on everyday questions like AI for meeting notes. Writing it is the part everyone expects to be hard. It was not the hard part. ## The part that actually was A policy is worthless until the people it governs understand it well enough to act. So I taught it. Personally, to more than half the company, hundreds of people, in fifteen-minute increments. Not a recorded module. Not a memo from Legal. Me, in the room, walking a group through what the data tiers meant for their actual Tuesday, what "no AI work product" meant for the report they were about to write, how to think about turning on transcription in their next meeting. Fifteen minutes, over and over, is a large amount of a VP's calendar. That was the point. Spending it said, at a level no email can, that this mattered, and that the person accountable for it would sit with you and answer your question to your face. > [Diagram: A policy becomes adoption only when it is taught] ## The teaching goes both ways The questions were the second reason to be in the room. Every session surfaced things the policy had not anticipated. I collected them, turned them into FAQs, and carried them back to update our leadership team and, where needed, the policy itself. The policy got better because I was explaining it, not in spite of it. A rule you have to say out loud to a hundred skeptical people is a rule whose weak spots you find fast. ## Responsible conservatism, and then blossoming At first, almost everyone did the same thing. I call it responsible conservatism. Handed a new capability and a new policy, good people default to the most risk-averse reading. They do not use the tool, to be safe. That looks like caution, and it is, but an organization frozen in caution is not safe. It is just slow, and quietly falling behind while it feels responsible. Teaching the nuance is what broke the freeze. Once people understood not only the rules but the reasoning, where the real risk lived and where it did not, they started to blossom. The person who would not touch a transcript in week one was, a month later, rethinking how their team ran meetings. The confidence came from understanding, and the understanding came from someone taking the time to hand it to them directly. Then it became self-sustaining: we built AI-policy acceptance into standard onboarding, and it held, because a new person with a question could ask the colleague at the next desk, who now knew the answer. That is the quiet signal that adoption is real. The organization can teach itself. ## What does not transfer Take the principle, not the format. Fifteen minutes was what fit us; your dose may differ. What transfers is that the policy has to be taught, in person, by someone senior enough that the time itself carries the message, and refined by the questions it provokes rather than defended against them. Be honest about the cost. This is expensive, a large amount of a senior leader's calendar, and it only worked because leadership backed the time as worth spending. If no one senior will spend the hours, you do not have an enablement plan. You have a PDF. And treat responsible conservatism as what it is: not apathy, not resistance to be overcome, but good people trying to do the right thing without enough information. The answer is never pressure. It is information, delivered by someone they trust. The [full record, at Avidity, is here](/case-studies/fifteen-minutes-at-a-time/). ## Monday morning Do not ship your AI policy to the shared drive and call it launched. Pick the most senior person who can credibly teach it, and have them teach it, in small live doses, to as much of the company as it takes. Collect every question. Let the questions improve the policy. Then wire it into the place new people learn everything else, so the organization keeps teaching it after you stop. --- ## [Issue] Delete It by Default Canonical URL: https://translationalintelligence.com/delete-it-by-default/ Date: 2026-07-21 Summary: AI meeting transcripts are useful and frightening for the same reason, that they stick around. Govern them by making the record delete itself, and making the act of keeping it the moment a named person becomes accountable for it. Everyone wants AI meeting transcripts, because nobody wants to type notes and a good transcript hands back an hour of attention. And everyone is right to be nervous, for two reasons that get tangled together. One is accuracy: the AI mishears a number, a name, a "not," and now a confident, wrong sentence sits in a record. The other is quieter and worse: retention. An imperfect transcript that sticks around forever is a permanent, discoverable record of things that may never have been said. The wrong response is to ban the tool. The right one is to govern it, and the way you govern it is the whole lesson: you make the accountability physical. ## Two mechanisms, and neither works alone At a company I worked with, we turned one principle into two mechanisms. First, every AI transcript auto-deleted after 72 hours. Not "should be deleted." Deleted, by the system, on a timer, unless someone acted. The default state of an AI transcript was gone, because [AI output is not work product](/there-is-no-ai-work-product/) and an ephemeral draft cannot quietly harden into a permanent record. The timer had one hard exception wired in from the start: a legal hold, or a record a regulation requires you to keep, always overrode the deletion, because a company's convenience does not get to delete what the law says to preserve. Second, keeping one was an act with a name attached. The moment a person downloaded a transcript, that person became the human author of record and owned everything that followed: the accuracy, the cleaning, the verification, the finalization into real minutes. This was an internal accountability rule, not legal alchemy. Downloading did not change the legal nature of the information. It named the person answerable for turning it into a record. > [Diagram: An AI transcript is ephemeral until a human takes ownership] Either mechanism alone is weak. Auto-delete without an ownership rule just loses useful notes and teaches people to hoard screenshots. An ownership rule without auto-delete leaves a swamp of half-verified transcripts everyone assumes someone else owns. Together, the record does not exist unless a named person reached out and took it, and the taking is the acceptance of responsibility. Attention expanded, accountability intact. ## The tool you pick is a data decision There was a quieter choice underneath the policy, and most companies get it wrong by treating it as an IT convenience. We ran two tiers of meeting. For the confidential ones, we used the tool that could restrict auto-sharing of the transcript to just the meeting owner, because a confidential transcript that auto-broadcasts to every attendee is a data-classification problem wearing a productivity costume. For the rest, either tool was fine. The AI feature was chosen by the sensitivity of the data in the room, not by which vendor the company already paid for. That is the [Permission pillar](/permission-people-programs/) in one decision: data sensitivity decides the environment, and the sharing model too. ## What does not transfer The specific tools and feature differences will change; treat them as an example of the question to ask, not a standing recommendation. The 72 hours is a policy choice, not a magic number, and it never overrides the law: once litigation is reasonably anticipated, a duty to preserve can attach to electronically stored information regardless of your timer ([FRCP 37(e)](https://www.law.cornell.edu/rules/frcp/rule_37)), and some regulated records carry their own retention requirements ([FDA guidance on IRB meeting minutes](https://www.fda.gov/regulatory-information/search-fda-guidance-documents/minutes-institutional-review-board-irb-meetings) is one). Retention and discoverability are genuinely legal questions; set the number with the people who own that risk. And it only holds if it is enforced, not announced. The auto-delete has to be configured in the system, and the people who download have to actually do the cleaning, or you have relabeled an unverified transcript as "minutes" and made things worse. A governance mechanism that depends on everyone remembering to be careful is not a mechanism. It is a hope. The [full record is here](/case-studies/the-72-hour-transcript/). ## Monday morning Pick your transcript tool by data tier, not by habit: for confidential meetings, does the default sharing keep the transcript with the owner, or spray it to the room? Set a default auto-delete on the raw transcripts. Then write the one sentence that does the real work: the moment you download it, you are the author of record. And before any of it goes live, walk it past legal and records. --- ## [Issue] Don't Default AI to IT Canonical URL: https://translationalintelligence.com/dont-default-ai-to-it/ Date: 2026-07-21 Summary: Ask most biotechs who owns AI and the answer is IT, a function trained to say no. Traditionally IT in a regulated company is a risk-management shop. Today it has to be a foundational enabler of AI, and that shift is a culture change at its core. Ask most biotechs who owns AI, and where its guardrails live, and the answer is IT. It is the default, and it is usually a mistake. Not because IT is not capable, but because of what the function has been built to be. In a regulated industry, IT was handed the job of control: validated systems, access management, data integrity, and audit trails, the real and unglamorous obligations of [21 CFR Part 11](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11) and GxP. Do that job for two decades and you get very good at one reflex: protecting the company by slowing the new thing down. Point your AI ambition at a function trained to say no, and you get exactly that. ## The default, and the better instinct The regulated reality that made IT a control function has shifted under it. AI is not one more system to validate and lock down; it is the capability the whole company now runs on. That flips what its guardian is for. Traditionally, IT in a regulated company is a risk-management function. Today it has to be a foundational enabler of the AI transformation, or it is the thing quietly blocking it. There is no neutral. So AI is a capability to be led, not a risk to be managed down. It should report to the most forward-thinking, respected senior leader you have, high in the company, not buried where new things go to be assessed. Do not default it to IT. > [Diagram: Governance as a brake versus a shaping cone] ## The move At a company where I now lead the AI and innovation strategy, I made an unusual case, the kind that raises eyebrows in most orgs: IT should report up through me. Then we did the part that mattered more than the org chart. We rebranded the culture of the function itself, from Information Technology to Innovation Technology. Same acronym. Opposite mandate. The reframe was explicit, and I said it in a picture. This team is the shaping cone on a rocket engine. A shaping cone does not stop the blast. It takes all that raw energy and turns it into directed flight. Their job is not to block the new. It is to ask, of everything new, "how do we do this responsibly?" That is the [Permission pillar](/permission-people-programs/) made real: good governance is not a brake, it is the cone that turns a blast into flight. The function is a group of earlier-career people, and the rebrand lit them up. Being told you are a risk-management cost center is a very different thing from being told you are the foundational champions of the company's responsible-innovation engine. IT stopped being the last stop that kills momentum and became a foundational component of the AI strategy itself. ## Why it works, and where it is easy to get wrong Two moves, and you need both. The reporting line put the function close to the ambition, under a leader whose job is to build and not only to protect. The culture rebrand gave the people a mandate they were proud to carry. A reporting change without a mandate change is a new box on an org chart. A rebrand without a reporting change is a poster on a wall. But do not mistake the mechanics for the change. Moving a box on the org chart is the easy, visible half. The real shift, the one that actually turns a risk function into an enabler, is a culture and ways-of-working change at its core: the same people, doing recognizably the same governance, but starting from "how do we make this work, responsibly" instead of "what could go wrong." You cannot restructure your way to that posture. You lead people to it, which is why this is a [people-first](/people-first/) change wearing an org-chart costume. ## What does not transfer Take the pattern, not the parts. You do not need to literally rename your IT department, and you may not be the right person for it to report to. What transfers is the principle: put AI and its governance high, under your most forward-thinking leader, and reframe the guardrail function from "prevent the bad" to "enable the responsible." And it only holds if the mandate is real. If "Innovation Technology" is still measured on tickets closed and incidents avoided, you have renamed the department of no and changed nothing. Change what the function is rewarded for, or the rebrand is theater. The [full record of the engagement is here](/case-studies/the-shaping-cone/). ## Monday morning Ask one question, and answer it honestly: where does AI report in your company, and what is that function actually rewarded for? If the answer is a risk silo rewarded for saying no, you have found the bottleneck. Move it up, to the leader most eager to build. Then change the function's mandate, out loud, from preventing the bad to enabling the responsible. Governance is not the brake. It is the shaping cone, and it is where responsible speed is either made or lost. --- ## [Issue] No Final Form Canonical URL: https://translationalintelligence.com/no-final-form/ Date: 2026-07-21 Summary: AI-native is not a milestone you reach and bank. It is a standing capacity to keep re-translating as the technology keeps moving. The company that is never finished, on purpose. Ask a leader when their company will "be AI-native" and you will usually get a date. Next year. After the platform lands. Once the pilots wrap. The question sounds reasonable, and the answer is the tell. It treats AI-native as a place you arrive, plant a flag, and stop. There is no such place. AI-native is not a milestone. It is a standing capacity, and the moment you treat it as finished, you have already stopped being it. Amazon has run on the opposite instinct for three decades. Jeff Bezos calls it [Day 1](https://www.aboutamazon.com/news/company-news/2016-letter-to-shareholders), and in his 2016 shareholder letter he is blunt about the alternative: "Day 2 is stasis. Followed by irrelevance. Followed by excruciating, painful decline. Followed by death." A company that decides it has arrived has quietly entered Day 2. ## The victory that freezes Here is the failure mode, and it is a subtle one because it looks like success. A company does the hard work. It sets [permission](/permission-people-programs/), names an owner, redesigns a real workflow around what the technology can now do, and it works. So it declares the transformation complete, moves the team onto the next thing, and locks the new way in place. A year later the technology has moved again, and the company has not. The workflow it was so proud of redesigning is now the concrete it once poured over the old one. It became AI-enabled, at one moment, for one generation of capability, and then it froze at the new position. Better than where it started. Still stuck. > [Diagram: The AI-native company runs a loop that never closes] ## Native, not finished The word is the clue. A native speaker is not someone who passed a test and received a certificate. It is someone fluent enough to keep absorbing new words, new idioms, new registers, without being thrown. Fluency is not a state you complete. It is a capacity you keep. An AI-native biotech is the same. It is not the company that finished adopting this year's models. It is [the company designed to keep translating](/ai-native-biotech/) the next capability, and the one after that, into how the work actually gets done, faster each time because it has done it before. The first re-translation is the hardest. The tenth is a habit. That habit, not any particular tool, is what "native" names. ## How you can tell An AI-native company keeps asking hard questions about its own design, and it never runs out of them. Should this workflow exist as it does, or only because it always has? What still needs to be separate now that one system can hold all of it at once? Which decisions could happen earlier, with better evidence, if the right person saw the right thing in time? Where does human judgment matter more, not less, than it did last year? A company that has stopped asking those questions has told you what it is, no matter what its slide says. The tell is not the tooling. It is whether the organization still changes shape when the ground moves, or whether it defends the shape it landed in. This is the same discipline as [naming the size of a change before you start it](/scope-ladder/): the enterprise rung is not a summit you reach once. It is a rung you keep re-climbing as the technology raises the floor. ## Monday morning Take the last AI initiative you called finished. The one that went into a board deck as a win. Ask a single question about it: what has changed in how that work is done since you declared it done? If the honest answer is nothing, you did not build an AI-native capability. You bought a one-time upgrade and stopped. That is not a failure. It is just a starting line you mistook for a finish. The company that wins is not the one that arrives. It is the one that never does. --- ## [Issue] The Blank Page Is the Expensive Part Canonical URL: https://translationalintelligence.com/the-blank-page-is-the-expensive-part/ Date: 2026-07-21 Summary: A regulatory team said no to AI for twelve months. Then a three-day demonstration on their own documents did what a year of argument could not. The lesson is not about drafting. It is that a real demonstration beats a year of no. You can argue with a person about whether a tool is safe for a year, and get nowhere, because you are asking them to trust a claim about their own most accountable work. Or you can show them a real draft of that work, in the room, and change their mind in an afternoon. One of these is how most AI stalls resolve. The other is how they actually resolve. ## Twelve months of no A clinical-stage biotech had a wall coming: a stack of INDs and BLAs to file that ran well past what its regulatory writing team could physically reach. The executive team wanted regulatory to trial AI for first drafts. Regulatory said no. Not once, and not briefly. For twelve months. The resistance was not stupidity. A writing team that owns some of the highest-stakes documents in the company was being asked to trust a new tool with exactly the work it is most accountable for. Caution there is a feature. But caution and a filing wall do not resolve themselves, and for a year they did not. It took a member of executive leadership to step in and mandate a trial. Notice where the change started: not with the team's consent, but with [Permission](/permission-people-programs/), used deliberately, because the stall had become more dangerous than the risk everyone was worried about. ## Three days in a room The company had also signed a six-figure vendor trial. Alongside it, we ran a head to head. I sat in a room for three days with [my AI Product Partner](/ai-product-partner/) and our standard, already-paid-for tools, and we drafted real first-draft sections of an upcoming IND. Not a demo document. Real sections the team would not otherwise have reached for months, buried under the backlog. Two things came out of that room. Our drafts, produced with no six-figure vendor, were far better than what the paid trial produced. And several members of the writing team were dumbfounded, watching a real draft of their own work appear. The drafts were roughly 60 to 75 percent of the way to a usable first draft. That is not the number that matters. The number that matters is that it is not zero. > [Diagram: An AI first draft clears the blank page; human authors do the decisive work] ## The aha A blank page is the most expensive thing in regulatory writing. It is where the backlog lives. Handing a writer a section already 60 to 75 percent of the way there does not replace them. It starts them far past the hardest part and gives them their time back for the judgment that actually needs a human. The team saw that, in their own document, in real time, and after twelve months of no the aha arrived in an afternoon. The momentum did not come from the mandate. The mandate only bought the demonstration a chance to happen. A regulatory writer watching a real draft of their own work appear is worth more than any number of assurances that the tool is safe. Be precise about what it was, because in regulated work the precision is the whole point. No AI-generated text went to the FDA. The first drafts were framing and a running start on structure. Then the team did the hard work themselves: the sourcing, the argument, the precision, the review. The [author of record was human](/there-is-no-ai-work-product/) from start to finish. What the tool removed was the busywork at the front of the job. That split is what the controlled research finds too: handed a generative tool, professional writers [shift their time away from rough-drafting and toward ideas and editing](https://economics.mit.edu/sites/default/files/inline-files/Noy_Zhang_1.pdf). What it never touched was the work that reaches a regulator. ## What does not transfer Copy the lesson, not the setup. The trial only happened because an executive spent real capital to force it after a year of stall; without that Permission, the wall just gets closer. The six-figure vendor was not the villain, but it was the wrong first move: the capability was already inside tools the company owned, and nobody had tested that baseline before signing the check, which is the whole point of asking [whether to self-serve before you buy](/buy-record-build-intelligence/). And a 60-to-75-percent draft is a starting point, not a submission. AI-drafted regulatory content has to go through your full human writing, review, and quality process, and what that must include is a question for [your own quality and regulatory function](/artifacts/clinical-stage-ai-map/), not a case study. The win was escaping the blank page. It was never skipping the work. The [full record of the engagement is here](/case-studies/better-than-a-blank-page/). ## Monday morning Find the workflow drowning in backlog, the one where everyone can see the wall. Before you sign a large vendor trial, run a real head to head with the tools you already own, on a real document, with someone credible in the room. Keep humans as the authors of record and route every draft through your normal process. Then let the demonstration do what months of argument could not. --- ## [Issue] The Product Is Belief Canonical URL: https://translationalintelligence.com/the-product-is-belief/ Date: 2026-07-21 Summary: The real output of a first AI win is not the hours it saves. It is a believer. Start at the individual, because belief is the thing that actually moves a company, and it travels through people, not licenses. "Start small" is easy to say and impossible to believe, because the smallest starts look too small to matter. A junior person's repetitive chore does not move a number a board would notice. So it never gets done, and the company waits for a big, respectable initiative that will supposedly change everything and usually changes nothing. That instinct has the logic exactly backwards. The value of a first win is almost never the win. It is what the win produces in the person who felt it. Get that right and a rounding error turns into a department. I have watched it happen. ## A task beneath everyone's notice On a procurement team at a clinical-stage biotech, a junior analyst had a chore he did on autopilot. Every new vendor, he drafted the same email, attached the same four PDFs, and sent it. Same words, same files, every time. It was not hard. It was just there, a small tax on every new vendor, paid by hand. And he was, by the org chart, nobody's priority: too junior to command an engineering team, too small a problem to carry a business case. In most companies that is the whole story. The irritation is real, the person is willing, and the system never connects the two. We only found it because we went looking low. The AI team ran what we called 20% time on lifestyle improvements: a standing invitation to bring us the small, personal, unglamorous friction in your day, not the strategic initiative, the thing that annoys you every Tuesday. He brought the vendor email. The fix was trivial: a small automation assembled the message, pulled the four attachments, and produced a finished draft in one click. Measured in hours saved it was the kind of thing a transformation office with a business-case template would never green-light. > [Diagram: One small win compounds into an organizational shift] ## Where the rounding error stops being a rounding error The analyst did not just get his afternoon back. He became a believer, because the thing worked and it was *his*. He joined the AI Ambassador program, the distributed network of non-experts who carry capability into their own functions, which is [the People pillar](/permission-people-programs/) in motion, and he became the person in procurement who had actually done it. Standing in front of his peers, he was social proof no central team could manufacture. Then it compounded. Through his coaching, his teammates stopped asking "can you automate this one email?" and started asking the bigger question: how would we run this whole process if we designed it today, knowing what these tools can do? One eliminated task became a function learning to interrogate its own workflows. It moved up the [Scope Ladder](/scope-ladder/) on its own, from a personal practice toward a function beginning to reimagine itself, because one credible person had felt what was possible and would not stop talking about it. The whole [record of the engagement is here](/case-studies/the-task-was-never-the-point/). ## Why the smallest rung is the right start This is the argument for starting at the individual level, and it is not the automation. The hours saved were never the point. The product was *belief*, and belief travels through people, not licenses. A respected peer who has done the thing, in the open, outweighs any all-hands slide. It is the oldest finding in diffusion-of-innovations research: new practices spread through [near-peer networks and credible opinion leaders](https://web.stanford.edu/class/symbsys205/Diffusion%20of%20Innovations.htm), not mandates or mass communication, which move only weakly held attitudes. That is exactly what the [Personal Practice rung](/scope-ladder/) is for: its real output is not productivity, it is a convert who becomes a change agent. It was also governed from the first line, which is what let it scale without fear. The tool could only ever *draft*. It never sent. The analyst stayed the author of record, read every draft, approved it, and hit send himself. That is [the standard the whole company runs on](/there-is-no-ai-work-product/), and it applied to a four-PDF onboarding email exactly as it applies to a regulatory submission. A machine drafting the words did not move his accountability by an inch. ## What does not transfer Do not copy the automation. It is worthless to you, because your tasks are different. What transfers is the sequence, and it has failure modes worth naming. It only worked because someone with the tools sat with someone who had the problem, on time the company had deliberately set aside. Cut the 20% time and this never happens. It only compounded because there was an [Ambassador program](/permission-people-programs/) to catch the convert and hand him a role. A win with nowhere to go stays a private win. And it would have died in a spreadsheet if anyone had graded it on ROI. Measured as efficiency it was nothing, and a company that funds only what pencils out will never fund the thing that shifts its culture. You cannot manufacture an acolyte. You can only build the conditions: dedicated time, genuine listening, a real win, and a path for the person to become a teacher. Then you let a true thing do what true things do. ## Monday morning Find your most junior person's most repetitive task. Not the one with the biggest return. The one that is beneath everyone and quietly annoys someone every week. Eliminate it, with someone who has the tools sitting beside the person who has the problem, and keep the human as the author of record. Then watch what the convert does next, and make sure you have somewhere for them to go. It is the smallest rung on the [ladder](/scope-ladder/). It is also where more transformations should start than do. --- ## [Issue] Buying AI Is Easy. Becoming a Different Company Is the Hard Part. Canonical URL: https://translationalintelligence.com/buying-ai-is-easy/ Date: 2026-07-28 Summary: The founding welcome to Translational Intelligence, an open operating system for building an AI-native biotech, because the technology is the easy part and the human part is most of the job. There are two industries I cannot stop thinking about. Biotechnology is the one I believe matters most. Artificial intelligence is the technology I am most excited about. For most of my career I have worked somewhere in the space between them, trying to understand what becomes possible when computation begins to change our ability to read, design, and ultimately engineer biology. The possibilities are extraordinary. New medicines designed faster. Clinical programs that learn continuously. Scientists relieved of administrative work that consumes their attention without benefiting patients. Organizations able to connect information across functions, identify patterns earlier, and make better decisions with less friction. But possibility is not the same thing as capability. That distinction has become increasingly difficult for me to ignore. The AI conversation in biotechnology is currently dominated by models, vendors, partnerships, pilots, and announcements. Companies are buying licenses. Teams are experimenting with tools. Executives are being told that everything is about to change. And some of it will. But buying AI is easy. Becoming a different company is the hard part. A different company is not a different tech stack. It is a different culture: how people work, what they are willing to let go of, and whether the organization can learn a new way of operating and make it hold. AI transformation is a people transformation wearing a technology costume. Lead it [people-first](/people-first/), or it does not stick. That is the problem I am building a new project to address. It is called Translational Intelligence: an open operating system for building an AI-native biotech, a growing body of frameworks, tools, case studies, and practical guidance for turning technological possibility into institutional capability. Not someday. Not in a theoretical company unburdened by regulation, legacy systems, scientific uncertainty, organizational politics, or limited resources. Inside real biotechnology companies, as they exist today. ## The missing translation layer Biotechnology already understands the importance of translation. A scientific discovery is not a medicine. Between the two sits an enormous amount of work: validation, development, manufacturing, clinical testing, regulation, financing, and execution. Progress depends on translating knowledge from one context into another without losing what made the original insight valuable. AI transformation has a similar problem. A capable model is not a capable organization. The distance between those two things is where most transformations fail. > [Diagram: The translation layer between a capable model and a capable organization] A tool can produce an impressive demonstration while changing almost nothing about how the company actually operates. A team can launch dozens of pilots without creating a single durable workflow. Employees can receive access to powerful systems while remaining uncertain about when they are permitted to use them, how their work will be evaluated, or who is responsible when something goes wrong. The technical layer may be working perfectly. The institutional layer is not. And the institutional layer is people: their habits, their incentives, and whether they are willing and able to work a different way. This is not only a biotechnology problem, or a new one. Julie Averill, who spent eight years as chief information officer of Lululemon, [describes the same pattern](https://www.nytimes.com/2026/08/03/opinion/ai-hype-tech-layoffs.html) across insurers, airlines, and manufacturers in the New York Times: tools that dazzle in a demo and stall the moment they meet a real company's mismatched data, tangled systems, and decades of human exceptions. She names the belief that a powerful model lets you skip that work *AI wishing*, and warns that better tools were never going to close the gap on their own. What is left is the slow, human work. That is the work this project is about, and [how to run a pilot so it does not stall like the rest](/the-demo-is-a-question-not-an-answer/) is one of the first questions it takes up. Translational intelligence is the ability to close that gap. It is the discipline of converting emerging technical capability into repeatable human and organizational capability. That means answering questions that are less glamorous than "Which model should we use?" but far more consequential. Who is allowed to use AI, with which information, for which kinds of work? Who owns the translation between a business problem and a technical system? How do you distinguish a useful workflow from an attractive demo? When should a company buy, build, configure, or simply redesign the underlying process? These are not primarily questions about technology. They are questions about institutions. ## Why I am building this I have spent more than a decade working with artificial intelligence and the last several years helping organizations rebuild themselves around it. That work has taken me through science, national security, public policy, technology companies, and biotechnology. I have seen AI from the perspective of the researcher, the operator, the executive, the policymaker, and the person standing in front of a team trying to explain what all of this means for their work on Monday morning. The consistent lesson is that the human and organizational work is most of the job, by a wide margin. Not as a polite aside. Most of it in the literal sense: get the people and the culture wrong and nothing else you do will matter, get them right and the rest becomes tractable. This is a cultural change first, led people-first, and every framework and tool here exists in service of that. The model matters. The data matters. The software matters. But none of them become capability on their own. Companies change when people have permission to act, someone is responsible for translating possibility into a real product or workflow, and programs exist to move the organization from scattered experiments toward sustained execution. I describe those three requirements as [Permission, People, and Programs](/permission-people-programs/). Permission establishes the rules of the road. People create ownership and translation. Programs turn isolated successes into institutional learning. Of the three, People is usually the hardest, and the one that decides whether the rest becomes real. Permission and Programs are how you make the human change possible, and they matter in their own right. The human change is the transformation. It is a simple framework. I do not pretend it is the final word. But it has proven useful because it forces leaders to confront the parts of AI transformation that cannot be solved through procurement. ## What I am building The project begins with a foundational collection that lays out the central argument: AI transformation is not fundamentally a software deployment. It is an operating-model redesign. From there, the site is organized into layers. The [Foundations](/foundations/) explain the core ideas: what translational intelligence is, why Permission, People, and Programs matter, how companies should think about buying and building, why the AI Product Partner is becoming a critical organizational role, and what an AI-native biotech might ultimately look like. The [Issues](/issues/) develop those ideas through longer arguments, one a week. The [FAQs](/faqs/) give shorter answers designed to be sent to a colleague, executive, or board member when a practical question arises. The [Artifacts](/artifacts/) translate the ideas into usable tools: maturity assessments, operating models, implementation plans, AI policies, build-versus-buy frameworks, and functional maps showing where AI can, and cannot responsibly, touch the work of a biotech. The [Case Studies](/case-studies/) document what happens when these ideas encounter real institutions: what worked, what failed, what produced measurable value, and what turned out to be more difficult than the framework suggested. That last category matters enormously. A framework should not be trusted because it is persuasive. It should be trusted because it survives contact with reality. I am still building that body of evidence, and some of the earliest case studies come from my own work. Over time, I hope others will contribute examples, corrections, counterarguments, and lessons from their own transformations. The ambition is not to make Translational Intelligence a record of what I believe. The ambition is to make it a reliable source of what the industry is learning. ## Healthy ambition requires credible humility I believe biotechnology has the potential to become one of the industries most profoundly changed by artificial intelligence. I also believe it may be one of the easiest places to get that transformation dangerously wrong. Biology is complex. The data is fragmented. The work is specialized. The consequences are real. Much of the industry operates within scientific, clinical, regulatory, and quality systems where a confident answer is not necessarily a correct answer, and where an efficient mistake can be far worse than an inefficient process. There is no serious version of AI-native biotechnology built on technological enthusiasm alone. The work requires restraint, evidence, domain expertise, careful governance, and respect for the humans who remain accountable for the result. That is why the project holds itself to explicit [editorial standards](/standards/). Claims are distinguished as doctrine, operator heuristics, evidence-backed conclusions, or regulatory guidance. Primary sources are used wherever the stakes require them. Frameworks are versioned and revised as the evidence changes. I will get things wrong. The industry will discover better approaches. Some ideas that appear universal will turn out to depend heavily on company stage, therapeutic modality, function, or culture. That is not a weakness in the project. It is the point of building it in public. We do not need another voice pretending the future has already been solved. We need a place serious people can work through it together. ## The work ahead Translational Intelligence sits at the intersection of science, technology, institutions, and human behavior. It asks not merely what AI can do, but what kind of organizations we must become to use it responsibly and well. And it is focused on an industry whose success can quite literally determine how many people live, how well they live, and which forms of suffering remain inevitable. That deserves more than hype. It deserves a serious operating discipline. So start with the argument this is all built on, [the biotech of tomorrow](/the-biotech-of-tomorrow/), and follow the [Foundations](/foundations/) in order. Use the artifacts. Send the pieces to your teams. Challenge the assumptions. Tell me where the frameworks break. The future of biotechnology will not be determined by which companies had access to artificial intelligence. Nearly all of them will. It will be determined by which institutions learned how to translate that intelligence into better science, better decisions, and better outcomes for human beings. That is the work ahead. --- ## [Issue] People First, or Not at All Canonical URL: https://translationalintelligence.com/people-first/ Date: 2026-08-04 Summary: A company can deploy every AI tool and change nothing. Deployment is not adoption, and the gap between them is people. You close it people-first, or the transformation does not hold. A company can buy every model, issue every license, and launch every pilot, and be exactly the same company a year later. This is one of the most common outcomes of an AI effort, and it is not a technology failure. Every tool worked. Nobody's work changed. That gap, between a tool being deployed and a tool being used, is the whole problem. And it is not a technical gap. It is a human one. ## Deployment is not adoption Deploying a tool is an event. You buy it, you turn it on, you announce it. Adopting a tool is a behavior change: a person, with a decade of hard-won method and a healthy distrust of anything that offers to think for them, decides to work a different way. The first is a purchase order. The second is the transformation, and it is the hardest, slowest, most personal thing an organization ever does. > [Diagram: Deployment is not adoption; the gap is people] An organization is its people. Change the technology and nothing has changed yet. Change how people work, and you have changed the company. Which is why AI transformation is a cultural change before it is a technical one, and why it is led people-first or not at all. The [People pillar](/permission-people-programs/) is not the only lever, but it is usually the hardest constraint. Permission creates the room to move, Programs create something worth moving toward, and People decide whether either becomes real. The cost of skipping this is now well documented from outside biotech. Julie Averill, eight years the chief information officer of Lululemon, [warns in the New York Times](https://www.nytimes.com/2026/08/03/opinion/ai-hype-tech-layoffs.html) that companies routinely cut roles in the name of AI efficiency before they have redesigned the work, then quietly rehire for the same capability, spending money and trust to learn the lesson. Every inflated claim, she notes, teaches the people who remain to distrust the technology, and distrust hardens into quiet resistance. Deployment does not simply fail to become adoption. Done to people instead of with them, it produces the opposite. It is the same gap that stalls most pilots, seen from the culture side rather than [the build side](/the-demo-is-a-question-not-an-answer/). ## The people-first move So point the effort at the people, on purpose. Not with a change-management binder or a value on a wall, but with a sequence of concrete, unglamorous acts. Start with one respected person and one real, small win, because belief travels through people, not licenses. Turn that convert into an ambassador, the peer whose example does what no central team can. Teach in person, in small doses, because behavior change is social and a memo changes no one. Make responsible experimentation safe, so good people stop freezing out of caution. And measure adoption, not deployment, because licenses issued is a vanity number and behavior changed is the only real one. ## The proof This is not theory. At Avidity, an AI policy became behavior not because it was written well, but because it was [taught, in person, fifteen minutes at a time, to more than half the company](/case-studies/fifteen-minutes-at-a-time/). People defaulted to responsible conservatism, and then, once they understood not just the rules but the reasoning, they blossomed. The person who would not touch a transcript in week one was rethinking how their team ran meetings a month later. The technology was the easy part. It always is. This is also the counterpoint to [the one-lever mistake](/the-one-lever-mistake/): pull the People lever hardest, because it is the one the machine cannot pull for you. > Artifact: [The People-First Playbook](https://translationalintelligence.com/artifacts/people-first-playbook/) ## Monday morning Stop counting licenses. Find one person, solve one real friction with them this week, and when it works, ask them to help the next person. Then teach the next group yourself. If you are waiting for a tool to change your company, you will wait forever. Companies are changed by people, led people-first, one at a time. --- ## [Issue] The Demo Is a Question, Not an Answer Canonical URL: https://translationalintelligence.com/the-demo-is-a-question-not-an-answer/ Date: 2026-08-11 Summary: Ninety-five percent of AI pilots are said to fail. They fail because companies invest before they prove adoption. Reverse the order, and let the demo find the truth instead of selling a future. Everyone is quoting the same number. Ninety-five percent of corporate AI pilots fail. It comes from an MIT study that went off like a firework in the late summer of 2025, and it has been borrowed to argue for an AI bubble, an AI winter, and every mood in between. Before you use it, read what it actually measured. MIT's Project NANDA found that only about five percent of enterprise AI pilots produced rapid revenue acceleration, and the rest delivered little to no measurable impact on the bottom line ([as Fortune reported it](https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/)). That is a finding about *return*, not about whether the technology worked. And MIT's own explanation for why is the part almost nobody quotes: not the quality of the models, but a *learning gap*, the failure of tools and organizations to adapt to one another. The models were fine. The institutions never changed around them. You do not need a study to recognize the shape of it. Julie Averill, eight years the chief information officer of Lululemon, [described it firsthand in the New York Times](https://www.nytimes.com/2026/08/03/opinion/ai-hype-tech-layoffs.html): tools that dazzled in a demo and stalled the moment they met a real company's mismatched data, tangled systems, and decades of human exceptions. She names the belief that a powerful model lets you skip that work *AI wishing*, and its cousin, describing the outcome you hope for as if it had already arrived, *AI washing*. Put those together and the ninety-five percent stops looking like a technology problem. It is a sequencing problem. The pilots that fail are the ones a company invests in *before* it has proven anyone will adopt them. And the demo is what does the damage, because a good demo is [a comfortable way to lie to yourself](/ai-product-partner/). It proves something is *possible*, and possibility gets mistaken for a reason to build. So invert it. The demo is a question, not an answer. Its job is not to sell a future. Its job is to find out, fast and cheap, what the real problem is and whether anyone actually wants it solved. Prove the pull first. Only then do you spend. > [Diagram: Two ways to run a pilot] ## The receipts This is not a thought experiment. At Avidity I ran pilots this way on purpose, and the stalled kind became rare. The [full engagement is its own case study](/case-studies/four-rungs-and-the-courage-to-stop/). Here is the transferable shape of it, in four moves. **Buy what you can.** The same MIT data found that buying tools from specialized vendors succeeded roughly three times as often as building them in-house. So the first gate is [buy versus build](/artifacts/build-vs-buy/), and only the work you cannot or will not buy should ever reach a build conversation at all. Most asks end here, cheaply, with something you did not have to make. **Put a person at intake, not a queue.** An [AI Product Partner](/ai-product-partner/) takes the request and first asks whether a no-code tool already solves it. This is the role doing exactly the unglamorous work the ninety-five percent skipped: reframing the ask before anyone writes a requirement, because the person asking usually cannot yet name what they need and tries to solution instead of describing the pain. **Climb, do not leap.** When something does have to be built, it earns each rung by proving traction on the one below, and each rung is a real, named thing. A *Sub24* is a clickable prototype an engineer builds in under a day, whose only job is to show the person what they actually asked for. An *App* is that single workflow built for real and put in front of them to use. A *Program* is what an App becomes once demand is proven and it earns executive sponsorship and a budget. A *Platform* is the rare survivor that graduates into durable, shared infrastructure the other rungs run on. This is [the Scope Ladder](/scope-ladder/) applied to a build, one order of magnitude at a time, and it is what keeps the demo honest: a Sub24 surfaces the real requirement in a day instead of winning funding for a roadmap. **Keep the right to stop.** Because investment tracks traction, an ask that solves its problem early is a success that *ends*, not a plan that has to justify itself. A request from Legal to compare contract clauses across many contracts had a full platform plan on paper. We stopped it at the program layer, because the pain was gone sooner than we expected, and the platform we never built is budget that went to the next real problem. ## The learning gap is closed by people None of this is only a technology discipline. Every rung was paired with [enabling and training](/people-first/) the people who would use it, so traction meant genuine adoption and not a login count. That is the whole point of the MIT finding, read honestly. The gap that sinks the ninety-five percent is a *learning* gap, between a tool and an organization that never taught itself to use it. You close that gap deliberately, with people, or you do not close it at all. A pilot is not the software arriving. It is the institution changing to meet it. ## Monday morning Take your loudest AI pilot, the one with a champion and a roadmap. Before you approve its next dollar, answer the question a Sub24 would force on you: what have you actually proven that someone will *use*, as opposed to what you have proven is *possible*? If the honest answer is that you have a great demo, you do not have a pilot yet. You have a question you have not asked cheaply enough. Ask it first. Let the answer decide what you build. --- ## [Issue] Arguing About the Wrong Thing Canonical URL: https://translationalintelligence.com/arguing-about-the-wrong-thing/ Date: 2026-08-18 Summary: The meeting is about which model and which vendor. Those choices matter less than the room thinks. The scarce resource was never the technology. You have sat in this meeting. The whole argument is about tools. Which foundation model. Which vendor. Build the copilot or buy it. Everyone leaves feeling like a decision was made. The choices matter, a little. But they do not decide your future, and pretending they do has a cost. It lets a room full of capable people feel busy while the company stands still. Ethan Mollick, who has spent years teaching organizations to actually use these tools, reaches the same conclusion. Everything he demonstrates, he notes, [is already possible today](https://www.oneusefulthing.org/p/reshaping-the-tree-rebuilding-organizations); the hard, slow part is "how to rebuild an organization around a fundamental shift in the way work is done." The capability is not the bottleneck. The organization is. The scarce resource was never the technology. It is the person who can hold a new capability in one hand and a real piece of work in the other and see how one should reshape the other. That person needs a name and a job. > [Diagram: The person who bridges the gap] I call the role the [AI Product Partner](/ai-product-partner/), and it exists because of exactly that gap. The people who know what AI can now do usually do not understand the work that has to change. The people who understand the work usually do not know what just became possible. Nobody who could close the gap alone is standing in it. ## Both words are chosen on purpose *Partner*, because this is not a ticket taker. The relationship is not tell me which tool to build. It is help me understand the outcome and the real work, and we will decide together what should exist. The job is one part enablement: someone who lives in the tools, carries real empathy for how hard it is to change how a person works, and spends the day teaching people to change themselves. *Product*, because a demonstration is a comfortable way to lie to yourself. A prototype proves something is possible. A product makes it a repeatable part of how the institution works. The other part of the job is translating what teaching cannot solve into clear build requirements, and handing them to a dynamic, innovative engineering team to make real. ## Not a new tool, a new seat So the first move is not a purchase. It is to put a person at that intersection, give them real standing across Permission, People, and Programs, and let them reframe the work instead of taking tickets. As capability gets cheaper and more abundant, deciding what to do with it is the scarce skill, and it will not commoditize. Where do your best people spend their days on work beneath them? Name that one function, and put a person at the seam this quarter, with the standing to change the work and not just field requests for it. The full role is on [The AI Product Partner](/ai-product-partner/). --- ## [Issue] Inside the Role Canonical URL: https://translationalintelligence.com/inside-the-role/ Date: 2026-08-25 Summary: We had engineers. We had data scientists. The hard part was not what we could build. It was whether people would trust it enough to use it. *A note from Titus. Lecya was the first AI Product Partner I ever worked with, back at Avidity. I asked her to tell the story of the role from the inside, in her own words. Here it is.* Avidity was building serious AI capability early. Our executive team saw AI becoming an important part of how a successful biotech would compete, so they invested in a strong technical team. As that capability grew, a new kind of work started showing up around it. Engineers needed context. Scientists and business teams had ideas, pain points, and questions, but not always a way to turn them into something technical. And sometimes the real challenge was figuring out whether the thing being asked for was even the right problem to solve. There was no clean name for that work yet. I happened to be looking for a way to have more impact on how science moves, and I started stepping into that space before any of us fully understood what it was becoming. Then one project made the need impossible to miss: a Competitive Intelligence Hub. The ambition sounded simple enough. Competitive information lived everywhere: emails, reports, conversations, individual relationships. We wanted something the organization could interact with, where information could become shared intelligence and help us become more proactive instead of simply reacting to whatever happened next. There was plenty we could imagine technically. *The hard part was not what we could build. It was whether people would trust it enough to use it.* The Hub touched multiple functions, each with different needs, risk tolerances, and expectations. Investor Relations was one of them. Their concerns were practical: sensitive information, limited time, unclear ownership, and an AI system that could still get something important wrong. Drafting an email with AI was one thing. Relying on it for sensitive competitive intelligence that could influence a business decision was another. A wrong source or a wrong date was not just an imperfect output. It could shape the wrong decision. That changed the nature of the work. Instead of starting with the technology, I stepped back and focused on how the work happened today, where judgment mattered most, what people were unwilling to hand over, and which parts of the process might actually benefit from technical support. Those conversations were happening across the organization, not only in Investor Relations. Different teams brought different concerns and different definitions of what better looked like. The role was not to become the expert in each function. It was to listen across them, identify patterns, and translate those patterns into something the technical team could act on. And then one morning, our IR partner came back with a different kind of energy. Instead of leading with concerns, she brought ideas faster than I could write them down. She was not the only one. That same shift started showing up again and again. People were no longer waiting for us to bring them an AI solution. They were showing us the difficult parts of their work, challenging our ideas, and helping shape what the outcome should become. And that changed what we built. Concerns about source quality became requirements around provenance and validation. *Ideas that sounded useful in isolation were dropped when they did not survive the real workflow.* By the time requirements reached the engineers, they were no longer a collection of AI requests. They were a clearer picture of what the organization actually needed. That was when the role became clear. The functional teams understood how their work really happened. The engineers understood what was technically possible. Someone had to help figure out what was actually worth solving, turn different perspectives into direction, and keep the technical team focused on something the organization could use. That was the gap. That was the role of the [AI Product Partner](/ai-product-partner/). > [Diagram: The role revealed by listening across functions] Looking back, I had already spent years practicing pieces of that work without realizing it. I had shadowed teams, joined projects outside my lane, and asked people to explain things I did not understand. I was comfortable saying, "I don't know. Can you teach me?" People invested their time in me. Then AI created an interesting reversal. The people who had spent years helping me understand their work were now navigating something unfamiliar themselves, and I had something useful to give back. I did not need to become the expert in their function. They could remain the expert. My role was to understand enough of their world, and enough of the technology, to help the two meet in a useful way. I used to think the years of relationships at Avidity were the reason that worked. Experience since then, both doing this work in a new organization and watching other AIPPs find their own way, has changed my mind. What matters more is the ability to operate between worlds: to ask questions before offering answers, listen long enough to understand how the work really happens, and know enough about the technology to see what is possible without forcing every problem into an AI-shaped solution. When we started, there was no established AI Product Partner role to copy. We found the gap first, and the work revealed the role. Now we have the opportunity to build it intentionally. Whether that person comes from inside the organization or outside it, I would look less for the person who knows the most about AI and more for the person who can earn the trust of domain experts, work credibly with technical teams, and help both sides figure out what is actually worth solving. *That is the work in between. And now it has a name.* --- ## [Issue] Write the Role Before You Fill It Canonical URL: https://translationalintelligence.com/write-the-role-before-you-fill-it/ Date: 2026-09-01 Summary: You cannot hire, grow, or even fractionally assign a job you have never written down. Defining the AI Product Partner is the first real act of the transformation, not the paperwork after 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](/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. > [Diagram: The definition comes before the hire] ## 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](https://hbr.org/2018/02/you-dont-have-to-be-a-data-scientist-to-fill-this-must-have-analytics-role), 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. > Artifact: [The AI Product Partner Role Definition](https://translationalintelligence.com/artifacts/ai-product-partner-role-definition/) ## 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](/artifacts/ai-product-partner-role-definition/) and cut it down, or hand that [fractional owner](/artifacts/small-team-operating-model/) 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. --- ## [Issue] The Contours of an AI Team Canonical URL: https://translationalintelligence.com/the-contours-of-an-ai-team/ Date: 2026-09-08 Summary: There are two jobs hiding inside the decision to build an AI team, and they call for different investments. One IT can handle. The other, changing how the company works, needs a small team of four built in a shape that barely existed five years ago. *A note from Titus. Karl was my Executive Director of AI and Data Science at Avidity, and he is now Chief AI Officer in the Vigilance Division at Alloy Therapeutics. I asked him to lay out how you actually staff a team to do this work. The AI Product Partner is one of the seats on that team, and the engineering seats around it are what this new series is about. This is its opening piece.* So you've decided you want to get going with AI and need a team to do so. The first thing worth settling is what you want that team to do, because there are two different jobs hiding inside the question and they call for different investments. The first job is getting tools into people's hands. Rolling licenses out across the company, standardizing on a common set of tools, and making sure people know how to log in is worthwhile work, and IT can usually manage it without much outside help. What it buys you is some personal productivity and learning, the same organization operating a bit faster. The second job is changing how the company works, and that's a bigger and slower bet. It means picking apart specific workflows, rebuilding them around what these systems can do, and getting people to adopt the result. No license purchase gets you there. Most biotechs end up needing both, tools rolled out broadly for baseline speed, and a small team going deep on the handful of workflows where the transformation happens. The team is for that second job. The right size for that team tends to land at four ICs with a leader. Go smaller and you're looking for too many different skillsets in one person. Go larger and you lose the ability to sit in a room and think through a problem together. Those five seats are the whole of it, so here they are before the detail: - **AI enablement**, getting no-code AI tools into people's hands one team at a time. - **A forward deployed engineer**, embedding in a function to build the bespoke thing it needs. - **A platform engineer**, owning the hub that lets everything else scale. - **A system engineer**, building the deep machinery underneath. - **A team lead**, choosing which workflows are worth it and winning the room to do them. Each one exists because the job it does cannot be borrowed from the seat beside it. The rest of this piece is what each is, and why. ## The new shape of the roles What makes a group that small viable is that the roles themselves have changed. If you're picturing the software team you'd have assembled five years ago, it would have included a PM, a scrum master, a few junior developers supporting a couple of senior ones. Much of that structure existed to move information between people and prioritize the work because writing code was expensive. AI allows you to remove the purely connective and the junior roles. What you want in the roles is overlap in the middle and spikes at the edges. Everyone should understand enough of the adjacent roles to cover a gap, review someone else's thinking, or carry a project one step further than their own seat strictly requires. But overlap alone produces a team of generalists who can each do a little of everything and none of it well. Each seat needs a spike, a depth that nobody else on the team has, running from someone who understands the business and can teach people to use no-code tools, to someone capable of architecting a backend. The overlap is what makes the team resilient. The spikes are what make it worth having. Overlapping skill profiles across the four building seats Four overlapping density curves along a continuum from breadth to depth. AI enablement is the broadest and most business-facing. The forward deployed engineer, platform engineer, and system engineer grow narrower and deeper in turn. Where the curves overlap is the breadth every seat shares, enough to cover an adjacent gap. Each curve's peak is the depth spike that only that seat brings. AI enablement Forward deployed Platform engineer System engineer breadth · business, no-code depth · backend, infrastructure Each seat is a curve. The overlaps are the breadth every seat shares, enough to cover a neighbor's gap. The peaks are the depth spikes only that seat brings. ## The four seats **AI enablement.** This seat is the [AI Product Partner](/ai-product-partner/), the role Titus has already written up, so I will not relitigate it here. This person works hand in hand with individual teams to figure out where no-code and low-code AI tools solve a problem worth solving. Their value isn't to scale the process, they work one person or one team at a time, but they have the fastest path to impact. This is the person who becomes the office's favorite coworker in about three weeks. Much of the job is training, and the good version of it looks less like a lunch-and-learn than like an apprenticeship. Sitting with someone while they work through a problem they care about teaches far more than a slide deck on prompting, which is why the work is slow and why it sticks. The trap is letting all of it stay one to one. Every session should leave something behind, a short guide, a worked example, a template someone else can pick up, so the second person with the same question can be handed an answer rather than an hour on the calendar. The other underrated part of this seat is broadcasting. Because they are the only person circulating through every department, they are the only one positioned to tell finance that clinical ops solved this exact problem last month. Left alone, companies build the same thing three times and nobody notices. A running internal record of what has been built and who to ask about it is worth more than it sounds, and this is the person who keeps it. **Forward deployed engineer.** Palantir made this model famous, an engineer who embeds directly with a business team and builds something bespoke for the workflow in front of them. Compared to AI enablement, the FDE can take on harder problems and has more tooling flexibility, at the cost of some speed, which makes this the seat you reach for when a problem is worth that tradeoff. What separates this seat from a normal engineer is that the hard part is not the code. The FDE spends a meaningful share of their time sitting with the regulatory team or clinical ops, watching how the work happens, and figuring out which of the twelve steps in a process are load-bearing and which exist because someone set it up that way in 2019. The people doing the work often cannot tell you this, not because they are being difficult, but because nobody has asked them to examine it in years. This is also where the failure mode lives. An engineer who takes the request at face value builds a faster version of a broken process, which is the most common way these projects produce something impressive that nobody uses. The FDE has to be willing to come back and say the thing you asked for is not the thing you need, and have enough credibility with that team to be believed. Hire for the willingness to sit in someone else's workflow for two weeks before writing anything. **Platform engineer.** Somebody has to own the platform itself, the hub, the internal app store, the thing that lets everything else scale. Part translator and part glue, this is also who the team leans on when demand spikes. They keep an overhead view across every application being built, which lets them spot the capabilities that need to exist before anyone else notices the pattern. If three or four applications all need to schedule activity, the platform engineer catches that overlap and hands it to the system engineer to build once instead of four times. They think in reusable components, and in how fast and how consistently the team ships code. The other half of this seat is judgment about when to build something permanent. Not every capability that shows up twice deserves to become part of the platform, and a person who promotes everything ends up maintaining a sprawling library that nobody uses. The platform engineer has to sit with a request and decide whether it is a passing need or a pattern, which requires enough distance from any single project to see the whole portfolio, and enough contact with the business to know which departments are about to need the same thing. They also set the standard for how the team works. Because the FDE and the enablement seat are moving fast and building things that will outlive their original use case, somebody has to decide what good looks like, which tools everyone builds with, how things get documented, and what has to be true before something gets deployed. That sounds like bureaucracy, and done badly it becomes exactly that. Done well it is the difference between a team where any member can pick up someone else's project and one where every application has precisely one person who understands it. **System engineer.** This is the deep technical seat, the person who builds the machinery everything else runs on. Databases that hold your data, the connections between systems that let one tool talk to another, the rules governing who is permitted to see what, and the capacity to handle a hundred people using something at once rather than one person testing it. The most important habit in this seat is building components that are abstracted. An abstracted component is a piece of machinery built once, general enough that many different applications can plug into it without knowing how it works inside. A light socket is abstracted. You screw in whatever bulb you want and the wiring behind the wall never changes. The alternative is a system engineer who builds a scheduling function for the regulatory team's application, then a second for clinical ops, then a third for the lab. Three times the work to maintain, three places for something to break, and no leverage from any of it. The second habit is writing adaptable code. Whatever model your applications are built around today will be surpassed within a year or two, and your team will want to swap it out. If a vendor's specific setup is hardcoded into a dozen places across your applications, that swap becomes a rewrite and a budget conversation. If everything routes through one layer designed to be changed, it becomes an afternoon of work. The system engineer is the person whose choices determine which of those two situations you're in, usually eighteen months before anyone notices it mattered. **Team lead.** The four seats above are tactical. They are heads-down on the problem in front of them, which is where you want them, but it means nobody in that group is looking up. The team lead is the person who does. Their first job is strategy, deciding which workflows are worth the team's attention and which are not. A four-person team can take on maybe a handful of meaningful projects a year, so choosing the wrong ones is expensive in a way that's hard to see until the year is over. That means saying no frequently, including to executives with a pet project. Their second job is organizational alignment. This team touches every function in the company, and every function has its own priorities, its own budget, and its own reasons to be skeptical. Somebody senior enough to sit with the head of R&D or the CFO has to build the case for why a team is embedding in their department, secure the sponsorship to make it stick, and handle the political friction that comes with changing how people work. Their third job is planning and roadmapping. Where the tactical team is thinking in weeks, the lead is thinking in quarters, sequencing work so the platform pieces exist before the applications that need them, forecasting when the team will run out of capacity, and making the case for the next hire before the shortage becomes a crisis. You can technically get away with one of the four carrying this part-time if they're senior enough, but the strategic work is the first thing to get dropped when a deadline gets tight, and it's the part with the longest lag between neglecting it and feeling the consequences. ## Handoffs and collaboration The way these seats connect matters as much as the seats themselves. Think of it as a filter, where every request enters at the same place and only the ones that need deeper resources travel further down. > [Diagram: The request filter] Every request goes to AI enablement first. A large share of what comes in is training, or an individual workflow, or something one team wants that doesn't need to work anywhere else. Those get handled on the spot with low-code and no-code tools like Claude Cowork or OpenAI's Codex, and they never travel further than the first seat. What survives that filter is the more complex work, or a workflow spanning several teams that needs something purpose-built. Those go to the forward deployed engineer. If the request is close to something the team has built before, the FDE assembles it from existing pieces and the chain ends there, which is the outcome you want most of the time. Duplicating a known pattern is cheap and fast. Only when there's new surface area, a capability the platform doesn't have yet, does it reach the platform engineer. Their call is which structural elements the new thing should be built from, what can be reused, and what needs to be constructed from scratch. Whatever falls into that last category gets handed to the system engineer. The reason to run it this way is resource scarcity. Deep engineering talent is the hardest thing on this list to hire, the most expensive to keep, and the easiest to waste. A system engineer spending their week on a request that a no-code tool could have handled is the most costly mistake a team this size can make repeatedly. The filter exists so that by the time work reaches the bottom, three people who understand the business problem have already agreed it belongs there. ## Why the small team wins This works better on paper than it probably should, for a few reasons. The overlap in skills builds in some redundancy even at four or five people, someone gets sick, someone leaves, and the team keeps functioning. Having all four in a room on one hard problem also means the group can take on complications that would otherwise need a much larger team. But the biggest reason is probably visibility, the whole team carries full context on the problem from day one. Compare that to how most enterprise AI projects stall out, where the customer-facing person hands off to a prototyping team, who hands off again to a production team, and something gets lost at every step along the way. This model skips that gap, not because the handoffs disappear, but because they happen between four people who were in the same room from the start. ## Where to go from here Assume this works and you need more capacity. The instinct is to scale the team evenly, adding an engineer for every enablement hire, but that gets the ratio backwards. Growth should be weighted heavily toward the top of the funnel, roughly two or three additions at the enablement and forward deployed layers for every one at the platform and system layers. The logic follows from how the work is built. If your system engineer has been abstracting components properly, each piece they finish serves many applications rather than one. A scheduling capability built once gets used by the regulatory application, the clinical ops workflow, and the two things nobody has thought of yet. The deep engineering work compounds, so a single person at that layer can support a growing number of applications above them without a proportional increase in their own workload. The people building workflows and training teams don't get that leverage. Their work is inherently one at a time, which means they hit their ceiling first. When your team is struggling to keep up, the constraint is almost never that you're short a database engineer. It's that the queue of departments waiting for someone to sit with them has stretched to three months. As you build this team, remember that the hardest part of AI transformation won't be the technology, it will be the change management. Which means the job doesn't end at the offer letter. Think hard about what these five people will need from you once they're in the building, because a team with the right skills and no organizational cover will spend its first year proving it deserves to exist. --- ## [Issue] You Don't Need a Roadmap. You Need a Quarter. Canonical URL: https://translationalintelligence.com/you-dont-need-a-roadmap/ Date: 2026-09-15 Summary: The request that kills more AI transformations than any budget line is the responsible-sounding one, bring me the roadmap. You do not need a two-year plan. You need one quarter you can run. The request that kills more AI transformations than any budget line is the one that sounds the most responsible. Bring me the roadmap. A two-year plan, phased, with milestones and a target operating model on slide fourteen. It feels like leadership, and it is mostly a way to not start, because the ground under a two-year AI plan moves faster than the plan does. By the time it clears the room, the capability it assumed is a year out of date. You do not need a roadmap. You need a quarter. Ninety days is long enough to name an owner, [score yourself honestly](/artifacts/ppp-scorecard/), ship one real workflow, spread it to a few people, and score again. It is short enough that the capability will not outrun you, and small enough that you can run it with the people and the runway you already have. > [Diagram: The first 90 days, as a repeating quarter] The quarter has a shape, and the shape matters more than the ambition. The first two weeks are for honesty and an owner, not launches: name the person who will own the work at a fifth of their time, and score the company out loud. The next month is one workflow made real where people can see it. The month after that is turning that one win into a few, by letting the person you helped bring their bigger idea and by recruiting the peers everyone else copies. The last two weeks are for scoring again and choosing the next pillar. Then you do the whole thing over. A roadmap promises you will know the entire path before you take a step. A quarter admits you will learn the path by walking it, which in a field moving this fast is the only honest promise on offer. The roadmap optimizes for the comfort of the room that approves it. The quarter optimizes for the one thing that compounds, which is *adoption*. Solve one person's real problem this quarter, and next quarter they arrive with a bigger one, and that is a company teaching itself to move. > Artifact: [The First 90 Days](https://translationalintelligence.com/artifacts/first-90-days/) So do not commission the roadmap. Name the owner today, put the [scorecard](/artifacts/ppp-scorecard/) on this week's agenda, and let your target for the quarter be a single level on a single pillar. Ninety days from now you will have moved, which is more than most roadmaps deliver in two years. That habit, run over and over, is what keeps a company [AI-native](/ai-native-biotech/). --- ## [FAQ] Where do I actually start with AI at my biotech? Canonical URL: https://translationalintelligence.com/faqs/where-do-i-start/ Date: 2026-07-01 Summary: The honest first move is not a tool or a task force. It is one workflow, one owner, and one real question. I get this one almost every day, usually from a CEO who has already been pitched ten platforms and is no closer to an answer. Here is the honest version. Do not start with a tool. Do not start with a task force, a strategy offsite, or a backlog of three hundred use cases. Those all feel like progress and produce none. Start with one workflow that matters. Not the easiest one, and not the one with the loudest AI request. One that carries real weight for the science or the business. Give it a single owner whose job is the outcome, not the software. Then ask two questions about it. If we designed this today, knowing what these systems can now do, what would we build? And what is actually stopping us, a hard constraint or a habit we inherited? The gap between those two answers is your starting point. It is concrete, it belongs to someone, and it will teach you more about transforming your company than any platform demo. Do that once, learn from it, and do it again. That is the whole method, and it is why I called this [translational intelligence](/translational-intelligence/) in the first place. If you want the long version, read [The Biotech of Tomorrow](/the-biotech-of-tomorrow/) and [Permission, People, Programs](/permission-people-programs/). --- ## [FAQ] Which pillar should I fix first? Canonical URL: https://translationalintelligence.com/faqs/which-pillar-first/ Date: 2026-07-02 Summary: Not the one you like to show off. Start with the pillar you are worst at, and it is usually People. Grade yourself honestly on all three, then start with your weakest, not your favorite. Almost everyone wants to start with Permission, because writing a policy feels like progress and it threatens no one. But a clean policy sitting on top of people who work exactly the way they did last year has changed nothing. The pillar that decides the outcome is almost always People, because behavior is the hardest and least visible part. Someone can have the tool, the training, and the policy in front of them and still not change how they do the job. If your governance is tidy but adoption is flat, you have Permission without People, and no amount of new policy will fix it. So the honest first move is to find one place a respected person on your team would change their Tuesday, and make that real. Then the other two pillars have something to grow around. The full model is on [Permission, People, Programs](/permission-people-programs/). --- ## [FAQ] How do I tell a real build from rebuilding a commodity? Canonical URL: https://translationalintelligence.com/faqs/real-build-or-commodity/ Date: 2026-07-03 Summary: One test. Could you buy it, and would buying it cost you nothing that matters? Then it is a commodity. There is a single test. Could you buy this, and if you did, would you lose nothing that sets you apart? If yes, it is a commodity. Buy it, and do not let pride talk you into a custom version of software the market already builds better. You build for two reasons. You cannot buy it, because your proprietary data and your particular workflow are the whole point and no vendor has them. Or you will not buy it, because it is bespoke enough that a vendor implementation would cost more work and compromise than building it yourself. Everything else is a system of record you should license. The trap in this era is rarely too little building. With AI in hand, it is building the wrong things: rebuilding the commodity while the small, differentiating tools go unbuilt. Route each request on purpose. The whole discipline is on [Buy the Record. Build the Intelligence.](/buy-record-build-intelligence/) --- ## [FAQ] Are we AI-native, or just AI-enabled? Canonical URL: https://translationalintelligence.com/faqs/ai-native-or-ai-enabled/ Date: 2026-07-06 Summary: One question tells you. What has your company reconsidered, versus just sped up? Ask one question. What has your company actually reconsidered, versus just made faster? If your workflows, your approval chains, your job descriptions, and your measures of value are the same as before, only now with a copilot bolted on, you are AI-enabled. You are quicker at the same documents, the same meetings, the same decisions in the same order. That is efficiency, and it is the old company with better throughput. AI-native means you treated those inherited assumptions as the actual work, and asked which of them should still exist now that the constraints that created them are gone. It is not a finish line or a particular tool. It is a capacity to keep reconsidering as the ground shifts. Most companies choose efficiency and call it transformation, because efficiency threatens no one and redesign does. The tell is whether anyone has changed what they decide, not just how fast they decide it. The full picture is on [The AI-Native Biotech](/ai-native-biotech/). --- ## [FAQ] What if legal wants a longer, stricter AI policy? Canonical URL: https://translationalintelligence.com/faqs/longer-stricter-policy/ Date: 2026-07-07 Summary: A longer policy no one reads protects no one. The one-page version is not lax; it is the enforceable one. Take the question seriously, then push back on the premise. A longer, stricter policy that no one reads or can follow does not protect you. It protects the person who wrote it. The one-page version is not lax. It is the only kind that gets followed, which is what protection means. Give legal the two things that carry all the weight. First, data sensitivity decides the environment: confidential information goes only into contracted, enterprise-secure tools you have approved, and everything else is fair game. Second, accountability is total and human: there is no AI work product, only AI-assisted human work product, and the author of record owns all of it. If legal wants more, add specifics for the few genuinely high-stakes cases, regulatory, clinical, legal, and stop there. Every clause past a page trades real adoption for the feeling of coverage. Take the one-page version and adapt it: [A Lightweight AI Use Policy](/artifacts/ai-use-policy/). --- ## [FAQ] How do I run build-versus-buy in a real meeting? Canonical URL: https://translationalintelligence.com/faqs/run-build-vs-buy-in-a-meeting/ Date: 2026-07-08 Summary: Out loud, with the people who own the requests. Route the three loudest, then the three smallest. Do it out loud, with the people who own the work, not on a spreadsheet by yourself. Take your three loudest AI requests. Route each one, in front of the room, through the five options: self-serve, buy, build, redesign, do nothing. Say why out loud. If all three come back build, stop, because you are almost certainly about to rebuild a commodity you could license. Then do the harder half. Take the three smallest problems your best people keep hitting, the ones too minor to make any roadmap, and pick one to build this week. That is where adoption is won, and adoption is the whole game. Give the routing a permanent owner whose job is to know the difference, and put a date on the calendar to re-route your biggest builds, because the line moves as the market moves. The one-page tool is [The Build-vs-Buy Decision Framework](/artifacts/build-vs-buy/). --- ## [FAQ] Doesn't thinking with AI make writing slower? Canonical URL: https://translationalintelligence.com/faqs/doesnt-this-make-writing-slower/ Date: 2026-07-10 Summary: At first, and that is the point. You are buying depth, not speed. Over a few pieces it is faster. At first, yes, and that is the point. You are not buying speed. You are buying depth, and depth is the thing worth having. The fast path, hand the model a prompt and take its clean draft, feels quicker right up until you notice the argument was never yours and cannot survive a hard question. Then you rewrite it, or worse, you ship it. That is not fast. That is expensive. Used to make the problem harder before it makes the prose easier, AI gets you to a sharper claim than you would have reached alone, and it gets you there without hollowing out your own thinking. Over a handful of pieces it turns out faster, because you stop rewriting drafts that cohered before they earned it. Slower on the first draft, quicker to something true. That is a trade worth making every time. The method is on one page: [The Think-Harder Writing Workflow](/artifacts/think-harder-workflow/). --- ## [FAQ] How do I get AI to write in my voice? Canonical URL: https://translationalintelligence.com/faqs/get-ai-to-write-in-my-voice/ Date: 2026-07-11 Summary: Do not describe your voice. Show it. Feed the model your real writing and correct what it gets wrong. Stop describing it. Everyone tells the model to be clear, smart, and concise, and everyone gets back the same thing, because those words describe no one. Your voice is a pattern of decisions, not a list of adjectives: what you notice first, where you put the tension, which comparisons you reach for, what you refuse to exaggerate, which sentences feel dishonest coming from you. You cannot recite that from memory. You derive it from evidence. So feed the model several things you wrote yourself, from different rooms, and have it find the recurring patterns. Its first read will grab the surface, that you favor short sentences, say, while missing that your real signature is moving from a concrete detail to a first-principles claim. Correct it. Every correction, this is too polished, I would never say that, the argument is cleaner but less true, makes your taste explicit, and that accumulated judgment is worth more than any prompt. The full guide is [How to Write With AI Without Sounding Like It](/artifacts/ai-writing-style-guide/). --- ## [FAQ] How do I audit my own company against its own rules? Canonical URL: https://translationalintelligence.com/faqs/how-to-self-audit/ Date: 2026-07-12 Summary: Write the rules down first, most cannot, then check your loudest AI work against them, in public. Write your rules down first. Most companies cannot, and that is the first and largest gap, because a rule you have not written is a rule you cannot be held to. Once they exist, take the work you are proudest of, the AI strategy you would show the board, and check it against them line by line. Where did you break your own standard? A rule you write down only means something if the gaps get closed, not just noted. Do it in the open, gaps included. A case study that shows only the wins is exactly the premature coherence worth distrusting. The value of holding yourself to a written standard is that the gaps come out small and findable, instead of large and hidden. A company that never audits itself against its own rules does not have fewer gaps. It just has not looked. See it done, on this publication itself: [Built by Its Own Rules](/case-studies/built-by-its-own-rules/). --- ## [FAQ] What's a passing score? Canonical URL: https://translationalintelligence.com/faqs/whats-a-passing-score/ Date: 2026-07-13 Summary: There isn't one. You are only as native as your weakest pillar, so the goal is not a high number, it is a rising floor. There is no passing score, and chasing one is its own mistake. The scorecard is not a test you clear once. It is a floor you raise, and the only number that matters is your lowest pillar, because [Permission, People, and Programs](/permission-people-programs/) grow together or none of them grows. That changes what "good" looks like. A company sitting at a steady *Practiced* on all three is in far better shape than one showing *Native* on Permission, *Native* on Programs, and *Absent* on People, even though the second one has two perfect scores. The first company has a high floor. The second has a wall with a hole in it. So do not celebrate your tallest pillar, and do not try to reach Native everywhere at once. Native on every pillar is not the target, and for most functions it is not even the right ambition this year. The healthy pace is one level, on your lowest pillar, per quarter. Grade honestly, raise the floor, put a date on the calendar, and grade again. If you want the tool, it is [the Permission, People, Programs Scorecard](/artifacts/ppp-scorecard/). If you are not sure which pillar to move first, that has [its own answer](/faqs/which-pillar-first/). --- ## [FAQ] Which rung of the ladder should I start on? Canonical URL: https://translationalintelligence.com/faqs/which-rung-should-i-start-on/ Date: 2026-07-13 Summary: Almost always one rung lower than your instinct. Start where you can make something real this quarter, then compose upward. Almost always one rung lower than the one you want to announce. The [Scope Ladder](/scope-ladder/) has five rungs, from a personal habit you build in an afternoon to a company you re-align over a year. The instinct, especially right after a good board meeting, is to reach for the top: re-form the whole function, re-align the enterprise. The instinct is wrong, not because the ambition is wrong but because the higher rungs are *built from* the lower ones. You cannot re-form a function whose individual roles have never been amplified. You would be drawing an org chart with nothing running inside it. So here is the honest first move for most companies. Start at rung two, the [workflow](/only-five-moves/). Pick one process that carries real weight for the science or the business, not the easiest one and not the one with the loudest AI request. Give it a single owner whose job is the outcome, not the software. Rebuild it around what these systems can actually do now, rather than bolting a model onto the version you inherited. That is small enough to finish this quarter and large enough to teach you something a personal habit never will. Why not rung one? You probably already have rung one, whether you named it or not. Someone on your team is quietly using these tools well. That is worth surfacing and celebrating, because it is how belief spreads, but it is not yet a transformation of anything. Why not rung four or five? Because you have not earned the information yet. Every rung you climb teaches you what the next one costs, where your data is weak, and which habits are load-bearing. Skip that and you are budgeting a restructure on guesses. Do one workflow all the way through, learn from it, and let what you learn tell you whether the next move is a second workflow, the same person's whole [role](/ai-product-partner/), or the [function](/artifacts/small-team-operating-model/) around them. The whole method is one honest rung at a time, in order. It is the same answer as [where to start at all](/faqs/where-do-i-start/): one workflow, one owner, one real question, done before you start the next. --- ## [FAQ] Who on my team should own AI? Canonical URL: https://translationalintelligence.com/faqs/who-should-own-ai/ Date: 2026-07-16 Summary: The T-shaped operator your people already trust, not your most technical person and not an outside hire. Look for the shape, not the title. Look for a shape, not a title. The right owner is T-shaped: deep enough in one part of the work to be respected, broad enough to see across the whole company, and genuinely curious about what the tools can now do. They can spend about 20% of their week on this without dropping the job you already value them for. In practice that is often a chief of staff, a head of operations, or a respected program lead. It helps to be clear about who it is *not*. It is not your most technical person by default, because the job is translation and trust, not engineering, and your best builder is often not your best persuader. It is not an outside hire, because the hardest part of the work is [changing how respected colleagues do their jobs](/permission-people-programs/), and that trust does not transfer with a contract. And it is not simply your loudest AI enthusiast, because enthusiasm is not the same as the trust of the room, and this job runs entirely on that trust. So the test is simple. Who already gets listened to, across functions, and would be curious enough to spend a fifth of their time here? That person is your owner. The full model for running it at your size is [The Small-Team Operating Model](/artifacts/small-team-operating-model/), and the role it scales down from is [the AI Product Partner](/ai-product-partner/). --- ## [FAQ] Can I use AI in a validated workflow? Canonical URL: https://translationalintelligence.com/faqs/ai-in-a-validated-workflow/ Date: 2026-07-17 Summary: Two different questions usually hide in that one. Drafting a document a human owns is not the same as putting AI inside a validated system of record, and mostly the second is where validation bites. Regulatory Two different questions usually hide inside that one, and much of the time they have different answers. What follows is the shape of the constraint, with the controlling sources linked, not legal advice. Confirm the specifics with your own quality and regulatory function. If AI is drafting a document a qualified human owns and reviews, a clinical study report, a safety narrative, a submission summary, you are mostly in People and Programs territory. The human is the author of record, your normal quality review still applies, and the main environment question is the data class from your [AI Use Policy](/artifacts/ai-use-policy/): patient data and unfiled results stay in your approved, enterprise-secure environment. That is closer to your existing accountability applied to a faster first draft than to a new regulatory frontier. It is not automatically free of validation questions, though: if that draft is generated or maintained inside a system that keeps a regulated record, the intended use, the inputs, and how the output is used can still pull it across the line. If AI is becoming part of a system that creates or maintains a GxP record, that is a different matter. Now you are in computer-system-validation and [21 CFR Part 11](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11) territory, records the agency has to be able to trust, with audit trails, access controls, and validation. It is your quality and regulatory function's call, not something to route around. Do not relitigate that gate out of principle. Do the Permission work once, choose controls you can stand behind, and bring quality in early. If the AI is being used to help establish safety, effectiveness, or quality, the FDA's 2025 [draft guidance on AI to support regulatory decision-making](https://www.federalregister.gov/documents/2025/01/07/2024-31542/considerations-for-the-use-of-artificial-intelligence-to-support-regulatory-decision-making-for-drug) sets out a risk-based credibility framework tied to the model's context of use. Most of the early value sits in the first case, not the second. So start where a human owns the output and the data is already yours to use, prove it, and let your quality function help you move the harder line deliberately. The full picture is [Where AI Touches a Clinical-Stage Biotech](/artifacts/clinical-stage-ai-map/). ## Sources - FDA and EMA, [Guiding Principles of Good AI Practice in Drug Development](https://www.fda.gov/media/189581/download) (January 2026), ten joint principles spanning the medicine lifecycle, from research through manufacturing and safety monitoring ([EMA announcement](https://www.ema.europa.eu/en/news/ema-fda-set-common-principles-ai-medicine-development-0)) - FDA, [21 CFR Part 11, Electronic Records; Electronic Signatures](https://www.ecfr.gov/current/title-21/chapter-I/subchapter-A/part-11) (eCFR, current) - FDA, [Considerations for the Use of Artificial Intelligence to Support Regulatory Decision-Making for Drug and Biological Products](https://www.federalregister.gov/documents/2025/01/07/2024-31542/considerations-for-the-use-of-artificial-intelligence-to-support-regulatory-decision-making-for-drug) (draft guidance, Federal Register, January 2025) - ICH, [E6(R3) Good Clinical Practice](https://www.ema.europa.eu/en/documents/scientific-guideline/ich-e6-r3-guideline-good-clinical-practice-gcp-step-5_en.pdf) (Step 4 reached January 2025; linked here as EMA's Step 5 implementation), on computerised systems and data integrity - EMA, [Reflection paper on the use of AI in the medicinal product lifecycle](https://www.ema.europa.eu/en/use-artificial-intelligence-ai-medicinal-product-lifecycle-scientific-guideline) (2024) --- ## [FAQ] Should I keep AI away from my most important work? Canonical URL: https://translationalintelligence.com/faqs/ai-on-your-best-work/ Date: 2026-07-20 Summary: Not never. But in a resource-constrained shop, point it at the low-judgment work first, and spend the bandwidth you free on the work only your best people can do. Not as a rule. But the instinct to aim AI at your most important work first is usually the wrong allocation, and it is worth understanding why. Your most important work is often also your highest-judgment work, the kind that needs your best people's judgment, not just their time. A BLA narrative is the clearest example: it carries data analysis and a standard of perfection only an expert can hold. You *can* use AI to clear the blank page there, with a human owning every line. But if your experts are your bottleneck, spending their scarce attention supervising AI on the work that most needs them is not where automation pays. The higher-return move, especially when you have more work than experts, is to point AI at the [high-enterprise, low-judgment corner](/artifacts/value-map/) first: the work the business needs but that does not draw on your best people's judgment. Resist sorting by whole document type, though. It is tempting to say point AI at the INDs and protect the BLAs, but that is too coarse. Some IND work is the highest-judgment work you have, and some of a BLA is routine drafting. Decompose the work to the section and the task, aim AI at the parts that consume expertise without requiring it, and spend the freed bandwidth on the parts only your experts can carry. So the question is never whether AI is allowed to touch important work. It is what freeing your best people would let them do instead, and whether that is better. Point AI at the grind on purpose, and reserve your genius for where genius is required. The full argument is [Don't Point AI at Your Best Work](/dont-point-ai-at-your-best-work/). --- ## [FAQ] If AI finds no red flag, is the target safe? Canonical URL: https://translationalintelligence.com/faqs/no-red-flag-safe-target/ Date: 2026-07-20 Summary: No. A clean day-one pass is not a clear. It means AI found no reason to stop in what it searched, which is not the same as no reason existing. No, and the gap between those two things is the whole discipline. When an AI-assisted [target safety read](/artifacts/target-safety-triage/) comes back clean, it has told you one thing: in the databases and literature it searched, it did not surface a disqualifying signal. That is genuinely useful. It is not the same as the target being safe, and treating it as if it were is how a program talks itself into false confidence. The asymmetry is the point. A disqualifying signal AI surfaces can earn a no, but only once you have verified it at the source and read it against your modality: an embryonic-lethal knockout, a broad and essential expression profile, a human genetic association with the exact toxicity you feared. Confirm it, interpret it, then act on it. But a clean pass is not a yes. Absence of evidence is not evidence of absence, and the machine has told you where it looked, not what is true. It did not run the assays. It did not read the paper that is not yet indexed. It did not know your modality's quirks. So a clean day-one read does not clear the target. It earns it the expensive human assessment, which now begins, not ends. Hand it to your safety scientist with the collection already done, and let them do the part that was always theirs: the judgment. Trust a verified signal, not the model. Never trust the silence. The longer version is [The Fast No](/the-fast-no/). --- ## [FAQ] Can I use an AI first draft in a regulated document? Canonical URL: https://translationalintelligence.com/faqs/ai-first-draft-in-a-regulated-document/ Date: 2026-07-21 Summary: For framing and a running start, yes. As the submission, no. The draft clears the blank page; the human writing, review, and quality process is untouched, and the author of record stays human. Yes, for the right part of the job, and it is a bright line worth stating plainly. Use an AI first draft as scaffolding: a running start on structure and language that clears the blank page, which is the most expensive part of regulated writing. That is a legitimate, valuable use, and it is where the backlog actually lives. What you do not do is treat that draft as the submission. Everything that reaches a regulator, the sourcing, the argument, the precision, the review, is the decisive work, and it stays human. AI-drafted content goes through your full, normal writing, review, and quality process, unchanged. No AI-generated text should go to an agency as-is, and the [author of record stays a human being](/there-is-no-ai-work-product/) from the first draft to the final filing. A machine producing the first version does not move accountability by an inch. The precise controls, what your review must include, what has to be documented, how validation applies, are not a question for a case study. They are a question for [your own quality and regulatory function](/artifacts/clinical-stage-ai-map/), and nothing here is a substitute for their judgment or for the controlling guidance. The worked example is in [The Blank Page Is the Expensive Part](/the-blank-page-is-the-expensive-part/). The rule it lives by: escape the blank page, never skip the work. --- ## [FAQ] How long should we keep AI meeting transcripts? Canonical URL: https://translationalintelligence.com/faqs/how-long-to-keep-ai-transcripts/ Date: 2026-07-21 Summary: There is no magic number. Default the raw transcript to auto-delete, set the timer with your legal and records functions, and never let it override a legal hold or a required regulated record. Short answer: default them to delete, and set the actual number with the people who own the risk, not the people who own the calendar. The instinct to keep everything is exactly backwards. An imperfect transcript that lingers forever is a permanent, discoverable record of things that may never have been said. So make the default state gone: configure the raw transcript to auto-delete on a timer, in the system, not as a suggestion people are asked to remember. Keeping one should be a deliberate act, and the moment a person keeps it, [they become the author of record](/there-is-no-ai-work-product/) and owe it the cleaning and verification that turns it into a real minute. How long is the timer? That is a genuinely legal question, and it is not one a case study can answer for you. Two hard constraints sit above any number you pick. Once litigation is reasonably anticipated, a duty to preserve can attach to electronically stored information regardless of your deletion policy ([FRCP 37(e)](https://www.law.cornell.edu/rules/frcp/rule_37)). And some regulated records carry their own affirmative retention requirements that your timer must never delete. Set the number with your legal, compliance, and records-retention functions, and check it against your own regulatory obligations if your meetings touch regulated work. The worked example, and why the ownership rule and the timer need each other, is in [Delete It by Default](/delete-it-by-default/). --- ## [FAQ] Isn't teaching the whole company the policy too expensive? Canonical URL: https://translationalintelligence.com/faqs/isnt-teaching-the-whole-company-too-expensive/ Date: 2026-07-21 Summary: Yes, and the expense is the point. Senior time spent teaching is the signal that the policy matters. The cheap alternative, a PDF on a shared drive, is what produces a policy nobody follows. Yes. It is expensive, and that is not a flaw in the plan. It is the plan. A senior leader spending hours teaching an AI policy in person, in small doses, is costly, and the cost is exactly what carries the message. Spending it says, at a level no email can, that this matters and that the person accountable for it will sit with you and answer your question to your face. The "cheap" alternative, shipping the policy to a shared drive and linking it in a deck, is not actually cheaper. It just moves the cost somewhere you cannot see it: into the [gap between a policy that exists and a policy people follow](/people-first/), where good people default to responsible conservatism and quietly decide on their own what is allowed. So do not price it as training overhead. Price it as the difference between a policy that works and a document that does not. Two things make the spend finite. The questions you collect while teaching become FAQs that make each session faster than the last. And you are not buying a permanent line item: you teach until the knowledge has spread far enough that the organization can teach itself, then you wire acceptance into onboarding and step back. If no one senior will spend the hours at all, you do not have an enablement plan. You have a PDF. The worked example is in [A Policy Is Only as Good as It Is Understood](/a-policy-is-only-as-good-as-it-is-understood/). --- ## [FAQ] How do I justify a win that doesn't show ROI? Canonical URL: https://translationalintelligence.com/faqs/justify-a-win-without-roi/ Date: 2026-07-21 Summary: You don't, not on ROI. Fund a small slice of time that is deliberately exempt from the business case, and measure it on adoption and belief, because the return is a change agent, not saved hours. You are asking the wrong metric to carry the wrong kind of win, and if you insist on ROI you will kill exactly the thing you most need. Some AI wins pay back in hours. Grade those on hours. But the first wins, the ones whose real product is a believer, do not show up on that ledger. Their value is what they start: a respected peer who has done the thing, in the open, and will not stop talking about it. That is worth more than a spreadsheet can hold, and it is invisible to every efficiency metric you own. So do not try to justify it on ROI. Do two things instead. First, carve out a small slice of time or budget that is deliberately exempt from the business case, the way a research line is. Call it what it is: money spent to find and fund belief, not to bank hours. Second, measure it on the thing that actually matters, [adoption, not deployment](/people-first/): did a person change how they work, and did they bring someone else along? A company that funds only what pencils out will never fund the thing that shifts its culture, because culture change never pencils out in advance. The [full argument is here](/the-product-is-belief/), and the [Scope Ladder](/scope-ladder/) is how you keep an eye on whether the small win is actually climbing. --- ## [FAQ] Isn't efficiency a good place to start? Canonical URL: https://translationalintelligence.com/faqs/isnt-efficiency-a-good-place-to-start/ Date: 2026-07-21 Summary: Yes, as the on-ramp. No, as the destination. Take the hours back, then spend them on redesign, not on a faster version of the same company. Yes, and it is the most dangerous place to stop. Efficiency is a fine on-ramp. The hours you save fund the harder work, and the early, visible wins buy you the political capital to attempt something that actually changes the company. Small wins build the habit that larger change stands on. So take the efficiency. That is not the mistake. The mistake is banking it as the destination. When you automate a process, you also freeze it. You take a workflow shaped by the limits of an older technology and pour fresh concrete around it. Faster concrete, still concrete. You made yesterday permanent and called it progress. A year later you are quicker at the same documents, the same meetings, the same decisions in the same order, and you wonder why nothing feels different. So the test is not whether you took the efficiency win. Take it. The test is what you spend it on. Efficiency that funds a redesign is the first move of a transformation. Efficiency that funds next year's slightly faster version of the same company is a dead end with good margins. The way to tell them apart is to [name the size of the change](/scope-ladder/) you are actually attempting, and to be honest that a faster workflow is one rung, not the whole climb. The long version is in [The Biotech of Tomorrow](/the-biotech-of-tomorrow/). --- ## [FAQ] Should AI report to IT? Canonical URL: https://translationalintelligence.com/faqs/should-ai-report-to-it/ Date: 2026-07-21 Summary: Not by default. Point AI at your most forward-thinking senior leader, high in the company. If IT is involved, its mandate has to change from control to enablement, or you have pointed the future at the department of no. Not by default, and the default is the trap. IT is the reflexive home for anything technical, so AI lands there without anyone deciding it should. The problem is not competence. It is mandate. In a regulated company, IT was built over two decades to control: validated systems, access, data integrity, audit trails. That is real and necessary work, and it trains a function to protect the company by slowing the new thing down. Point your AI ambition at a function whose whole reflex is to say no, and you get exactly that. So the better instinct is the opposite one. AI is not one more system to lock down; it is the capability the whole company now runs on, which means its owner should be your most forward-thinking, respected senior leader, high in the company, not a compliance silo. [Give it a real owner](/ai-product-partner/), close to the ambition. If your AI does end up connected to IT, the reporting line is only half the job. The mandate has to change with it, from "prevent the bad" to "enable the responsible," and the function has to be rewarded for the new mandate rather than for tickets closed and incidents avoided. Otherwise you have renamed the department of no and changed nothing. Governance done this way is not a brake; it is the shaping cone that turns a blast into directed flight. The worked example is in [Don't Default AI to IT](/dont-default-ai-to-it/). --- ## [FAQ] How do I know I can trust any of this? Canonical URL: https://translationalintelligence.com/faqs/how-do-i-know-i-can-trust-this/ Date: 2026-07-28 Summary: Because it shows its work. Every claim is labeled by what kind of claim it is, sources are primary and linked, and corrections happen in the open. Fair question, and the right one to ask of anyone telling you how to run your company. The short answer is that this is built to be checked, not believed. Three things make that real. First, every consequential claim is labeled by what kind of claim it is: doctrine (my argument, offered to be used and argued with), an operator heuristic (a rule from experience, test it against your own numbers), evidence-backed (primary research or multiple independent cases, linked at the foot of the piece), or regulatory (tied to a controlling document, linked, and written to be checked by your own quality and regulatory function). Most of the numbers here are honest operator heuristics, and they say so. Calling a heuristic a heuristic makes it stronger, not weaker. Second, sourcing is primary over secondary, vendor marketing statistics are treated as suspect, and there are no invented or decorative citations, ever. If no honest source exists, the claim stands as a labeled heuristic or it does not stand at all. Third, this is AI-assisted human work product, disclosed as such, with Alexander Titus as the author of record for every word, number, and diagram. When something is wrong, it gets fixed in the open. The full accounting lives in the [editorial standards](/standards/), and the site even [audited itself in public](/case-studies/built-by-its-own-rules/) to prove the rules bind. Do not trust a framework because it is persuasive. Trust it because it survives contact with reality, and tell me where it does not. --- ## [FAQ] We have the tools. No one's using them. Now what? Canonical URL: https://translationalintelligence.com/faqs/tools-but-no-adoption/ Date: 2026-08-04 Summary: The problem is not the tools; it is that deploying a tool is not the same as adopting it. Adoption is a people problem, and you fix it people-first, not by buying more software. Stop shopping. The instinct, when a tool sits unused, is to wonder whether you bought the wrong one. Almost always, you did not. Deploying a tool and adopting it are different acts, and the gap between them is not technical. It is human. Adoption is a behavior change, and behavior change is slow, social, and personal. A license does not change how a scientist with a decade of method decides to work. A respected peer does, once they show it is safe and worth it. So the fix is not more software. It is to lead the human change you skipped. Concretely: find one respected person and solve one real, small problem with them; turn that convert into an ambassador; teach in person, in small doses; make responsible experimentation safe; and measure adoption, not deployment. That sequence is [The People-First Playbook](/artifacts/people-first-playbook/), and it is the whole job. The longer argument is [People First, or Not at All](/people-first/), and the worked example is [Avidity](/case-studies/fifteen-minutes-at-a-time/), where a policy became behavior fifteen minutes at a time. If your tools are unused, you do not have a tool problem. You have a people problem wearing a tool problem's costume, and no purchase order will fix it. --- ## [FAQ] How do I keep an AI pilot from stalling? Canonical URL: https://translationalintelligence.com/faqs/keep-a-pilot-from-stalling/ Date: 2026-08-11 Summary: Stop letting a demo authorize a build. Prove adoption at each rung before you fund the next, and let the prototype find the real problem instead of selling a roadmap. Stop letting a demo authorize a build. The pilots that stall are almost always the ones a company invested in *before* it had proven anyone would use them, which is the real lesson under [the widely quoted claim that ninety-five percent of AI pilots fail](/the-demo-is-a-question-not-an-answer/). Fund adoption, not ambition. In practice that is a sequence, and each step is a cheaper way to fail than the one after it. First, [buy what you can](/artifacts/build-vs-buy/). Most asks should end here, with a tool you did not have to make. Only the work you cannot or will not buy has any business becoming a build. Second, put a person at intake, not a ticket queue. An [AI Product Partner](/ai-product-partner/) reframes the request before anyone writes a requirement, because the person asking usually cannot yet name what they need and reaches for a solution instead of describing the pain. A one-day clickable prototype is how you drag that real problem into the open, cheaply. Treat it as a question, not a pitch. Third, climb one rung at a time. Let a prototype earn a single-workflow app, let real demand earn a program, and let only the rare survivor earn durable infrastructure. That is [the Scope Ladder](/scope-ladder/) applied to a build, and it keeps every step matched to the traction it has actually proven. Fourth, keep the right to stop. If the pain is solved at a smaller rung than you planned for, that is the method working. End the project and move the budget to the next real problem instead of building the platform you no longer need. The tell that you are about to join the ninety-five percent is simple. You can describe the demo in vivid detail but not the changed behavior it produced, and you are budgeting a platform before a single workflow has run a new way. When that is true, you do not have a pilot yet. You have a question you have not asked cheaply enough. The full argument is in [The Demo Is a Question, Not an Answer](/the-demo-is-a-question-not-an-answer/), and the worked example is [Four Rungs, and the Courage to Stop](/case-studies/four-rungs-and-the-courage-to-stop/). --- ## [FAQ] Do I hire an AI Product Partner, or grow one? Canonical URL: https://translationalintelligence.com/faqs/hire-or-grow-ai-product-partner/ Date: 2026-08-18 Summary: Usually grow one, from someone who already understands the work. The scarce half is judgment, not tools. Grow one, in most cases. The role rewards range over pedigree: product judgment, enough technical fluency to tell commodity from advantage, real curiosity about how your scientists and operators work, and the humility to discover the original problem was the wrong one. The tool fluency is the easy half to teach. The judgment and the empathy are not. So look first for someone who already knows a function well enough to see its friction, and whom people trust, then give them the AI fluency and the standing to act. Standing matters more than the reporting line. They need real authority across Permission, People, and Programs, not a seat buried in a backlog taking tickets. Where do they sit? Close to the work, not off in a central lab. The whole point of the role is to live where capability meets the work, and to change how it happens. The full role is on [The AI Product Partner](/ai-product-partner/). --- ## [FAQ] How does the AI Product Partner role actually start? Canonical URL: https://translationalintelligence.com/faqs/how-does-the-ai-product-partner-role-start/ Date: 2026-08-25 Summary: Not on an org chart. Point a trusted translator at a real, cross-functional problem, and let the role reveal itself before you name it. You do not start it by writing a job description. The role tends to appear the other way around. A real, cross-functional problem shows up, work starts collecting around it that no one owns, and someone has to translate between the people who know the work and the people who can build. You name it after you have seen its shape, not before. That is exactly how it happened in [Inside the Role](/inside-the-role/). The gap showed up before the title did. The work that gathered around a hard problem needed someone to turn scattered concerns into clear requirements, and the role was obvious only once it was already being done. So the first move is not a hire, and it is not a tool. It is a real problem and a trusted person, given the standing to work across functions instead of taking tickets. Once you have watched the role happen, write it down, using something like [The AI Product Partner Role Definition](/artifacts/ai-product-partner-role-definition/), so the next person does not have to rediscover it from scratch. The full role is on [The AI Product Partner](/ai-product-partner/). --- ## [FAQ] What does an AI Product Partner actually do all week? Canonical URL: https://translationalintelligence.com/faqs/what-does-an-ai-product-partner-do-all-week/ Date: 2026-09-01 Summary: Less than the title suggests and more than a calendar shows. The clearest picture of the job is one real week, from the morning briefing they built to the two lines they write in the board deck. If you want to know whether you need [this person](/ai-product-partner/), do not read the job description. Watch their week. It starts before the first meeting. They open a briefing they built for themselves, one that has already read their inbox, their calendar, and yesterday's meeting notes and handed back a single screen: what changed, what needs an answer, who owes what. They run their own automations first, every day, because they will not ask anyone to trust a habit they do not keep. Most of the week is people. An hour sitting beside a regulatory writer, watching how a submission actually gets built, then showing them a faster path. One or two coaching sessions. Office hours anyone can walk into. A standup here, a discovery interview there, hunting for where the real time goes. And one honest sync with leadership, so what the company wants and what is actually happening stay the same story. Then the week widens into the month. A bigger training push. A short roundup of wins, so progress is seen and not just felt. Two lines in the board deck, in the company's own language. A check-in with the outside vendors. Notice what none of that is measured by. Not a full calendar, which anyone can produce by Thursday. It is measured by whether a team runs its own workflow now, whether the person who was scared of the tool in week one is teaching it in week six, and whether work stopped landing on engineering because people can finally handle it themselves. A busy AI Product Partner is not the goal. A company that no longer needs them for the small things is. The full picture, and how the week changes as the job grows from a fractional owner to a Head of AI Enablement, is in [The AI Product Partner Role Definition](/artifacts/ai-product-partner-role-definition/). --- ## [FAQ] When do I add the next person, and to which seat? Canonical URL: https://translationalintelligence.com/faqs/which-ai-team-seat-to-hire-next/ Date: 2026-09-08 Summary: Weight the hires to the top of the funnel. The deep engineering seats compound; the enablement seats hit their ceiling first. Weight your growth toward the top of the funnel, roughly two or three additions at the enablement and forward-deployed layers for every one at the platform and system layers. The instinct is to scale evenly, one engineer for every enabler, but that gets the ratio backwards. The reason is leverage. If your system engineer has been building abstracted components, each piece serves many applications rather than one, so a single deep-engineering seat supports a growing pile of work above it without a matching increase in its own load. Enablement and forward-deployed work does not compound that way. It happens one team at a time, which means those seats hit their ceiling first. So read the queue, not the org chart. When the team is underwater, the constraint is almost never a missing database engineer. It is that the line of departments waiting for someone to sit with them has stretched to three months. That is the signal, and it points at the top of the funnel. The full team is on [The Innovation Engineering Team](/innovation-engineering-team/), and the enablement seat is [The AI Product Partner](/ai-product-partner/). --- ## [FAQ] What will the first 90 days cost? Canonical URL: https://translationalintelligence.com/faqs/what-will-90-days-cost/ Date: 2026-09-15 Summary: Mostly attention, not budget. The real cost is one owner's 20% and an honest scorecard meeting. If you are writing a big check in the first quarter, you are doing it backwards. Mostly attention, not budget. The real cost of the first quarter is one owner's 20% of a week and the honesty of a single scorecard meeting. Almost everything else you need, you already have, because the licenses are usually sitting in a drawer and the point of the [first 90 days](/artifacts/first-90-days/) is to use them, not to buy more. So resist the instinct to make it expensive. Writing a big check feels like commitment, and commitment feels like seriousness, but at a sub-100-person company the serious move is the cheap one. Do not buy a platform in the first quarter. You have not yet earned the signal that tells you which one you need, and once you have shipped a workflow or two, you may find you never needed it at all. Run each request through the [five moves](/artifacts/build-vs-buy/) before any money moves. The genuinely expensive version of this is the one you are trying to avoid: buy the platform first, adopt it never, and spend the next year explaining a line item that changed nothing. Spend attention this quarter, not budget. If you want the week-by-week version, it is [The First 90 Days](/artifacts/first-90-days/). --- ## [Case Study] Built by Its Own Rules Canonical URL: https://translationalintelligence.com/case-studies/built-by-its-own-rules/ Date: 2026-07-11 Summary: The strongest test of a system is whether its author will use it. This publication was built with the exact framework it teaches, AI-assisted and human-accountable. Here is how, including where I was breaking my own rules. The strongest test of a system is whether its author will use it. Not describe it, not sell it, use it, on their own work, in public, where the gaps show. So here is the most honest thing I can hand you: this publication, built with the exact system it teaches. Every claim in it, applied to itself. ## What this is [Translational Intelligence](/translational-intelligence/) is the capacity to turn new capability into durable advantage, again and again, as the technology moves. This site is that capacity made concrete. It has a [system](/permission-people-programs/), a [discipline](/buy-record-build-intelligence/), a [role](/ai-product-partner/), and a [destination](/ai-native-biotech/). I did not only write about them. I built the thing you are reading by their rules, and this is the accounting. ## Buy the record, build the intelligence The stack is a live example of [the discipline](/buy-record-build-intelligence/). I bought the commodity, the system of record, and I built the layer that is mine. > [Diagram: Bought the record, built the intelligence] Astro and Keystatic hold the pages. Beehiiv sends the email. Cloudflare serves it, GitHub holds the source, and the frontier models do what frontier models do. None of that is where the advantage lives, and writing my own would have been vanity. What I built is the layer that is genuinely mine: the design language, a signature diagram in every piece, the [Artifact Library](/artifacts/), the voice, and the way every page links into one connected argument instead of a feed. No vendor could sell me that, because no vendor has my problem. And it leans build more than the old wisdom would, on purpose. The [ethos](/stop-swinging-for-the-fences/) is that in this era the line has moved toward build, and that adoption is won by solving small. This site is a stack of small builds, each one shipped before the next was started. ## There is no AI work product Here is the part most publications about AI will not say out loud. This one is AI-assisted. I use AI to draft, to argue with, and to build the site itself. And [there is no AI work product, only AI-assisted human work product](/there-is-no-ai-work-product/). I am the author of record. Every claim, every number, every diagram, I own completely, whether I, a colleague, or a model produced the first version. That is not a hedge or a disclaimer. It is the standard I ask you to hold, and I am holding this publication to it in the open. A standing note now sits on the [About](/about/) page, because I preach disclosing AI assistance where it is material, and for a publication about using AI well, it is material. ## I do not automate the struggle I do not use AI to skip the thinking. I use it to reach the hard part more often. The ideas start with me: an argument I have been circling, a contradiction I cannot yet resolve, a claim I suspect is true but cannot defend. Only then do I put the model to work, and I put it to work making the problem *harder*, not finishing it. The [Think-Harder Writing Workflow](/artifacts/think-harder-workflow/) is not a theory I admire. It is the process that produced every piece here, this one included. ## Where I was breaking my own rules A case study that shows only the wins is exactly the *premature coherence* I warn about. So before I published this, I audited the site against its own written rules. Here is what I found. Every Issue is supposed to carry its own signature diagram. When I ran this audit, the founding piece was the one exception. It has one now, added the same day I wrote this. A rule you write down only means something if the gaps get closed, not just noted. I preach disclosing AI assistance where it is material, and until this study there was no disclosure anywhere on the site. That was a real gap in the thing I most insist on. It is why the [About](/about/) note now exists, and why this case study does. The cadence labels, the Tuesday and Friday stamped on everything, had drifted from useful into decorative, so I cut them back to where they inform. None of these are catastrophes, and that is the point. The value of holding yourself to a standard you wrote down is that the gaps come out small and findable, instead of large and hidden. A company that never audits itself against its own rules does not have fewer gaps. It just has not looked. ## Monday morning If you want to know whether a system is real, watch whether its author will apply it to themselves, in public, with the gaps left in. Try the thing this piece just described. Take your own AI strategy, the version you would show your board, and audit it against the rules you have written down. If you have not written the rules down, that is the first gap, and it is the biggest one. Then fix the smallest thing you find this week. That is where it starts. It is where this started too. --- ## [Case Study] The Task Was Never the Point Canonical URL: https://translationalintelligence.com/case-studies/the-task-was-never-the-point/ Date: 2026-07-14 Summary: A junior analyst automated one repetitive task in an afternoon. The hours saved were trivial. What it started was not. One convert became an AI Ambassador, and a whole department began to reimagine its work. The facts behind [The Product Is Belief](/the-product-is-belief/): a real engagement, and what it actually produced. ## What happened On the procurement team at a clinical-stage biotech, a junior analyst had a recurring chore. Every time the company onboarded a new vendor, he drafted the same email, attached the same four PDFs, and sent it. Same words, same files, every time. By the org chart he was nobody's priority: too junior to command an engineering team, the problem too small to carry a business case. The AI team found it by running 20% time on lifestyle improvements, a standing invitation to bring in the small, personal friction in your day rather than the strategic initiative. He brought the vendor email. The fix was trivial: a small automation assembled the message, pulled the four attachments, and produced a finished draft in one click. Measured in hours saved, it was a rounding error. It was governed from the first line. The tool could only ever *draft*, never send. The analyst stayed the author of record: he read every draft, approved it, and sent it himself. That is [the standard the whole company runs on](/there-is-no-ai-work-product/), and it applied to a four-PDF onboarding email exactly as it applies to a regulatory submission. ## What it produced The measurable time saved was negligible. The consequence was not. The analyst became a believer, because the thing worked and it was his. He joined the AI Ambassador program, the distributed network of non-experts who carry capability into their own functions, and became the person in procurement who had actually done it, standing in front of his peers as social proof no central team could manufacture. Through his coaching, his teammates stopped asking "can you automate this one email?" and started asking how they would run the whole process if they designed it today. One eliminated task became a function beginning to interrogate its own workflows, climbing the [Scope Ladder](/scope-ladder/) from a personal practice toward a function reimagining itself. ## The conditions that made it work Three specifics carried it, and they are the part to copy, not the automation: - **Dedicated time to go looking low.** Without the 20% time, someone with the tools never sits with the person who has the problem, and the analyst sends the email by hand for another three years. - **A program to catch the convert.** The [Ambassador program](/permission-people-programs/) gave the believer a role. A win with nowhere to go stays a private win. - **No ROI gate.** Graded on hours saved, this dies in a spreadsheet. Its entire value was in what it started, which no efficiency metric will show you. The argument for why this is the right place to start, and how to run the play yourself, is in [The Product Is Belief](/the-product-is-belief/). **How this was measured.** This is a firsthand account; the compounding from one convert to a function reimagining its work is qualitative, not measured. A directional operator account from a single individual and function. --- ## [Case Study] Better Than a Blank Page Canonical URL: https://translationalintelligence.com/case-studies/better-than-a-blank-page/ Date: 2026-07-15 Summary: A wall of INDs and BLAs the writing team could not reach, and twelve months of no. Then three days in a room proved that a first draft at 60 to 75 percent beats a blank page, and a resistant team finally had its aha. The facts behind [The Blank Page Is the Expensive Part](/the-blank-page-is-the-expensive-part/): a real engagement, and what the demonstration actually produced. ## What happened A clinical-stage biotech had a wall coming: a stack of INDs and BLAs to file that ran well past what the regulatory writing team could physically reach in the time it had. The executive team wanted regulatory to trial AI for first drafts. The team said no, and held that no for twelve months, because it owns some of the highest-stakes documents in the company and was being asked to trust a new tool with exactly the work it is most accountable for. The stall broke when a member of executive leadership stepped in and mandated a trial. The company had signed a six-figure vendor trial; alongside it, we ran a head to head. Over three days in a room, working with the company's standard, already-paid-for tools, we drafted real first-draft sections of an upcoming IND, not a demo document. ## What it produced Two results. The drafts made with standard tools were far better than what the six-figure paid trial produced, so the vendor check was never the right first move. And the drafts landed at roughly 60 to 75 percent of a usable first draft, which was enough for several members of the writing team, watching a draft of their own work appear, to be dumbfounded. After twelve months of argument, the aha arrived in an afternoon, and the momentum that followed was large. Precisely what it was: no AI-generated text went to the FDA. The first drafts were framing and a running start on structure. The team did the decisive work, the sourcing, argument, precision, and review, and the [author of record was human](/there-is-no-ai-work-product/) throughout. Every section went through the standard writing and quality process. ## The conditions that made it work - **Permission spent to force the trial.** Without an executive using real capital to end the stall, the wall just gets closer. A demonstration nobody will authorize converts no one. - **A real head to head before the check.** The needed capability was already inside tools the company owned. [Test your own baseline](/buy-record-build-intelligence/) before signing a paid trial. - **The draft is a start, not a submission.** In regulated work, treating a 60-to-75-percent draft as finished turns a good tool into a liability. What the full review must include is a question for [your own quality and regulatory function](/artifacts/clinical-stage-ai-map/). The argument for why a demonstration beats a year of no is in [The Blank Page Is the Expensive Part](/the-blank-page-is-the-expensive-part/). **How this was measured.** The 60-to-75-percent figure and the comparison to the vendor trial are the participating writers' qualitative, in-the-room judgment, not a blinded or standardized score. Treat it as a directional firsthand operator account from a single organization, not a controlled study. --- ## [Case Study] The 72-Hour Transcript Canonical URL: https://translationalintelligence.com/case-studies/the-72-hour-transcript/ Date: 2026-07-16 Summary: Everyone wanted AI meeting transcripts, and everyone feared them, the wrong details and the permanent discoverable record. The fix was to make the transcript delete itself in 72 hours, and to make downloading it the act that assigned responsibility, under company policy, for finalizing the record. The facts behind [Delete It by Default](/delete-it-by-default/): a real meeting-transcript policy, and the two mechanisms that carried it. ## What happened AI meeting transcripts were wanted and feared for two tangled reasons: accuracy (a misheard number or "not" becomes a confident, wrong sentence) and retention (an imperfect transcript that sticks around forever is a permanent, discoverable record). At a company I worked with, we governed the tool rather than banning it, with two mechanisms. - **Auto-delete at 72 hours.** Every AI transcript deleted itself on a timer unless someone acted, so an ephemeral draft could not harden into a permanent record. One hard exception, wired in from the start: a legal hold or a required regulated record always overrode the deletion and stopped the clock. - **Downloading assigns responsibility.** The moment a person downloaded a transcript, that person owned the accuracy, cleaning, verification, and finalization into real minutes, under company policy. An internal accountability rule that named who was answerable, not a change to the legal nature of the information. ## What it produced The two mechanisms need each other. Auto-delete alone loses useful notes and drives screenshot-hoarding; an ownership rule alone leaves a swamp of half-verified transcripts nobody owns. Together, the record does not exist unless a named person reached out and took it, and the taking is the acceptance of responsibility. Attention was expanded during the meeting; accountability stayed intact after it. Underneath sat a quieter decision: the tool was chosen by data tier. For confidential meetings, we used the tool that could restrict auto-sharing of the transcript to just the meeting owner; for the rest, either tool was fine. The AI feature was picked by the sensitivity of the data in the room, not by the incumbent vendor, which is the [Permission pillar](/permission-people-programs/) in one decision. ## The conditions that made it work - **Enforced, not announced.** The auto-delete was configured in the system on a timer; a rule people must remember to follow is a hope, not a mechanism. - **The number is a legal question.** The 72 hours never overrides a duty to preserve ([FRCP 37(e)](https://www.law.cornell.edu/rules/frcp/rule_37)) or an affirmative retention requirement; it was set with legal and records, not by convenience. - **Ownership only holds if the owner does the work.** Downloading has to be followed by real cleaning and verification, or you have relabeled an unverified transcript as "minutes." The argument for governing AI output this way is in [Delete It by Default](/delete-it-by-default/). **How this was measured.** This is a firsthand account of a policy design and its rationale from a single organization; its effects are described qualitatively, not measured, and the specifics are an operating example, not legal advice. --- ## [Case Study] Fifteen Minutes at a Time Canonical URL: https://translationalintelligence.com/case-studies/fifteen-minutes-at-a-time/ Date: 2026-07-17 Summary: At Avidity the AI policy was written by Legal, IT, and my team. Then I personally trained more than half the company on it, fifteen minutes at a time, because a policy that cannot be understood is functionally not a policy. The facts behind [A Policy Is Only as Good as It Is Understood](/a-policy-is-only-as-good-as-it-is-understood/): the enterprise rung, from the inside, at Avidity. ## What happened At Avidity, where I was the VP of AI, Legal, IT, and my team wrote an AI policy we believed in: the data tiers and where each was allowed to go, the position that [there is no AI work product](/there-is-no-ai-work-product/), and practical guidance on everyday questions. Writing it was the part everyone expects to be hard. It was not. The hard part was that a policy is worthless until the people it governs understand it well enough to act. So I taught it personally, to more than half the company, hundreds of people, in fifteen-minute increments. Not a recorded module or a memo from Legal, but in the room, walking each group through what the tiers meant for their actual Tuesday. Fifteen minutes at that scale is a large amount of a VP's calendar, and spending it was the message: this mattered, and the person accountable for it would answer your question to your face. ## What it produced The teaching went both ways. Every session surfaced things the policy had not anticipated; I turned them into FAQs and carried them back to refine the policy. It got better because I was explaining it. At first almost everyone defaulted to responsible conservatism, not using the tool to be safe, which looks like caution and is really just slowness. Teaching the reasoning, where the real risk lived and where it did not, broke the freeze, and people began to blossom. The person who would not touch a transcript in week one was, a month later, rethinking how their team ran meetings. Eventually it became self-sustaining: AI-policy acceptance went into standard onboarding and held, because a new person with a question could ask the colleague at the next desk. The organization could teach itself, which is the quiet signal that adoption is real. ## The conditions that made it work - **Senior time, spent visibly.** It had to be taught by someone senior enough that the hours themselves carried the message. If no one senior will spend them, you have a PDF, not an enablement plan. - **The questions refine the policy.** The rule got stronger because it was said out loud to skeptical people who found its weak spots fast. - **Responsible conservatism is information-hunger, not resistance.** The answer was never pressure. It was information, delivered by someone they trusted. The argument for why a policy has to be taught, not shipped, is in [A Policy Is Only as Good as It Is Understood](/a-policy-is-only-as-good-as-it-is-understood/). **How this was measured.** The reach (more than half the company) and the adoption arc are the operator's firsthand account; behavior change was observed in the room, not independently or quantitatively measured. A directional firsthand account from a single organization. --- ## [Case Study] The Shaping Cone Canonical URL: https://translationalintelligence.com/case-studies/the-shaping-cone/ Date: 2026-07-18 Summary: How a function defaulted to the department of no became the engine of responsible speed. IT reframed as Innovation Technology, reporting high, with governance as the shaping cone rather than the brake. The facts behind [Don't Default AI to IT](/dont-default-ai-to-it/): a real reframe of an IT function, and what changed. ## What happened At a company where I lead the AI and innovation strategy, AI and its guardrails sat where they usually do, with IT, a function a regulated industry had trained for two decades to protect the company by slowing new things down. Two moves changed that. - **The reporting line.** I made the case, the kind that raises eyebrows in most orgs, that IT should report up through me, close to the ambition rather than buried where new things go to be assessed. - **The mandate.** We rebranded the culture of the function from Information Technology to Innovation Technology. Same acronym, opposite mandate. The framing was explicit: this team is the shaping cone on a rocket engine, which does not stop the blast but turns raw energy into directed flight. Its job is not to block the new, but to ask of everything new, "how do we do this responsibly?" ## What it produced The function is a group of earlier-career people, and the rebrand lit them up. Being told you are a risk-management cost center is a very different thing from being told you are the foundational champions of the company's responsible-innovation engine. IT stopped being the last stop that kills momentum and became a foundational component of the AI strategy itself, the team that makes fast responsible instead of the team that makes responsible slow. ## The conditions that made it work - **Both moves, or neither.** A reporting change without a mandate change is a new box on an org chart; a rebrand without a reporting change is a poster on a wall. - **The mandate has to be real.** If "Innovation Technology" is still measured on tickets closed and incidents avoided, you have renamed the department of no and changed nothing. Change what the function is rewarded for, or the rebrand is theater. - **It is a culture change, not a structural one.** Moving the box is the easy half. The real shift is the same people starting from "how do we make this work, responsibly" instead of "what could go wrong," and you lead people to that, you do not restructure your way to it. The argument for why IT should not be AI's default home is in [Don't Default AI to IT](/dont-default-ai-to-it/). **How this was measured.** This is a firsthand, recent account of an org and mandate change from a single organization; its effects are described qualitatively and are still early, not measured against a baseline. --- ## [Case Study] Four Rungs, and the Courage to Stop Canonical URL: https://translationalintelligence.com/case-studies/four-rungs-and-the-courage-to-stop/ Date: 2026-08-11 Summary: How Avidity ran AI pilots so few of them ever stalled. An AIPP at intake, a Sub24-to-Platform ladder gated by traction, and the discipline to stop an ask the moment the pain was already solved. The facts behind [The Demo Is a Question, Not an Answer](/the-demo-is-a-question-not-an-answer/): how we actually ran AI pilots at Avidity, and why so few of them ever became the stalled kind. ## What happened Every ask ran a gauntlet before it earned a dollar of build. The first gate was [buy versus build](/artifacts/build-vs-buy/). We only built what we could not or would not buy, for reasons that deserve their own piece someday. The second gate was a person. Our [AI Product Partner](/ai-product-partner/) was the first line who took in a request and asked whether a no-code tool already solved it. Most of the time something did. Only when the honest answer was no did the ask move to engineering. Inside engineering we had built an **AI Hub**, shared infrastructure that let us prototype features and workflows quickly without standing up plumbing every time. Against it ran a four-rung ladder: **Sub24 to App to Program to Platform.** - A **Sub24** was a clickable prototype an engineer could turn around in under twenty-four hours of a narrowly scoped request. Its only job was to let the business partner *see* what they had actually asked for, because nine times out of ten they did not yet have the words for what they needed and reached for a solution instead of describing the pain. It pulled the real problem into the open, fast and cheap, before anyone committed to building anything. - An **App** was that one validated workflow built for real: a single self-contained tool that did exactly the thing and nothing more, deployed through the AI Hub so the partner could pilot it and give feedback without us standing up new infrastructure. - A **Program** was what an App became once it drew enough demand to justify more. That meant executive sponsorship, a resourcing conversation, and a commitment larger than a single self-contained workflow. - A **Platform** was the rare survivor that earned a place as durable, shared infrastructure meant to last. Most asks never reached it. The AI Hub the other rungs ran on was itself a Platform. ## What it produced Because investment followed traction rather than hope, we could pilot, take feedback, refine the request, and often decide to *stop*. A good number of asks were sunset once the project team concluded they were not solving the problem we had targeted, and that was the system working, not failing. The clearest example came from Legal, who asked for a way to assess contract clauses across many contracts. We had a full platform plan on paper. We prototyped and piloted it the way described above, and we stopped at the Program layer, because we had solved the pain earlier than we expected to. The platform never needed to be built. The money and attention it would have consumed stayed free for the next real problem. ## The conditions that made it work - **A person at intake, not a queue.** The AI Product Partner reframed the ask and routed it, and the no-code gate meant engineering only ever saw problems that genuinely needed building. - **The demo was a question, not a pitch.** A Sub24 existed to surface the true requirement in a day, not to impress a room into funding a roadmap. - **Investment was gated by traction, and stopping was allowed.** Nothing climbed a rung it had not earned, and an ask that solved its problem early was celebrated for ending, not pushed to justify its plan. - **It was human-first, not only technical.** Scaling resource commitments was paired with enabling and training the people who would use each tool, so traction meant real adoption rather than a login count. **How this was measured.** The ladder, the gates, and the Legal example are the operator's firsthand account. The "nine times out of ten" is a heuristic from experience, not an audited figure, and no independent success rate was calculated. A directional account from a single organization, offered as one worked example of the argument, not as proof of a number. ---