Last week, I was teaching core AI skills to a group at the Opus College of Business. The conversation that got the most energy was about project management.

That made sense to me.

A graduate from one of my classes had recently called with a problem. She had been managing two or three projects at a time. Then her organization gave her eight or nine.

She was not worried about whether she understood project management. She knew how to run a meeting, work with a team, and keep an eye on a timeline.

She was worried about the work created after every meeting.

Notes had to be cleaned up. Commitments had to be assigned. The project tracker had to be updated. Reminders had to be sent. Reports had to be prepared for the team and for senior leadership.

None of those tasks is difficult by itself. Together, they can take over a week.

We talked through where AI could help. By the end of the conversation, she had a better way to approach the work and a lot more confidence that eight or nine projects did not automatically mean eight or nine times the administrative burden.

Where Project Managers Lose Time

The best project managers do work that cannot be reduced to a tracker.

They notice when a small delay is about to become a real problem. They recognize when two teams are depending on each other without realizing it. They hear the concern behind a polite update in a status meeting. They know when to bring a decision to senior leadership and how to explain the consequences of waiting.

That is the job.

But much of the week gets spent on the surrounding administration:

• Capturing notes during status meetings

• Turning those notes into action items

• Confirming owners and due dates

• Updating a project tracker

• Following up with people who have commitments

• Preparing team updates

• Preparing a different version of the update for senior leadership

A project manager needs accurate information. The issue is how much time it takes to collect, organize, and restate that information over and over again.

What AI Can Take Off Your Plate

If your team uses Zoom or Microsoft Teams, you may already have a transcript from your meeting.

That transcript can give you a useful starting point. Rather than starting with a blank page, you can ask AI to organize the conversation, pull out commitments, and identify questions that still need an answer.

Prompt 1: Turn a Meeting Transcript Into Clear Commitments

Use this after a project-status meeting.

Review this project-status meeting transcript.

Create:

• A concise summary of decisions made

• A list of action items, including the owner, due date, and any dependency mentioned

• A list of commitments that were discussed but do not have a clear owner or due date

• Draft follow-up emails for each person with an action item

Do not infer missing information. If a commitment, owner, or deadline is unclear, list it as a question for me to resolve.

Once you have the commitments organized, the next question is whether the project plan itself is telling you something you may have missed.

Prompt 2: Review the Tracker for Risks and Bottlenecks

Use this when you have exported or copied your project tracker into the AI tool.

Review the project tracker below as if you were preparing for a project-status meeting.

Identify:

• Tasks that are overdue or likely to become overdue

• Dependencies that could delay other work

• Work assigned to the same person that may create a capacity problem

• Milestones that appear at risk based on the current dates and status

• Questions I should ask the team before deciding whether the project timeline needs to change

Separate confirmed issues from items that need further investigation. Do not assume that a late task automatically puts the project at risk.

This is useful because it gives you a short list of items to investigate before you walk into the next meeting. It does not replace your understanding of the project, but it can help you focus your attention.

The third place AI can save time is in preparing the update that goes to senior leadership.

Prompt 3: Prepare a Leadership Update That Helps People Decide

Use this after you have reviewed the meeting notes and tracker yourself.

Using the information below, draft a weekly update for senior leadership.

Include:

• What was completed this week

• What is planned for next week

• The two or three issues that need the most attention

• Any decision, resource, or escalation needed from leadership

• The likely effect on the delivery date, if there is one

Write in plain language. Be direct about risks, but do not overstate them. If the information is incomplete, identify what needs to be confirmed before the update is sent.

These prompts are meant to give you a strong first draft. They are not meant to send an update, change a tracker, or make a decision without your review.

Keep the Judgment Where It Belongs

AI can notice that a task is overdue. It cannot tell whether the date was unrealistic in the first place.

AI can identify a possible bottleneck. It cannot bring the right people together, negotiate for a resource, or decide which commitment should move.

AI can produce a clean leadership update. It cannot judge how a particular executive will react to bad news, nor can it make the case for a change in scope, timeline, or budget.

That work depends on experience. It also depends on relationships.

A capable project manager uses the information in front of them, asks the next question, and helps people decide what to do. No transcript or tracker can do that on its own.

Why This Matters for Your Career

When organizations are under pressure, people often talk about doing more with less.

For managers, that can become a trap. You work longer hours keeping the machinery moving, but you have less time to show the leadership that makes you useful.

Using AI well gives you a chance to change that.

You can spend less time formatting reports and more time working through the issue behind the report. You can look across projects for patterns instead of simply keeping each one current. You can give leaders a clearer picture of what needs attention before a deadline is missed.

That is the kind of work people remember.

If you are interviewing, this is also a practical example to bring into the conversation. You do not need to claim that AI will solve every project problem. Explain how you would use it to speed up meeting follow-up, organize commitments, and surface risks for review—while keeping decisions and communication in the hands of the manager.

That shows you understand both the tool and the job.

My goal in teaching AI has always been straightforward: help capable people spend more of their time on the work that requires their capability.

Project management is a good place to start.

What part of project administration takes the most time in your week? Reply and let me know. And if someone you know is trying to manage too many projects at once, please share this with them.

The interviewer asks, “Tell me about a time your analysis was wrong.”

You prepared twenty good answers. They are all about successes.

And for a few seconds, you have nothing.

That moment is not necessarily evidence that you are unqualified. It is evidence that interview preparation is usually pointed in the wrong direction.

Most candidates prepare by predicting questions and rehearsing answers. That is sensible up to a point. But a question is rarely the thing an interviewer actually wants to know. It is a rough instrument: an attempt to find out whether you can do the work, how you think under pressure, where you may create risk, and whether you will make that person’s life easier or harder.

The person asking it may not even be fully conscious of all of that.

That is why two candidates can give similarly strong answers and one advances while the other does not. The interviewer is hearing the answer through a particular set of concerns: a difficult vacancy, a prior bad hire, a demanding manager, a team under strain, or a department trying to change. The written job description is part of the picture. It is not the whole picture.

The preparation task, then, is not simply: What questions might I be asked?

It is: What is this person trying to learn before they are willing to take the risk of hiring me?

Here is the sequence. Each step gives the next one something better to work with:

1. Collect evidence about the role, company, team, and interviewer.

2. Build an interviewer hypothesis: the outcomes, risks, and proof points that may matter most.

3. Use that hypothesis to identify the difficult questions—especially the ones your resume does not answer cleanly.

4. Pressure-test your real stories against those questions and likely follow-ups.

5. Rehearse out loud so you can think clearly rather than recite a script.

Most people begin at step three, with a generic list of questions. The more useful preparation happens in the two steps before it—and becomes real in the two steps after it.

The interviewer has more reps than you do

An experienced interviewer may have met dozens—or hundreds—of candidates. Most professionals enter a high-stakes interview only a handful of times in a decade. You cannot close that experience gap overnight.

You can reduce the information gap.

I have written before about building personas for the people in a boardroom: not caricatures, but working hypotheses about what each person needs to hear, what they will challenge, and what they consider risky. The same method is useful in an interview.

Not because it lets you “game” the interviewer. It does not. And it should not encourage you to invent a false version of yourself.

It helps you do something more useful: prepare for the concerns behind the questions, identify the stories in your experience that will bear real scrutiny, and practice making your value legible to the person deciding whether to move you forward.

This works for an external job search. It also works for a promotion panel, a skip-level conversation, or any situation where someone needs to decide whether you are ready for more responsibility.

Step 1: Collect evidence, not guesswork

Start with public, relevant information. You are not trying to psychoanalyze someone. You are building a practical working brief.

Collect four inputs:

1. The role. Read the posting for more than keywords. What outcomes does it emphasize? What is repeated? What problem seems urgent enough that the company is hiring now?

2. The company. Look at recent news, earnings or investor materials when relevant, leadership communications, customer announcements, and the company’s own language about what differentiates it. Ask: What pressures or priorities are likely shaping this hire?

3. The team. If you can, speak with people who work in or alongside the department. Associates, specialists, and managers may have a clearer view than a corporate careers page of how work actually gets done and what the team values. Treat individual perspectives as perspective—not fact.

4. The interviewer. Use the hiring manager’s or recruiter’s public profile, professional background, and published work. For a hiring manager, also look at profiles of people doing similar work on the team. Patterns in how they describe the role can reveal what the written posting leaves out.

Step 2: Turn the evidence into an interviewer hypothesis

Now ask a generative AI tool to help you turn those inputs into an interviewer hypothesis. The language matters. It is a hypothesis, not a diagnosis. You are asking the tool to organize evidence and surface questions—not to claim access to a stranger’s private thoughts.

Here is a prompt to begin:

I am preparing for an interview. Below are the job posting, public information about the company and team, and a public summary of the interviewer or hiring manager.

Build an evidence-based interviewer brief. Identify: (1) the outcomes this hire likely needs to deliver, (2) the risks or problems the interviewer may be trying to avoid, (3) what they are most likely to probe, and (4) what evidence would earn confidence. Separate supported observations from reasonable hypotheses, and flag what I cannot know from public information.

Do not skip that last sentence. It keeps the output honest.

Step 3: Find the questions you do not want

Most interview tools will gladly generate a generic list of questions. That is the easy part—and the least valuable one.

Once you have an interviewer brief, use it to find the questions that expose a gap between your resume, the role, and the concerns behind the hire. These are the questions worth rehearsing.

Based on the interviewer brief, the job posting, and my resume below, generate the ten most likely challenging questions. Then identify the three questions most likely to expose a weak or incomplete story in my background. For each, tell me what the interviewer is trying to learn and what I should prepare or clarify. Be direct; do not assume I am a strong fit.

Notice the shift. The goal is not to manufacture a perfect answer. It is to learn where your evidence is thin before someone else finds it in the room.

For each difficult question, prepare one real example. Know the situation, what you did, what changed, what you learned, and the limits of your role. That gives you the raw material for the next step. If an answer requires too much polishing to work, it probably is not yet your best story.

Step 4: Pressure-test the story, not just the delivery

Candidates often practice until an answer sounds smooth. Smooth can be useful. It can also sound rehearsed.

The more valuable practice is to make the interviewer skeptical and let them follow the thread.

Here is a story I plan to use in the interview: [paste]. Act as the interviewer described in the brief. Where would you lose confidence? What follow-up questions would you ask? What is unclear, unsupported, or too polished? Be specific, and distinguish feedback grounded in the brief from general interview advice.

This is where a good story gets better. You may discover that you need a clearer result, a more candid account of what went wrong, or a more precise explanation of what you did rather than what the team did.

It is also where you may discover that a story does not belong in your interview at all. Better to learn that in rehearsal.

Step 5: Run the rehearsal out loud

Once the persona and stories are ready, conduct a live simulation. Answer verbally. An interview is not a writing assignment, and many answers that look crisp on a screen become tangled when spoken.

Conduct a realistic interview using the interviewer brief and my resume. Ask one question at a time, beginning with the most challenging. After each answer, give concise feedback on what increased confidence, what created doubt, and the most likely follow-up. Do not invent facts about the company or interviewer. Stop after six questions and identify the three changes that would most improve my performance.

Run this more than once. Change the sequence. Ask for a recruiter version and a hiring-manager version if both will interview you. The point is not to memorize a script. It is to become more comfortable thinking clearly when the question is not the one you hoped for.

What this method cannot do

This approach is preparation, not prediction.

It cannot turn thin experience into the experience the role requires. It cannot reveal private dynamics, and it cannot tell you why a company selected someone else. Public information may be incomplete or stale; generative AI may confidently invent details. Verify every company fact you plan to mention, and never present a hypothesis about an interviewer as if it were fact.

It also should not make you over-script. The best interviews still feel like a conversation between two people trying to decide whether there is a real fit.

But there is a meaningful difference between walking into that conversation hoping you have rehearsed enough answers and walking in with a clearer view of the person, problem, and decision on the other side of the table.

That is the advantage worth preparing for.

Try this before your next interview

Spend 30 minutes on the evidence brief before you ask for a single list of interview questions. Build the interviewer hypothesis, identify the three questions you most hope will not be asked, and answer them aloud.

