I Thought AI Would Make My Job Easier. First, I Had to Learn How to Use It.

The Beginning: I Thought I Was Asking the Right Questions

When I first began exploring artificial intelligence, I did not approach it as someone trying to become an AI expert.

I approached it as a Technical Project Manager curious about whether this technology could make my work more efficient.

Like many project managers, my days were filled with meetings, sprint planning, project updates, release coordination, technical discussions, documentation, stakeholder communication, and the constant responsibility of making sure the right people had the right information.

I had heard how AI could save time, summarize information, improve writing, and help professionals work more effectively.

Naturally, I wanted to understand how.

What I did not anticipate was how frustrating the learning process could be.

I would ask a question and receive an answer that looked professional.

Sometimes it was beautifully written.

Sometimes it was organized exactly the way I wanted.

But then I would read it more carefully.

It was not what I had asked for.

Or it included information that had never been provided.

Or it missed the most important part of the request.

And sometimes it was simply wrong.

I remember thinking, how can something that is supposed to be so intelligent misunderstand what seems like such a simple question?

I later realized the question might have seemed simple to me because I already understood the situation.

AI did not.

I brought years of professional experience, organizational knowledge, and project context into the conversation without explaining any of it.

I expected the technology to understand what I meant.

That was my first wrong turn.

And it would not be my last.

Learning That the Wrong Answer Sometimes Started With My Prompt

At first, I often wrote prompts the same way I would ask a coworker for help.

"Can you summarize this meeting?"

"Can you create a status update?"

"Can you write a professional email?"

"Can you help me organize these sprint goals?"

I assumed the instructions were clear.

After all, if I asked another project manager to prepare a status report, they would probably understand what I needed.

But that person might already know the project, the stakeholders, the current risks, and the purpose of the report.

AI did not necessarily have any of that information.

I began to recognize a pattern.

When I gave AI very little context, it often produced something generic.

When I asked broad questions, I received broad answers.

When I failed to explain the audience, the tone or level of detail could be wrong.

When I didn't tell it what information was missing, it sometimes filled those gaps with assumptions.

That last problem concerned me the most.

In technical project management, assumptions can have consequences.

An assumption about whether a ticket is completed can affect a release.

Assuming who owns an action item can create confusion.

An assumption about a technical dependency can affect a timeline.

An assumption about a stakeholder's approval can create an entirely different problem.

I began to understand that AI could help me organize information, but I needed to set boundaries on what it could conclude.

One of the most useful instructions I learned to include was:

"Use only the information provided. Do not assume missing details. If something cannot be confirmed, identify it as unknown."

It was a small change with an important purpose.

I was no longer asking AI for a simple answer.

I was asking it to distinguish between what it knew from the material and what it didn't.

That became a foundation of my approach.

The Difference Between Asking a Question and Writing an Effective Prompt

One of the most important discoveries in my AI journey was that prompting is a skill.

And like most professional skills, it improves with practice.

At first, I thought a prompt was simply a question.

Eventually, I learned that an effective prompt is more like a carefully written assignment.

It needed to establish the situation, explain the objective, identify the audience, describe the expected output, and set boundaries.

I began using a framework that I now include in my book, AI in Project Management:

Context + Task + Audience + Requirements + Format + Boundaries + Review

For example, imagine I needed to communicate sprint priorities.

My original approach might have been:

"Write our sprint goals."

AI could produce a perfectly reasonable list of generic sprint goals.

But that was not what I needed.

I needed goals that reflected actual work, specific Jira tickets, technical priorities, and what the team expected to accomplish by the end of the sprint.

A better prompt would be:

"Act as a writing assistant for a Technical Project Manager. Using the sprint information below, rewrite the goals so they are clear, specific, and measurable. Preserve the Jira ticket numbers and existing commitments. Organize the goals by team or workstream. Do not add new deliverables, change deadlines, or assume that work has been completed. If a goal is ambiguous, flag it for clarification."

Now I had established expectations.

I had explained what I wanted.

I had told AI what it should preserve.

And I had specifically instructed it not to change the information's meaning.

This became particularly valuable when working with technical documentation.

I did not always need AI to create something new.

Often, I needed it to help me communicate information I already had more clearly.

That is an important difference.

A project manager should not have to surrender control of the facts to improve the quality of the writing.

Meeting Notes: Where I Learned That a Summary Is Not the Same as the Truth

One area where I became especially interested in AI was meeting documentation.

As a Technical Project Manager, I meet every day.

Sprint planning.

Daily standups.

Technical discussions.

Requirements reviews.

