Your AI Is a Teammate, Not a Search Box. Here’s How to Start.

A getting-started guide for product managers and product marketing managers

Many product managers tell me they use AI every day. When I ask how, the answer is almost always the same. They type a question, read the answer, and move on. That’s a search engine with better grammar.

There’s nothing wrong with that. But it’s a bit like buying a pickup truck and only using it to drive to the mailbox. The truck works fine. You’re just not getting what you paid for.

The real value shows up when you stop asking AI questions and start giving it work. Not a single answer, but an ongoing job with a goal, a set of inputs, and a standard for quality. In other words, you treat it the way you’d treat a sharp new analyst on your team.

What I often hear next is, “Fine, but where do I start?” Let me give you an example from outside my day job, because it shows the process without any corporate baggage.

The example: a neighborhood committee and a lot of data centers

I live in Gainesville, Virginia, in Prince William County. If you follow the data center industry, you may know the name. Northern Virginia is the world’s largest data center market, and conversations about data centers here tend to generate more heat than light.

I was asked to join my homeowners association’s Data Center Impact Committee. I am not anti-data center. I support responsible development: minimize the impact, protect neighbors, and hold developers to their promises. But I’ve sat in enough meetings to know how this usually goes. Without a shared set of facts, a committee becomes a place where people repeat what they heard from a neighbor. Too much complaining, not enough action.

So I approached it the way I’d approach any product problem. This is basically competitive analysis. Instead of competitors, we have sites. Instead of feature comparisons, we have zoning cases, power lines, hearing dates, and building heights. The goal is the same: replace internal opinion with market evidence.

Within an hour, I had a working tracking app. Within a few days, it was updating itself. I didn’t write any code.

Here’s the process, step by step, so you can do the same thing with your own problem.

Prompts are the new requirements

Here’s where it gets interesting for product people. Every step below started with a prompt, and every prompt is a requirement. A vague requirement gets you a vague product, whether the builder is an engineering team or an AI. A clear one gets you something useful. I’ve included the prompts I used, lightly edited.

Step 1: Describe the problem, not the solution

My first prompt was three sentences:

I would like an organizing app for researching, monitoring, and reporting on data center activity near Gainesville, VA. The idea is similar to competitive analysis. I am planning to join an HOA Data Center Impact Committee and would like to focus it on facts and not just bloviate about how bad data centers are.

Notice what’s in it. Who it’s for (a committee). What job it does (research, monitor, report). A familiar model to borrow (competitive analysis). And the quality standard (facts, not opinion). Notice what’s missing: screens, fields, buttons. I described the problem and the outcome and let the builder propose the solution. That’s the same discipline I ask of product managers writing for engineering.

In moments, the AI returned an app organized around sites, a timeline, a fact book, open questions, and a report that builds a committee brief with numbered sources. It seeded the app with sourced facts it found on its own.

Step 2: Hand over your own context

A new analyst is only as good as the background you give them. I had already written a guide for the committee and a research brief. I also had a spreadsheet, built by AI from the county’s mapping system, listing every data center campus within five miles —using datasets I’d never heard of from sites I didn’t know existed. I connected the folder and asked the AI to read the files and rework the app around them.

This is the step most people skip, and it’s the one that made the biggest difference. The app reorganized itself around my guide. It found 31 sites sorted by distance, each with its case number, county planner, next milestone, and the questions my guide said to ask. My stance on responsible development showed up on the overview page because it was in my documents, not because I typed it again.

Step 3: Set the standard for evidence

Because my first prompt asked for facts, not bloviating, every entry now carries its sources, the date it was last checked, and an evidence label:

• Verified: confirmed in a primary document, like a county record or a utility filing

• Reported: from news or trade coverage

• Disputed: sources conflict

• Inferred: our own calculation

This paid off immediately. One widely quoted industry figure got marked Disputed because the same article described a canceled project as still approved. The county’s own map still listed that canceled project as pending. And every distance in the app is marked Inferred, because it was measured from an approximate point until the HOA confirms its boundary. Those are exactly the details that get a committee into trouble when nobody writes them down.

Step 4: Ask how to use it

Then I asked the question every customer should ask and few do:

How would I use this day to day?