The goal is not to predict the interview perfectly.

It is to make the next question less likely to surprise you—and to make your real experience easier for the interviewer to see.

This is the first in a practical job-search series. Next: how to treat the search itself as a managed pipeline rather than a collection of browser tabs and half-finished applications.

I have been thinking more about vibe coding, and one place where I think it may matter a lot is the relationship between business teams and IT.

Most organizations have some version of the same problem. The business team explains what it needs, IT listens carefully, someone writes requirements, and everyone seems to agree. Then the first working version appears, and people realize they were not actually imagining the same thing.

The business team says, “That’s not what we meant.” The technology team says, “That’s what you asked for.” And now everyone is frustrated.

I do not think this usually happens because people are careless or incompetent. I think it happens because written requirements are a pretty limited way to describe something people have not seen yet.

That is where vibe coding gets interesting.

I am not suggesting that business teams are going to replace IT. I am also not suggesting that a vibe-coded prototype should be treated as production-ready enterprise software. That would be a mistake.

The practical value is that vibe coding gives business and technology teams something to look at together before they spend months trying to build something they may not actually agree on.

What I Mean by Vibe Coding

Vibe coding is the ability to create a rough website, dashboard, app, workflow, or tool by describing what you want in plain language and then improving it through a conversation with an AI tool.

You start with intent. You explain what the tool should do, who it is for, what problem it should solve, and what a useful first version might include. Then you react to what appears. You revise the pages, buttons, fields, workflows, labels, examples, and outputs.

The result may be rough, but it can still be useful.

It may not be secure. It may not be scalable. It may not connect to enterprise systems. It may not comply with internal standards. It may not be ready for customers, employees, or regulators.

But that is not the point.

The point is that the idea is no longer trapped in a document. It is visible, clickable, and easier to discuss.

The Old Requirements Process Has a Translation Problem

In many organizations, the technology development process starts with written requirements. That makes sense. Requirements matter. So do documentation, governance, architecture, security, and integration.

The problem is that written requirements can create the illusion of shared understanding.

A marketing team may say, “We need a better customer portal.” A sales team may say, “We need a better account planning tool.” A finance team may say, “We need a dashboard that lets us run scenarios.” An operations team may say, “We need a workflow that tracks approvals.”

Those statements sound clear until someone has to build them.

What does “better” mean? Which user matters most? What decision should the tool support? What should the first screen show? What should happen when a user clicks? Which exceptions matter? What should the output look like? What should the tool not do?

These are not minor details. These are the product.

This is why so many projects become frustrating. The business team believes it has explained the need clearly. IT believes it has followed the request. Both sides are often acting in good faith, but they are relying on words to describe something that really needs to be seen.

Mockup, Prototype, and Production System

I think it helps to separate three things that are often blended together.

A mockup shows what something might look like.

A prototype shows how something might work.

A production system is what the organization can actually rely on.

Vibe coding is most useful in the middle category. It is not just a picture, but it is also not the final system. It sits in between. It gives people something realistic enough to react to, without pretending that the real development work is finished.

That distinction is important. If leaders treat the prototype as the product, they will underestimate the work required. If IT treats the prototype as irrelevant because it is not production-ready, they may miss the business clarity it provides.

The value is in using the prototype for the right purpose.

Vibe Coding Creates a Shared Object

A prototype gives both sides something to point to. That sounds simple, but it can change the discussion.

Instead of saying, “We need a dashboard,” the finance team can show a rough version of the dashboard. Instead of saying, “We need a better customer experience,” the marketing team can walk through a draft version of the customer journey. Instead of saying, “We need a workflow tool,” the operations team can demonstrate the steps they think the workflow should include.

Then people can react to something specific.

They can say, “That screen is wrong.”
“That workflow skips a step.”
“That data does not exist.”
“That is not how managers would actually use it.”
“That would create a compliance issue.”
“That is the part we really need.”

Those are much better conversations to have early.

A static mockup may help people react to design. A working prototype helps people react to logic, sequence, flow, language, data, decision points, and user behavior.

That is why I think vibe coding could become an important part of the requirements process. It gives the organization a better way to discover what people actually mean.

This Is Not About Bypassing IT

A reasonable skeptic might say, “Isn’t this just shadow IT with better branding?”

That is a fair concern.

If vibe coding becomes a way for business teams to build tools outside normal governance, avoid security, skip documentation, and ignore architecture standards, then it could create real problems.

That is not the use case I am arguing for.

The better use of vibe coding is not to bypass IT. It is to improve the front end of the development process. Business teams can use prototypes to make their needs clearer. IT teams can use those prototypes to ask better questions, identify risks earlier, and translate the business need into something that can actually be built, secured, integrated, and maintained.

The useful next step is not to hand the prototype to IT and say, “Build this.”

The useful next step is to say, “This is our best attempt to show the business need. Now help us understand what is feasible, what is risky, what would need to change, and what we are missing.”

That is a very different conversation.

What Should Happen After the Prototype?

This is the part that matters if organizations want to use vibe coding responsibly.

The process should probably look something like this.

First, the business team creates a rough prototype to show the need. The goal is not technical perfection. The goal is clarity. What does the user need to do? What information do they need? What decisions should the tool support? What does a better process feel like?

Second, the business team and IT review the prototype together. This is where the assumptions come out. IT can ask about data sources, permissions, integrations, security, maintenance, scalability, and edge cases. The business team can explain what is essential and what was only included to make the prototype easier to understand.

Third, IT translates the useful parts into real requirements, architecture, and development plans. Some parts of the prototype may survive. Some may change. Some may be impossible or too expensive. That is fine. The point is that the discussion starts from a clearer place.

The prototype is not the thing you ship. It is the thing you use to have a much better conversation.

A Simple Example

Imagine a finance team wants a tool that lets regional managers test different sales assumptions.

In the old process, the team might write a requirements document. It might describe inputs, outputs, formulas, approval steps, and reports. That document would be useful, but it would still leave a lot to the imagination.

With vibe coding, the finance team could create a rough version of the tool. It might include input fields for sales growth, margin, staffing, and regional assumptions. It might show a simple output chart. It might include a few scenario buttons: conservative, expected, aggressive. It might show the questions managers are supposed to answer before submitting their forecast.

That prototype would not be the final system. It probably would not connect to the company’s financial data. It might use fake numbers. It might be wrong in several places.

But it would let finance, IT, and regional leaders have a much better conversation.

Finance could show what it means by scenario planning. IT could identify the real data and integration issues. Regional leaders could say whether the tool matches how they actually think about the business. Executives could decide whether the idea is worth funding before the organization invests heavily in building it.

That is the value.

Where This Could Matter

The obvious use case is websites. A business team could prototype a landing page, product microsite, internal portal, or customer education site. Instead of handing over a vague request, they could show the structure, language, flow, and intended experience.

But I do not think this stops with websites. The same pattern applies to dashboards, reporting, financial modeling, sales tools, internal workflow tools, and executive presentations.

A sales leader could prototype a better account planning interface. A marketing team could build a mock customer journey. An operations team could sketch a new approval process as a working application. A finance team could create a rough scenario-planning tool.

I also think this could change some executive presentations. PowerPoint is still useful, but we often use slides to describe systems, workflows, and tools that would be easier to understand if people could interact with a rough version. For some ideas, a prototype may be more persuasive than another deck.

The Risk: A Good Demo Can Be Misleading

There is one danger here.

A good-looking prototype can make the real build seem easier than it is. Leaders may look at a working demo and assume the hard part is done.

It is not.

The hard parts may still include data quality, system integration, permissions, security, maintenance, compliance, change management, training, and support. In some cases, the prototype may make something look simple that is actually quite complicated inside the organization.

That does not mean the prototype is bad. It means leaders need to understand what it is and what it is not.

A prototype should help people understand the desired future. It should not be used to pretend that the technical, organizational, and governance work has disappeared.

The Leadership Shift

The practical leadership question is not, “Can my team vibe code?”

The better question is, “Where are we still using documents to describe things that should be demonstrated?”

Documents still matter. Requirements still matter. Governance still matters. But for many business technology projects, the first serious artifact could be a rough prototype paired with a short explanation of the business problem, the intended user, and the desired outcome.

That would change the early stages of development. Business teams would have to think more clearly about what they actually want. IT teams would have a better object to critique. Executives would see ideas earlier. End users could react sooner. The organization could kill bad ideas faster and improve good ideas before they become expensive.

Vibe coding is not just about speed. Speed is useful, but speed in the wrong direction is still waste.

The bigger opportunity is getting to clarity earlier.

Three Prompts to Try

Here are three prompts you can use if you want to test this idea inside your own work.

Prompt 1: Turn a Business Need Into a Prototype Brief

I want to create a rough prototype for a business capability before taking it to IT.

The business problem is: [describe the problem].
The primary users are: [describe the users].
The decisions or actions this tool should support are: [list them].
The current process is frustrating because: [explain what is slow, unclear, manual, or ineffective].

Help me turn this into a prototype brief. Include the likely screens or pages, the core workflow, needed data or inputs, expected outputs, and questions IT would likely ask before building this for real.

Prompt 2: Stress-Test a Vibe-Coded Prototype Before Showing IT

I have created a rough prototype for the following business process: [describe the process].

The prototype is intended to show: [describe what it demonstrates].
The audience is: [IT team, executive sponsor, operations leader, finance team, etc.].

Review this as a skeptical technology partner. What assumptions are unclear? What security, data, integration, governance, scalability, or maintenance questions need to be answered? What parts are useful for requirements gathering, and what parts might mislead people if we are not careful?

Prompt 3: Convert a Prototype Into Better Requirements

I have a rough prototype that shows the business capability we want to build.

Help me convert it into a first draft of business requirements. Organize the output into: business problem, intended users, core user stories, key workflows, required data inputs, expected outputs, integration needs, security or compliance considerations, open questions for IT, and items that are only illustrative in the prototype and should not be treated as final requirements.

The Bottom Line

I do not think vibe coding eliminates the hard parts of enterprise technology development. You still need IT, governance, security, integration, and disciplined execution.

But it may give organizations a much better place to start.

Instead of asking business teams to describe something they have not seen yet, we can ask them to create a rough version, react to it, improve it, and then work with IT to figure out what it would take to build it properly.

That feels like a real shift to me.

Not because business teams can suddenly replace technology teams. Because business teams and technology teams may finally be able to look at the same thing before they spend months trying to build it.

Next week, I’ll walk through a specific example of what this could look like in practice.

For the past six months, I have been building websites for my executive education courses and for my personal site. Each one has taken less than an hour to build, using content I already had and a working conversation with AI.

That should get more attention than it does.

Most business leaders still think of websites as something that requires a formal project, technical skill, outside support, or a long back-and-forth with marketing or IT. That assumption is getting weaker fast.

Vibe coding changes the starting point.

A non-technical professional can describe the site they want, upload relevant materials, and work with an AI tool to build it. In many cases, the result is not just a single page. It is a structured, multi-page site that reflects the content, priorities, and audience the user had in mind. A presentation, proposal, or set of documents can become a working site in a short amount of time.

And in many cases, the tool will host it too.

That means a business user can move from an idea to a working site to a shareable link without waiting for a full development cycle.

Why This Matters

The value here is not just speed.

The bigger shift is that business people now have a much faster way to make an idea visible.

That changes the conversation.

A written concept note is easy to misunderstand. A requirement list leaves room for interpretation. A website prototype gives people something concrete to react to. Once that happens, the quality of the feedback improves, the gaps become easier to spot, and the discussion gets more productive.

That is why I do not think vibe coding is mainly a website story.

I think it is a communication story.

Four Places Where This Has Immediate Value

1. Product Development

This matters for both digital and physical products.

One of the hardest parts of early product work is helping people see what you mean. A website prototype makes the idea more tangible. Leaders can show what the product is, how it works, what the user experience might feel like, and how the pieces fit together.

That makes early discussion better, when changes are still cheap, and the idea is still flexible.

2. Market Research

