Prompt your way from pain to prototype

Keep Claude open beside this page, copy a prompt, paste it in, and keep the same chat going all the way through.

Jump to
Start here

Frame the exercise

I want to work through a dealership pain point, with you playing the role of auto industry consultant and thought partner to me. If I want you to put on an additional hat for a specific step, I will say so explicitly. We'll use a structured approach: First, help me explore the underlying problems that might be driving it, broadly, before narrowing in on one to focus on first, not necessarily the only one, just where we'll start. Then, broadly brainstorm possible solutions to that problem, before narrowing in on one to actually build first, again, just our starting point, not the only one we'll try. I'll kick off each part of this with its own prompt, so hold onto this framing as we go. 

The pain I want to start from is aging inventory at my dealership. Start by finding my dealership in the Foureyes MCP and give me a very brief overview of all the data you have access to so I understand what we're working with.

01

Pain

Unpack the pain you're feeling 

Have Claude ask you questions about your pain point

Before we look at the data, I want you to gather context that the data itself won't show you. Ask me one question at a time, no more than 3 total, to understand how I define "aging" and what I'm noticing on the ground. Ask if I have any hunches, and note them as something worth checking later, not a starting assumption.

Keep it conversational, not a form. Once you've got a clear picture, summarize what you've heard back to me, and check whether it feels accurate before we move on. I will provide the prompt for the next step, so don't skip ahead.

02

Problem

Analyze root causes and pick one to solve

Compare stores across the group

Before we dig into root causes, look across the stores in the group and compare how each is doing on aging inventory over the last 3 months. Use the industry inventory data from Foureyes and the context I gave you about each brand's market dynamics to judge each store against what's normal for its brand, not just against each other directly.

Briefly tell me how each store stacks up, and which one you'd say is struggling the most, and why, current severity, worsening trend, or both. Check with me that this tracks with what I'm seeing before we focus our analysis on that store.

Have Claude analyze the data to identify underlying problems

Now unpack the shape of the problem at that store using our data and go a bit deeper, acting as a data analyst as well as a consultant: is this affecting new inventory, used, or both? Is it broad across our whole lot, or concentrated in particular models or segments? Tell me what you find, and check that it matches what I'm actually seeing before you move on.

Once we've confirmed the shape, scan our data broadly for patterns that could point to underlying problems, considering pricing, exposure, follow-up, and anything else worth flagging, focused on the segment(s) we've identified as affected. Compare against national franchise dealer data where useful, to judge whether something looks unusual or normal, not just against our own history. Treat any hunches I've shared as possibilities to check, not assumptions, and tell me if the data contradicts or complicates one.

Briefly describe what stands out, and which problems deserve a closer look. Check with me before going further.

For each one I confirm:

  • Dig in for real evidence it contributes to our aging inventory, not just that it's plausible. Compare against national data where it helps show whether we're in line with the industry.
  • Note the nuance: full explanation or partial, affecting everything or specific segments, how significant relative to the others.
  • If the data doesn't hold up, say so and drop it.

End with a short list of problems the data genuinely supports, each with a brief summary of why it made the list. Don't continue to reference theories the data doesn't back. 

Stack rank the problems and pick one

Now stack rank every problem from our analysis that's genuinely worth tackling based on the data, not just the top one or two. This is meant to become a working list I can come back to over time, so include anything you think is worth solving, ranked from most to least likely to move the needle on our aging inventory.

For each one, briefly explain why it's ranked where it is relative to the others, not just why it matters on its own.

Tell me which one you'd recommend we tackle first, but the choice is mine to make.

03

Prototype

Brainstorm solutions and pick one to build

Brainstorm tactics

Now that we've picked a root cause to focus on, let's brainstorm ways to address it. I'm attaching a reference on what Claude and Foureyes can actually do together, use it to keep your Claude-buildable suggestions grounded in what's real, not guessed at.

I want this to go both directions: suggest tactics you think could work, and also ask me for my own ideas, building on what I bring rather than just handing me a list. Push back if something seems impractical, and ask follow-up questions if an idea needs more shape.

Consider a range of tactics: operational process changes, automations, marketing strategies if they're relevant to this problem, and things that could become an actual app. Include options that could be built directly in Claude, whether through native functionality or the app builder, as well as tactics that would happen entirely outside of Claude. Make sure at least one tactic on the list is something that could become a standing tool or dashboard, since that's the kind of thing we'll prototype today.

By the end, give me the full list of tactics we've landed on together, don't narrow it down yet, that's the next step.

Build an action plan

Let's turn this list of tactics into an action plan. Organize it by order of operations, thinking through how the tactics relate to each other, some might be quick wins, some might depend on others being in place first, some might work better together than alone.

For each tactic, note whether it's something we could build directly in Claude today, something to build in Claude later, or something that happens entirely outside of Claude, like a process or policy change. If you're not confident a 'buildable today' tactic is genuinely realistic given what Claude and Foureyes can actually do, say so rather than labeling it with false confidence.

Suggest a simple way we'd measure whether each tactic is actually working.

Then, out of everything that could become an actual app, recommend the one you think we should build first. Tell me why, but the final call is mine.

Define the prototype requirements

Let's take that tactic and turn it into something concrete enough to actually build. I want you to act as a product manager would, before any building starts, refining what we're actually building and why, not jumping straight to a solution.

Ask me questions, one at a time, to nail down:

  • Who's this for, just me, or other people on my team too?
  • What does success look like, what should be different once this exists?
  • How often would this get used, is it a one-time check, a daily habit, something in between?

Don't move through these mechanically, follow up if an answer raises something worth digging into further. Once you've got a clear picture, summarize the information back to me as a short brief, and check that it's right before we write up formal requirements.

Once I approve of the brief, turn it into true product requirements for the app we're building and let me review.

Once I approve the requirements, we'll hand it over to the Foureyes app builder to execute.