Uh-Oh. Steve Is Vibe Coding

Building an AI-assisted application revealed a timeless lesson. Even seasoned product managers find that the best way to uncover important requirements is through conversation. Context changes everything.

I’m building an app. It’s going slower than expected because my AI tool keeps asking me questions. It wants me to fully explain my requirements.

And the AI is right.

I’ve spent most of my career helping product teams build better products. I’ve worked with thousands of product managers, reviewed countless requirements documents, and participated in more software projects than I can remember. I’ve spent decades teaching people how to think clearly about what they’re building and why.

And yet there I was, staring at a screen, answering straightforward questions from a tool I was using to build an application. Frustrated because I was anxious to start building the application.

That’s when I knew I was learning something. Or actually, re-learning something I have known for years. Context matters.

The Problem 

Over the last few weeks, I’ve been experimenting with what we are now calling “vibe coding.” Using tools such as Base44, Claude, ChatGPT, and GitHub Desktop, I’ve been building an application that grew out of a spreadsheet I’ve used for years. The spreadsheet supports one of my consulting offerings: assessing a product team’s strengths and challenges, and exploring opportunities for improvement. Participants evaluate a set of product management activities, identify which are important, assess how well they are being performed, and provide insight into where coaching or organizational change might be needed.

The spreadsheet worked reasonably well. It could support one participant, but not many. It could generate results, but not aggregate them. Unfortunately, I eventually realized that I was spending more time teaching people how to use the tool than exploring what the results meant.

The obvious answer was to build a web-based application. Participants could respond anonymously. Their answers would be confidential. Results could be aggregated automatically. Reports could be generated. All without gymnastics involving sharing files with complex formulas and hidden columns and tabs. The assessment could finally do what I had always wanted it to do.

The technology turned out to be easier than I expected, eventually. The hard part was something else entirely.

Reqs and specs 

As the AI tools asked questions about users, permissions, workflows, reporting, confidentiality, and administration, I kept discovering requirements that existed only in my head. They were not documented. They were not specified. They were simply experiences I had carried around for years because I understood the problem so well.

Initially, my app allowed everyone to see everything—the default way of handling permissions.

However, anyone who has facilitated organizational assessments knows that confidentiality is essential. Product managers need to be candid. Engineering leaders need to be candid. Sales leaders need to be candid. If people believe their responses can be traced back to them, the quality of the feedback declines immediately. People stop answering honestly and start answering politically.

The AI didn’t understand the requirement; it needed me to explain what confidentiality truly meant for this application.

Confidential from whom?

Can managers see their team members' responses? Can team administrators? Can consultants? Can executives? Can anyone export the data? What information appears in reports? Who controls access? How is that access managed?

What emerged was a much more specific requirement: only super-administrators can access individual responses, while everyone else sees aggregated data. The requirement had been there all along—but only in my head.

Good requirements require conversations

The same thing has been happening with product teams for decades.

Someone says a system needs to be secure. Someone else says it needs to be simple. Another stakeholder says they need better reporting. These statements sound useful, but they aren’t requirements. They are aspirations or platitudes.

Secure from whom? Simple for whom? Better than what?

The actual requirements emerge only with a conversation.

This is the reason I continue to believe that product management is fundamentally about conversations. We spend enormous amounts of time discussing documents, templates, roadmaps, user stories, and backlogs. Those artifacts are useful, but they are not the source of understanding. Understanding emerges when people ask questions, discuss scenarios, and clarify what they really mean.

Years ago, Ron Jeffries introduced the Three Cs of stories: Card, Conversation, and Confirmation. Most teams focus on the card because it’s tangible. Many focus on confirmation because it can be tested. In my experience, the conversation is where the value resides. A story is not a requirement; a story is an invitation to discuss the requirement.

My experience with AI felt surprisingly similar. Many prompts generated additional questions. Every question revealed information that had never been included in any prompt or shared document. In many ways, the AI was my business analyst first, then my developer. It was helping me—forcing me—to articulate the undocumented requirements.

Reqs vs Specs 

The experience also reminded me of a distinction that product managers frequently blur: the difference between requirements and specifications.

A requirement describes the problems to be solved. A specification describes how the solution will be implemented. Today’s product requirement documents are not requirement documents; they are specification documents.

I caught myself making exactly the same mistake I see product managers make every day. At one point, I was so focused on solving a problem that I started telling the AI how to build a solution — wandering into implementation before I had fully described the need. In many cases, it created what I asked for, and I said, “Oh, wait, not like that!”

Product managers do this constantly. We say, “build this feature” when what we mean is “solve this problem.” We specify a solution because we haven’t fully explained the underlying need.

The AI helped expose that habit, too.

What I ultimately learned from this experiment had remarkably little to do with vibe coding.

Conversations are the way 

Requirements have always emerged through conversation. They always will. Documents simply capture what was learned.

What surprised me was how effectively an AI tool could play the role of the person asking the right questions — not because it understood my business, but because it kept asking me to explain it, to be clear.

That’s worth thinking about the next time your team is tempted to skip the conversation and go straight to the card.

Who is asking your team the questions that force real answers? If the honest answer is “nobody,” that’s a problem worth solving — whether you hand it to an AI, a business analyst, or a product manager who knows how to push back.

The technology may be new. The lesson isn’t.

It’s not AI product management. It’s just product management.