How AI Helps Us Ask Better Questions (Before We Build Anything)
Most discovery processes start with a consultant's standard checklist. We let AI generate the questions instead, then use it again to find patterns we might miss. The result is a clearer path to what actually needs building.
The Problem with Standard Discovery
When Petrograph came to us wanting to replace Miro for AI-assisted design work, we could have run our usual discovery workshop. Ask about current tools, pain points, success metrics. Check the boxes, write the brief, start building.
But standard questions get standard answers. "Our current tool is slow" tells us nothing about whether the slowness happens during ideation, collaboration, or export. "We need better AI integration" could mean anything from autocomplete to full generative workflows.
We needed questions that dug into the specific ways their team actually worked, not generic software evaluation criteria.
AI-Generated Questions for Real Problems
Once we understand the basic goal, in Petrograph's case, building a Miro alternative optimized for AI workflows, we feed that context to Claude or GPT-4. Not to get answers, but to generate interview questions.
The prompt is straightforward: "Given this project goal and these known constraints, what questions should we ask the people who will actually use this product?" We include role-specific context: designers vs. product managers vs. developers.
For Petrograph, AI suggested questions we wouldn't have thought to ask: "When you're iterating on a design concept, how do you currently capture the reasoning behind each decision?" and "What happens to your workflow when someone joins the project mid-stream?"
These questions revealed that their biggest bottleneck wasn't tool speed, it was context handoff between team members. That insight shaped everything we built.
Pattern Recognition in the Transcripts
After conducting interviews with five to eight people across different roles, we have transcripts. Lots of transcripts. Reading them manually works, but humans are terrible at spotting subtle patterns across multiple conversations.
We upload the transcripts to Claude and ask it to identify recurring themes, contradictions between different roles, and gaps between what people say they need and what their described workflows actually require.
In the Petrograph interviews, three different people mentioned "version control" as a need. But the AI analysis caught that they were talking about three different things: file versioning, design iteration history, and decision audit trails. Manual analysis might have grouped these under "version control" and missed the nuance.
From Patterns to Opportunities
The AI analysis gives us raw material, not final insights. It might flag that "collaboration" appears in 80% of responses, but it can't tell us whether that represents a real opportunity or just people using buzzwords.
This is where human judgment matters. We review the patterns, cross-reference them with what we observed during the interviews, and filter for opportunities that align with what we can actually build well.
For Petrograph, the analysis revealed that their team spent significant time recreating context for new project members. But they also mentioned loving the "happy accidents" that happened during collaborative brainstorming. The opportunity: build context preservation without killing serendipity.
Business Value Before Technical Planning
Before we write a single technical specification, we map each opportunity to measurable business impact. Not generic ROI promises, but specific changes the client can expect to see.
The Petrograph context handoff problem translated to: "New team members productive in 2 hours instead of 2 days." The serendipity preservation translated to: "Maintain current creative output while reducing project setup time by 60%."
These aren't marketing claims. They're testable hypotheses that guide what we build and how we measure success.
What This Process Actually Delivers
By the end of discovery, we have three things: a ranked list of opportunities, expected business value for each, and enough specificity to start technical planning without guessing.
More importantly, the client understands not just what we're going to build, but why each piece matters to