A fast-built site also makes it easier to test concepts with customers.

Instead of describing a future offering, you can show people something they can actually react to. That usually produces better feedback. People respond more clearly to an experience than to an explanation.

And when the site can be revised quickly, that feedback loop gets much tighter.

3. Business and IT Alignment

This may be one of the most useful applications.

A familiar pattern in technology work is that the business team signs off on requirements, the technology team builds what those requirements describe, and the business team then says the end product is not what they had in mind.

Usually, that is not because one side failed to listen.

It is because a list of requirements is a weak substitute for something people can see.

A quickly built website gives business users a better way to respond more quickly. It gives technology teams a clearer direction. It should also reduce some of the revision cycles that create frustration on both sides.

4. Sales and Executive Communication

This is where I expect many professionals to use it first.

A salesperson can build a site for a specific prospect instead of sending only a proposal deck. That site can show the offering, illustrate the customer’s likely use case, and make the impact easier to understand. It also signals effort. A tailored site shows that real thought went into the pitch.

The same logic applies inside companies.

I can see vibe-coded sites taking on some of the work that PowerPoint handles now. A website can hold more depth, more navigation, and more supporting material than a slide deck. It also lets the audience move through the material based on their own questions.

PowerPoint is still useful. But many people are exhausted by how much time is spent formatting slides when the real work should be clarifying the message and anticipating what the audience will need.

What This Is Not

This is not an argument that every AI-built site is ready for production use.

Security still matters. Governance still matters. Brand standards still matter. System integrations still matter. Not every internal document should be uploaded into a tool, and not every quickly built site should be shared externally without review.

I am also not arguing that vibe-coded websites will replace formal development teams.

That is not the point.

The point is that they can dramatically improve what happens before formal development begins. They can help teams test concepts, surface misunderstandings, improve feedback, and make ideas more concrete before making larger time, budget, and technology commitments.

That is still a meaningful shift.

The Broader Shift

The real story is not that websites are becoming easier to build.

The real story is that business professionals are getting a faster way to turn rough ideas into visible prototypes.

That matters because many ideas stall when they are still trapped in the form of explanation. Once people can see the idea, the conversation improves. Better questions show up earlier. Misunderstandings surface sooner. Progress speeds up.

Vibe coding does not remove the need for clear thinking. In some ways, it increases it. If the concept is vague, the site will reveal that quickly. But that is part of the value. Weak ideas and unclear assumptions show up earlier, when they are easier to fix.

That is why I think vibe coding matters.

Not because everyone suddenly needs to become a web developer.

Because more professionals now have a way to communicate ideas with more clarity and less friction.

You can already see signs of this shift in tools like Lovable and in the push by major AI platforms toward easier site creation and hosting. The tool names will change. The broader pattern will not.

Three Prompts You Can Use

Prompt #1: Turn a Concept into a Website Prototype

Create a simple multi-page website for this concept. The audience is [target audience]. The purpose is [sales / internal communication / product concept / event / executive education]. Using the content below, propose the site structure, page flow, headlines, and key sections for each page. Keep it clear, practical, and business-focused, then build the first site outline.

Prompt #2: Convert Existing Materials into a Site

Using the source materials below, create a website concept that is clear, organized, and easy for a non-technical audience to navigate. Recommend the site architecture, identify what should become separate pages or sections, and note any missing content needed to strengthen the site. Prioritize clarity, usefulness, and audience engagement over decorative design.

Prompt #3: Build a Client-Specific Sales Page

Create a client-specific website concept for this prospect. The goal is to show that we understand their situation, explain how our offering fits their needs, and make the value easy to see. Use the materials below to recommend the page structure, messaging, proof points, and visuals. Keep it specific, credible, and focused on the client’s likely priorities rather than generic marketing language.

What Leaders Should Watch

If you are evaluating this seriously, I would watch three things.

How quickly can your team move from idea to visible prototype?

Does that improve the quality of customer or internal feedback?

Does it reduce friction between the people asking for something and the people responsible for building it?

That is where the value will show up first.

The Takeaway

Vibe coding is easy to dismiss if you see it as a faster way to make websites.

I think that misses the point.

It is a faster way to make ideas visible.

And once ideas become visible, better business conversations usually follow.

Last week I learned something about AI-generated content that I wasn’t expecting: a piece of content I wrote myself was flagged as AI-generated.

The article was intended for possible publication through our university’s media department. My process is straightforward. I dictate ideas, examples, observations, and recommendations into Microsoft Word, then use AI to help improve organization and structure. This is very similar to how I develop many of my Substack articles.

This time, however, I added an extra step. Because the article was intended for newspapers, newsletters, and podcasts, I asked AI to revise the language to better fit those formats.

The resulting article looked good. The ideas were mine. The facts were accurate. The recommendations were unchanged. Although I noticed the tone was somewhat different from my normal writing style, I assumed that was simply a result of adapting the content to a new medium.

That assumption turned out to be wrong.

Shortly after submitting the article, I received an email informing me that both the university media department and the publication distribution service had flagged the content as AI-generated.

My first reaction was embarrassment. I had not intended to submit AI-generated content and have always been careful to ensure that the ideas and recommendations I share come from my own experiences, observations, and conversations with business leaders and practitioners.

My second reaction was confusion. If I had written the article myself, how could it be identified as AI-generated?

As I reviewed my process, the answer became obvious.

I had asked AI to optimize the content for publication standards, but I had forgotten to tell it to preserve my voice.

Looking back, that was the entire mistake.

The revised article sounded like something I would read in a business publication. It was polished. It flowed well. But it no longer sounded like the way I naturally explain ideas to students, executives, or clients.

In trying to make the article more publishable, I had unintentionally removed many of the characteristics that made it mine.

The problem wasn’t that AI wrote the content.

The problem was that AI replaced my voice.

After recognizing the issue, I went back to my original dictated version. Instead of asking AI to rewrite the article, I asked it to identify areas where the content could be improved. Where were transitions weak? Which sections needed additional context? What might be unclear to a general audience?

AI became a reviewer rather than a ghostwriter.

I then made the revisions myself. The final version was clearer, more authentic, and ultimately more compelling than the AI-rewritten version. More importantly, it sounded like me.

The experience highlighted a lesson that I suspect will become increasingly important as AI writing tools continue to improve.

Most conversations about AI writing focus on whether the facts are accurate or whether the content was created by a human. After this experience, I think there is another issue that deserves just as much attention.

What happens when your writing no longer sounds like you?

If you repeatedly accept AI-generated phrasing, vocabulary, and sentence structure, your work can gradually begin to sound like everyone else’s. The ideas may still be yours, but the language that communicates those ideas becomes less distinctive.

For professionals whose value depends on expertise, credibility, and perspective, that should be a concern.

What Changed in My Process

The experience changed two parts of my workflow.

First, voice now has to be an explicit requirement whenever I use AI to assist with writing. Not just tone, but the specific characteristics that make the writing recognizable: sentence structure, vocabulary choices, pacing, examples, and the types of observations I tend to make.

Second, I am increasingly using AI as an editor rather than a writer. Instead of asking for complete rewrites, I ask for critique. Where is the argument weak? What assumptions am I making? Which sections need more context? What questions might a reader have?

That approach keeps ownership of the language where it belongs while still benefiting from AI’s ability to identify opportunities for improvement.

Two Prompts You Can Use

Prompt #1: Preserve My Voice

Paste a sample of your writing and then use:

Analyze the writing samples below and identify the characteristics of my writing style, including sentence structure, vocabulary, tone, pacing, use of examples, and common patterns. When revising my content, preserve these characteristics. Do not replace my voice with a generic professional writing style. Explain any significant changes before making them.

This helps prevent AI from defaulting to the same polished business language that appears across thousands of articles and LinkedIn posts.

Prompt #2: Critique Instead of Rewrite

Instead of asking AI to improve your content, try asking:

Review the article below and identify areas where clarity, organization, transitions, examples, or audience understanding could be improved. Do not rewrite the article. Instead, provide specific recommendations and explain why each recommendation would strengthen the piece.

This turns AI into an editor rather than a ghostwriter.

The Bigger Lesson

The ideas in my article were mine from the beginning. The problem was that I had delegated too much of the language. In trying to make the content fit a broader publication format, I had allowed AI to smooth away some of the characteristics that made the writing recognizable.

Going forward, my process will be simple:

1. Dictate or draft the content myself.

2. Use AI to improve structure and organization.

3. Ask AI to critique clarity and audience fit.

4. Make the revisions myself.

5. Compare the final version to examples of my previous writing.

The lesson wasn’t that AI produced bad content.

The lesson was that I stopped paying attention to whether the content still sounded like me.

Last week, I walked into a room where I was clearly out of my depth.

I was presenting at my first academic conference. Two papers. Two sessions. An audience of professors and Ph.D. students who had spent years studying the exact topics I was about to talk about.

They knew the literature better than I did.
They knew the frameworks better than I did.
And they were trained to ask hard questions.

I had a co-author there, which helped. But once the session started, it was still on me.

That’s where I changed how I prepared.

The mistake most people make

When the stakes go up, most people do more of the same:

• Re-read their slides

• Practice delivery

• Hope they don’t get asked something they can’t answer

That’s not enough.

Because in high-stakes situations, the risk isn’t forgetting what you planned to say.

It’s not being ready for what you didn’t plan for.

What I did instead

I treated preparation as a simulation.

Not just:

“What am I going to say?”

But:

“What is this room going to do to me?”

So I built the room before I walked into it.

Step 1: Recreate the audience

I gave ChatGPT as much context as I could:

• The conference

• The session

• The other presenters

• The general tone of academic discussions

Then I asked:

Create a profile of someone likely to attend this session. 
What do they care about? What do they challenge? What do they expect?

This changed how I saw the presentation.

I stopped thinking about what I wanted to say—and started thinking about what they would question.

Step 2: Pressure test the content

Next, I had it go through my material and look for weak points:

Review this presentation. Identify:
- Areas that are unclear
- Gaps in logic
- Claims that need stronger support
- Places where a skeptical audience would push back

This is where the real work happened.

I ended up revising each presentation multiple times—not for style, but for clarity and structure.

Step 3: Generate the questions you don’t want to get

This was the most valuable step.

Generate a list of challenging questions an academic audience might ask after this presentation.
Prioritize questions that test assumptions, methodology, or missing context.

Some of the questions pointed to papers I hadn’t read.

So I followed up:

Summarize this paper and explain how it relates to my topic.
What position does it take, and how might someone use it to challenge my argument?

That alone reduced most of the anxiety.

Because now, I had already heard the hard questions.

Step 4: Adjust how I positioned myself

This was something I wouldn’t have done on my own.

I asked:

Given this audience, how should I position myself at the start of the presentation to establish credibility?

The answer was consistent across slides:

• Acknowledge my background briefly

• Then move quickly into the process and structure behind the work

• Speak to the framework, not just the outcome
  

That shifted how I talked through each slide.

I wasn’t just presenting ideas.

I was showing how the ideas were built.

What actually happened

Across both sessions, I got one question that really pushed me.

My co-author stepped in, we worked through it, and the discussion moved forward.

Everything else?

I had already seen some version of it.

What this means for your work

You don’t need to be presenting at an academic conference for this to matter.

This applies anywhere the stakes are high:

• Executive presentations

• Client proposals

• Board meetings

• Job interviews

Most people prepare for delivery.

Very few prepare for interaction.

Use this before your next high-stakes moment

If you only do one thing, do this:

Here is my presentation:
[paste]

Here is the audience:
[describe them]

Generate:
1. The 10 most likely challenging questions
2. The 3 questions that would expose a weak argument
3. What I should clarify before presenting

Then fix the weak points before you walk into the room.

What changes when you prepare this way

• You stop hoping it goes well

• You start expecting what will happen

• You spend less time reacting and more time responding

And most importantly:

You walk in knowing where you might get challenged—and what you’ll say when it happens.

Bottom line

High-stakes situations aren’t about perfect delivery.

They’re about being ready for the moment the plan breaks.

Prepare for that.

Final takeaway for your work

