Part 2: Ideation & Validation

Before AI, ideation meant trying out several similar products myself, or pulling UI references from Mobbin, to find a direction that felt right. From there I'd sketch wireframes, and getting to a working hi-fi prototype in Figma meant either staying flat, or pouring in an enormous amount of time to make it actually function. Data that could show real user behaviour only existed once all engineering resources were committed and we'd shipped a beta.

That's not how it works anymore.

Diverging on ideas

Once I've clearly defined the problem I'm trying to solve, I ask AI for it and get back a batch of ideas along with a first pass at reference research.

Why: In the early divergence phase, the number of ideas itself has value. A person sketching one at a time is capped by how fast they can draw, but AI has no cost to throwing out a wide range, so it's well suited to widening the thinking early on.

Prompt example: "Suggest 5 UX directions for solving [problem definition]. For each, give the core idea, likely pros and cons, and any reference products that solved a similar problem."

Out of the long list AI comes back with, I still decide which ones are actually worth trying myself. No AI summary of a competitor's flow replaces the feel of clicking through it directly, so that filtering step stays mine before anything moves forward.

I ideate flat designs in Stitch or ChatGPT, and I ask teammates to bring their own AI-generated ideas too, with pros, cons, and trade-offs also drafted by AI as a first pass.

Why: Having multiple people each use their own AI guards against prompt bias, getting stuck inside one person's way of framing the problem. The final call on what gets adopted still belongs to the team, since only the team knows our project's context, resources, and strategic priorities.

Prototyping

Once an idea is picked, I go straight into building a working prototype in Claude Code, skipping the wireframe stage entirely. Instead of designing against a fixed set of PRD user stories, the PM and I develop the working prototype together, and scope gets discussed and shaped as it takes form.

Why: Wireframes were always just an intermediate artifact on the way to something real. Vibe coding lets us skip that step and go straight to a functional version. And building the prototype alongside the PM, rather than handing off a finished PRD first, means scope isn't locked in before we've actually seen the thing working. It's easier to catch what's missing or unnecessary when you're looking at a real flow, not a list of user stories.

Getting there takes a lot of prompts and a lot of iteration. It's rarely one clean pass, more like refining the same flow over dozens of small rounds until it actually feels right.

It also makes collaboration with multi functional teams including sales, customer success, and engineers more effective, since it gives us something tangible to test, discuss, and refine together before development even begins, rather than a document or flat design to interpret.

Why: Flat design always relied on the viewer's imagination to guess how a feature would actually be used, and that imagination has limits. A tangible, working prototype removes that gap, so the feedback we get from other teams is far more grounded and useful.

Validation

Testing with partners or users who had opinions on the relevant feature now happens at the working prototype stage. Testing that used to only be possible with a flat mockup, or after release, now happens before release.

Why: A flat mockup couldn't show real interaction, so user reactions to it were limited. Testing after release happens at a point where changes are already expensive. A working prototype fills the middle ground, realistic enough to get honest reactions, cheap enough to still change.

I've found that this approach helps us move faster upfront while reducing the amount of iteration needed after launch, and the risk of confusing users through frequent changes in production. The result is a more validated solution at launch, which cuts down on both future iteration and dev effort.

Limits

This breaks down for features that need to be compatible with the existing product, or that depend heavily on a user's existing data context.

Why: Prototypes run on placeholder data, not production data, so they can't reproduce the messiness of a real user's actual data state or edge cases. Those features still need validation later, once real data and dev resources are involved.

Looking back at this stretch of the process, the shift isn't that AI does the ideating or the building for me, it's that trying things got cheaper and faster, not free. Divergence got wider, validation got earlier, and the gap between an idea and something a team can actually react to shrank noticeably. Think about the development cost and effort this alone has saved us. What stayed constant is the filtering and prioritisation: deciding which direction is worth pursuing, and knowing when a prototype is ready to put in front of real users, is still something a person has to do.

Next up in this series: what changes once the prototype is validated and it's time to move into hi-fi and QA.

Part 1: Research

