A Day as an AI-Era PM: How I Turned One Sentence Into a Prototype You Can Actually Tap

Let me start with something concrete. Last Wednesday afternoon, a fuzzy idea popped into my head: “I want a little thing to jot down what I spend.” A little over two hours later, my coworker was tapping away on my phone for real — tap “Add,” type an amount, pick a category, go back to the home screen and see how much he’d spent this month, with a pie chart split into a few slices. Not a single line of code.

I’m not telling this story to show off how magical AI is. I’m telling it to make a counterintuitive point: most people think that now AI is here, PMs had better hurry up and learn programming or they’ll get replaced. But my gut sense over the past six months or so has been exactly the opposite — the barrier to writing code is collapsing fast, and the thing that’s actually becoming valuable, and scarce, is something else entirely: getting a thing described clearly enough that AI gets it right on the first try.

I’m not going to argue that point in this piece — I’m going to show you exactly how I did it. I’ll use that little expense tracker as the example and walk you through it step by step, potholes included. If you’ve got an idea you’ve been sitting on for ages, by the end you should be able to go try it yourself.

Step one: don’t rush to make it build — make it interrogate me first

When I first started building things with AI, my favorite mistake was to fling that fuzzy sentence in my head straight at it — “build me an expense-tracking app” — and then wait for a finished product.

The result was always the same: it would hand me something it thought I wanted, a thousand miles from what was in my head. I’d correct it a little, it’d drift a little, and the two of us would sit there guessing at each other until I lost my temper.

Later I changed one habit — it’s just one sentence, but it works absurdly well: I stopped asking it to build directly, and started making it interrogate me first. I’ll say: “I want to build a little expense-tracking tool. Don’t write anything yet. First ask me 5 questions — the things you need to know but that I haven’t told you yet.”

So it asks: who’s it for, just you or multiple people? Do you want categories, defined by you or a few presets I pick? Should amounts separate income from expenses? Is storing data locally on the phone fine, or do you need to see it across devices? Do you want a budget alert?

See, every one of these questions lands exactly on the stuff that was a muddled mess in my head — stuff I hadn’t thought through. It forced “what do I actually want” out of me. By the time I’ve answered those 5 questions, the shape of the thing is clearer in my own mind. And now when I let it build, the odds of getting it right in one shot go way up.

A pothole I stepped in: the two minutes you save by skipping this step, you’ll pay back with two hours later. Once, I got annoyed at all its questions and just told it to build. It produced something fully featured and completely not what I wanted, and by the end the rework was worse than starting over. Now I never skip this step.

Step two: change only one thing at a time

The first version comes out, you can tap it, but it’s definitely off in some way. And here’s where the second pothole is waiting: dumping all ten things you don’t like on it in one breath.

“The home screen color’s too pale, the category icons are ugly, I want to change the pie chart colors, the Add button’s too small, oh and can the amount auto-add the decimal point, and while you’re at it throw in a search…”

I used to do exactly this, chasing speed. The result: it makes the changes, gets the color right, but forgets the button; or fixes the button and breaks the pie chart. The more changes at once, the more it drops one to catch another, and you can’t even tell which of your sentences did what or which one it quietly skipped.

Now I’ve switched to saying one change at a time — say it, tap it once on the phone, confirm that one spot is right, then say the next. Slow? Looks slow. But every step is solid, no backtracking. I’ve done the math: going through it this way is actually much faster than “say everything at once, then rework it all together,” and I know the exact state of things the whole way through.

This isn’t some AI trick. It’s the plainest rule in product work: small steps, each one verifiable. It’s just that AI has crushed the cost of each step so low that you have even less excuse to get greedy.

An aside: how to phrase each change so AI actually gets it

I said “change one thing at a time” above, but just “one” isn’t enough — the key is how you say that one thing. This is the most hands-on part of the whole piece, and the one that pays off fastest.

The biggest pothole I stepped in was giving AI instructions with adjectives. “Make the home screen nicer,” “make the button bolder,” “make the color classier” — the moment those words leave my mouth, I’ve handed all the judgment back to it, because “nice” and “classy” have ten thousand interpretations in its head, and it’ll grab one at random, most likely not the one you meant.

So I forced myself to do two things instead: give it a reference, give it a state, don’t give it adjectives.

Give it a reference — instead of “make it nicer,” say “the cards on the home screen, use whitespace like WeChat Read does, three or four per screen, don’t cram them.” It knows immediately what you want, because you’ve given it a concrete thing to align to instead of a vague verdict it’s free to interpret.

Give it a state — instead of “handle the case where there are no entries,” say “when there isn’t a single entry, show one line of gray text in the middle of the home screen: ‘No entries yet — tap the button at the bottom right to add one,’ and don’t show an empty pie chart.” Spell out exactly what the screen should look like in each state — what it looks like with data, without data, while loading, when it errors. The more specific you are, the less room it has to “freely interpret” its way into something you don’t want.

My self-check now is: after I finish an instruction, I look back for adjectives. If there’s a “nice,” “bold,” “classy,” or “clean this up,” I stop and translate it into “reference what, look like exactly what.” This little move has done more for me than any AI trick I’ve learned.

Step three: the first version runs on real data — no “placeholder text”