If your preparation only includes what you plan to say, you’re not fully prepared.

The advantage comes from preparing for:

• The questions

• The pushback

• The conversation that follows

That’s where most people lose control.

And where you can stand out.

Last week I was reviewing a workshop presentation that included multiple slide decks, activities, Google Drive links, prompts, datasets, worksheets, and supporting documents.

As I walked through it, I kept thinking:

“This should work.”

But I have learned something important about workshops over the last few years.

The instructor is usually the worst person to judge whether a workshop actually makes sense.

Not because the instructor is unprepared.

Because the instructor already understands everything.

We know:

• where the files are

• what the acronyms mean

• which prompts are supposed to work

• what the end result should look like

• which tabs need to stay open

Participants do not.

And the more expertise you have, the harder it becomes to see the workshop the way a first-time learner sees it.

That is where ChatGPT has become surprisingly useful for me.

I no longer just use it to help create presentations.

I use it as a participant.

Making ChatGPT Attend the Workshop

Before I run a workshop now, I ask ChatGPT to take on the persona of one of the attendees.

I give it background information such as:

• role and experience level

• technical comfort with AI tools

• goals for attending

• likely frustrations or concerns

• time or workflow constraints

Then I upload:

• slide decks and activity instructions

• worksheets, prompts, and datasets

• supporting documents and links

And I ask ChatGPT to go through the workshop step by step as if it were attending live for the first time.

The results have been far more useful than I expected.

What ChatGPT Notices That I Often Miss

When ChatGPT acts as a participant, it starts identifying friction points almost immediately.

For example:

• “I do not know where to find this file.”

• “The instructions refer to a spreadsheet with a different name than the earlier slide.”

• “This activity assumes I already know how to use pivot tables.”

• “I am not sure what success looks like for this exercise.”

• “I would probably fall behind at this point.”

Those comments are valuable because they reflect the participant experience rather than the instructor perspective.

In one workshop, ChatGPT pointed out that I had used slightly different wording for the same deliverable in three different places.

I had never noticed it because I already understood what I meant.

A participant would not.

In another case, it identified that an activity depended on a support document that had never actually been linked anywhere in the materials.

Again, I never noticed because I already had the document open on my own computer.

The Dangerous Assumption Experts Make

One of the biggest risks in teaching, training, consulting, and presenting is assuming that clarity in your own head equals clarity for everyone else.

It does not.

Experts compress steps mentally.

We skip explanations because the transition feels obvious to us.

We forget how many small decisions participants are trying to process simultaneously:

• new terminology

• unfamiliar tools

• unclear instructions

• timing pressure

• uncertainty about whether they are “doing it right”

What feels smooth to the instructor can feel chaotic to the participant.

That gap matters even more in AI workshops because many participants already feel like they are behind before the workshop even starts.

If they get stuck early, frustration piles up fast.

The Prompt I Have Started Using

Here is a version of the prompt structure I now use regularly before running workshops and training sessions.

You are not simply asking ChatGPT to “review” the workshop.

You are asking it to experience the workshop like a real participant would.

That changes the kind of feedback you get completely.

You are attending this workshop as a participant for the first time.

Your background:
- Role and experience level
- Technical comfort with AI tools
- Goals for attending
- Likely frustrations or concerns
- Time or workflow constraints

I am going to provide:
- slide decks and activity instructions
- worksheets, prompts, and datasets
- supporting documents and links

Your job is to go through the workshop step by step exactly as a participant would.

As you review the material, identify:
- unclear instructions or inconsistent terminology
- missing files, links, or support materials
- places where participants may become confused, frustrated, or fall behind
- activities that assume knowledge or skills that were never taught
- pacing, timing, or cognitive overload issues

For every issue you find:
1. Explain why it could create confusion
2. Rate the severity from 1–10
3. Suggest a specific improvement
4. Rewrite unclear instructions where appropriate

Do not be polite or encouraging.

Be honest and critical from the participant perspective.

I have found that the more context I provide about the audience, the more useful the responses become.

Prompt: Stress-Test Timing and Attention

One thing ChatGPT is surprisingly good at identifying is when a workshop starts asking too much from participants at once.

Instructors often underestimate how mentally exhausting workshops can become, particularly when participants are switching between multiple tools, datasets, prompts, and browser tabs simultaneously.

I now use a second prompt specifically to see where pacing and attention start to break down.

Review this workshop from the perspective of participant attention, pacing, and cognitive overload.

Identify:
- sections that move too quickly
- activities that overload participants with simultaneous tasks
- moments where participants may become mentally fatigued or disengaged
- abrupt transitions or unclear workflow changes
- areas that need more examples, demonstrations, or recap points

Suggest where breaks, simplification, or additional support would improve the participant experience.

This matters even more in AI workshops because many participants already feel like they are behind before the workshop even starts.

Prompt: Identify Missing Dependencies

The other major issue ChatGPT regularly identifies for me is missing dependencies.

These are the hidden assumptions instructors often miss because we already know how the workshop is supposed to work.

Review all workshop materials and identify hidden dependencies.

Look for:
- missing files, datasets, or links
- inconsistent naming conventions or instructions
- places where I assumed participants would know how something worked
- software setup or access requirements that were never explained
- references to tools, documents, or skills that were never introduced

Create a checklist of everything participants would need before the workshop begins.

This has helped me catch:

• files that were never shared

• exercises that assumed skills I had not yet taught

• inconsistent naming conventions

• instructions that referenced the wrong documents

• activities that depended on software settings participants would not already know how to change

Most of these issues are small individually.

But in a live workshop, small moments of confusion pile up fast.

I Don’t Think This Stops with Workshops

I think this same approach could be useful for:

• onboarding experiences

• customer training

• online courses

• internal documentation

• AI adoption programs

In many organizations, the people designing the experience are simply too close to it to see where confusion actually happens.

ChatGPT can help expose those blind spots before real users experience them.

Not perfectly.

But often well enough to prevent avoidable frustration.

The Real Value

Most people still think of generative AI primarily as a content creation tool.

Write slides.

Summarize documents.

Draft emails.

Those are useful applications.

But I think one of the more important uses is something else entirely.

Using AI to expose the mistakes experts no longer notice.

Because once you know your material too well, you stop seeing it the way everyone else does.

You stop noticing:

• skipped steps

• unclear instructions

• hidden assumptions

• moments where participants quietly fall behind

And participants rarely tell you exactly where it happened.

They just disengage.

That is why having ChatGPT experience your workshop as a participant is so valuable.

It helps you see the room before the room exists.

Last week, I watched someone draft three emails.

Each time, they began the same way:

“Write a professional email about…”

Then:

“Make this sound better.”

Then:

“Shorten this.”

The outputs were fine. But it took longer than it should have. And none of it sounded like them.

They weren’t building on anything.
They were resetting every time.

The problem

Most people treat this like search.

You open it, type a request, get something back, and move on.

That works for one-off tasks.

It breaks down when the work actually matters.

Because your work has:

• A point of view

• A specific audience

• A standard for what “good” looks like

If you don’t bring those in, the output defaults to average.

The shift

Stop starting from scratch.

Start with the same foundation each time.

Not a complicated setup. Just a few things you reuse.

The 3-part foundation

1. About you

What you do. Who you work with. How you think.

Example:

• I teach graduate business students how to apply this in real business settings

• My tone is direct and practical

• I avoid vague language

This keeps the work grounded.

2. What good looks like

Be specific.

Not “make it better.” Define better.

Example:

• Short sentences

• Concrete examples

• No filler

• Clear next step

This sets the bar.

3. Examples

Show it.

Paste something you’ve written that you like:

• A paragraph

• A post

• An email

This is what closes the gap between “correct” and “useful.”

What this changes

Instead of:

“Write a LinkedIn post about AI in marketing.”

You move to:

Here is context about me:
[paste]

Here is what good looks like:
[paste]

Here are examples:
[paste]

Now write a LinkedIn post about AI in marketing.

Same task. Different result.

Why this works

The tool doesn’t know you unless you show it.

If you don’t, it fills in the gaps with something generic.

When you provide context:

• Less rewriting

• More consistent output

• Work that actually sounds like you

You’re not guessing anymore. You’re starting from something solid.

Where to use this

Start with work you do often:

• Emails

• Posts

• Proposals

• Course materials

Anywhere consistency matters.

A simple way to implement

Create one document:

“My context”

Include:

• A short description of your work

• A list of what “good” looks like

• A few examples
  

Copy and paste it at the start.

That’s enough.

What happens if you don’t

You’ll keep:

• Rewriting

• Adjusting tone

• Getting close, but not quite there

And you’ll assume the tool isn’t that helpful.

Bottom line

The difference isn’t the tool.

It’s whether you bring a starting point.

Stop starting from scratch.

Last week, I sat in a meeting where someone walked through a 15-slide deck explaining a new service offering. It made sense—but it was hard to picture how it would actually work.

Later that day, I saw the same idea presented as a simple website. I could click through the flow, see examples, and understand it in about two minutes.

Most ideas die in slides. The best ones get experienced.

Why this matters

A deck tells people what you mean. A website lets them explore it.

That changes:

• Speed — you can test ideas in hours, not weeks

• Clarity — gaps show up immediately

• Access — non-technical people can build and share

This isn’t really about websites. It’s about turning concepts into something people can interact with—quickly.

What this looks like in practice

Job search

Before: resume + cover letter
After: a site built for one company

• Three ways you help that team hit its goals

• Short examples of your work

• A clear point of view on how you fit

That stands out—and signals how you think.

Product development

The shift is speed.

A customer says, “This isn’t quite right.”
You update the page and show a new version in minutes.

You’re not describing the idea. You’re adjusting it live.

Business development

A proposal site lets stakeholders go where they need:

• CFO → pricing and ROI

• Operations → implementation

• Leadership → strategic fit

Instead of presenting, you let people explore.

Build it in an hour. Ship it in five minutes.

Old workflow: hire → wait → revise → wait
New workflow: describe → iterate → upload → share

Step 1: Give a real brief

Most people skip this. That’s why their output feels generic.

Before you type anything:

• Who is this for?

• What do you want them to do?

• What content do you already have?

Prompt:

Create a single-page HTML website for a management consultant who works with mid-size banks on AI strategy. The audience is CFOs and COOs. Tone: professional but direct.

Sections:
- Hero with a clear value statement
- About (3–4 sentences)
- Three services (AI Readiness Assessment, Executive Education, Implementation Support)
- One testimonial block
- Contact section with email and LinkedIn

Design:
- Navy and white color scheme
- Clean HTML and CSS (no frameworks)

Here is my bio:
[paste bio]

Step 2: Iterate in the same conversation

Stay in one thread and refine.

Examples:

Make the headline shorter and clearer.

Add one line under each service explaining who it’s for.

Use simpler language throughout.

You’re adjusting in seconds, not waiting on revisions.

When you’re done:

Give me the complete final file in a single code block.

Step 3: Ship it in five minutes

Go to netlify.com/drop
Drag your file (index.html) into the browser

You don’t need to understand the code. You’re just uploading a file.

You’ll get a live URL in under a minute. Share it immediately.

Whether you’re using Claude or ChatGPT, you’ll still upload the file to a hosting service like Netlify. The difference is that ChatGPT can guide you through that step if it’s new to you.

If you’re using ChatGPT instead of Claude

Same workflow. Be more explicit about constraints.

Create a complete, single-page website as one HTML file.

Context:
- I am a management consultant working with mid-size banks on AI strategy
- Audience: CFOs and COOs

Requirements:
- HTML and CSS only
- One file

Sections:
- Hero
- About
- Services
- Testimonial
- Contact

Design:
- Navy and white

Here is my bio:
[paste bio]

Output:
Single complete HTML file in one code block. No explanation.

If needed:

Combine everything into one HTML file in a single code block. No extra text.

Refinement prompts

Use these after the first version:

Rewrite this homepage to be specific to CFOs at regional banks.

Remove generic language. Make everything more concrete.

Add one example under each service showing what the work looks like.

When not to use this

This is not for:

• Production systems

