Kevin Naughton recently shared something that caught my attention: "8 months ago I told my manager at Google I was leaving. They asked me one question: "What’s your plan?" I didn’t really have one." That mix of honesty and conviction hits because it is the opposite of the polished startup narrative most of us expect.

He described his "plan" as a problem worth solving, some savings, and the belief he could "figure it out along the way." No co-founder. No funding. No safety net. Just him and a laptop.

I want to expand on what Kevin is really pointing to here, because there is a practical playbook hiding inside that seemingly reckless sentence.

The surprisingly effective "no plan" plan

Kevin’s story is not about being impulsive. It is about choosing a different kind of plan.

Most career paths, especially at top companies, reward optimization: promotions, vesting schedules, performance cycles, and predictable milestones. Kevin contrasts that world with a scrappier one: while others optimized their corporate trajectory, he was searching "how to set up Stripe payments." That one detail is more revealing than it looks.

It signals a shift from:

Planning for approval to planning for customers
Building a resume to building distribution
Measuring output in reviews to measuring outcome in revenue and retention

"Turns out "figure it out along the way" is a valid strategy if you’re solving a real problem."

That last clause matters. "No plan" only works when the problem is concrete enough to guide your next step. Otherwise you are not improvising, you are drifting.

Start with an itch you personally feel

Kevin’s product idea came from a daily frustration:

He creates content across LinkedIn, X, YouTube, Threads, and a newsletter, and he was spending 30+ minutes a day reposting the same content everywhere, manually.

This is the kind of pain that produces good SaaS:

It happens frequently (daily)
It wastes time in a measurable way (30+ minutes)
It is emotionally annoying ("Manually. Like an animal.")
It has a clear before-and-after outcome (post once vs post everywhere)

The best part is that you can validate it without market research decks. If you feel it, odds are many others do too, especially if you are already in the target community.

A quick reality check: is your pain a product?

When I hear a founder say they are solving their own problem, I look for three signals:

Frequency: weekly is good, daily is great.
Stakes: does it cost time, money, or opportunity?
Workaround: are people already cobbling together solutions?

Cross-posting checks all three. Creators either do it manually, pay for a social media tool that is too heavy, or accept the loss of reach.

Build the smallest thing that removes the pain

Kevin built Ferryman: post once on the platform you love, and Ferryman distributes it everywhere else within minutes.

That is a tight promise. It is not "an AI content suite" or "a creator growth platform." It is distribution automation, framed as getting 30 minutes of your day back.

This focus is what many early products miss. Founders often overbuild because it feels safer. But early on, the product’s job is to make one painful job disappear.

Why this positioning works

Ferryman’s message succeeds because it is:

Specific: "post once" and "everywhere else"
Fast: "within minutes"
Outcome-driven: "let me save you 30 minutes"
Easy to explain: you can repeat it in one breath

In a crowded SaaS landscape, clarity is distribution. People share what they can understand quickly.

Revenue is not vanity when it proves retention

Kevin shared early traction:

$600+ MRR three months in
Users are paying and staying
$1,000 MRR within reach

The numbers are not the point. The shape of the evidence is.

MRR is useful because it answers questions that likes and sign-ups cannot:

Did someone value it enough to pay?
Did they keep paying after the first month?
Is the pain recurring, not one-time?

"A real product turned into real revenue."

I also like that Kevin framed this as a progression. In bootstrapped SaaS, momentum often looks like this:

A real problem (felt daily)
A real product (does the job reliably)
Real revenue (payment proves value)
Real retention (staying proves ongoing value)

If you are building, aim your weekly work at moving one step to the right.

The hidden strategy: trade certainty for speed of learning

When Kevin says he had no plan, what he is really saying is: he chose learning velocity over certainty.

A traditional plan tries to remove unknowns before action. The "figure it out" plan assumes unknowns are inevitable, so you design your life and product to learn quickly:

Build in public so feedback is constant
Ship small changes so you can correct course
Charge early so you learn what people truly value
Keep scope tight so you can maintain quality alone

This approach is not reckless if you respect constraints:

Know your runway (time and savings)
Pick a problem you deeply understand
Limit the surface area of the product
Measure retention, not applause

A practical framework you can copy this week

If you are a creator, indie hacker, or operator thinking about a small SaaS, here is a simple, Kevin-inspired path.

Step 1: Write your "annoying daily task" list

List the 5 tasks you repeat weekly that feel dumb, manual, or error-prone. Highlight the ones that:

take 15+ minutes
involve copying and pasting
have clear success criteria

Step 2: Define the one-sentence promise

Ferryman’s promise is essentially: "Post once, distribute everywhere." Your version should be equally crisp.

If you need three sentences, you do not understand the core job yet.

Step 3: Build the smallest reliable automation

Early users forgive missing features. They do not forgive broken trust.

If your tool touches distribution, scheduling, or payments, reliability is the feature.

Step 4: Charge earlier than you think

Charging does two things:

Filters for real users with real pain
Funds the unglamorous work (support, fixes, infrastructure)

Kevin even offered a low-friction entry point (a basic plan promo). You can do the same while still respecting your product’s value.

What creators should take from Ferryman

Even if you never build software, Kevin’s post is a reminder that content itself is an operations problem.

If you publish on multiple platforms, your bottleneck is often not ideas. It is distribution consistency.

Automating the boring parts frees you up for:

writing better
engaging with replies
iterating on what performs
building an email list

And if you do decide to build a tool, creator workflows are full of "30 minutes a day" problems hiding in plain sight.

Closing thought: you do not need a perfect plan to start

Kevin’s story resonates because it acknowledges the fear without romanticizing it. Not every bet pays off. But the bigger risk is never placing one, especially when you have identified a real, recurring pain.

If you are sitting on a problem you live every day, you might not need a grand plan. You might just need to start solving it, charge someone for the solution, and let reality steer.

This blog post expands on a viral LinkedIn post by Kevin Naughton, Ex-Google Software Engineer | Try Ferryman (FREE) 👇. View the original LinkedIn post →