This is the one I think gets ignored most and affects the outcome most.

A lot of people building prototypes have AI put up a “frame” first — filled with fake stuff like “Title 1,” “content placeholder,” “¥000.00” — thinking “get the structure right, fill in content later.”

I don’t do that anymore. I have it run on real data from the very first version. For this expense example, I just had it preload a few things I actually spent yesterday: breakfast 12, a cab 28, groceries 63, and one that stung a bit — 2000 for my kid’s classes.

Why? Because fake data lies to you. When everything is “¥000.00,” the interface looks clean and tidy and you think “yeah, this is fine.” But the instant you drop in a real, uneven-digit number like “2000,” the problems all surface at once: the amount gets long and the right edge butts up against the screen; the pie chart gets crushed by that one 2000 entry until the smaller slices are nearly invisible; a slightly longer category name warps the whole layout.

Every one of these potholes is invisible with fake data, and they all smash into real users’ faces the moment you ship. With real data, they’re exposed in your own hands in the very first version — and the earlier they’re exposed, the cheaper they are to fix. At this stage it’s a one-line change; fixing it after users are cursing at the live app is a whole different thing. My habit now: if I can use real numbers I’ll never use a placeholder, and the more real and more extreme the better — the longest name, the biggest amount, the emptiest state (what does the interface look like when there isn’t a single entry?) all need to show up in the first version.

Step four: you must tap through it yourself on a real device

Once the prototype’s built, AI will usually tell you very confidently, “Done, all the features are implemented.”

Don’t believe a word of it. It’s not lying — it just doesn’t have hands. It can’t actually tap anything.

I’ve been burned by this. Once it swore up and down that recording, deleting, and stats were all done, I couldn’t find a flaw in the code logic either, so I believed it. Then my coworker took it, added an entry — fine; tapped that entry to delete it — nothing happened. It had drawn the delete button, but the “actually delete it when tapped” action, it had missed — and it had no idea, and still told me “done.”

Ever since, I set an iron rule: any “it’s done” only counts after I’ve personally walked the key path through it on a real device. Add an entry, watch it appear in the list, delete it, watch the stats change with it — until I’ve tapped that whole chain through myself, I treat it as unfinished. This step takes under three minutes, but it’s the only wall standing between you and “discovered by users after launch.”

I’ve got a dumb little method for how to walk it, too: before I start, I write down the two or three most critical paths of this thing on a piece of paper. For this expense tracker, I wrote: “① can add an entry and see it ② can delete an entry ③ home-screen numbers and pie chart change accordingly.” Just those three. When it’s done, I don’t look at what AI says — I take that paper and tap through it on the phone, one line at a time. Cross off each path that works; whatever I can’t cross off isn’t finished.

Don’t underestimate that piece of paper. It forces you, before you start, to get clear on “what few things does this thing actually stand or fall on” — a lot of people lose the plot halfway through precisely because they never pinned those two or three main paths down on paper. They build and build, get dragged off by details, and end up with a pile of features while the single most core path doesn’t even work. Get clear on which few paths must work, then let AI build, then verify those paths by hand — those two pieces of paper, the front end and the back end, matter more than however much code it wrote in between.

Step five: the acceptance line is “can you tap through it,” not “does it look right”

String the steps above together and it’s really the same judgment showing up over and over: what, exactly, do I use to decide whether this thing works?

The answer I’ve given myself: whether you can actually tap through one complete path, not whether it looks right.

“Looks right” is the easiest thing to be fooled by. Drop a screenshot in the group chat and everyone says it looks great — and maybe not one person has actually recorded a single entry. “Can tap through” is hard: a real person, from opening it, to recording an entry, to seeing the result, gets through the whole thing without getting stuck, without a single dead button — once that path works, the thing genuinely stands.

This is also where I think AI-era PMs should hold the line hardest. When the cost of building is crushed to nearly zero, “producing something that looks presentable” is no longer worth anything — the screen is full of them. What’s worth money is whether you can still judge: is this presentable-looking thing actually usable, or does it just look like it? That judgment, AI can’t do for you — because it’s the very thing that will confidently say “done” while missing the delete button.

So — do you actually need to learn to code?

Back to the question at the top.

My answer is: you don’t need to learn how to write code, but you do need to learn how to get your words clear enough that AI gets it right on the first try — and those are two different things. The former is learning a craft that’s depreciating; the latter is training a judgment that’s getting scarcer: forcing a fuzzy idea into clarity, advancing only one step at a time, checking it against real things, tapping it through by hand before you believe it.

None of these, honestly, is “technical.” They’re more like the habits a person should already have — someone who’s clear on what they want and willing to verify it step by step. AI just amplifies the payoff of those habits many times over: the clearer you think, the more accurate what it gives you; the more you fudge it, the more it fudges you back.

There’s still stuff I haven’t figured out, and I’ll toss it your way: when “turning an idea into something you can tap” gets fast enough to run several rounds in a single afternoon, where exactly is the line between a product manager and “an ordinary person who’s clear on what they want”? I’m still looking for the answer myself. But at least I know the line isn’t drawn at “can you write code” — that little expense tracker last week, from start to finish, I didn’t touch a single line of code.