• Complex apps with logins or databases

• Long-term brand infrastructure

It’s for fast, focused concept sites.

What the tool can’t do

The tool builds the site. It does not know your work.

If you write:

“AI consultant helping businesses”

You’ll get something generic.

If you describe:

• The exact problems you solve

• Who you solve them for

• What the work looks like

The site starts to feel specific.

Bottom line

This makes building easy.

It does not make thinking optional.

If this was useful, share it with someone who is still sending decks.

You open an Excel file.

It has everything you need:

• customer names

• email addresses

• purchase history

You could get real insight from it.

But instead, you hesitate.

“I’m not putting this into ChatGPT.”

So you either:

• work manually

• or use a fake dataset and get weaker results

That hesitation is justified.

Companies worry about exposing customer data, losing trust, and compliance risk.
Even with paid tools, many teams still avoid using real datasets.

A better way to approach this

Instead of avoiding ChatGPT, use it to help you prepare your data before it leaves Excel.

The workflow is simple:

Keep the raw data → remove identity → analyze → reconnect later

You keep the value. You reduce the risk.

The goal: keep structure, remove identity

For most analysis, you don’t need:

• names

• emails

• phone numbers

You need:

• patterns

• trends

• relationships

So the objective is:

Replace identifying fields with a consistent ID.

Step 1: Design the approach (no data required)

Start by describing your dataset—not sharing it.

Writing

I have an Excel dataset with the following fields:

• Customer Name

• Email Address

• Order ID

• Purchase Amount

• Purchase Date

I want to analyze patterns (spend, frequency, segments), but I need to anonymize sensitive fields.

Suggest a way to anonymize this dataset so that:

• Customer identity is protected

• Relationships between rows are preserved

• I can map the results back later if needed

This gives you a plan without exposing anything sensitive.

Step 2: Create a non-obvious customer ID

A common mistake is using:

• Customer_001

• Customer_002

That works—but it’s predictable.

A better approach:

Use a consistent, non-sequential ID.

Ask ChatGPT for the method

Writing

I have an Excel dataset with email addresses.

Give me a formula or Power Query method to create a consistent, non-obvious ID for each email.

The ID should:

• Be consistent (same email = same ID)

• Not be easily reversible

• Not be sequential or predictable

Apply it in Excel

• Create a new column (e.g., CustomerID)

• Apply the formula

• Copy → Paste as values

Then:

Delete the original email and other identifying fields.

Now you have a dataset that preserves relationships without exposing identity.

Step 3: Check for hidden risks

Even without names, some fields can still identify people.

Writing

I have anonymized my dataset by replacing customer identifiers with IDs.

Here are the remaining fields:
[LIST YOUR FIELDS]

Are there any fields that could still indirectly identify individuals?

Suggest steps to reduce that risk while keeping the dataset useful for analysis.

Step 4: Analyze the data

Now you can:

• paste a small sample

• clean the data

• run analysis

• identify patterns

You are working with the behavior in the data, not who it belongs to.

Step 5: Reconnect results (locally)

If you identify:

• high-value customers

• churn risk segments

• behavior clusters

You can map them back in Excel:

• Keep a separate lookup table (ID ↔ customer)

• Use XLOOKUP or VLOOKUP

This step stays outside ChatGPT.

Optional: Make this repeatable (Power Query)

If you do this often, use Power Query.

Find it here:
Data → From Table/Range

Power Query lets you create columns, remove sensitive fields, and reuse the same steps every time.

Simple example

You have an Email column.

In Power Query:

• Go to Add Column → Custom Column

• Create CustomerID

• Apply a transformation to generate a consistent ID

Then:

• Keep CustomerID

• Remove Email

• Load back into Excel

Create a column → remove the sensitive field → load the result.

That’s enough to get started.

A quick note on data privacy

Do not paste raw customer data into ChatGPT.
Use a small, anonymized sample instead.

Why this matters

Most people use ChatGPT for writing.

A more useful role in business is this:
helping you prepare data before analysis.

Once your data is ready:

• analysis gets easier

• patterns become clearer

• decisions move faster

Next:
Now that your data is clean, we can use ChatGPT to analyze it and explain what the numbers mean.

Last quarter, you presented a well-built recommendation to your leadership team.

You had the numbers.
You had the logic.
You anticipated a few questions.

What you didn’t expect:

• Finance questioned your assumptions

• Operations pushed back on feasibility

• One senior leader stayed quiet—and never supported it

You left the room thinking:
What did I miss?

I’ve been there.

The problem isn’t your content

In most cases, the issue is not weak analysis.

It’s this:

You built the presentation.
You didn’t build the audience.

You are not speaking to one person. You are speaking to people with:

• Different priorities

• Different decision styles

• Different definitions of “good”

Ignore that, and even strong work stalls.

A better approach: simulate the room

Instead of asking:
“How do I improve this presentation?”

Ask:
“How will each person react to it?”

You can do that by building simple personas for each key stakeholder.
For most high-stakes meetings, this takes minutes—not hours—and it replaces guesswork with something you can test.

Step 1: Build the persona

Start with what you already know:

• Past meetings and feedback

• Public signals (LinkedIn, talks, articles)

• Input from colleagues

Focus on:

• What they care about

• What they question

• What earns their approval

This doesn’t need to be perfect. A rough version is enough to surface blind spots you would likely miss on your own.

Here’s a simple way to do it:

You are helping me prepare for a presentation to this stakeholder:

Role: [insert]  
Priorities: [insert]  
Common concerns: [insert]  
Style: [direct, detail-oriented, big-picture, etc.]  

Create a working persona:
- What they care about most  
- What they will question or challenge  
- What makes them lose confidence  
- What earns their support  
- How they prefer information structured

Step 2: Validate it

Take a past presentation that didn’t land.

Ask:

• Would this persona react the same way?

• Would they raise the same objections?

If yes, you’re close. If not, refine.

Step 3: Stress test

Run your next presentation through each persona.

Look for:

• Confusion

• Objections

• Gaps

Use this to pressure test your content:

Act as this persona reviewing my presentation.

Where would you:
- Push back or disagree?
- Lose confidence?
- Ask for more detail?
- Question the assumptions?

Be direct and specific. Do not soften the feedback.

Then adjust:

• Structure

• Level of detail

• Framing

Step 4: Plan for conflicting perspectives

Most presentations involve competing viewpoints:

• Finance (risk, return)

• Operations (feasibility)

• Strategy (direction)

Personas help you see those tensions early.

Use this to prepare for those conflicts:

I am presenting to multiple stakeholders with different priorities:

[Persona 1 summary]  
[Persona 2 summary]  
[Persona 3 summary]

Where will these stakeholders:
- Disagree or create tension?
- Prioritize different outcomes?
- Challenge each other’s assumptions?

Then recommend:
- How I should structure the presentation to address this upfront  
- What tradeoffs I should acknowledge directly  
- How to sequence the discussion to reduce friction

So you can address those dynamics before they surface in the room.

You’re not trying to predict every reaction—just prepare for the ones most likely to matter.

Why this works

When people feel understood, they engage differently.

You get:

• Better questions

• Better feedback

• Faster decisions
  

Where AI fits

AI makes it faster to build slides.

That’s not the advantage.

The advantage is what you do with the time.

Use it to:

• Build personas

• Test reactions

• Refine your message
  

Less time building slides.
More time preparing for how people will respond.

Final thought

Most people walk into a meeting hoping their presentation works.

A smaller group prepares for how people will react.

That difference is what moves the room.

Most of the time, I use generative AI to draft content, clean up writing, or improve a presentation.

That’s useful. But it’s also late.

By the time most of us bring AI in, we’ve already decided what the problem is. We’ve already chosen a direction. We’re just asking for help expressing it.

That limits what AI can do.

It can make your answer better.
It cannot fix a weak question.

And in many cases, the problem isn’t the answer. It’s that we never asked the right question in the first place.

Where AI actually helps more

There’s an earlier moment where AI is more valuable:

Before the draft.
Before the plan.
Before the decision.

At the point where you’re still figuring out what you’re actually trying to solve.

That’s where I’ve started using AI differently—not as a writer, but as an interviewer.

The shift

Instead of asking:

“Help me decide what to do here”

Ask AI to interview you first.

Not to give advice.
Not to generate options immediately.
To ask better questions than you would ask yourself.

Because most decisions don’t fail from lack of effort.
They fail from weak framing.

We move too quickly to solutions.
We define the problem too narrowly.
We miss stakeholders, constraints, or second-order effects.

A good interviewer slows that down.

You can do this on your own. The difference is consistency. AI will keep asking, keep pressing, and won’t stop at your first answer.

What this looks like in practice

Let’s say you’re deciding whether to move forward with a new initiative.

The typical approach:

• Think it through

• Form an opinion

• Ask AI to improve the write-up

A different approach:
Ask AI to question you before you commit to a direction.

It might push on things like:

• What decision are you actually making?

• Why does this matter now, and what would success look like in concrete terms?

• Who is affected that you haven’t considered?

• What assumptions are you making, and what might a skeptical stakeholder challenge?

• What happens if you do nothing?

Those questions often change the shape of the decision.

Sometimes they reveal that you’re solving the wrong problem.
Sometimes they show that timing—not strategy—is the issue.
Sometimes they break one decision into three.

A quick example

A director I worked with was trying to decide whether to hire another analyst.

His initial framing was simple:
“We’re overloaded. We need more capacity.”

He was ready to move forward and asked AI to help draft the business case.

Instead, he paused and had AI interview him first.

Within a few minutes, the questions shifted the situation:

• What specific work is causing the overload?

• How much of that work is recurring vs one-time?

• What would happen if nothing changed for 90 days?

• Are you solving a capacity problem or a prioritization problem?

• Could this work be reduced, automated, or reassigned?

By the end of the conversation, the decision had changed.

He didn’t need to hire—at least not yet.

The real issue was unclear prioritization and duplicated reporting across teams. Fixing that removed enough work to avoid adding headcount.

Same situation. Different question. Different outcome.

AI won’t get every question right. You still need judgment. But even imperfect questions can surface things you wouldn’t have considered.

The point

AI is not just useful for getting to answers faster.

It’s useful for asking better questions before you decide.

That’s a different kind of advantage.

A simple way to try this

Before your next decision, don’t ask AI for a recommendation.

Ask it to interview you.

This isn’t necessary for every decision. Use it when the stakes are higher, the situation is unclear, or the cost of getting it wrong is meaningful.

Here is a prompt you can use:

Act as a decision interviewer, not a quick advice generator.

Do not give me recommendations yet. First, ask me one question at a time to help me clarify:
- the decision I’m actually making
- why it matters now
- what success and failure look like
- constraints and stakeholders
- risks, assumptions, and unknowns
- what I may be missing

Challenge vague answers. Push me to be specific. Surface blind spots and alternative perspectives.

Only after you have enough context:
1. Summarize the decision clearly
2. Lay out the main options
3. Explain pros, cons, and risks
4. Offer a recommendation if appropriate
5. Suggest next steps

If the questions start repeating or you’re no longer learning anything new, that’s your signal to move forward.

This doesn’t replace talking to your team or a trusted colleague. It helps you show up to those conversations clearer on what you’re actually deciding.

Closing

The quality of your decisions is limited by the quality of your questions.

Most people use AI to improve their answers.

The better use is to let it improve the question first.

Before you ask AI for the answer, make sure you’re asking the right question.

Most people don’t walk into meetings ready to move them forward.

They’re catching up.

Most people don’t walk into meetings ready to move them forward.

They’re catching up.

You join a meeting a few minutes early and open the deck.

It’s 80 slides.

You recognize your section, but the rest is new.
The presenter starts. People nod.

Ten minutes in, someone raises a risk you hadn’t considered.
Another mentions a competitor you hadn’t heard about.

You start catching up in real time.

By the time you’re ready to contribute, the moment has passed.

Most People Prepare This Way

You skim the deck.
You review your slide.
You hope the rest makes sense in the meeting.

That’s often all the time you have.

But most meetings are not about your slide.
They’re about the decision behind it.