Triage meetings.

Release preparation.

Stakeholder updates.

And the list continues.

Each meeting can produce decisions, action items, questions, risks, and follow-up work.

Keeping that information organized is essential.

So the idea of using AI to help with meeting notes was appealing.

But I quickly recognized a problem with asking AI to simply summarize a meeting.

A summary might tell me what everyone talked about.

It didn't necessarily tell me what was actually decided.

That distinction is critical.

Consider a technical meeting in which someone says:

"We should probably look into that issue before the next release."

Another person might respond:

"Yes, that may be something we need to address."

AI might interpret that exchange as an agreed action item.

But was a decision actually made?

Was someone assigned to investigate?

Was there a confirmed deadline?

Did the team agree to include the work in the next release?

Those questions matter.

A suggestion is not automatically a decision.

A discussion is not automatically an action item.

And a possible deadline is not the same as an agreed commitment.

I began changing how I asked AI to work with meeting transcripts.

Instead of:

"Summarize this meeting."

I moved toward instructions such as:

"Review the meeting transcript and identify confirmed decisions, action items, open questions, risks, blockers, and items requiring follow-up. For every action item, identify the owner and due date only if explicitly stated. Do not create assignments or deadlines. Separate suggestions from confirmed decisions. Where possible, include a reference to the relevant part of the transcript."

That was a much more useful approach.

I also learned that I needed to review the output against the original discussion.

Even a carefully written prompt cannot guarantee a perfectly accurate summary.

A transcript can contain errors.

People can speak ambiguously.

Technical terms can be misunderstood.

Several people may discuss the same issue without reaching a final decision.

The AI may still misinterpret the conversation.

My responsibility was to verify the information before treating it as an official project record.

I started thinking about meeting notes as evidence.

What was actually said?

What was actually agreed upon?

What still needed clarification?

And what should not be recorded as a commitment?

This helped me understand that effective AI use is not about accepting the first answer.

It is about knowing how to evaluate the answer.

The Misspelled Project Name That Taught Me a Lesson

One experience that stands out from my learning journey involved something that might seem minor: a misspelled project name.

I was using AI to help with meeting documentation, something I had begun exploring as a way to save time and organize information more effectively.

The generated notes looked professional.

The information was organized.

The format was useful.

But AI had misspelled a project name.

Fortunately, I didn't take the response word for word.

I reviewed the notes and recognized the mistake.

I corrected it, but not before the error was called out.

I will admit that was frustrating.

I was trying to learn a new technology and improve how I worked, only to run into a mistake as basic as a project name.

But the experience taught me something important.

In technical project management, details matter.

A project name is not just another word in a document.

It identifies specific work, connects conversations to initiatives, and helps people understand what is being discussed.

The same applies to Jira ticket numbers, technical terminology, release names, and product references.

An incorrect name can create confusion, especially when meeting notes become part of the official project documentation.

I realized that even when AI produces a polished response, it can still get the simplest details wrong.

Whether I wrote the notes myself or used AI to assist me, I remained responsible for the information.

That was not always a comfortable realization.

But it was necessary.

I couldn't simply say AI made the mistake and move on.

I had chosen to use the tool.

I was responsible for reviewing the output.

I was responsible for ensuring the information was accurate.

That experience changed how I approached my prompts.

I began adding more specific instructions:

"Preserve all project names, product names, technical terminology, and Jira ticket numbers exactly as provided. Do not guess at unfamiliar names or attempt to correct terminology without confirmation. If something is unclear, identify it for review."

I also learned the value of providing an approved list of project names and technical terms when appropriate.

This helped reduce the opportunity for mistakes.

But it did not eliminate the need for review.

That is one of the lessons I want to emphasize in my book.

A better prompt can reduce errors, but it does not eliminate accountability.

Learning to Remove Names From Meeting Notes

Another important lesson came when I began looking more carefully at how AI handled people's names in meeting documentation.

Meeting transcripts often identify everyone who speaks.

When AI creates a summary, it may carry those names into the final document.

At first, I did not always think about whether those names were necessary.

But as I continued learning, I began asking myself a different question.

Did the meeting notes really need to identify every person who made a comment?

Or should the notes focus on what was discussed, decided, and assigned?

For example, a meeting summary might state:

"John expressed concerns about the deployment process, and Sarah recommended reviewing the testing requirements."

But was it necessary to identify John and Sarah?

If the purpose of the notes was to communicate the issue and the next step, perhaps a more appropriate statement would be:

"Deployment concerns were discussed, and a review of testing requirements was recommended."

