No computer science degree. Here is the case I make for an AI product role.

I should say at the top what this is and is not. I have not landed an AI product role. I am applying for them. So this is not advice from the other side of the door — it is the argument I am currently making, written down so it can be examined, and it may not work.

I am writing it anyway because the discussion around this is unhelpfully split between people insisting a degree does not matter and people insisting it does, and neither camp states the actual objection.

#The real objection, stated properly

Nobody serious believes a computer science degree is required to decide what a product should do. Plenty of excellent product managers have never had one and nobody thinks this is remarkable.

The concern about someone like me is narrower and it is legitimate:

Can you tell when the system is wrong? Or will you ship what it produced because it looked finished?

That is a real question about a real failure mode. Someone who can generate an application but cannot evaluate it will confidently ship something with an authorisation check that only exists in the interface, or a data model that lets any user read any record. The output looks the same either way from the outside. That is what a hiring manager is actually worried about, and "I am passionate about AI" does not touch it.

So the case has to be made against that question, not against the degree.

#What I would put in front of it

Evidence, not enthusiasm. Every item here is checkable, which is the only property that matters:

• Twenty-one products shipped independently, several publicly usable, across quite different problem domains — an encrypted inheritance vault, an autonomous agent fleet, a native Android app, an applied-AI system in a regulated industry.
• A language model trained from scratch for a narrow task, with a stated parameter count, a stated training set size, and a measured accuracy figure. Not fine-tuned — trained. That is an unusual thing to have done and it is the single artefact I would lead with.
• A second model fine-tuned and benchmarked against a standard evaluation, so the number means something to somebody who has run one.
• A documented security practice, including a system that carries dozens of automated security tests written across several independent audit passes.
• A written review discipline — every change read before it is accepted, no automatic acceptance, and I can talk about specific things that caught.

The reason those answer the objection is that none of them are claims about my attitude. They are things that either exist or do not, and they can be examined by anybody who wants to spend twenty minutes on it.

#What I would not claim, and why saying so helps

I am not an engineer. I could not sit a systems design interview against someone with ten years of production experience and I would not pretend otherwise. There are whole categories of problem — distributed systems failure modes, performance work at scale, the deep end of a language's semantics — where my knowledge is shallow and I know roughly where the edge is.

I include that because it is the thing that makes the rest credible. A person who claims a two-year self-taught path has made them equivalent to a trained engineer is telling you they cannot calibrate, which is exactly the deficiency the objection was about in the first place.

#What an AI product role actually requires

Product management is judgement about what should exist, for whom, and in what order. An AI product role adds a second requirement: knowing what these systems can and cannot actually do, which is a moving target and is not taught anywhere yet.

That second thing is learned by building with them and watching them fail, repeatedly, in circumstances where the failure costs you something. Two years of that is a more current education than a curriculum designed before any of these tools existed. It is not a better education. It is a more recent one, in a field where recency is unusually load-bearing.

And the first requirement — judgement about what should exist — is the part I have nine years of. Deciding what an audience actually wants, whether a proposition is believable, whether something lands. That was my job for a decade before I wrote a line of anything.

#How I would want to be tested

The strongest thing an applicant in my position can do is name the test, because it demonstrates the thing being tested. So:

1. Show me your product and ask me what is wrong with it. Not what I would add — what is confusing, what will be misread, where somebody will get stuck.
2. Ask me what happens when the model is wrong. In my own work, and then in yours. A candidate with no answer has not shipped anything real.
3. Ask me what I have refused to automate, and why. Judgement shows up more clearly in what someone declined than in what they built.
4. Ask me to scope something down. Take a feature and cut it to what actually ships this month. This is most of the job and it is where enthusiasm becomes visible as a liability.
5. Ask me to read something I did not write and say what concerns me about it.

I would rather be assessed on those five than on a credential, and if I fail them then the objection was right in my case and the hiring decision is correct.

#Where this actually stands

This argument has not yet succeeded. I am making it, it is on a public site attached to the work it refers to, and the market will decide whether it is any good. If it does not work, I would rather have made it explicitly than have wondered whether the phrasing on a CV was the problem.

If you are in a similar position, the transferable part is this: find the actual objection, which is almost never the one being said out loud, and answer that one with things a stranger can verify. Everything else is decoration.