• What problem are we solving?

• What assumptions are we making?

• What changed since this was written?

If you only prepare your piece, you walk in without the full picture.

A Better Way to Prepare

You don’t need more time.
You need a short way to get oriented.

The goal:

Understand what’s going on
Decide what matters
Be ready to contribute

This takes about 10 minutes. The first time may take closer to 15.

Paste sections of your document into your tool and run these prompts in sequence.

Step 1: Get to the Point

Focus on what matters, not everything.

Writing

You are preparing me for a meeting.

Here is a document. Break it down into:

1. The core objective

2. The key arguments or recommendations

3. The assumptions behind those arguments

4. What matters most vs. what is filler

Keep it structured and concise. Assume I have 5 minutes.

Result:
You see what the document is trying to do.

This does not replace reading. It helps you decide what to read closely.

Step 2: Look for What’s Missing

Most documents are incomplete.

Writing

Based on this document, identify:

1. What important questions are NOT being addressed

2. What risks or downsides are underexplored

3. What assumptions might be weak or outdated

4. What additional data would strengthen this

Answer like a thoughtful but skeptical executive.

Result:
You see gaps others may miss.

Step 3: Add Outside Context

Internal materials rarely tell the full story.

Writing

I am preparing for a meeting about [topic].

Give me a short briefing on:

1. Recent developments (last 30–90 days)

2. Relevant competitor or industry activity

3. Risks or opportunities not likely covered internally

Keep it practical and decision-focused.

Result:
You connect the discussion to what’s happening outside.

If you don’t have materials, start here and move to Step 4.

Step 4: Decide How You’ll Contribute

Go in with a plan.

Writing

Based on everything above, help me prepare:

1. Three high-value questions to ask

2. One meaningful risk to raise

3. One idea that could improve the discussion

Keep it concise and practical.

Result:
You know when and how to speak.

If needed, frame questions as clarification:
“Can I ask how we’re thinking about…”

What This Sounds Like

Instead of:

“That makes sense”

You might say:

• “What happens if this assumption doesn’t hold next quarter?”

• “How does this compare to what others are doing?”

• “What data would increase confidence here?”

You don’t need to say more.
You need to say something useful.

Where This Can Break Down

This works if you stay engaged.

It breaks down when you:

• Stop at a summary

• Accept everything at face value

• Skip forming your own view

Spot-check key points before using them.

For technical or sensitive topics, use this as a first pass.

What Changes Over Time

You move from:

• Owning a section

To:

• Understanding the situation

People notice that shift.

What to Do Next

Try this once this week.

1. Pick a meeting where a decision is being made

2. Run the four steps

3. Use at least one question

Afterward, ask:

• Did I contribute earlier?

• Were my questions different?

• Did I move the discussion forward?

Success looks like asking a question that changes how others think.

Try this once, and you’ll see how quickly you can move from reacting in meetings to helping move them forward.

I was having coffee with a friend this morning.

She was frustrated.

No matter how many times she asked her AI tool for a specific PowerPoint format or Excel visuals, she couldn’t get consistent results. Even worse—when she did get something right, she had to start over the next time.

No memory. No carryover. Just repetition.

That’s not a tool problem.

It’s a setup problem.

The Core Issue

Most people use generative AI like a one-off assistant:

Ask → answer → move on → repeat.

Unless you teach the system what matters to you, it has no stable reference point.

So it keeps guessing.

The Shift That Changes Everything

To get better outputs faster, give AI three things:

1. A document about you

2. A document defining what “good” looks like

3. Examples that meet your standard

Simple. But intentional.

1. Create a “Document About You”

This is your context layer.

Instead of re-explaining who you are, write it once.

Include:

• Your roles

• Your audiences

• Your goals

• Your preferences

• Links to your work

• Personal interests (optional)

Example:

Instead of repeating:

“My graduate students are mid-level business managers…”

You write it once.

Now the AI already knows who they are, what they care about, and how to frame content.

Prompt you can use:

I want you to help me build a “document about me” that I can reuse across projects.

Ask me a structured set of questions to capture:
- My professional roles
- My typical audiences
- My goals when using AI
- My preferences for tone, structure, and level of detail
- Any recurring use cases (teaching, presentations, analysis, writing, etc.)

After I respond, organize everything into a clean, well-structured document that I can reuse as context in future prompts.

This also improves:

• Travel planning

• Recipes

• Writing tone

More context leads to better first drafts.

2. Define What “Good” Looks Like

This is where most people struggle.

They say:

“Make this better”

But “better” is undefined.

Create a second document that spells it out.

Include:

• Writing style (short, direct, practical)

• Formatting rules

• Brand standards (colors, layouts)

• Structural preferences

Example from my workflow:

• Slides must be 16:9

• Text must stay within slide boundaries

• Tone is informal but clear

• Focus on application, not theory

Also include:

• Words or phrases to avoid

• Patterns that feel too AI-generated

Prompt you can use:

Analyze the following examples of my past work.

Identify patterns in:
- Tone and writing style
- Structure and organization
- Level of detail
- Use of examples
- What makes the work effective

Then create a document titled “What Good Looks Like” with clear, repeatable guidelines I can reuse in future prompts.

You can also ask AI to analyze your past work and describe your style. Add those observations back into this document.

3. Provide Examples of “Good”

This is your reference library.

Include:

• Presentations

• Analyses

• Writing samples

Without examples, AI guesses.

With examples, it aligns.

Prompt you can use:

Here are 2–3 examples of work that represent my standard.

Using these, generate a reusable instruction set I can include in future prompts so outputs match these examples in tone, structure, and quality.

Be specific. Focus only on observable patterns.

What Changes When You Do This

You don’t eliminate iteration.

You reduce it.

Instead of:

• 6–8 cycles

You move toward:

• 1–2 refinements

One Move Most People Miss

After refining something through multiple iterations, ask:

“What have you learned about my preferences from this conversation?”

Edit the response and add it to your “what good looks like” document.

Now your system improves over time.

One Important Reminder

You still review.
You still edit.
You still decide.

This improves the starting point—it doesn’t replace judgment.

The Bottom Line

If your outputs feel inconsistent, it’s not random.

It’s under-specified.

Give AI:

• Context (about you)

• Standards (what good looks like)

• Examples (proof of good)

You’ll spend less time fixing outputs
—and more time using them.

One of the most common complaints about AI-generated writing is also one of the most accurate: it often sounds like AI.

The tone is too polished. The phrasing is generic. The rhythm feels off. And if you use that writing for work that reflects your judgment and credibility, people notice.

The fix is not to stop using AI for writing. The fix is to stop asking it to write from nothing.

If you want a draft that sounds more like you, you need to give AI more of you to work with: your raw material, your structure, and clearer instructions about your voice.

The goal is not a perfect final draft. The goal is a better first draft that you can revise without starting over.

Here are three ways to get there.

1. Start with your own raw material

The fastest way to get generic writing is to give AI a blank prompt and ask for a finished piece.

A better approach is to start with material that came from you first, even if it is rough:

• dictated thoughts

• rough notes

• fragments of a draft

• meeting reflections

• examples or stories you want to include

That gives AI your ideas, your wording, and your way of explaining things. The result is usually much closer to usable than a draft built from a one-line request.

Yes, this takes a little more work up front. But it usually saves time later because you are revising your thinking instead of rewriting generic filler.

Prompt to try

I am going to paste in rough source material for a piece of writing. It may include dictated thoughts, incomplete sentences, repeated ideas, and rough examples.

Turn it into a clear first draft without making it sound generic or overly polished. Keep the core ideas, logic, and examples, but improve the structure and readability.

Write in a direct, plainspoken professional style. Do not use inflated language, generic transitions, or dramatic phrasing. If parts are unclear, make the best interpretation you can without inventing claims or examples that are not grounded in my material.

First, identify the main argument and the likely supporting points. Then draft the piece.

Here is my source material:
[paste notes, dictation, or rough draft here]

2. Build a simple voice guide

Most people tell AI what they want it to do. Far fewer tell it what to avoid.

That is where a lot of bad AI writing starts.

If you want better output, give AI examples of your own writing and ask it to describe your style in practical terms:

• tone

• sentence length

• pacing

• level of formality

• common wording patterns

• what sounds unlike you

That becomes a voice guide.

It does not need to be long. In fact, shorter is usually better.

Here is what a basic version might look like:

Voice Guide

• Write in a direct, conversational professional tone.

• Use plain language rather than inflated business phrasing.

• Keep sentences short to medium in length.

• Open with a concrete problem or tension.

• Use examples from work, management, teaching, or decision-making.

• Avoid generic transitions and overly tidy endings.

• Prefer clear statements over abstract claims.

AI will not become you. But it can often get much closer than people expect when you give it real samples and clear rules. That is often enough to turn a weak draft into a useful one.

Prompt to try

I am going to give you several samples of my writing. Study them and build a practical voice guide that I can reuse in future prompts.

I do not want a flattering description. I want a useful one.

Analyze the samples for:

• tone

• sentence length and rhythm

• level of formality

• common openings and closings

• patterns in how I explain ideas

• words or phrases I seem to prefer

• words, transitions, or sentence habits that would sound unlike me

Then create:

1. a short voice guide in bullet form

2. a short “do not do this” list

3. a reusable paragraph I can paste into future prompts to tell AI how to write more like me

Here are the samples:
[paste 2 to 5 writing samples here]

3. Build the outline before the draft

This is one of the best ways to improve AI writing quickly.

Before asking AI to draft, define the structure of the piece:

• the main point

• the major supporting points

• the best order

• where examples should go

• what the reader should take away

Six to ten bullets is often enough.

Why does this matter so much? Because poor structure is one of the main reasons AI drafts feel frustrating. When the organization is weak, everything becomes harder to fix.

If you only adopt one part of this process, start here. A better outline often matters more than a better prompt.

Prompt to try

I want you to help me create a strong draft, but do not write the draft yet.

First, review the rough material I provide and turn it into a logical outline with 6 to 10 bullets. The outline should identify:

• the main point

• the major supporting points

• the best order for those points

• where examples should go

• what the reader should take away

After you create the outline, stop and present it clearly. Once the outline is approved, use it to draft the piece.

When you eventually draft, use these writing preferences:
[paste your voice guide here]

Here is my rough material:
[paste notes, ideas, or source material here]

What editing should you still expect to do?

Even with a better process, you should still expect to edit.

Usually that means:

• tightening the opening

• replacing generic phrases

• adjusting examples

• cutting repetition

• sharpening the ending

For a routine internal update, the editing may be light. For a newsletter, article, or thought leadership piece, you should expect a stronger pass.

That is normal. AI can help you get to a better draft faster, but you still supply the final judgment.

One more thing: save your edits. Over time, they become the raw material for a better voice guide and better future prompts.

Why this matters

This is not just a writing issue. It is a credibility issue.

If you use AI for emails, memos, presentations, reports, or public-facing content, the writing still represents you. If it sounds generic, trust can slip. If it sounds more like your actual voice, AI becomes much more useful.

That is the standard to aim for.

Not perfect automation.

A better first draft that still sounds like it came from a real person.

Final thought

If AI-generated writing sounds generic, the problem usually is not the tool.

The problem is that you are asking it to write before you have given it enough to work with.

Give it your raw material.
Give it your voice rules.
Give it your structure.
Then revise what comes back

That is how you get writing that sounds more like you and less like everyone else.

Question for readers:
What has helped you most when trying to make AI-generated writing sound more like you?

What Will You Build With the Time You Get Back?

There’s a question I’ve been sitting with lately.

We talk a lot about how AI reduces repetitive, painstaking work by 80–90%. Drafts that used to take three hours now take thirty minutes. Data cleanup that used to consume an afternoon can be handled in a short working session. First-pass analysis, summaries, and slide outlines are no longer the bottleneck.

But here’s the part we don’t talk about enough:

What are managers, directors, and vice presidents supposed to do with the margin?

If the execution layer shrinks, what expands?

If we’re not clear about that, the time just fills back up—with more meetings, more drafts, more noise.