The information was still there.

The concern was documented.

The recommendation was preserved.

But the unnecessary attribution was removed.

I began to see the difference between documenting the work and documenting every person involved in the conversation.

That led me to improve my prompts again.

I learned to include instructions such as:

"Prepare professional meeting notes focused on project updates, decisions, risks, blockers, and follow-up work. Remove individual participant names from general discussion summaries. Use neutral language where appropriate. Retain names only when necessary to document assigned responsibilities, formal approvals, or required accountability. Do not invent owners or assignments."

This became especially useful when preparing notes intended for a broader audience.

Not every stakeholder needs to know who made every suggestion.

They need to understand what was discussed, what was decided, what remains unresolved, and what happens next.

Of course, there are situations where names are necessary.

If someone is formally assigned an action item, that ownership may need to be documented.

If an approval must be attributed to a specific individual, the record should reflect that.

And organizational documentation requirements must always be followed.

But I learned not to include names simply because AI had extracted them from the transcript.

I also learned an important security distinction.

Removing names from the final summary does not mean the original transcript has been anonymized.

The source material may still contain personal or sensitive information.

That information must be handled according to organizational security and privacy policies.

Again, I learned that the right prompt was only part of the process.

I also needed to understand what information was appropriate to include, what to remove, and what to keep for accountability.

The Bigger Lesson From My Meeting Notes

Looking back, the misspelled project name and my decision to remove unnecessary names from meeting notes may seem like two separate experiences.

But they taught me the same underlying lesson.

I needed to become more intentional.

I needed to think about what I was asking AI to do.

I needed to define what an accurate result looked like.

I needed to consider the audience.

And I needed to review the output before relying on it.

I stopped treating AI-generated meeting notes as a finished product.

Instead, I treated them as a draft that required my professional judgment.

I checked project names.

I verified technical terminology.

I reviewed action items.

I confirmed decisions.

I looked for unsupported assumptions.

I removed unnecessary names.

And I made sure the final document accurately reflected the meeting.

Being called out for that misspelled project name was not particularly enjoyable.

But it taught me a lesson I have carried forward.

AI can help me prepare the documentation, but my name, my credibility, and my professional responsibility are still attached to the final result.

Learning to Ask AI to Show Me What It Could Not Confirm

Another change in my prompting was learning to ask AI to identify missing information.

At first, I wanted complete answers.

I assumed that a complete response was a useful response.

But in project management, an incomplete answer that accurately identifies what is unknown may be more valuable than a complete answer built on assumptions.

Consider release readiness.

A project manager may have information showing that development work is complete, testing is underway, and deployment preparations have started.

That does not necessarily mean the release is ready.

There may still be outstanding defects.

Approvals may be missing.

Documentation may be incomplete.

A technical dependency may remain unresolved.

Instead of asking AI whether the release was ready, I learned that a more effective question would be:

"Based only on the information provided, identify which release readiness criteria are confirmed, which are incomplete, and which cannot be determined. Do not conclude that the release is ready unless the required evidence is present. List the questions that must be answered before a readiness decision can be made."

This is a different use of AI.

I am not asking it to make the decision for me.

I am asking it to help me identify what information I need to make an informed decision.

That distinction changed how I approached many project management responsibilities.

Sometimes I did not need AI to provide an answer.

I needed it to help me recognize what I had not yet asked.

Working With Security: Learning That the Right Question Comes Before the Prompt

As I became more comfortable with AI, another concern became increasingly important.

Security.

Technical project managers often work with information that cannot simply be shared anywhere.

We may have access to internal system architecture, customer information, operational procedures, technical vulnerabilities, credentials, confidential discussions, or business information.

When using AI, it can be tempting to provide as much context as possible.

After all, better context often leads to better responses.

But I had to recognize that more context is not always appropriate.

Before entering project information into an AI system, I needed to consider whether the tool was approved for that purpose and whether the information could be shared.

That meant asking different questions.

What information am I working with?

Is it confidential?

Does it include customer data?

Does it reveal internal security details?

Is this AI application approved by the organization?

What are the data retention and access policies?

Could I explain the problem using generalized or fictional information instead?

If I am uncertain, who in the organization can confirm what is permitted?

This is where I believe working with security professionals becomes particularly valuable.

Instead of treating security as an obstacle to using AI, we should involve the right teams to understand how to use it responsibly.

Our questions for security professionals should be practical.

Which tools are approved?

What categories of information can be entered?

Are there restrictions on meeting transcripts?

Can approved AI tools access internal documentation?

How should sensitive information be removed or protected?

