When ChatGPT launched, I used it to generate a Python script for scraping web data. It produced the code, but I still had to dust off what I remembered from a college Python class to run it locally. The tool could write the code. Getting it to do anything still required knowing something.
A few years later, tools like v0 feel like a different era. You can build basic prototypes with little to no technical background. It reminds me of when Canva took off: it didn’t make everyone a professional designer, but it dramatically lowered the barrier to producing solid work. These tools are doing the same thing for software. Most people haven’t noticed yet.
PMs are actually well-positioned for this. The instincts are the same ones you already use: start small, define the problem clearly, write the requirements before you start building. What’s different is that you’re the one doing the building. Here’s what I’ve learned building with these tools myself.
Build a working app without an engineer
I built a lightweight commute helper for myself. It tells you exactly when to leave to catch your train. You save your usual routes and walking time, check the site when you’re heading out, and it calculates the best departure time so you’re not standing on the platform in the Chicago winter waiting for the next one.
I built it using v0, with no engineering support. At no cost, v0 will publish the site for you so you can share it. The app and my full build log are at amousseau.com.
It is not a complex application. That’s the point. If you’re a PM trying to understand what these tools can do, a small, scoped problem is the right place to start. You learn more from shipping something simple than from planning something ambitious.
Get started without wasting time or credits
1. Start with a design, not a blank prompt.
v0 works significantly better when you give it something visual to work from. Before I started building, I used ChatGPT Pro to generate a concept image. That image became the starting point for the first prompt. The tool had something concrete to build toward, and the output was much closer to what I actually wanted. If you’re starting from scratch without a design, you’ll spend a lot of credits iterating on the wrong thing. Spend a few minutes generating a rough visual concept first.
2. Treat it like product development, not a prompt lottery.
The biggest mistake I see people make is treating these tools like a magic box: put in a vague idea, expect a working app. Development using an AI build tool works the same as developing with a team. What has actually worked: start with a basic MVP. Write full user stories. Be specific about scope. The more precisely you define what you want, the better the output. The tool doesn’t fill in ambiguity with good judgment. It fills it in with guesses.
3. Build a shared memory between sessions.
The tool only references the context of the app itself and the individual chat you’re in. It doesn’t remember decisions from previous conversations. If you want it to have context in future sessions, ask it to create a markdown file, then ask it to update that file with critical decisions as you make them. That file becomes the shared memory between sessions.
4. Know your tools.
Cursor is preferred by developers and gives you more control, but you’ll need to set up a backend and host the app yourself if you want to release it. For PMs starting out, v0 is the lower-friction entry point. If you want to go deeper on Cursor specifically, this Maven course is built for PMs.
5. Don’t burn your credits on trial and error.
Every AI build tool runs on some kind of credit system. The way to avoid burning through them is to not use the build tool for exploration. Use it for execution. Keep a separate LLM open alongside your build tool and use it to craft prompts and troubleshoot before you paste anything in. Two prompts that have saved me a lot of frustration:
“I’m using [tool] and want to achieve X. Write a prompt I can paste into the tool.”
“I’m stuck setting up [tool]. Help me troubleshoot what to check next.”
The first helps you go in with a clear instruction. The second gives you a way out when something breaks and you don’t know why.
The tools are more accessible than they look, and the process is PM-native. The only thing between you and a shipped prototype is starting with a small, well-defined problem and treating it the way you’d treat any other build. You already know how to do that part.
Resources and people worth knowing
- For a broader foundation on working in AI-native product environments, Lenny’s AI-native PM course on Maven is worth your time. I’ve also found Maven’s Lightning Lessons useful for getting acquainted with specific tools quickly.
- If you have questions about getting started or want to compare notes on what’s worked, reach out to me on LinkedIn
- If you’re a PM working on an AI product and want to pressure-test your approach before it reaches engineering, Gritmind works with product teams on AI readiness and production validation