Efficiency alone does not raise your value. Reallocation does.

I’m not suggesting you carve out a new day on the calendar. I’m suggesting you redirect one hour you just saved.

The Misallocation Trap

When a five-hour task becomes a one-hour task, most professionals do one of three things:

• Take on more tasks

• Attend more meetings

• Produce more output

None of those automatically move you up.

If you stay in production mode—even faster production mode—you’re still operating at the same level of contribution. You’re just doing it more efficiently.

The real opportunity is different.

AI doesn’t just reduce effort. It lowers the cost of exploration and expansion. That changes what kind of work is rational for you to do.

Four Better Uses of the Margin

Here’s a more strategic reallocation of freed time.

1. Test New Concepts Before They’re Urgent

Most leaders only explore ideas when they are forced to.

Now you can explore earlier.

You can ask:

• What adjacent opportunity are we not considering?

• What would break if this assumption fails?

• What alternative model could outperform our current one?

Sample Prompts

Concept Exploration

We currently operate under this strategy: [insert short summary].
Identify three adjacent opportunities we are not exploring and outline risks, resource requirements, and likely time to impact for each.
Rank them by potential upside and implementation complexity.

Downside Scenario

If this initiative underperforms by 30%, what operational, financial, and reputational effects follow?
Quantify where possible and identify which impacts would be reversible versus permanent.

Competitive Reaction

If our largest competitor wanted to neutralize this move within six months, how would they respond?
Outline likely pricing, marketing, talent, and partnership strategies they might deploy.

The cost of asking “What if?” has dropped dramatically.

When exploration becomes cheap, avoiding it becomes costly.

2. Expand Ideas Beyond Their First Draft

Most work stops at adequacy.

The proposal is coherent.
The slides are clean.
The logic seems reasonable.

But very little time is spent deepening the idea.

Freed time allows you to:

• Add second-order effects

• Identify counterarguments

• Separate facts from inference

• Build scenario trees

• Clarify tradeoffs explicitly

A mid-level proposal might say:

“We should test a new pricing tier.”

An expanded version maps downside risk, models competitor response, clarifies churn exposure, and visualizes decision thresholds.

Sample Prompts

Assumption Extraction

Extract all explicit and implicit assumptions in this proposal. Group them into market, financial, operational, and behavioral categories.
Highlight which assumptions are unsupported by current data.

Vulnerability Scan

For each assumption, rate vulnerability (Low/Moderate/High) and describe a plausible failure scenario.
Indicate which assumptions would have the largest impact on revenue or margin if wrong.

Tradeoff Clarification

Identify the three core tradeoffs embedded in this proposal and explain what we are implicitly prioritizing.
Clarify what we are explicitly choosing not to optimize.

This isn’t about adding complexity. It’s about clarifying risk and tradeoffs so decisions move faster, not slower.

3. Turn Reasoning Into Visual Assets

This is the underused move.

When time pressure eases, convert thinking into durable tools:

• A decision tree

• A risk heat map

• A scenario diagram

• A one-page framework

• A visual tradeoff map

You don’t need design training. Simple structured visuals built in PowerPoint, Miro, Excel, or Canva are enough.

Sample Prompts

Decision Map

Convert this proposal into a one-page decision tree showing key assumptions, decision points, and risk triggers.
Clearly label which conditions would trigger reconsideration or escalation.

Risk Heat Grid

Create a risk matrix categorizing identified risks by likelihood and impact.
Highlight which risks require mitigation plans before approval.

Scenario Diagram

Build a simple scenario tree outlining best case, base case, and downside case with key drivers for each branch.
Include estimated probability ranges for each scenario.

Visuals sharpen your own thinking and travel farther inside organizations than paragraphs.

A clear one-page framework often shapes more decisions than a 20-slide deck.

4. Build Reusable Structures

Instead of producing one-off answers, build systems.

• A repeatable stress-test template

• A standard pre-mortem checklist

• A recurring prompt sequence for major proposals

• A decision-criteria framework

Sample Prompts

Build a Template

Create a reusable checklist for stress-testing any strategic proposal before executive review.
Structure it so it can be completed in under 30 minutes.

Pre-Mortem Framework

Design a 10-question pre-mortem template for evaluating strategic initiatives in our industry.
Ensure the questions surface operational, financial, behavioral, and competitive risks.

Decision Criteria Builder

Help me define 5–7 consistent evaluation criteria we should apply to all capital allocation decisions.
Include measurable indicators for each criterion.

Operators complete tasks.
Architects improve how tasks are done.

AI gives you time. Systems give you leverage.

The Promotion Question

If execution shrinks in value, what replaces it?

Senior leaders are paid for:

• Framing better questions

• Anticipating risk

• Clarifying tradeoffs

• Improving how decisions are made

If AI reduces your time in execution, you have a choice:

Fill the margin with more activity.

Or use the margin to elevate the level of your contribution.

That shift is visible.

When someone consistently:

• Expands ideas instead of stopping at the first draft

• Tests new concepts before they are required

• Turns reasoning into clear visual frameworks

• Builds reusable structures

They start operating differently. And others notice.

A Simple Experiment for This Week

Take one task AI just made easier.

Instead of stopping when the draft is “done,” use the saved time to:

• Add one scenario you hadn’t considered

• Extract and test three hidden assumptions

• Build a one-page visual of the decision logic

• Create a reusable template from the process

Don’t produce more.

Expand more.

AI buys you margin.

What you build with it determines whether you stay efficient—or become more valuable.

Most managers use generative AI to write faster.

That’s fine.

But once you’re comfortable producing drafts, summaries, and outlines, the real advantage begins somewhere else.

The next step is using AI as a thinking partner.

Not to create content.
To pressure-test it.

The Problem: You Can’t See Your Own Blind Spots

Every strategy rests on assumptions.
Every proposal has weak points.
Every presentation leaves something unsaid.

The most dangerous risks are the ones you don’t think to question — because if you saw them clearly, you would have addressed them already.

AI gives you a structured way to surface what you are missing:

• Hidden assumptions

• Fragile logic

• Stakeholder concerns you have not modeled

• Counterarguments you would rather avoid

This is not about writing.

It is about preparation.

A Real Example

Recently, I was preparing a presentation for a nonprofit organization on how generative AI could expand their reach without increasing headcount or overloading staff.

Before finalizing the slides, I loaded the presentation into ChatGPT and asked:

• What questions would nonprofit staff raise that I haven’t considered?

• How would those differ from a for-profit setting?

• What concerns might emerge given this organization’s mission and culture?

The response suggested enough material for ten additional slides. That was too much, so I asked the model to narrow it. We refined it to six targeted additions woven throughout the presentation.

The result was not a longer presentation.

It was one that addressed likely objections before they surfaced.

That is the shift.

Where This Matters Most

You can apply this immediately in three high-impact areas.

1. Strategic Plans

Paste your strategy into AI and ask it to extract:

• Explicit assumptions

• Implicit assumptions

• Assumptions dependent on external conditions

Then ask:

• Why does each assumption matter?

• What evidence would validate or invalidate it?

Most teams never formalize this step. That is why plans often look strong on paper but weaken under pressure.

When assumptions are explicit, you can test them.

2. Structured Blind Spot Review

Ask AI to examine your proposal across specific dimensions:

• Financial risk

• Operational strain

• Customer experience impact

• Competitive response

• Legal or compliance exposure

• Organizational capacity

For each area, ask:

• What is the risk?

• What is the likely impact if ignored?

You will quickly see where confidence exceeds evidence.

3. Counterarguments Before the Meeting

This is where careers change.

Most managers avoid thinking deeply about objections. It feels uncomfortable.

But imagine walking into a meeting already prepared for:

• The finance leader’s pushback

• Operational capacity concerns

• Political tension between departments

• Cultural resistance you know exists

AI can generate realistic objections — if you provide context:

• Who will be in the room

• Their incentives

• Known interpersonal dynamics

• Previous resistance patterns

Then ask it to help you craft thoughtful responses.

You will look prepared and composed because you have rehearsed the hard questions in advance.

Common Concerns (Straight Answers)

“Isn’t this overthinking?”
Time-box it. Ten to twenty minutes of structured pressure-testing is usually enough. That small investment often prevents weeks of revisions and follow-up meetings.

“Can’t I generate objections myself?”
You can try. The challenge is emotional investment. You are attached to your proposal. AI is not. It will question assumptions you unconsciously protect.

“What if the output is generic?”
Generic input produces generic output. When you include stakeholder roles, incentives, and real constraints, the objections become sharper. You still apply judgment. The tool generates possibilities; you decide which matter.

“Is it safe to paste internal strategy into ChatGPT?”
Follow company policy. Remove sensitive numbers, anonymize proprietary details, and use enterprise tools when available. The purpose is to test logic, not expose confidential data.

“Will this make me dependent on AI?”
Used correctly, it builds your independent thinking. Over time, you internalize the questions it asks. You start spotting weaknesses before the model does.

“Does this actually change outcomes?”
In practice, it leads to fewer surprise objections, faster approvals, and fewer post-meeting revisions. You resolve friction before it appears in public.

“What’s the downside?”
AI may raise low-probability risks or edge cases that do not matter. That is why you filter the output. Treat it as a structured critic, not an authority.

“When shouldn’t I use this?”
Skip it for minor updates or decisions that are already final. Use it when stakes are meaningful: strategy, budget requests, change initiatives, board presentations, cross-functional proposals.

Prompts You Can Use Immediately

Below are four structured prompts. Copy them into your AI tool and adapt them to your situation.

Prompt 1: Extract Assumptions From a Strategy

Use this when you want to surface what your plan depends on.

I am going to paste a short strategy proposal.

Identify:

• Explicit assumptions (clearly stated)

• Implicit assumptions (unstated but necessary for success)

• Assumptions dependent on external conditions (market, customer, regulatory, competitor)

For each assumption:

• Explain why it matters

• Explain what evidence would validate or invalidate it

Strategy:
[PASTE TEXT]

Prompt 2: Structured Blind Spot Analysis

Use this before presenting a proposal to senior leadership.

Review the following proposal.

Identify blind spots in:

• Financial

• Operational

• Customer experience

• Competitive response

• Legal or compliance

• Organizational capacity

For each blind spot:

• Explain the risk

• Estimate the likely impact if ignored

Proposal:
[PASTE TEXT]

Prompt 3: Argue the Opposite Position

Use this when you want to stress-test your logic.

Construct the strongest possible argument against this proposal.

Provide:

• A strategic objection

• A financial objection

• A risk-based objection

• A cultural or organizational objection

Then rank which objection is most serious and explain why.

Proposal:
[PASTE TEXT]

Prompt 4: Board-Level Challenge

Use this when stakes are high.

Assume you are a skeptical board member reviewing this proposal.

Ask 10 probing questions that pressure-test:

• Logic

• Assumptions

• Expected outcomes

The questions should be specific and difficult to answer without real evidence.

Proposal:
[PASTE TEXT]

Final Thought

If you are using AI only to write faster, you are operating at the entry level.

If you use it to test your thinking before others do, you move into a different category of manager.

The difference is not productivity.

It is disciplined preparation.

And disciplined preparation is what separates managers who present ideas from leaders whose ideas withstand scrutiny.

— Mark

One of the biggest reasons people struggle to produce content is this:

They try to structure it while they’re still inventing it.

Dictation for content generation

Structure and creativity are different tasks.

When you force them to happen at the same time, you slow both down.

AI fixes this — not by creating your ideas, but by organizing them.

It does not decide what you believe.
It does not replace judgment.
It organizes and pressure-tests your thinking. The ideas remain yours.

Separate the Work Into Two Phases

Instead of:

Think → Structure → Edit → Think more → Restructure

Do this:

1. Create freely.
2. Hand structure to AI.

The content stays yours.

Dictation for content generation

The organization becomes assisted.

This works for:

• Presentations

• Proposals

• Financial summaries

• Board updates

• Strategy documents

  Dictation for content generation

Anywhere thinking and formatting compete for attention.

What I Actually Do

I open Word.
I turn on dictation.
And I speak.

