2
8 Comments

Automation exposed a new bottleneck: deciding what to ship next

I recently looked at a founder’s shift from manual campaign work to a more automated acquisition flow.

The surprising lesson wasn’t that automation increased output. It was that output became easier than decision-making.

Before automation, the bottleneck was execution: writing, launching, following up, repeating. After automation, the harder question became:

“When is a buyer objection or risk signal strong enough to justify creating the next asset?”

For example, do you wait until:

  • the same objection appears in multiple sales calls?
  • a campaign gets clicks but no qualified replies?
  • prospects ask for proof, pricing clarity, integrations, or comparisons?
  • one asset consistently reduces friction before demo/signup?

I’m curious how other builders handle this.

When do you decide that buyer risk has been reduced enough, or surfaced clearly enough, to turn it into the next landing page, email, comparison page, case study, or ad?

on July 6, 2026
  1. 1

    "same objection in multiple sales calls" is a strong signal — that's when it stops being anecdote and becomes a playbook gap.

    curious: are you on those calls yourself, or reviewing recordings after? changes what you'd fix first (live moment vs post-call process).

  2. 1

    I like the shift from asking "what can we automate?" to "what deserves to exist?"

    Automation makes creating assets cheaper, but it doesn't make deciding which ones actually reduce uncertainty any easier. That decision process can become the real competitive advantage once execution is no longer the bottleneck.

    1. 1

      I like this framing.

      Automation makes asset creation cheaper, but it doesn’t answer the harder question: which asset actually reduces buyer uncertainty?

      Once execution stops being the bottleneck, judgment becomes the bottleneck.

      1. 1

        Interesting.

        Your reply made me think less about the assets themselves and more about what happens once judgment becomes the scarce resource instead of execution.

        I don't think I can explain where that line of reasoning leads properly in a thread without oversimplifying it.

        If you're interested, what's the best email to reach you on?

        1. 1

          Thanks! That sounds like a fascinating topic.
          Honestly, I'd love to have this conversation right here in the thread if you're open to it. I think the whole IndieHackers community would greatly benefit from reading your thoughts on "judgment vs execution," even if it has to be a bit simplified. What do you think?

          1. 1

            Happy to share the rough version.

            My intuition is that once execution becomes cheap, the bottleneck doesn't simply become judgment.

            It becomes deciding which judgments deserve to shape the business in the first place.

            That's a much bigger shift than it sounds, and I don't think I can do the full reasoning justice in a few paragraphs. But that's the direction your comment made me think about.

            1. 1

              I think there are two different kinds of production: one that requires creating a large volume of output, and another that requires a smaller amount of highly polished work.

              The former is about producing enough variations to narrow things down through processes like A/B testing. The latter is closer to branding—it reflects the distinct taste, perspective, and attention to detail of the person or company behind it.

              With my product, I place particular emphasis on the planning stage, because that is where the brand’s identity and core strengths are first defined and refined. Once that foundation is in place, whether the work should be produced at scale depends largely on the medium or channel.

              My product primarily supports the first category: large-scale production and iteration. However, because the quality of the planning is so important, we do a significant amount of research before production begins.

              My general view is that, once the upstream strategy and planning have been properly reviewed and approved, the downstream execution should require relatively little additional approval.

              1. 1

                Good question. In my case it’s PLG, so I’m not really on sales calls and I’m not reviewing call recordings.

                The equivalent signal for us is when the same friction shows up repeatedly in user behavior, onboarding drop-offs, support messages, or signup/demo flow confusion.

                So I think the first fix is less about improving a live sales moment, and more about building a better feedback loop: tag repeated friction, decide whether it belongs in the product, onboarding, docs, pricing page, comparison page, or proof asset, then see if it reduces the drop-off.

  3. 1

    This comment was deleted 2 months ago