What using AI looks like when you're a PM without a technical background

A while ago we published a post about how we use Claude for product management at MarsBased and our guides about how we develop using AI. We explained the general approach across the company: connecting Claude to our tools, encoding our processes into reusable skills, and letting AI take over the mechanical parts of the job so PMs and engineers can focus on the actual product.

This post is from a more personal perspective. I want to write about what AI looks like from my desk specifically, because I don't come from a technical background. I'm not writing code, I used to avoid the terminal at all costs. But now, while I still don't live in it, I'm not afraid to open it when Claude guides me through the commands. So here's the ground-level version: what I actually use it for, where it saved me real time, and where it surprised me.

Starting from "I'm not a developer"

Let me give you some context, first. My role is to give clients a clear picture of the project: how we're progressing, what's still missing, any roadblocks. To keep an eye on time and budget, and make sure we're building the things that actually matter. Internally, it is about flagging how we're doing and when the development team would free up for the next project.

Most of my conversations with clients don't happen at the level of code. I usually talk to non-technical people, so my job is to explain things to them in non-technical ways. They rarely need to hear about a specific function or method, but they need to understand what it means for their product.

Reports that write themselves (mostly)

This is where things shifted the most for me.

Before, a status report meant real legwork: custom Linear filters to catch everything that changed during the week, then digging back through my notes to reconstruct it all. Most of it lived in my head until Friday afternoon, when I finally had to get it down on paper.

Now, using our internal company tooling and simple Slack/Linear integrations (which I managed to configure with Claude’s step-by-step guidance), I have these running on a schedule. They pull from where the work actually lives, so instead of starting from a blank page, I open my laptop and the first draft is already waiting. I review it, adjust the tone, add the human context AI can't know, and send. The same goes for the recurring nudges and summaries I rely on to not drop balls: highlights of what changed, a draft of the team update for Slack, that kind of thing. None of it is glamorous, but all of it used to eat my Friday afternoons.

The mechanical part is done before I even sit down.

Investigating tools I don't "speak"

Our projects touch a lot of third-party tools, and as a PM I'm expected to understand them on a functional level. Things like RevenueCat for subscriptions and paywalls, Klaviyo for messaging and event triggers, or Expo Go when I need to check something on a mobile build. Each of these has its own logic, its own dashboard, its own quirks.

Before, getting up to speed on one of these meant working through whatever I could find online: manuals, FAQs, tutorials, forum threads. Then I'd take my remaining questions to a dev. Now I just talk it through with Claude. I can ask it to walk me through how a paywall is set up, what a specific event trigger is supposed to fire, or why something I'm seeing doesn't match what I expected. It explains things at my level, without assuming I know the jargon, gives me a checklist and the resources to follow, and then quizzes me on it to make sure I've actually understood, rather than just nodded along. I've also set up my own skills so the output comes back the way I want it, tailored to how I work.

There's an important line I'm careful not to cross, and it's the same one we drew as a company: I use AI to understand, not to build. I'm not shipping code, and I wouldn't pretend to. Vibe-coding my way into a production system would be reckless, and an engineer who truly understands the system is irreplaceable. But understanding enough to ask a sharper question, or to avoid blocking a dev with something I could have worked out myself? That's a real upgrade.

QA, with a second pair of eyes

A good chunk of my work is QA, especially around a release, and it's where AI has quietly become one of my most useful tools.

It starts before I test anything: I get the project running on my own machine with Claude. It's not always seamless, sometimes a setup step is missing and I still pull in a dev, but it gets me much further on my own than before. Then I have it help me build a checklist of what needs testing, instead of making that list from memory and second-guessing whether I'd missed something.

When I hit a behaviour that seems off, I can cross-reference it with the original requirements and logic we mapped out with Claude, catching edge cases before they even reach the developers.

And when I confirm a bug, writing it up is instant: I run it through the skill I've set up and get a clean, structured Linear issue ready for an engineer to pick up.

Building little things, carefully

There's a small category of tasks that sits between "writing" and "understanding": little bits of setup and tinkering I've always done, just far more slowly. They're not part of any formal process, they're just things that make my own work run smoother.

Setting up email filters so my inbox sorts itself. Putting together a budget spreadsheet without fighting formulas for an hour. Even building a small custom routine for a report I generate often, so I don't have to re-explain it every time. I used to do these things too, but it would take me a while to set everything up and then double-check it actually worked. AI has sped that up enormously. None of it is engineering. It's more like having a patient assistant who knows how the tools work and handles the fiddly parts while I describe what I want, and then I tweak it until it's exactly right.

What actually changed

Comparing my own experience to the post I mentioned at the beginning of this entry, the takeaway is the same: AI takes over the mechanical, repetitive layer of the job. What differs is how that plays out day to day for me.

My version is the non-technical way into the same building. I lean on the conversational side and on automation: preparing reports on a schedule, getting a fast functional read on an unfamiliar tool, and, when I'm running QA, checking whether a behaviour I'm seeing actually makes sense. Same building, different door in.

The thing I'd tell another non-technical PM is this: don't think of AI as a developer tool you're borrowing. Think of it as an operations partner that happens to also speak fluent engineer. The moment I stopped treating it as a Linear assistant and started treating it as a general-purpose teammate, the real value showed up.

I'm still the one making the calls. AI just takes the repetitive, tedious parts off my plate, the work that always got done, but never really needed my full attention to get there.