The answer mapped the app to the routine in my own guide: a 15-minute weekly check, what to update when a hearing is announced, and how to produce a brief before a committee meeting. It also showed me how to put the app in my computer’s dock, so it feels like a real application.

Step 5: Iterate in plain English

Every improvement after that was a one-line request. Some examples:

Please make me an icon. Maybe something with an eye.

(Yes, I literally asked for an eye.)

Add a list of upcoming public meetings and town halls.

This request produced a new Meetings tab with 17 meetings and deadlines through January. Each one says whether the committee should attend (Must attend, Should attend, Optional, or Not needed), explains why, tells you how to sign up to speak, and has an “Add to Calendar” button.

This is how product iteration should feel. Small, frequent changes based on how the thing is actually being used.

Step 6: Make it recurring

This was the turning point. I asked:

How is it updated? Automatically in the background? Whenever I open it?

The honest answer was no, it wasn’t updated. It only knew what someone put into it. So I asked for a weekly check. Every Monday morning, the AI now reviews the county’s pending cases and hearing calendar, the state utility commission case on proposed power lines, and local news. It updates the app with sources and evidence labels and tells me what changed.

The first run added 15 updates, including a new companion permit on the site we’re watching most closely and two new cases that weren’t in my spreadsheet. A later run caught the deadline for public comments to the utility commission. I also have a “Check for updates now” button for the morning of a meeting. It didn’t work the first time. I sent the error message back, and it was fixed in a few minutes. That’s normal software. It’s also normal product management.

Step 7: Remain the decision maker

The AI makes recommendations. I make decisions. When I asked about building a standalone app instead, it laid out the trade-offs and recommended staying with the simple version until the committee’s process proves itself. When it recommended I approve each weekly update before it went into the app, I chose fully automatic instead, because the evidence labels already tell me how much to trust each entry. Either choice was reasonable. The point is that AI gave me the options; I made the final decisions.

What this teaches product managers

The app isn’t the point. The discipline is. Three lessons carry over directly to product work.

The quality of the output reflects the quality of the requirement. My best prompts described a problem, a user, and a standard. My weakest ones described a feature. That’s not an AI lesson. It’s the oldest lesson in product management, and AI just makes the feedback loop shorter. You find out in minutes, not after a sprint, whether your requirement was any good.

Context beats cleverness. People spend a lot of energy looking for magic prompt formulas. In practice, the biggest improvement came from handing over documents I had already written. Your market research, win/loss notes, product documents, and customer interviews are sitting in folders right now. They’re the difference between a generic answer and one that fits your business.

Evidence labels are worth stealing. Most competitive analysis I see mixes verified facts, sales rumors, and someone’s hunch into the same slide, with the same font and the same confidence. Labeling each claim as Verified, Reported, Disputed, or Inferred takes almost no effort. It changes the conversation from “who’s right?” to “how do we know?” That’s a much better conversation to have with an executive team, or a homeowners association.

Your first project this week

Don’t start with your biggest strategic question. Start with something small, something recurring, that you already do badly or not at all.

Consider any complex spreadsheet that you’ve been maintaining. I am wild about famous quotes, and AI built an app that replaced the spreadsheet of 5,000 quotes and sayings. It suggested tracking where I read or heard each quote and when I last used it, and it made searching by phrase, source, or keyword easier.

For product managers, competitive tracking is ideal. Or anything you need to monitor.

Then follow the same seven steps:

1. Write a three-sentence prompt: who it’s for, what job it does, and what “good” looks like.

2. Hand over the documents you already have.

3. Require a source and an evidence label on every entry.

4. Ask how you should use it day to day.

5. Improve it with one-line requests as you use it.

6. Make it recurring, so it checks for changes on a schedule.

7. Leave the design to the AI, but keep the decisions for yourself.

Here’s a starter prompt you can adapt:

I’d like an app for tracking our top five competitors. It’s for our product and sales leadership, and it should help us prepare for quarterly planning. I want facts, not opinions, so every entry needs a source, the date it was checked, and a label showing whether it’s verified, reported, disputed, or our own inference.

Write it the way you’d write it for your best engineer. That’s the whole trick.

Search gives you answers. Well-written requirements give you a teammate.