A PM Primer for No-Code Developers

A PM Primer for No-Code Developers

Product thinking for the vibe-coding era

Artificial intelligence and no-code platforms have made it unbelievably less expensive to build software applications. When releasing a prototype can be done in a weekend, by any non-technical person with an idea, the question becomes: What is worth building and how do you know? In short, when engineering is fast and cheap, product thinking becomes even more important.

I'll avoid (or at least try to avoid) defining Product Management generally. You can browse LinkedIn to get all the best hot takes on the subject. Suffice to say that the Product Manager is typically the role in a software company who answers questions like “what is worth building,” “how do we know it is doing what we want,” and “how do we pull it all together?” There are a ton of frameworks that good Product Managers pick up over time. Some frameworks even become branded by consultants and adopted as dogma within companies. I'll spare you my pithy equivalent to the conjoined triangles of success. Instead, here is how I would advise a vibe-coding amateur to develop product thinking.

So you have a million-dollar idea. If I know anything about you, and I do, you are ready to make your idea a reality. You sit down at your computer with your coffee (or zyn if your idea involves finance) and enter a few prompts that get you...in the ballpark. You continue playing with prompts, layering command on command. Every time you fix something, the app breaks elsewhere. In frustration, you eventually realize there are features you didn't ask for and the ones you wanted only work partially. Good idea, poorly executed. Eventually, you give up. If only you'd have started with a better plan. Welcome to Product Management.

Where should you actually begin before you begin? Let me politely recommend that you start with your user. Sounds obvious but most amateurs (as we say in the biz) are so into the idea that they skip this most important step. Before you ever sit down to write (or prompt) code, you need to be able to answer two questions:

• Who is your user?
• What problem are they trying to solve?

Start with Your User

Start with the user. To find the first answer, it is common to build a user persona where you write down the attributes of your user. Some personas are way too involved. You don't need that here, but you should think through a few things: where is the user when they encounter your application, what are they thinking and feeling when they come to your app to solve a problem, are they on desktop or mobile, are they driving or performing another activity? Importantly, is your user tech-savvy, or do you need to build big Jitterbug buttons? Think through the context. Is the user engaging with your app as a critical part of their job? What terminology makes sense to them? The best way to know your user is to talk to them. Talk to lots of them. Make sure you know who you're building for before writing the code, but don't get lost in the weeds. You are mostly concerned at this point because you want to meet them where they are. Think of this as a starting point.

Define the Outcome

Next, identify what your user needs to accomplish. If you take only one word from this whole post, it should be “OUTCOMES.” Your user will be engaging with your app because they want to accomplish something. Again, this seems rudimentary, but you would be amazed how often these steps are skipped or glossed over. You probably already know the outcomes from getting to know your user, so write it down. The act of trying to put it on paper will sharpen your thinking. If you are really doing it right, you're also speaking with your customer to validate that you understand the “why” for your app. Know your user's desired outcome and start thinking about how you will objectively measure if you're providing that outcome through your app later (more on measurement at the end of this post).