When a problem signal showed up, I used to run the whole process alone. I'd prepare the interview or survey, conduct it, transcribe it, and summarize the insights myself, start to finish.

That's changed a lot in the AI era, but not evenly. One thing hasn't moved at all: which data to look at, and how to interpret it, is still entirely mine, not AI's. Deciding which angle or segment of quantitative data actually reveals the real cause requires context on the project and domain judgment built up over time, and that's not something AI can substitute for. If you just ask AI to "find the problem in this data," it will surface surface-level patterns readily enough, but it has no sense of whether that pattern is a real signal or just noise. That judgment call is where I still start every research phase, before anything gets handed off to AI.

The real shift happened somewhere else: in how I research qualitative data.

Preparing the interview facilitation

Once I've clearly defined what insight I'm trying to get, AI drafts a strong first version of the question list.

Why: If the goal is clear, working backward from it to structure questions is a fairly patterned task, so AI does it well. But if the goal itself is wrong, no amount of good questions fixes that, so defining the goal stays mine.

Prompt example: "We want to understand what happens between [a sales rep preparing a quote and the customer giving final approval]. Specifically, we want to uncover what [communication and processes take place outside the product], as well as [what sales reps and customers actually check or negotiate] beyond the steps defined in the official workflow.

Based on this goal, write a 30-minute user interview guide with warm-up questions, core questions, and potential follow-ups. Avoid leading questions and focus on understanding why users behaved as they did, rather than simply what they did. For example, explore what happens before [a quote is sent to the customer], why customers [request explanations or revisions for certain items, and what discussions and decisions take place both inside and outside the product before final approval.]"

Analysing the data

• Summarising insights from open-ended survey responses or interview transcripts goes to AI.

• For large volumes, I cross-check across GPT, Claude, and Gemini instead of relying on one.

Why: Reading dozens of transcripts and manually tagging recurring themes is pure labor time, which AI can absorb. But different models tend to emphasize different themes in the same data, so trusting a single model's summary risks accepting a biased read without knowing it. Cross-checking reduces that risk.

Prompt example: "Here are 8 user interview transcripts about [feature]. List the recurring pain points ranked by frequency, and quote the statements that support each one. Don't add your own interpretation, only what's grounded in the quotes."

I still sit in on interviews

• I still join most interviews myself, asking follow-up questions live and reading the context and nuance of the conversation.

• I compare AI-generated findings against what I observed directly, to check whether the interpretation drifted from context or missed something.

Why: Insights users reveal through behaviour rather than words, like a cursor hesitating over a button during a screen share, never show up in a transcript. That only gets caught by being in the room, and no AI summary replaces it.

AI's role here isn't to interpret the insight, it's to turn insight I've already reached into a format I can share cleanly with the team.

Prompt example: "Turn my interview observation notes into a script for a team-facing report. Structure it as three key findings, the evidence for each, and suggested next actions. Don't change my interpretation or conclusions, just restructure them."

Looking back at this stretch of the process, the shift isn't that AI took research away from me, it's that it took the parts that were pure labor and left me with more time for the parts that actually require judgment: knowing which data matters, sitting in the room to catch what a transcript can't, and making sure a summary reflects what I actually saw. That's the trade I'd make every time.

Next up in this series: how that same shift plays out in ideation, where the problem isn't too little output anymore, it's too much of it, and figuring out what to do with all of it.

Where it started

If you build B2B SaaS long enough, this moment becomes familiar. Sales closes a hard-won deal, the customer starts onboarding, genuinely intending to use the product. Then, not long after, they say:

"We don't think we're ready to use this yet."

Our product was a B2B SaaS with an enterprise ICP, and this line kept showing up as the reason customers dropped out of onboarding. Once or twice, you'd chalk it up to an individual customer's circumstances. But it was showing up often enough to call it a pattern.

A proposal to solve this problem landed on my desk. It came with wireframes, and a note that it was already "aligned with customers."

The solution I was handed