What approvals are required for new integrations?

How are outputs reviewed before they become part of official project documentation?

I learned that responsible AI use isn't just about writing the right prompt.

It begins with deciding whether the information belongs in that prompt at all.

And you can't delegate that decision to an AI tool.

A well-written prompt does not make an unauthorized disclosure acceptable.

Learning That Different AI Methods Serve Different Purposes

Another important part of my journey was recognizing that AI isn't a single tool or method.

When I first began exploring AI, I focused on asking questions and receiving written responses.

Over time, I began looking at different ways AI could support my work.

For example, I could use conversational AI to explore how to structure project communication.

I could use an approved AI assistant to help organize information from documents.

I could use writing assistance to improve clarity and tone.

I could use AI capabilities integrated into existing project management systems to help locate or summarize authorized project information.

And I could use AI to evaluate a draft against a set of requirements.

These approaches are related but not identical.

One lesson I learned was that the method should match the task.

If I need to improve an email, I may only need writing assistance.

If I need to review a lengthy meeting transcript, I need a method that can work with the source material and help me trace conclusions back to it.

If I need to examine project information stored in Jira or Confluence, an approved integrated tool may be more appropriate than manually transferring information to an unrelated application.

If I need to evaluate a release checklist, I need to provide the actual criteria and supporting evidence rather than asking AI to make assumptions.

And if I need help understanding a technical concept, I may use AI to generate an explanation and follow-up questions, then verify the details against authoritative documentation and the appropriate technical experts.

During my learning, I explored tools such as ChatGPT, Microsoft Copilot, Atlassian Rovo, and Grammarly.

What became important was not simply learning which buttons to select.

It was understanding what I was trying to accomplish and which approved method best supported that objective.

I also began experimenting with different prompting techniques.

Sometimes I used a direct prompt with detailed instructions.

Sometimes I broke a complex task into smaller stages.

For example, instead of asking AI to review a meeting transcript, identify all decisions, assign priorities, and draft a stakeholder update in one request, I divided the work.

First, extract the relevant information.

Second, verify and organize the findings.

Third, identify what remains unclear.

Fourth, use the verified information to draft the communication.

This approach made it easier to identify where an error had occurred.

I also learned to use AI as a reviewer.

Instead of asking it to create a document, I might provide a draft and ask:

"Review this document for clarity, missing information, unsupported assumptions, and inconsistencies. Do not rewrite the content yet. Identify the areas that require my attention."

That was a valuable change.

AI was no longer just creating content.

It was helping me evaluate content.

I began to understand that learning AI was not about finding one perfect application.

It was about developing a collection of methods I could use appropriately in different situations.

The Frustration of Getting the Wrong Answer More Than Once

One part of learning AI deserves more attention.

The frustration.

We often hear about the successful results.

The perfectly written prompt.

The report created in seconds.

The time saved.

The impressive demonstration.

We hear less about what happens when the tool repeatedly misunderstands what we are asking.

I found that simply telling AI an answer was wrong did not always solve the problem.

If I said, "That is not what I meant," I might receive another response that was different but still incorrect.

If I said, "Try again," the tool might rewrite the same information without addressing the underlying issue.

Eventually, I realized that I needed to be more specific about the error.

Was it misunderstanding the audience?

Was it using the wrong source information?

Was it making an assumption?

Was it combining two separate issues?

Was it changing the meaning of a technical statement?

Was it confusing something discussed with something decided?

Once I could identify the problem, I could give better corrective instructions.

For example:

"You identified this item as a confirmed decision, but the transcript only shows that it was discussed. Move it to open questions and do not assign an owner."

Or:

"You stated that testing is complete, but the information provided only says testing is in progress. Correct the status and review the remaining summary for similar unsupported conclusions."

Or:

"This email sounds too formal and does not communicate the actual concern. Keep the facts unchanged, make the tone professional but direct, and clearly state the decision I am requesting."

These were more productive corrections than simply asking AI to try again.

I also learned that when the response kept being wrong, the best solution was sometimes to start over with a clearer prompt or a smaller task.

The goal wasn't to win an argument with the technology.

The goal was to get a reliable result.

Sometimes that meant recognizing that AI wasn't the right approach for the task.

The Moment My Approach Began to Change

As I kept practicing, I noticed my questions were changing.

I was no longer simply asking AI to produce something.

I was thinking about what information it needed.

I was thinking about what assumptions it might make.

I was thinking about how I would verify the result.

I was thinking about whether the output was appropriate for the intended audience.

And I was thinking about whether AI should handle the task in the first place.

