Need suggestions on how to go to market for an accounts payable reconciliation app for Indian businesses. Target would be businesses dealing with at least 50+ vendors for it to actually qualify as a problem within their organization
It has been a bit of a slow start as of now. Only been able to reach out through WhatsApp. Not sure if we should start investing in performance marketing.
GTM IS DEAD. Your $150k GTM Engineer title is a scam and the bubble is about to burst.
This bubble is gonna burst harder than Prompt Engineer and Growth Hacker did.
You guys are NOT engineers. You are Zapier janitors connecting Apollo to Clay to HubSpot and calling it "architecture".
Everyone saw a salary screenshot on LinkedIn and now thinks they are technical.
Stop chasing titles. You don't know business.
Learn the boring stuff first:
SALES. Real sales. How to take 80 NOs on a cold call without crying. Not how to write a sequence in Lemlist.
MATHS. CAC, LTV, payback, margin, unit economics. The actual business math.
PROCESS. How a sales process actually works from lead to cash, not just how to enrich a lead.
If your entire skill is "I know Clay", AI will replace you in 6 months. If you know how to sell and how business makes money, you'll survive.
If you want to be a real GTM, learn GTM = Go-To-Market = how to take something to market and make it profitable. It's not a tool stack.
Rant over.
I understand the basic flow: product → ICP → prospects → outreach → calls → close.
But what does this actually look like at 0 → 1?
The general suggestions around this is usually a lot of expensive GTM tools which frankly i dont think i need at this point of time.
Would love to hear more on what tools people currently at my stage are using to land their first customers
Build to learn, buy to scale.
I still buy tools. I like good tools. But I want to know what I am buying them for.
A lot of GTM stacks are purchased before the workflow is understood, so the tool becomes the strategy. That is how you end up with expensive dashboards and no motion.
Test before you invest.
Hand-roll the ugly version. Run it for one client. See what matters. Then buy or build the part that deserves to scale.
UIs used to block most operators from the underlying system. Now you can direct the build in plain English and inspect the outputs.
You still need taste and judgment to spot when the agent is making things up, when the map is fake-useful, and when the board would actually make a prospect say, "yeah, this is how our GTM should run."
You can run the experiment yourself before turning it into a real internal tool.
Miro is programmable. Docs are programmable. Proposals are programmable.
CRM updates are programmable. Even the handoff from "this person is interested" to "here is the first version of their operating system" can be programmed enough to learn from.
So how does this work in practice you might ask.
The proposal alone is a weak sales artifact because it asks someone to judge a promise.
A working map is better.
Before the pitch gets formal, build a rough version of the client's GTM operating system.
For me that means a Miro board showing lead sources flowing into a database, enrichment, CRM, outreach, content, and measurement.
It can be ugly. It just needs to make the client point at the screen and say "this part is wrong" or "this is exactly the mess."
The useful version also has the week-one checklist, stack doc, API access doc, roadmap, and proposal/agreement generated from the same source.
DocuSeal is interesting here because the signature layer can be another programmable step. Same with open source proposal generators. Same with Miro. Same with docs.
The more I use Claude Code, the more I think GTM builders should treat tools like programmable surfaces.
Miro is a canvas API. Docs are a document API. DocuSeal is a signing workflow. HubSpot is a data model with a UI on top.
Start by programming the workflow once instead of buying the finished system.
Put the client info in a small JSON file: known stack, unknowns, owners, campaign type, current bottlenecks.
Claude Code reads it, creates the Miro board, fills the docs, marks missing fields as NEEDS INPUT, screenshots the board, and tells you what looks broken.
That creates a different first call.
Instead of "here is what we can do for you," it becomes "here is how I think your GTM system currently works. Fix my map."
Better feedback and trust during scoping.
testing out Deep Line over the weekend, hearing great things. Just connected it to Codex. Looking good. We'll have more updates
capping with a question to you guys.
you see building as also a learning experience or buy or die?
catch chapter 17 here https://github.com/shawnla90/gtm-coding-agent/blob/main/chapters/17-client-onboarding-miro-boards.md
Shawn Tenam co founder and CEO @ clearbox "your reddit opportunity inbox"
Hey everyone, I built Linki a few months ago as a free self-hosted alternative to Waalaxy and Lemlist. Back then it was a basic LinkedIn sequencer. I just shipped a huge update and it's now a proper AI SDR, so wanted to share what changed.
What is Linki (for those who don't know)
Self-hosted LinkedIn automation + cold email with an AI agent that writes every message for each lead individually. No SaaS middleman, no per-seat pricing, your data stays on your machine. You connect any model via OpenRouter (Claude, GPT-4o, Mistral, whatever).
What's new in this version
The AI agent is now the center of everything. There's a 3-layer prompt system: global context about your business and offer, campaign-level instructions, then per-step prompts. The agent writes with full context instead of just filling a template.
LinkedIn + email in the same campaign now. So you can do visit, connect, wait 2 days, send a LinkedIn message, wait 3 days, send a cold email. All in one sequence.
Unified inbox. All email replies from all your campaigns show up in one place. LinkedIn reply detection too.
Apollo enrichment built in. Connect your Apollo key, click enrich on any list, get verified emails and company data.
Big reliability improvement on the LinkedIn automation itself. Rewrote the DOM targeting and message delivery, about 63% improvement in connection reliability. Also added randomized pacing on imports to avoid bot detection.
AI cost tracking. Every generation is logged with model, token count, and cost. You always know what you're spending.
Hosting
Docker compose or manual Node.js. Or one-click on Opsily if you don't want to deal with the terminal. SQLite, no external DB needed.
Repo: github.com/moaljumaa/linki
Enjoy!!
I'm researching a problem I keep seeing: GTM teams juggle tools like Apollo, Clay, LinkedIn Sales Navigator, Crunchbase, Smartlead/Instantly, and Make/n8n across different stages of outbound. While each tool is great individually, the overall workflow feels fragmented and difficult to manage.
I'm exploring an AI GTM Operating System that sits on top of these tools as an orchestration layer—allowing teams to manage the complete outbound workflow, unified inbox, AI-powered reply handling, and meeting booking from one place without replacing their existing stack.
Since you've built GTM systems at scale, I'd really value your perspective:
Just validating whether this is a problem worth solving. Even a brief reply would be hugely appreciated.
I’m considering a Product GTM role at an early cross border payments company and I’m trying to figure out where I’d focus first.
They have:
• Virtual accounts
• Stablecoin powered pay in and payout rails
• FX, OTC and embedded payment APIs
• 30 plus currencies, with strong Asian and emerging market coverage
A few verticals I’m thinking:
1. Trade, sourcing and logistics
Supplier payments, collections, FX, reconciliation
2. Specialist workforce platforms
International staffing, nurses, BPO, contractor networks
3. Student mobility and newcomers
Education agencies, migration and relocation platforms
4. Travel intermediaries
OTAs, wholesalers and tour operators
I’m intentionally looking beyond the more obvious fintech customers. My instinct is also to avoid major airlines, property and very high risk sectors at the start.
Would love feedback on:
• Are these the right places to look, or is there a much better vertical I’m missing?
• If you were trying to find a repeatable GTM wedge for this kind of product, how would you go about it?
I’ve been building a GTM Strategy system designed to go beyond the usual “define your ICP and post on LinkedIn” AI advice.
It takes context about your startup and works through positioning, ideal customers, acquisition channels, messaging, launch strategy, and an actionable GTM plan.
Before I turn it into a paid product, I want to test it with 10 real founders.
What you get:
→ A GTM strategy built specifically around your startup
→ ICP + positioning recommendations
→ Recommended acquisition channels
→ Messaging and launch approach
→ Prioritized actions for getting your first/next customers
Cost: Free.
What I need in return is honest feedback: what was useful, what was generic, what was wrong, and what you’d actually implement.
If you’re building or planning to build something right now and want to participate, comment “GTM” or DM me.
First 10 founders only.
I'm researching a problem I keep seeing: GTM teams juggle tools like Apollo, Clay, LinkedIn Sales Navigator, Crunchbase, Smartlead/Instantly, and Make/n8n across different stages of outbound. While each tool is great individually, the overall workflow feels fragmented and difficult to manage.
I'm exploring an AI GTM Operating System that sits on top of these tools as an orchestration layer—allowing teams to manage the complete outbound workflow, unified inbox, AI-powered reply handling, and meeting booking from one place without replacing their existing stack.
Since you've built GTM systems at scale, I'd really value your perspective:
Just validating whether this is a problem worth solving. Even a brief reply would be hugely appreciated.
I've been following the growth of GTM Engineering, and something keeps bothering me.
The stack is becoming seriously capable.
Signals, enrichment, research, scoring, automation, outreach, CRM workflows, analytics - people are connecting all of this together and building GTM infrastructure that would have required a software team not that long ago.
It's becoming sophisticated enough that GTM Engineering is now emerging as a profession in its own right.
But I don't see nearly as much discussion about what happens when this moves beyond one person.
If two GTM Engineers join the same company, can they both improve the same GTM infrastructure?
Do they divide ownership of different parts of the stack?
Can one understand, maintain and improve what the other has built?
Or do we eventually end up with two very capable people running two slightly different GTM stacks, with context, prompts, workflows and logic accumulating separately?
Curious how teams with multiple GTM Engineers are handling this today.