Over the past two years, public discourse around artificial intelligence in product development has fallen into two equally unhelpful extremes.
On one side is uncritical techno-optimism: the belief that natural language prompts will soon replace engineers, designers, and product managers entirely, generating billion-dollar apps from a single paragraph of text.
On the other side is cynical dismissal: the view that generative AI produces nothing more than derivative slop, broken boilerplate code, and hallucinated user research that no serious professional should touch.
As someone who spends their days thinking through product strategy, user experience, and systems architecture, my experience lives squarely in the messy, practical middle.
I do not view myself as an AI architect or a visionary predicting the singularity. I am a product practitioner exploring how modern computational tools can expand the fidelity, velocity, and thoroughness of product craft.
When used with structural discipline, AI does not replace product thinking. It accelerates the feedback loop between an ambiguous observation and a testable, interactive reality.
Here is how I actually use AI across the product lifecycle—as a workflow, not a list of novelties.
The Workflow at a Glance
The mistake most teams make is adopting AI as an isolated tool: "Let's use an AI tool for user personas, and another AI tool for wireframes."
Point solutions generate disconnected artifacts that quickly become shelfware. The power of modern models emerges when you weave them into a continuous intellectual loop:
- Problem Framing & Pressure Testing (Challenging assumptions and discovering edge cases).
- System Architecture & Behavioral Modeling (Defining state machines, permissions, and data schemas).
- Assisted Prototyping & Code Verification (Building real, interactive frontend and API environments).
- Validation & Failure Mode Analysis (Stress-testing how the interface handles latency, errors, and ambiguity).
- Critical Learning & Synthesis (Distilling operational lessons into durable product principles).
Phase 1: Problem Framing as an Intellectual Sparring Match
The earliest stage of any product initiative is the most perilous. You have an intuition, a user complaint, or an operational bottleneck. If you immediately jump into Figma or code, you risk solving the wrong problem with immaculate precision.
I use models like Claude and ChatGPT not to give me answers, but to vigorously interrogate my framing.
Instead of asking: "Write a product spec for a split expense app," I approach the model with a deliberate adversarial prompt:
"Here is a problem hypothesis for Splitflow: Roommates avoid settling shared dinner bills because calculation friction turns social moments transactional. Critique this hypothesis. What unstated social dynamics am I overlooking? What failure modes exist when one person consistently covers upfront costs? Where does the traditional 50/50 model break down in multi-currency or unequal-income households?"
The model acts as a tireless debate partner. It surfaces edge cases, behavioral anxieties, and economic asymmetries that might have taken weeks of passive ideation to recognize.
Crucially, I never outsource the user research itself to AI. Synthetic personas cannot tell you what real humans feel. What the model can do is help you formulate much sharper questions before you sit down with a real human being.
Phase 2: Specifying System Behavior Before Drawing Pixels
Before opening an interface canvas, a product thinker must define how the system behaves under stress. What happens when network connectivity drops mid-transaction? Who has permission to approve an expense over-budget? What are the valid state transitions for an invoice?
Here, LLMs excel at translating natural language problem statements into formal state specifications.
Working on the permission architecture for Weekwise, I used conversational prompting to map out the state machine for timesheet approvals:
- What happens when an employee submits hours after the weekly closure gate has passed?
- Can a team lead approve a booking if the project code belongs to another department?
- What exact database mutation occurs when an approval is retracted?
By generating strict TypeScript interfaces, Zod validation schemas, and Mermaid state diagrams during discovery, the product logic is bulletproofed before a single component is styled.
Phase 3: Assisted Prototyping with Real Code
For years, the standard transition between product thinking and engineering was the static design mockup. Product managers wrote 40-page PRDs; designers produced pixel-perfect Figma screens; engineers looked at both and explained why half the interactions were technically impossible.
Today, tools like Cursor and Claude Code have collapsed this divide.
Rather than handing off static drawings, I build working, interactive prototypes in Next.js, React, and Tailwind.
The workflow is fluid:
- I write the core data structures, component architecture, and interaction philosophy.
- I use Cursor to rapidly implement component scaffolding, boilerplate state hooks, and complex CSS layouts.
- I feed real JSON payloads through the interface to test actual layout behavior with long strings, missing avatars, and extreme numbers.
When you prototype with live code, you discover realities that Figma will never reveal: layout shifts on mobile viewports, the awkward jerkiness of un-throttled scroll listeners, and the cognitive friction of multi-step modal workflows.
Phase 4: Model Independence and Failure Handling
When building AI-powered features (such as the conversational guide in Weekwise), I treat the underlying foundation model as an untrusted third-party service.
Whether the application calls OpenAI, Anthropic's Claude, or Google's Gemini, the interface must remain resilient to model failure:
- Latency Fallbacks: If a model takes 2.4 seconds to stream a response, does the UI show a generic spinner, or does it provide immediate deterministic feedback while the stream warms up?
- Schema Validation: Every JSON output returned by an LLM is piped through a strict runtime parser (like Zod). If the model hallucinates an invalid enum, the system catches the error at the boundary and falls back to a safe default.
- Model Swappability: Software should never be tightly coupled to a single vendor's proprietary SDK. Wrapping AI interactions behind clean domain adapters ensures that when a newer, cheaper, or faster model emerges, the product can switch providers with zero changes to frontend UX.
For a deeper dive into how authority boundaries protect production applications from model failure, read my analysis in Why AI Products Need Authority Boundaries.
The Moat is Taste, Not Tools
There is a growing fear among creators that because AI can generate code, wireframes, and copy in seconds, individual craft no longer matters.
My experience points in the exact opposite direction.
When the cost of generating software approaches zero, the value of knowing what to build skyrockets. The world does not need more automatically generated applications with generic button styles and repetitive marketing prose.
The moat is not whether you know how to type a prompt into an LLM. The moat is:
- Do you understand the quiet, unstated anxieties of the human using your product?
- Do you know when to introduce friction to protect data integrity, and when to eliminate it?
- Do you have the aesthetic restraint to strip away decorative clutter and let typography and hierarchy breathe?
- Can you hold a complex multi-tier system in your head and spot the single logical contradiction that will derail a sprint?
AI is the most capable cognitive amplifier we have ever had. But an amplifier only magnifies the signal you feed into it. If you feed it superficial product thinking, it will manufacture superficial software at unprecedented scale.
If you feed it deep curiosity, structural rigor, and obsessive attention to human craft, it allows a single focused thinker to build systems of extraordinary depth and elegance.
Explore how this methodology informed the creation of Weekwise and Splitflow, or read more about my background on the About page.