That was when I began to feel more confident.

Not because AI had suddenly become perfect.

It had not.

But because I was developing a process I understood.

I could recognize when a response was too generic.

I could spot missing information.

I could ask for clarification.

I could provide better instructions.

I could challenge unsupported conclusions.

And I could decide whether the final result was suitable for professional use.

I began seeing AI as a tool that could support my experience rather than replace it.

That distinction mattered.

I had spent years developing my abilities as a project manager.

Learning AI did not make those skills irrelevant.

It made me more aware of how important they were.

My project management background helped me spot when an AI response was wrong.

My experience working with technical teams helped me identify the questions that needed asking.

My knowledge of stakeholder communication helped me recognize when a message was inappropriate.

And my responsibility for project outcomes reminded me that I could not simply accept an answer because it looked professional.

The technology became more useful when I stopped expecting it to know everything and started using my own knowledge to guide it.

Why I Decided These Lessons Needed to Become a Book

When I began writing AI in Project Management, I thought about the experiences that had shaped my own learning.

I thought about the first prompts that produced disappointing answers.

I thought about the time spent rewriting instructions.

I thought about learning how to distinguish decisions from discussions in meeting notes.

I thought about the misspelled project name that reminded me why every detail matters.

I thought about learning when to remove names from meeting documentation and when accountability required keeping them.

I thought about the importance of protecting sensitive information.

I thought about the different AI tools and methods I had explored.

And I thought about how much easier the beginning might have been if someone had explained these lessons to me.

That became part of my motivation for writing.

I didn't want to write a book that simply told project managers how wonderful AI could be.

I wanted to help them understand how to use it.

What to ask.

What to avoid.

How to recognize an incorrect answer.

How to improve a prompt.

How to work with meeting information.

How to approach security.

How to evaluate different AI methods.

And how to preserve their own professional judgment.

Most importantly, I wanted new project managers to understand that AI should not replace the fundamentals of project management.

It should support them.

Because no matter how sophisticated the technology becomes, someone still needs to understand the project.

Someone needs to ask the difficult questions.

Someone needs to recognize the risks.

Someone needs to communicate with stakeholders.

Someone needs to support the team.

And someone needs to be accountable for the decisions being made.

That responsibility doesn't disappear just because AI can generate an answer.

What I Hope Other Project Managers Learn From My Wrong Turns

I still consider myself a learner when it comes to artificial intelligence.

The technology keeps evolving, and new capabilities, questions, and challenges will always emerge.

But I no longer approach it the way I did at the beginning.

I understand that a good prompt requires thought.

I understand that a professional response still needs verification.

I understand that meeting notes must distinguish between facts, decisions, suggestions, and unresolved questions.

I understand that even a misspelled project name can affect the final document's credibility.

I understand that names should be included in meeting documentation for a reason, not simply because they appeared in the transcript.

I understand that security considerations must come before convenience.

I understand that different tasks may require different AI tools and methods.

And I understand that the most important skill is not simply knowing how to ask AI for an answer.

It is knowing whether that answer deserves to be trusted.

If I could offer one piece of advice to someone beginning this journey, it would be this:

Do not become discouraged when your first prompts do not produce the answers you expected. Instead, become curious about why.

Ask what information was missing.

Ask whether your instructions were clear.

Ask whether the technology made assumptions.

Ask whether the task should be broken into smaller steps.

Ask whether you have enough evidence to trust the response.

And never be afraid to challenge the answer.

That is how I began moving from frustration to understanding.

Not by discovering one magical prompt.

Not by finding an AI application that never made mistakes.

But by learning how to ask better questions, evaluate the results, and apply my experience as a Technical Project Manager.

The wrong turns became lessons.

The lessons became better habits.

And those habits eventually became the foundation for the book I am writing today.

AI did not teach me how to become a project manager. It taught me that even as an experienced project manager, I still had something new to learn about how I ask questions, evaluate information, and make decisions.

For me, that has been one of my most valuable discoveries.

Author's Note

This article draws on the themes, practical frameworks, and lessons developed for my forthcoming book, AI in Project Management. It reflects my perspective as a Technical Project Manager learning to integrate artificial intelligence into professional practice. The sample prompts and illustrative scenarios demonstrate the methods discussed, while the misspelled project name reflects a real lesson from my professional journey.

My research and prompting experiments have included tools such as ChatGPT, Microsoft Copilot, Atlassian Rovo, and Grammarly. I also used AI to help organize and develop this article. The perspectives, professional principles, and final editorial responsibility remain my own.