From "Is This a Real Problem" to "How Do You Convince People"
The Eight AI Skills I Actually Use

Not long ago, AI seemed to mostly help us with brainstorming, answering questions from existing knowledge, and structuring problems — but we had no idea which thinking models sat behind the answers it gave us. Were those frameworks or theories even ones we agreed with?

Can we "require" AI to work through our problems using the theories, processes, and thinking approaches we consider appropriate, and have that thinking approach be repeatable again and again — that's what I think a Skill is.

But understanding that concept alone still felt vague to me, so I wanted to use an actualproduct project to really experience what Skills can do for us, and where we might use them in the future to serve our clients. Here I'm documenting it layer by layer — which skill I used at which stage, what wrong turn it blocked me from taking, and what concrete output it left behind.

🧊 Stage One: Is This a Real Problem?

I fed the pain point the client initially proposed the product should solve into the sharp-problem-test skill, and the verdict came back "NEEDS MORE EVIDENCE" — the evidence wasn't sufficient yet, and it pointed out the directions that needed validating.

Without this step, relying on my own judgment and research wouldn't necessarily have been as thorough or as broad as what the AI came up with. Because it flagged something I hadn't realized myself: in my head I was benchmarking against general-purpose tools like Asana, Trello, and Notion, but the real competitors this idea would actually be up against were more vertical, worker-oriented tools like HoneyBook and Dubsado. Get the competitor wrong, and every positioning and design decision downstream drifts off course too.

🔎 Stage Two: Has Someone Already Solved This?

Once the problem direction was confirmed, the next step was checking whether anyone in the market was already doing this. For this stage I used yushi-competitive-analysis, running a detailed analysis of competitors' user numbers, feature breakdowns, and marketing angles, then synthesizing the findings.

What this report blocked was the illusion that "there doesn't seem to be anything out there." The report showed one competitor already had 120,000 paying users — a number that says two things at once: first, that this customer segment is genuinely willing to pay, meaning the problem is real; and second, that with that many users already in place and still nobody truly solving the piece we cared about, there's confirmed room for a distinct angle.

🎯 Stage Three: Where's My Angle?

With the competitor data in hand, I fed the angle back into sharp-problem-test for another round, and this time the verdict was SHARP, landing on the "worker-facing" angle.

What this round blocked was just as concrete: I'd originally planned to make the "quote editor" the core selling point of this project, but the test results showed it would only deliver roughly a 1.5–2x improvement — not a large enough gap, just an optimization of a feature others already had, not enough to carry a flagship selling point. That warning let me shift my focus before I'd even started designing.

🧭 Stage Four: How Do You Validate It?

Once the angle was confirmed, we needed to gather more real-world data on how the target audience actually works to validate the hypothesis. For this stage I used customer-discovery-week, which produced a draft interview outline, a questionnaire, and an execution plan all in one pass.

👥 Stage Five: Who Do You Ask?

Once we'd settled on doing interviews, the first concrete question was "who do we ask." For this stage I used claude-persona, which generated 10 personas targeting the dimensions where I judged we needed breadth.

For example, this project's target audience scale was locked in from the start at 1–2 person studios — that wasn't going to change. But we wanted more breadth on the industry side, so I could define that constraint for the skill, and it would complete the task within the limits I gave it.

What it blocked was the easiest mistake to make — only interviewing people in the same industry who are similar to yourself and who you'd normally talk to anyway. Answers gathered that way often just echo your own thinking back at you; they sound like agreement, but they don't bring any real new information.

📝 Stage Six: What Do You Ask?

With interview subjects identified, the next step was deciding what to ask. For this stage I used interview-guide-builder, which produced 7 research questions (RQs) and a 35-question interview guide.

Principles I held firm to in designing the interview guide — such as moving from recent experience to more distant past experience, and from concrete behaviors to more value-oriented questions, a funnel-style approach — were already built into the skill's design, so there was no need to re-communicate them each time.

🕳 Stage Seven: Are There Gaps in the Guide?

Once the interview guide was written, I ran it through interview-simulator for a simulation round first, generating roughly 350 exchanges.

In an actual interview, a real person's time is the most expensive resource in the whole process — if the guide itself has gaps, and you only discover the questions weren't hitting the mark once you're sitting down for the real interview, that time is simply wasted.

✂️ Stage Eight: How Big Should the First Version Be?

Once validation was more or less complete, it was time to decide the scope of the first version. For this stage I used slc-or-mvp, which produceseither an MVPor an SLC,to determine whether the product should start fromMVP(an experiment built purely to learn from, meant to be thrown away afterward, no one grieves it) or fromSLC(Simple, Lovable, Complete — a product built to actually be used, just with a very small scope).

This way of thinking prevents cramming every feature discussed along the way into the first version. It's a more effective way to assess what belongs in version one, rather than relying on gut feel.

Looking back at these eight stages, what the AI skills did here was keep asking me one more question — "are you sure, is the evidence enough" — continually pulling in data, testing the reasoning, and coming at things from different angles. But whether to actually accept a given verdict, whether to keep moving forward, still comes down to human experience making the call.

Right now, every one of these nodes could still be explored further — digging into exactly how the data we get back should be judged. More to share as that continues!