Some examples of the persona-problem pairing (hey, there's my conjoined triangles, ™ ™ ™):

• A tech-savvy 35-year-old wants to improve their golf game before meeting key customers.
• A real-estate agent needs to know and understand the implications of their client donating their property to charity.
• A working parent of two with children in daycare keeps forgetting to bring more diapers to the facility.

These could all be improved, but the point stands that you should know who you're building for and what they want to solve. Note that none of the examples include the solution yet. Focus first on the OUTCOMES your user needs. You do this by correctly identifying the problem or pain they feel and having a really good idea of what “solved” would mean for them.

Check if It Already Exists

Before you write a single prompt, spend fifteen minutes seeing if someone beat you to it. I know, I know — you've got the itch, and asking “does this exist already” feels like admitting your million-dollar idea might be a five-dollar idea. Do it anyway. Search around, poke at competitors, see what's out there solving something adjacent to your problem. Sometimes you'll find nothing and get to feel smug about it. More often you'll find three tools halfway there, and now you know exactly what they're missing — which is a much better starting point than a blank prompt window. This isn't about killing your idea. It's about knowing the landscape before you build in it.

Map the User Workflow

Now that you have both where the user is starting from and their desired outcome, your job is to map the path that leads from problem to solution. Fill in the blanks. This is called a user workflow. You can look up good information on methods for creating good user workflows. Start by identifying every point where the user needs information to make a decision, where they get that information from (inputs), what options they may have and what paths those decisions would lead to, and what events kick off when a decision is made. You want to see the sequence of events that lead from problem to solution. Draw this on paper or use a diagramming tool like LucidChart or Figma. You should see the whole map that gives context on why the user is hitting a problem, where they find friction, what prevents them from solving their problem, any workarounds they're currently using, and where things break down. Finally, you can begin working on a solution.

Note that much of this process is evolving in the time of AI and no-code platforms. When engineering was expensive, this was a vital step. Now, there may be even better ways to understand the user and place them in the context of their problem using ultra-fast iterations or a combination of AI and user discovery. The point stands that you must understand the problem you're trying to solve before you start mashing in those prompts, and you should absolutely be able to express what “solved” means for your user. This is NOT “the user gets a PDF at the end of the process” but something more like “the client has a full understanding of the financial implications of donating their property and is informed to make a decision.”

Scope Your First Version

You've got your user, you've got the outcome, you've mapped the whole workflow. Now comes the part everyone skips: deciding what you're actually building first. This is where our vibe-coding friend from the intro went sideways — no scope, no plan, just prompt after prompt until the app was a pile of half-finished features nobody asked for.

Take your workflow map and turn it into a real list. What has to be in version one for your user to actually reach that outcome you wrote down? What's a nice-to-have you can bolt on in week two? You don't need a fancy framework here (though look up MoSCoW if you want one — must-have, should-have, could-have, won't-have). You just need to be honest about the difference between “solves the problem” and “would be cool.” Write the list down before you touch the keyboard. Future you, three days deep into scope creep, will thank present you.

Failure Modes

It is easy to imagine your perfect user and use case and to design around it. In your head, your user understands the product the same way that you do. In reality, they're going to find ways to break your product. You can never fully imagine how users will interact with your app in the wild. Your job is to imagine how they'll interact with your app in the wild anyway. Think about breaking it before they do. I've heard that you should try to make your product so easy that your aging mother isn't confused, or so intuitive that a baby could use it. I like to ask myself, “how is the dumbest person I know going to tie themselves up in the app?”

Human Failure Modes

Designing for failure can be hard. Your user workflow is key here. Use it to visualize where things go wrong. Look for ways that you can revisit the user workflow to eliminate failure modes through good design. Go upstream of the break and see how you can prevent your user from following an identified bad path. In the user workflow phase you're not solutioning yet. Here, as you're visiting failure modes, you may have already started designing the solution. I'll call any maps you make at this point user journeys. Don't confuse your user workflow with your app's user journey. The workflow is agnostic and is how the customer is experiencing the pain today. The journey is how they'll use your app.

Systems Failure Modes

Your app can also fail even with perfect users using your app perfectly. Here, it helps to think in extremes. What happens when you have 100 users? 1,000 users? 1,000,000 users? What happens if different users are in the same part of the system editing a record at the same time? Does anything become unusable if the page loads too slowly, or if an autosave fails? What is the impact of a user's sensitive data being shown to a different user? Think in extremes and engineer accordingly.

Measure and Iterate

Define Your Metrics

Supposing you have a good persona, you've created beautiful user journeys through the app. You have intuitive features that even Blake Lestors (dumbest person I know) could navigate with ease. You release it. Now what? This stage is my very favorite and can be lost in the thrill of releasing your million-dollar idea on the world. Time to measure, monitor, and improve.

Let's briefly revisit your user and desired outcomes (there's that word again). You should know what your user is trying to achieve when they come to your app. You need to now determine if that is actually happening. As a practice, think not only of your outcome initially, but also how you will measure it. Is your user trying to book a vacation stay through your app? Maybe measure completed bookings as a key result. For bonus points, also track abandoned bookings and total number of listings on your platform. Are you a note-taking app? Measurements such as notes per user, average notes per user, revisited notes, and frequency of notes per user in a week could all be useful to tell you if the app provides the value you intended. If you monitor correctly from the beginning, you can also slice the data to see if your users have important subgroups. Are there certain users who are power users, logging multiple notes daily? Now you can work to understand them and grow that demographic through iterative improvements.

Other important metrics to be aware of, though of lesser importance, are: traffic sources to your site, unique visitors, daily/weekly/monthly active users, engagement time in the app and even on each feature and page, returning visitors, downloads, etc. These will tell you the health of your app. They are your superpower post-release as you scramble to improve and gain customers.

There are also app health metrics to pay attention to as your user base grows. These might be: page-load times, crash-free sessions, rage clicks, memory usage, feature abandons, etc. Helpful tools include PostHog, UXCam, Pendo, Google Analytics, and Varicode. Find the suite that works best for your case.

Iterate on What You Learn

Measuring is only half the job. The other half is actually doing something with what you find. This is the step that turns your dashboard from a wall of numbers into a product roadmap.

Look at what your data's telling you and ask why. If power users are doing something specific, go find out what and see if you can make it easier or more visible for everyone else. If a feature's getting ignored, figure out if it's broken, buried, or just not needed — those are three different fixes. If people are dropping off at the same spot every time, that's your user journey map again, telling you exactly where to go dig. Iteration isn't a mysterious art. It's just closing the loop — you measured, now go fix the thing the measurement pointed at, then measure again.

Conclusion

This is by no means meant to be the definitive guide to product management. Instead, view this as a primer on product thinking. It is the partner in crime to engineering skills. It is doing the homework before you code, and the measuring after you release. Failure to think about your customer and their pain will always result in a worse end product. Lack of understanding around the context of your customer's pain will always mean that your app won't become that million-dollar idea. There are so many other aspects to Product Management. Delving into the practice will improve every single project you sit down to vibecode, so go out, meet your customers, and create the next big app.