I was recently working on a process map that was supposed to be automated by one big workflow. The project was meant to be transformative – one solid automation that would move everything. Two months later it was in a drawer. It was too complicated, it broke with every change to our processes, and on top of that, nobody understood it.
That’s classic waterfall thinking, but in the world of automation. And today I want to flip that idea on its head.
A Lesson from Product
You know how PMs talk about MVPs and iterations? “Instead of one big feature, build something small and check for feedback”. The same works for automation. Instead of trying to automate your entire product discovery flow with one workhorse – build ten small, independent ones.
Take collecting customer feedback. It would be easy to think: “I’ll build one powerful automation that collects feedback, analyzes sentiment, categorizes it, sends it to Google Sheets, posts to Slack, and generates a summary for the report”.
But what happens? If something goes wrong at the sentiment stage – the whole flow breaks. If you change the category structure – you need to rewrite the logic. If OpenAI goes down – nothing gets through.
Instead: ten separate, small, independent automations, each doing one thing – but doing it well.
How This Looks in n8n
I recently analyzed the most frequently used workflows on this platform by product managers. And you know what? Everyone who says “it works” operates on exactly this principle.
First automation: feedback lands in Google Sheets. Period.
Second: every new row in Sheets triggers sentiment analysis.
Third: sends a Slack notification if sentiment is negative.
Fourth: weekly, gathers all feedback and sends it to Notion.
Each workflow is 5-10 nodes. Easy to build. Easy to fix. Easy to understand.
And you know what’s the best part? You can work asynchronously. Feedback appears in Sheets a minute after it arrives? No problem. Sentiment doesn’t get analyzed right away? Nothing breaks, because it’s a separate automation.
Specifically: What to Automate for a PM
If you’re working on product discovery, a few small things are worth your attention:
Monitoring Product Hunt – a small workflow that checks every hour what’s new. Sends to Slack. That’s it. This automation takes 15 minutes to put together.
Collecting feature requests – form arrives, request goes to Google Sheets. And that’s all. A separate automation categorizes them. Yet another one, separate, aggregates them weekly and sends the report.
Tracking competitors – one workflow takes screenshots of competitor pages every Friday. A second workflow compares them to the previous week and sends differences to Notion. Two separate processes.
Analyzing sales calls – one automation extracts transcripts. Another analyzes them. A third tags insights. Each does one thing – but does it well.
The Philosophy of Small Pieces
There’s something deeper here. Sometimes I hear PMs say: “but this will be scattered”. Well, of course it will. And that’s a feature, not a bug.
Scattered systems are:
- Easier to debug (something broke? One thing, not ten)
- Easier to scale (want to add a new category? You modify one workflow, not the entire structure)
- Easier to understand (new team member looks at a diagram with 5 nodes, not 50)
- More resilient (if YouTube API breaks, your competitor analysis doesn’t suffer much, because it’s a separate thing)
This is a principle that engineers know as microservices. But we PMs don’t usually think about it when working with automation.
The Problem with Big Plans
There’s always someone who says: “But if everything is scattered, it’ll be a mess”. Of course, if you don’t organize it. But that’s not a problem with small automations. That’s a problem with documentation and process.
Two files:
- Google Doc with a list of all workflows (what it does, when it triggers, who maintains it)
- Tag in n8n:
product-discovery,monitoring,analysis,reporting
Done. Now you have transparency.
When to Start
Don’t wait for the “perfect automation”. Build a workflow for collecting feedback today. It’ll take 30 minutes. Tomorrow add a second one for analysis. In a week you’ll have a system that actually works, instead of one hybrid monolith sitting on the shelf.
Will it be imperfect? Yes. Will it be scattered? Yes. Will it work? Also yes.
And that’s what matters for a product manager – things that work, that you can change without apocalypse, and that actually save time in discovery work.
Instead of one big dream about automation, take ten small wins.