How I Actually Use AI to Build Products, and What It Means for Project Management

I don’t really use AI as a chatbot anymore

Like most people, my early experience with AI was conversational. You opened a browser tab, typed a question into a text box, and waited for an answer.

If you wanted to do practical work, that workflow had clear limits. You had to copy text back and forth, clean up generic filler, and manually adapt pieces into your actual documents or tools.

I still use conversational AI constantly, but I no longer treat the chat window as the end of the workflow.

Over time, my workflow changed. Instead of relying on a single prompt to produce an answer, I began using AI across different stages of working through a problem: exploring initial ideas, stress-testing requirements, structuring plans, directing coding agents inside software repositories, and running independent review passes.

The goal is not to have AI do my job or make decisions for me. The goal is to shorten the distance between an idea and a working result that I can evaluate, test, and improve.

The biggest change: the distance between an idea and execution

My background is in product and project management. I have spent years working with cross-functional teams, managing delivery timelines, writing requirements, and aligning stakeholders.

In traditional digital product work, there has always been a significant gap between defining what should be built and seeing it work.

As a product manager, you could take an idea, research the problem, talk to users, and write a thorough specification. But once the document was complete, you reached a hard boundary. You had to hand the specification over, wait for development capacity, and wait for staging builds before you could interact with the software, test your assumptions, and discover what you had overlooked.

That distance often meant that testing small hypotheses took substantial coordination.

What AI changed for me is not that it writes code. What changed is that it allows someone with product and project experience to move much further down the delivery path independently.

For me, execution is much less of a barrier than it used to be. That puts more pressure on getting the problem, requirements, and quality bar right. When building a prototype or a personal digital product, I can take an ambiguous concept, turn it into a structured plan, coordinate an agent to implement it inside a repository, test the result, and iterate on the details myself before deciding what to do with it.

How I build products with AI

When I work on my own product ideas today, I follow a structured loop:

Idea → Research → Challenge Assumptions → Define the Product → PRD & Plan → Coordinate Implementation → Work in the Repo → Test & Identify Problems → Iterate → Deploy

1. Research and challenging assumptions

Every project starts with an unrefined problem. Instead of jumping straight into solutions, I use AI to help me pull the problem apart.

I feed in raw notes, rough context, and user observations, and ask questions to expose blind spots:

What assumptions am I taking for granted?
What operational or user constraints am I ignoring?
If this idea fails after launch, what is the most likely reason?

Using AI as a critical sparring partner before defining requirements helps catch flawed assumptions early, when changing direction is simple.

2. Defining the product and structuring the plan

Once the concept holds up to scrutiny, I move to definition. I use AI to help structure my thoughts into an actionable Product Requirement Document (PRD) and implementation plan.

We break the work down into clear components: core functional scope, user flows, edge cases, and acceptance criteria. A clear plan makes dependencies visible and defines what “done” looks like for each step.

3. Coordinating implementation inside the repository

When it comes to building, I do not copy and paste snippets from a browser window. I work with AI coding agents that operate directly inside the project repository.

Because these agents have access to the repository context — existing files, dependencies, styling rules, and folder structure — they can make concrete changes that match the project’s setup.

My role here is coordination and evaluation, not pretending to be a software engineer manually executing every step:

I define what should be built and set explicit acceptance criteria.
The coding agent inspects the repository, applies the modifications, and runs the necessary builds and automated checks.
I review the resulting behavior, inspect the output, and test the user experience.
When an issue or unexpected behavior appears, I do not guess. I convert the problem into a narrowly scoped correction task for the agent.

The cycle repeats until the result meets the acceptance criteria.

4. Testing, iterating, and deploying

Once the pieces function, I use AI to help surface edge cases I might have missed during initial testing: unusual inputs, missing empty states, or layout issues across screen sizes.

When the checks pass and the output matches what I intended, I deploy the project through standard pipelines. Real usage then provides the next round of feedback.

The multi-agent workflow: separation of roles

One important lesson from working this way is that asking a single AI prompt or system to do an entire job rarely produces great work.

A stronger approach is to separate roles and use independent verification:

One AI conversation can be used for discovery, research, and thinking through requirements.
A different, context-aware coding agent can be assigned to work inside the repository with specific instructions.
A separate review pass can examine the resulting output against the original requirements and look for weaknesses.
The identified issues can then be handed back to the implementation agent as a targeted correction task.

The article you are reading right now is an example of this exact workflow in practice:

I decided I wanted an article about my actual use of AI.
We discussed the editorial direction and guidelines.
An AI agent inspected the repository to understand the site’s conventions.
A GitHub Issue was created as the formal task specification.
An agent generated a complete first draft.
A separate model independently reviewed that draft against the guidelines.
Specific correction instructions were formulated based on that review.
The draft was revised.
Final human review confirms the content before anything is committed or deployed.

