Did he just say: 'Forget writing requirements, just use AI'?

Forget about articulating your product vision and learning what you actually should build based on customer discovery. Do not bother writing reqs, just go AI-first and start prototyping. This is what a product exec on Google's Gemini team recently shared on social. And he is not the only one pushing product teams into a build-now, write-never mentality.

"Just build it and they will come," as someone once said. Now, the mantra is: "Just vibe code it and you will miraculously solve a customer problem."

Do not get me wrong: Using AI to spin up prototypes is an interactive way to express your ideas and get feedback. But only after you understand what the challenge is and make sure it aligns with your product vision.

And as I have shared in recent blog posts, our observation — which we call the Waters theory — is that from here on out, the percentage of code written by AI (not people) will quintuple year over year. AI accelerates much of what we do as product builders too, and it is only going to help us move faster the more we use it.

But I keep reading about company leaders who believe simply using AI means they are ahead of the curve. Every social forum you turn to has discussions that include some version of this as a recommendation. The code may be writing itself more than ever, but someone still needs to have customer insights and clear product goals.

Even if (when?) agents replace the human work of managing projects, they are unlikely to determine why the product matters.

When you bypass customer discovery and rush past requirements, you outsource critical product decisions to an algorithm without necessary context.

Here are some of the issues with skipping customer discovery and requirements:

• Problems are messy: The hard part is problem framing, not code generation. Discovery transforms ambiguous needs into solvable problems. AI is powerful at implementation, but not at resolving organizational ambiguity.

• Speed is a mirage: AI boosts throughput. Without clear goals and customer insights, you create more output with the same (or greater) risk of misfit — increasing rework, technical debt, and opportunity cost.

• Change is costly: It is always cheaper to iterate on a concept, prototype, or requirement than a shipped system with users, data, and integrations.

• Value lies in use: Will anyone use it? Will they pay? These are discovery questions answered via research, segmentation, jobs-to-be-done, and validation — not by a passing build.

• AI can amplify bias: Model-driven outputs reflect the data and prompts you provide. Poor discovery injects bad assumptions at scale. Requirements serve as guardrails to reduce bias propagation.

If you have pride of purpose and want to build something of value, you cannot accept the "let AI do it for you" mentality.

So, how do you convince your boss that you need to take a beat and talk to customers? How do you push back against executives who push for AI-first development with disregard for upfront human analysis?

Here are a few specific rebuttals you can try when your boss (or the board) tells you to "just use AI to build it":

• "AI is a force multiplier — not a compass." It can help accelerate research synthesis, option generation, prototyping, and test execution. But only after you have defined the problem and success criteria.

• "AI cannot read our customers' minds." AI generates code based on patterns in its training data — not insights into your specific users' workflows. It might build a feature that looks pretty good, but misses core customer needs.

• "AI fills gaps with assumptions, not insights." When requirements are unclear, AI makes its best guess based on common patterns. Those assumptions rarely align with a differentiated product strategy.

• "AI cannot help us iterate if we cannot measure success." Without clear requirements defining success metrics and acceptance criteria, it is impossible to tell if you are improving your product or just changing it incrementally.

• "AI compounds the cost of being wrong." If you are building the wrong thing a larger percentage of the time, you are wasting effort and creating even more distractions on your way to success.

Customer discovery and requirements are not overhead — they are your targeting system.

When everyone can build fast, the companies that win are the ones that build precisely. Remind your team that there is real cost in skipping upfront discovery and planning work. It is the cost of not actually listening to what your customers want to pay you for and building what they do not.

You might find that while you are rebuilding features that missed the mark or just discarding them, someone else is shipping things customers actually need.

For more than 12 years, we have said that the best product builders take a goal-first approach. AI will not change that.

Build better products with Aha! starting today.