AI Product Manager Portfolio: A Real Example, Annotated

Search for AI product manager portfolio examples and you get CV templates, salary pages and lists of things a portfolio "should include". You rarely get an actual portfolio with the reasoning behind it. So this essay uses the one I know best, the site you are reading, as a worked example. I have been an ML engineer at Cowlar Design Studio and an Associate Product Manager at ImagineArt, where ChatlyAI grew from 200K to 1.2M+ monthly active users, and I now do machine learning research at the University of Alberta. The site has to make that mix legible to someone who will spend a few minutes on it.

What follows is section by section: what each part of the page is for, what it is meant to prove, and the checklist I would hand anyone building their own.

What a hiring manager is actually checking

My view, from both sides of the product and engineering line: a reviewer looking at an AI PM portfolio is trying to answer three questions quickly.

1. Did this person make decisions, or just attend meetings? Feature lists don't answer this. A described trade-off does.
2. Do they understand the model well enough to be dangerous? An AI PM who can't talk about latency, evaluation or failure modes will struggle to hold their own in a room with ML engineers.
3. Can I trust the numbers? Every metric on the page is something they may ask about in an interview. One number that falls apart under a follow-up question costs more than three that hold.

Everything on a good portfolio should serve one of those questions. Anything that serves none of them is decoration, and decoration costs the reader time.

The worked example, section by section

The homepage of this site has six numbered sections under a short hero. Here is what each one is doing.

A contact section closes the page. Two choices are worth copying.

The hero carries evidence, not adjectives. The line under the headline names three things: 200K to 1.2M users at ChatlyAI, computer vision for a patented fiber-optic machine, and multimodal clinical ML at the University of Alberta. A reviewer who reads nothing else still leaves with three checkable facts. "Passionate, data-driven product leader" gives them nothing to check.

Three case studies, not twelve. The ChatlyAI case study, the fiber organizer and the smart shopping cart cover a consumer AI product, industrial computer vision and edge deployment. Everything else goes into a one-line index. A reviewer will read one case study properly, maybe two. Making them choose between twelve means they read none of them well.

Lead case studies with constraint and decision

Most portfolio case studies are written as feature tours: what we built, then screenshots. The case studies on this site use a fixed structure instead: problem, constraint, decision, outcome. Each one has those four fields, in that order, before any of the detail.

The constraint is the part most people skip, and in my opinion it is the part that does the most work. It is what makes the decision look like a decision. On the fiber organizer, the constraint was physical: fibers 250 microns across, alignment to 5 micrometers, on a production line where every second of latency is paid on every cable. Once a reader knows that, "sorting time went from about three minutes to eight seconds" reads as an engineering outcome rather than a brag. I wrote the longer version of what that project taught me in production ML on a factory floor.

The smart cart works the same way. Action recognition at 95% accuracy is a model metric. "95% accuracy in real time on edge devices" tells a reviewer the person understood that accuracy you can only deliver slowly is accuracy no shopper ever sees.

For an AI PM, the constraint is often where the AI understanding shows up. Latency budgets, data you don't have, evaluation you can't run yet, a model that is right 95% of the time and a product that has to behave sensibly the other 5%. Write those down. They are evidence that you know what you were managing.

Metrics you can defend in an interview

Here is the rule I use: every number on the page should be one I can source, explain and put in context without looking anything up.

• Source it. Know where the number came from: a dashboard, a release report, a public record. The fiber organizer is covered by viaPhoton's US Patent 12,001,073 B2, and my essay on that project links the patent so nobody has to take my word for what the machine does.
• Attribute it honestly. The patent belongs to viaPhoton. I worked on the machine learning and computer vision for the machine it covers. An earlier version of my fiber essay overstated that, and it now carries a dated correction at the bottom. A correction note is not something to hide. It tells a careful reader that the rest of the page has been checked.
• Keep the verb accurate. "Contributed to revenue growth to the $6.5M range" and "drove $6.5M in revenue" are different claims. A hiring manager who has run a growth team knows which one is plausible for an APM, and will ask about the other.
• Don't round up. "200K to 1.2M+" stays exactly that. Smaller, precise numbers survive follow-up questions. Big round ones invite them.

Some of the most convincing numbers are small. Launching AI Docs at ChatlyAI took it from 0 to 2K+ users in 30 days. That is not a headline figure, but it is a clean, bounded result with a launch and a time window, and it gives an interviewer something concrete to ask about.

Show the AI part, not just the product part

The difference between a product manager portfolio and an AI product manager portfolio is whether the reader can tell you understand the model's behavior, not only the funnel around it.

On this site that evidence comes from the engineering and research work, which is why the Experience section keeps the ML roles next to the product role rather than hiding them. My current research at the University of Alberta is on multimodal clinical prediction from ECG waveforms, clinical notes and EHR data. I have developed and evaluated 8 multimodal fusion architectures, with patient-level bootstrap confidence intervals, DeLong testing and leakage audits. None of that is product work. All of it is the kind of evaluation discipline an AI product needs and rarely gets.

If you are coming from the product side without a research background, you can still show this. Some options:

• A short write-up of how you evaluated an AI feature before launch: what the test set was, what counted as a failure, what you decided not to ship.
• A teardown of an AI product you use, focused on its failure modes rather than its interface.
• A small working prototype with an honest note about where it breaks. A link to a GitHub repository with a clear README is better evidence than a mockup.

The "Also built" section does this job on my site, with one line each for side projects such as gitmind, an offline AI git workflow that runs against local models. A contribution to Ultralytics YOLO, distributed parallel training that shipped in a release, sits in the About section for the same reason. One line is enough. The reviewer who cares will click.

Write the career story once, plainly

If your path into AI product management is not a straight line, the portfolio has to explain it in one short narrative, or the reviewer will invent their own explanation. Mine runs from freelance ML work and an internship, through ML engineering, into an APM role, and then into research. I wrote about the first switch in from ML engineer to product manager.

Keep that story in one place, the About section, and let the rest of the page be evidence. A portfolio that tells the career story in every case study reads as defensive.

A checklist for your own AI PM portfolio

Before you send the link to anyone, go through this list:

• The hero names at least two specific, checkable results, not adjectives.
• There are two to four case studies, not more. Everything else is a one-line index.
• Each case study states the problem, the constraint, the decision you made and the outcome, in that order.
• At least one constraint is about the model: latency, data, evaluation or failure modes.
• Every metric has a source you could name in an interview, and the verb matches your role ("contributed to", "led", "built").
• No number is rounded up. Ranges and "+" signs stay as they are.
• Public evidence is linked where it exists: a patent, a repository, a live product, a directory listing.
• Mistakes and corrections are visible, not deleted.
• Roles and dates are easy to find, and they match your LinkedIn profile.
• The career story appears once, in one place.
• A reviewer can find your CV and a way to contact you within one scroll of the top.

If you can only do three of these, do the case study structure, the defensible metrics and the visible corrections. Those are the parts a hiring manager will test in an interview, and they are the parts that make the rest of the page believable. The Credentials section and the CV can carry everything else.