This sequence works because no single system is grading its own homework. Separating the roles creates accountability across the process.

Where the same principles apply to project management

While my hands-on technical use of AI is focused on personal product building, the underlying principles have obvious applications across professional project management.

Project management is fundamentally about creating clarity from ambiguity, aligning stakeholders, and managing risk. Those are areas where structured AI assistance can provide valuable support.

Looking at project management as a discipline, several practical applications stand out:

Structuring fragmented information: Projects regularly produce large volumes of unstructured material — discussion notes, conflicting feedback, and complex technical updates. AI can help a project manager synthesize these inputs, identifying agreed decisions, emerging dependencies, and items that belong in a risk register.
Challenging assumptions before decisions: Before committing to a milestone change or presenting a proposal to stakeholders, an AI model can serve as a neutral sounding board. It can highlight unstated assumptions, suggest alternative approaches, and point out questions that have not yet been addressed.
Adapting information for different audiences: Different stakeholders need different views of the same project reality. A technical lead needs precise scope boundaries; an executive sponsor needs milestone health, resource implications, and decision gates. AI can help reframe the same underlying facts for different audiences without losing accuracy.
Reducing administrative drafting: Drafting recurring status updates, structuring agenda templates, or formatting change requests takes time away from active coordination. Having an AI generate clean initial drafts allows a project manager to spend more time where it matters: resolving blockers, talking to people, and managing expectations.

In project management, the most useful role for AI is often before and after the central task: helping someone understand a messy problem before acting, and checking the draft or plan after it is written.

AI is very good at looking right even when it is wrong

There is an important trap in working with AI: modern models are exceptionally good at producing output that looks completely finished, even when it contains serious errors.

Because AI writes with fluent confidence, a draft that seems polished on the surface can easily contain:

Plausible-sounding facts or numbers that were entirely invented.
Subtle misunderstandings of context.
Unnecessary complexity that adds no real value.
Generic platitudes disguised as practical insight.

The first draft of this blog post provided an immediate reminder of that problem.

When the agent generated its initial version, the writing was clean, articulate, and well-structured. However, it also included specific productivity numbers I had never achieved, referenced time savings I had never measured, and described personal workflows that sounded believable but did not match reality.

Because a separate review was built into the process, those invented details were caught and flagged immediately.

This is why human oversight cannot be treated as a quick final glance. It is the most critical step in the workflow. If you publish or act on AI output without thorough review, you are outsourcing your reputation to an algorithm.

What I don’t delegate

Working effectively with AI requires clear boundaries about what belongs to the tool and what belongs to the person directing it.

There are several areas I do not delegate:

Deciding what problem is worth solving: AI can help analyze options, but it cannot tell you what matters to your users or your business. Setting intent and deciding where to invest effort requires human judgment.
Deciding what “good” looks like: An AI model will produce content until you tell it to stop. It has no taste, no sense of craft, and no instinct for whether a product experience feels right. The human sets the quality bar.
Protecting confidential information: Any professional working with AI needs strict boundaries around data privacy and governance. Knowing what information can be shared with an external tool and what must remain protected is an absolute responsibility.
Final accountability: If a requirement is missed or an issue slips into production, saying “the AI generated it” is meaningless. The person directing the tool is entirely responsible for the outcome.
Human relationships: Project work is fundamentally social. Building alignment among stakeholders, understanding team dynamics, listening to concerns, and earning trust cannot be automated.

The skill that matters now: knowing what good looks like

Much of the conversation around AI focuses on “prompt engineering” — the idea that finding clever phrasing is the key to good results.

In practice, prompting is relatively simple. The skill that actually matters is domain judgment, evaluation, and orchestration.

To get useful work from an AI system, you must already understand what good work looks like:

If you do not understand product fundamentals, you cannot tell whether an AI-generated requirement document solves the right problem.
If you do not understand project governance, you will miss the organizational risks an automated summary overlooked.
If you do not understand how software is structured, you cannot guide an agent through a safe, incremental implementation.

Domain knowledge does not become obsolete when using AI. It becomes more critical. When you have a solid foundation in your field, AI stops being a novelty and becomes a tool that helps you think more clearly and execute more effectively.

Closing

I do not look at AI as an autonomous system that will replace product managers or build applications on its own.

I look at it as a practical tool that allows me to move further through a problem before needing a handoff. It gives a single person who understands the problem and the product the ability to explore ideas, build working prototypes, and test them with far less friction than before.

The technology is capable, but speed is only valuable if you remain responsible for what gets produced. The real advantage is not removing the human from the process — it is allowing the human to work across more of the process while retaining ownership of every decision.