The logic behind the proposal was straightforward: customers felt unready because they didn't yet have a project worth putting into our product. So the plan was to extend our product's scope upstream, into the stage before real usage, to help customers surface and prioritise project ideas.

The design added a whole new capability: collect project ideas, build a mapping/prioritisation feature around them, and connect the output into a real project inside our core product. Directionally, it made sense. The problem was scope. This wasn't a feature; it was effectively a second product. It called for a PM, a product designer, an engineering lead, and five software engineers, for six months or more.

The question I stopped to ask

I had no objection to the plan on its face. But before committing that much scope, one thing kept nagging at me.

Was "we're not ready yet" really one situation, or several different ones, flattened into a single phrase?

The proposal had already arrived with the premise that one solution was aligned with customers. I wanted to test that premise itself before building on top of it. So I broke down the possible reasons behind "not ready yet" into three hypotheses:

1. No project to manage, yet: at the point of onboarding, the customer simply doesn't have a project to put into the product

2. A project exists, but it doesn't fit our product's structure: the customer has a project, but its shape doesn't match the structure our product requires

3. A project exists and is structurally compatible, but there's no good way to bring it in: the content and structure line up, but there's no viable import path

The three hypotheses look similar on the surface, but they call for entirely different solutions. If it's #1, "help customers discover project ideas" is the right answer. But if it's #2 or #3, an entirely different kind of solution is needed.

Checking it against data

Once the hypotheses were set, I went to the people closest to customers, Sales and CS, to ask which of the three actually matched what they were seeing. I wanted to know, among customers who dropped out during onboarding, which reason came up most.

The result didn't match the premise the original proposal was built on. By a wide margin, the dominant reason wasn't #1 (no project to manage); it was #2: "there's a project, but it doesn't fit our product's structure."

In other words, customers weren't stalling because they lacked a project to put into the product. They already had projects, run their own way, and were dropping out at the moment they realised how much re-structuring it would take to fit our format.

Had we gone ahead with the original plan, we would have spent six months building a solution for a problem (#1) that, in practice, was barely happening.

The solution I proposed instead

I brought this data back to the stakeholders. It didn't land at first. I framed it as "I tested the hypotheses and got a different picture," but momentum doesn't shift that easily. So I changed approach. I invited Sales and CS directly into the room and let stakeholders hear the actual customer cases from the people who'd lived them. The specific stories from people who'd talked to customers carried far more weight than the data I'd summarised.

That's how I ended up proposing a much smaller alternative.

The core idea was simple: let customers bring in their existing projects as-is, as a raw data source, before asking them to restructure anything to fit our product. Instead of treating structural compatibility as a prerequisite for onboarding, flip the order: let customers onboard first, and clean up the structure gradually, afterward.

• Not a new feature to help customers discover project ideas,

• but an intake path that lets an existing project in, structure-agnostic, from day one.

With this, customers no longer had to answer "does our project fit this product's structure?" before they could even start. Structuring becomes a later problem, not a gate.

The outcome

The original six-month proposal pivoted into a smaller, validated solution. The team that would have been assigned to it, a PM, a product designer, an engineering lead, and five software engineers, eight people in total, was freed up to work on other priorities instead. A rough estimate, based on industry-average loaded salary costs, puts six months of that team's time at roughly A$700K or more in Australian dollars. But the number matters less than what it represents: eight people's worth of engineering capacity that could have gone toward an unvalidated problem, redirected toward a validated one instead.

The solution I'd proposed was eventually built and shipped, and onboarding drop-off went down.

What stayed with me

"We're not ready yet" was one sentence from the customer, but behind it were three distinct situations. Even a solution that looks like it's already aligned with customers is worth checking again: aligned with which question, exactly.

What this experience reinforced, ultimately, comes down to one thing: the larger the scope of a proposal, the more worthwhile it is to validate the problem definition before building. Framing hypotheses and asking the people closest to the data, in this case Sales and CS, took two days. Those two days changed the direction of a six-month project.

The question that stayed with me since is this: is the "already-decided solution" in front of me actually solving a validated problem, or just the loudest voice in the room?