Dictation for content generation

No outline.
No order.
No polishing.

If I think of the ending first, I dictate it first.

Dictation for content generation

The goal is simple: get the ideas out with as little friction as possible.

Dictation for content generation

Then I give AI a precise instruction:

“Structure this raw dictation into a Substack newsletter. Match the tone of my previous posts. Use short sections, bold headers, and a clear closing takeaway.”

In minutes, I have structure.

For sensitive material, I either use secure enterprise tools or remove identifying information before structuring.

But I’m not done.

The Real Advantage

Next, I ask:

• Where are ideas underdeveloped?

  Dictation for content generation

• What questions might readers have?

  Dictation for content generation

Often the feedback is practical:

• “You claim this saves time, but don’t quantify it.”

• “A skeptical reader may question originality.”

• “You reference iteration but don’t illustrate it.”

I add what’s missing.
I run it again.

Two to four iterations usually gets me where I want to be.

Dictation for content generation

This isn’t about cutting corners. It’s about allocating cognitive effort to judgment instead of formatting.

Only after that do I move to design:

• Slide outlines into Gamma.app

  Dictation for content generation

• Structured drafts into image tools

  Dictation for content generation

Design is the final layer, not the first.

What This Changes

Before separating creation from structure, a presentation or proposal draft could easily consume five or six hours — largely because I was organizing while thinking.

Now, the first structured draft often appears in under an hour.

You stop draining energy by trying to invent and organize at the same time.

Dictation for content generation

You keep ownership of the thinking.

Dictation for content generation

And you cut meaningful time from preparation.

The bottleneck isn’t ideas.

It’s structure.

And structure is now the easiest part to delegate — without delegating your voice.

If this process interests you at the team level, it’s trainable. Most organizations don’t teach people how to separate creative generation from structural refinement.

Last week I wrote about reducing the administrative weight of project management — meeting notes, task lists, status updates, trackers.

That saves time.

But it does not answer the harder question project managers deal with every week:

Where is this project actually heading?

The Limits of the Gantt Chart

Most projects begin with a detailed plan.

A Gantt chart shows:

• Phases

• Dependencies

• Assigned resources

• Target completion dates

At kickoff, it feels solid.

Then things start to move.

Scope changes.
A vendor slips.
Someone gets reassigned.
A task runs long.

Updating the plan takes time. It pulls people into estimation discussions. It slows execution.

And after all that effort, you still may not believe the forecast.

The Agile Adjustment — and the Leadership Gap

To avoid heavy long-range planning, many teams rely on sprint cycles.

Two or three weeks at a time. Adjust. Repeat.

That works for delivery teams.

It does not fully work for senior leadership.

They want to know:

• When will we reach the end goal?

• Are we ahead or behind overall?

• What will total cost look like?

• What resources will we need next quarter?

Sprint dashboards rarely answer those directly.

So teams combine sprint updates with occasional revisions to the long-term plan. It works, but it adds coordination and constant recalculation.

Forecasting becomes a recurring burden.

Why Forecasting Feels So Difficult

A live project depends on many moving parts:

• Remaining tasks

• Actual team velocity

• Resource availability

• Budget burn

• New scope introduced midstream

Each sprint changes the math.

Most project managers manage this with spreadsheets and experience. They revise timelines, adjust assumptions, explain variance.

It works. It is also exhausting.

What Generative AI Adds

You already have the data.

Project plan.
Sprint history.
Resource tables.
Budget to date.

AI can help you reason forward from it.

Not to replace your judgment.
Not to override your plan.

But to quickly test how current trends affect what comes next.

It can:

• Recalculate projected completion dates

• Estimate workload by month

• Surface possible bottlenecks

• Draft summaries for stakeholders

The difference is speed and pattern recognition.

Three Versions of the Future

A practical way to use this is scenario forecasting.

Ask for three projections:

• If progress improves

• If current trends hold

• If progress slows or scope grows

From the same inputs, you can get:

• Estimated completion dates

• Budget at completion

• Resource load by month

• Areas of likely pressure

Now the conversation changes.

Instead of “we think we’re close,” you can say:

“If current velocity holds, we finish in October. If scope grows by five percent, we slip about three weeks. If we add one more analyst, we recover two weeks.”

Clear assumptions. Clear implications.

Spotting Trouble Early

Another benefit is forward scanning.

AI can detect:

• Future overallocation of key contributors

• Tight dependency chains

• Milestones stacked too closely

• Budget acceleration later in the timeline

These issues often exist before they appear in status reports.

Seeing them earlier gives you options.

What This Looks Like in Practice

You do not need a new system.

You need a practical AI-enhanced workflow layered onto what you already use.

That means exporting the data you already maintain and using AI to project it forward.

A simple approach:

1. Export your current plan from MS Project, Smartsheet, Jira, or similar.

2. Gather sprint velocity from the last several cycles.

3. Include resource allocation tables.

4. Add budget spent to date.

5. Run structured scenario forecasts.

You could use a prompt like this:

“Using the attached project plan, sprint velocity history, resource allocation table, and budget-to-date, generate three forecasts: optimistic, median, and pessimistic.

For each scenario, provide:

• Projected completion date

• Estimated budget at completion

• Resource utilization by month for the next quarter

• Likely bottlenecks over the next 90 days

• A short executive summary explaining assumptions and risk factors

Include charts where helpful.”

You review the output. You adjust assumptions. You decide what to share.

The point is not prediction accuracy to the day.

The point is informed direction.

What This Will Not Do

This approach does not guarantee perfect predictions.

If your underlying data is inconsistent, incomplete, or politically shaped, projections will reflect that. AI cannot fix unclear scope or unreliable estimates.

It also does not replace formal forecasting tools in mature PMO environments. If you already run structured Monte Carlo simulations or advanced portfolio models, this may function as a faster exploratory layer rather than a replacement.

And it does not remove judgment. Forecasts still require interpretation. Assumptions still need to be challenged. Trade-offs still require leadership decisions.

What it does provide is faster forward visibility.

It helps you see how current trends affect likely outcomes — before those outcomes are locked in.

Why This Matters for Mid-Level Leaders

Mid-level managers translate between teams and executives.

You are asked to interpret sprint progress in terms of quarterly goals.

You are asked to explain risk without sounding uncertain.

You are asked to update forecasts without rebuilding everything.

AI can reduce the mechanical work and surface patterns faster.

Less time rebuilding plans.
More time making decisions.

If you are already using AI to summarize meetings, forecasting is the next step.

Stop focusing only on where the project has been.

Start modeling where it is likely to go.

Most project managers don’t get buried by “project work.”

They get buried by “meeting exhaust.”

One hour in a meeting turns into:

• 20 minutes of notes

• 15 minutes of “what did we decide?”

• 20 minutes turning vague tasks into real action items

• 15 minutes sending follow-ups

• 30 minutes updating the system of record

• 20 minutes writing a status update someone won’t read closely

That’s the multiplier.

The meeting is the visible hour.
The cleanup is the hidden two.

And it repeats, week after week.

Today is about a simple workflow that makes the cleanup smaller, faster, and more consistent—especially if your ChatGPT use so far has been: “write an email” and “summarize this.”

Your meetings are costing you 3x more than you think

The simplest way for project managers to cut follow-up work in half (without changing how your team runs meetings)

One of the biggest efficiency leaks in modern organizations isn’t strategy.

It’s administration.

And in project management, the most expensive admin is what happens after the meeting: recreating what happened in notes, decisions, action items, follow-ups, tracker updates, and status reports.

That work is necessary. It’s also repetitive.

Which makes it a perfect candidate for a better process.

The unlock isn’t clever wording.

The unlock is this: a usable transcript becomes the raw material for everything that comes next.

The goal: one meeting → five outputs (in one pass)

After each meeting, you need the same five things:

1. Decisions (and what they mean)

2. Action items (owner + date)

3. Risks / issues (what could break)

4. Open questions (what’s still unresolved)

5. A clean update you can paste into Teams/Slack/email/Jira/Asana

You can keep producing these by hand.

Or you can set up an assembly line: transcript in, five outputs out.

Same ingredients. Less rework.

Step 1: pick one place where recordings live

Don’t overthink tool choice. Use what your organization already uses.

• Microsoft Teams meeting recording + transcript

• Zoom recording + transcript

• Google Meet recording + transcript

• Any approved transcription tool in your environment

Your only requirement: you can copy the transcript text (or export it).

If you can’t get a transcript, nothing else works.

So start there.

Step 2: make the transcript “clean enough”

Transcripts don’t need to be perfect.

They just need:

• the main discussion

• roughly who said what

• the moments where decisions were made

If the transcript is messy, do one quick cleanup pass first.

Two minutes here saves twenty later.

Step 3: run the same play every time

This is where most people lose the benefit.

They improvise.

They try a new prompt every meeting.

They end up spending their savings deciding what to do.

Don’t do that.

Run the same sequence every time:

A) Extract decisions + actions
B) Convert actions into tracker-ready format
C) Draft the follow-up message
D) Produce a status update block
E) Update your risk/issues list

That’s the whole system.

Step 4: keep humans in the loop where it matters

Two things still need your judgment:

• Is this actually a decision, or just someone talking confidently?

• Are these dates real, or wishful thinking?

You’re not handing off responsibility.

You’re removing the administrative drag that keeps you from doing the real work: alignment, prioritization, and clearing roadblocks.

What this looks like in practice

Before

• Meeting ends at 10:00

• You’re still writing at 11:15

• You send follow-ups at 2:30

• Someone replies: “That’s not what we agreed”

• You hunt through notes and half-remembered comments

After

• Meeting ends at 10:00

• By 10:20 you have decisions, actions with owners/dates, risks, and a follow-up draft

• You skim, correct two items, send

• Your tracker gets updated while the meeting is still fresh in everyone’s head

The difference isn’t speed typing.

It’s fewer passes.

Prompt Box (Copy/Paste)

Prompt 1 — Clean transcript (only if needed)

Clean up this transcript for readability. Keep meaning intact. Add speaker labels if missing. Remove repeated lines and obvious transcription errors. Output as plain text with short paragraphs.

Prompt 2 — Decisions + actions + risks (the core output)

You are my project meeting scribe. From this transcript, extract:

1. Decisions (Decision | What it means | Any conditions)

2. Action items (Action | Owner | Due date | Dependencies | Notes)

3. Risks/issues (Risk/Issue | Why it matters | Trigger | Suggested mitigation | Owner)

4. Open questions (Question | Who needs to answer | By when)
   If an owner or date is missing, flag it as “TBD” instead of guessing.

Prompt 3 — Follow-up message (ready to send)

Draft a short follow-up message I can send to the group.
Structure it as: 1. Top 3 decisions, 2. Action items by owner (bulleted), 3. Open questions that need answers.  Keep it direct and professional. No fluff.

Prompt 4 — Status update block (for execs)

Write a weekly status update based on the extracted decisions/actions/risks.
Format: (1) Status: Green/Yellow/Red (choose and explain in one sentence) (2) This week: 3 bullets (3) Next week: 3 bullets (4) Risks/blocks: 2–4 bullets with what I need from leadership (if anything).  Keep it tight. Assume the reader has 30 seconds.

Prompt 5 — Tracker format (Jira/Asana-ready)

Convert the action items into a tracker-ready table:
Title | Description | Owner | Due date | Dependency | Priority (High/Med/Low)
Keep titles short. Put detail in the description. Do not invent dates.

The setup is the work. The payoff is the repeat.

The first time is slower because you’re doing two jobs:
running the meeting and building the machine.

After that, the machine runs.

By meeting three, you’re not “capturing notes.”
You’re producing decisions, actions, and updates on command.

That’s the difference between busy and effective—and it’s where 50–70% comes back to you.

Try this once this week

Pick one recurring meeting that always creates follow-up pain.

Run the workflow once.

Then track two numbers:

1. Minutes spent on follow-up this time

2. Minutes spent on follow-up last time

If you get the follow-up down from “two extra hours” to “twenty minutes,” you’ve just broken the meeting multiplier—and you can pull that lever every week.