The SPARK Method: What Years in Online Business Taught Me

Weeks spent building. Then silence when you tried to sell.

The SPARK method came out of a period when I was deep into digital knowledge products, pre-sales and automated income. After decades in online business, I'd seen too many experts invest weeks in courses, videos and platforms before a single customer had paid.

I wanted to change that. Before we built a big course, people should see a concrete offer and decide whether to pay for it. Their questions and reactions would then shape what we actually built. That became SPARK.

SPARK is no longer a current core offer. I'm sharing the method here because its most important idea is easy to lose when building with AI. Just because you can now create a product in hours doesn't mean anyone wants it. You simply reach the point of finding out faster.

What SPARK stood for

The name described five steps. The language and some of the tactics belong to their time. But the business logic carries over clearly to today's AI products.

Ask about the last time it really hurt.

In the original SPARK process, I often started with this question: If I could solve one problem for you, what would it be? That finally got the conversation away from my product idea. The customer could talk about what was actually on their mind.

Today, I'd dig deeper. When did the problem last happen? What did you try? What did it cost you? Why wasn't the previous solution good enough? How would you know it was solved? Those specific stories tell you more than abstract wish lists.

Surveys can reveal patterns. They don't prove willingness to pay. For that, you need an offer, a price and a real opportunity to say yes or no.

What pre-selling means and where its limits lie

Pre-selling isn't a trick for making people pay for an empty idea. A credible pilot makes clear what already exists, what you'll develop together, how much support is included and what result you can realistically aim for.

Both sides gain. The customer gets closer support and more influence. The provider learns from real cases instead of spending months on assumptions. Recurring questions become part of the product; recurring obstacles become features or focused support.

With traditional courses, that often meant delivering content live first, then turning it into a repeatable process. With AI products, the first working core can now emerge much faster. What doesn't come faster is the judgment to know which result is valuable and responsible to pursue.

Today, CoachWunder builds the first version. Asking the right question is still your job.

With the Golden Ticket, nobody should spend weeks recording modules, developing prompt chains or piecing together software. You upload your expertise to CoachWunder. Within a few hours, it becomes the first working core of a personal AI product that real people can try.

The human work focuses on where experience makes the biggest difference: positioning, audience, result, offer, price, validation and sales. It's the direct next step from those earlier years of building products.

The gain is talking to customers sooner. You have something they can try. Their questions show you where your product isn't helping yet. That gives you a basis for improving it. Another week polishing your idea alone wouldn't give you those answers.

Validating an AI product: what else you need to check today

For an AI product, interest in buying isn't enough. The interaction with the product also needs to be helpful, safe and consistent. One convincing demo conversation doesn't establish that.

Work with pilot customers to see whether the AI understands context correctly, asks useful follow-up questions, follows the method and knows when to stop. Document wrong turns and use them to improve instructions, data, tools or handoffs to a person.

A strong pilot answers three questions: Will people pay for the result? Do they actually use the path you've built for them? And does the product move them measurably closer to the promised result?

• Willingness to pay: Is this a problem people will pay to solve?
• Quality of use: Does the customer understand how to work with the product?
• Progress toward the result: Is there visible progress?
• Reliability: Does the system stay within its method and boundaries?
• Profitability: How much human time does it take to help a customer succeed?

What I'd do exactly the same way with my next product

Keep the closeness to customers, validation before major production, early sales and responsible use of resources. You don't need to keep old funnel tactics, artificial scarcity or the idea that a large content archive automatically makes a strong product.

The old method and today's software are different things. But the question behind them still follows me: Why are we building this? If the only answer is that it would be technically interesting, I'm still missing the customer. That's where I'd start.