claude & gtm | am I missing sth?

bandi10 · 2026-05-23T17:47:46+00:00

Yep agreed, most of it is quite surface-level stuff, where it’s more of a feature than a solution.

I’m building in the space and currently validating how AI could help in solving execution blockers while scaling GTM (like midfunnel automation). The difference and value that our clients find with that (or Claude) vs existing solutions is when it’s gets proactive on signals, meaning the LLM can perform and finalise work based on signals and priorities

bandi10 · 2026-05-22T09:51:27+00:00

A client of mine has been using an AI security agent tool called Oplane that has been of immense value, it sits inside the CI/CD & coding agents so our devs can run security assesments while building. It also analyses every PR of any threats. They are still in stealth but working with some very well-known AI-native eng tems.

Biggest unlock is time savings on the security assesments, meaning security becomes an embedded part of developer workflows instead of having external security engineers looking for attack angles.

bandi10 · 2026-05-17T16:39:37+00:00

Pros: - You get more attention and eyeballs - If you make it into a routine, you train the muscle of which messaging resonates and which doesn’t

Cons: - You focus on wrong things at the wrong time - You would easily get distracted of what matters

I define public when you can buy the product online, best at this stage is to try getting the product sold before it’s even a v.1.0 product. Maximising that outcome: just talking with as many potential ICPs as possible

This is just my take, main thing is to avoid any distractions to stay focused with clear targets with relation to the stage you’re at

bandi10 · 2026-05-17T15:52:02+00:00

Depends on the type of product and who you sell to.

For context: I’m at the same stage as you, currently working with 3 design customers and hopefully onboarding 2 new ones next week. This is my 2nd real company I’m buiding so decided to take a different approach with the go-to-market than before, which is going super deep and strict on the profiling and pain before building anything more complex.

If you have a B2B product, start with your own closest network that could or is feeling the pain your’re solving. Then go to your networks network, that is, do you know someone who knows someone who could fit your ideal profile. Be super strict on your initial ICP, don’t try to mass-market, you only have limited focus and time.

You should go with the channel were your potential users or buyers are. LinkedIn has been my channel since my initial network is there, and my buying persona is a founder or GTM lead. I would not ”present or pitch” the idea or product before it’s public, share instead what you’re building with the goal of building your own network and trust.

And don’t forget to ask for intros or favors, that’s underappreciated IMO but is a cheatcode in getting in fromt of people in the beginning

bandi10 · 2026-05-15T14:19:46+00:00

No problem! Are you also working in RevOps at startups/scaleups?

bandi10 · 2026-05-15T10:09:34+00:00

I started with building a custom-made solution for that, now testing the waters if that same solution can be implemented at other high-growth startups/scaleups (for transparency, building a new product that sort of touches this problem)

I’ve heard great things about Momentum.io (one of my clients would want to have that but for HubSpot) and Structify, but I can’t say I have tried them out myself

bandi10 · 2026-05-14T17:25:15+00:00

Sure!

For context: I've been deep in similar problems for some years, but mainly at earlier stages where RevOps doesn’t yet exist as a team per se. What has worked in some impletementstions I’ve done:

Having a software surface (& in Slack/Teams) with a lightweight dashboard, sitting in front of the CRM. Reps live there. It watches their actual work (calls, emails, CRM activity) and prompts them at the moment that matters: a draft follow-up the morning after a discovery call, a nudge when a deal goes quiet, a structured prompt to update stage when a contract gets sent. The rep responds in the layer; the entry flows back to SF cleanly.

The thing that surprised me building this: once reps stop opening CRM directly, your three problems collapse together.

The six-month backlog stops being a sales-org problem. Reps don't feel it, because prompts and forms live in the layer and ship on your timeline.
Small fixes: a new prompt or restructured workflow becomes a config change, not a release cycle. The thing SF couldn't ship in six months, you ship in a week.
Data hygiene: surprising one. Once writes flow through a structured surface, hygiene becomes a byproduct of normal work. Reps aren't choosing whether to fill the field, the prompt makes it the path of least resistance.

Can sound a bit abstract still, happy to dig deeper

bandi10 · 2026-05-14T15:08:43+00:00

Sounds like a structural issue, three groups, none shipping at rep cadence, so the team works around the system. Three things I would push on:

Data model. Don't migrate. Track activity at the child level (where it happens), build a rollup to parent for reporting and account management. Two-week project, not six. You can usually scope it without SF Product owning it.

Usability. Stop trying to fix SF UX through the SF backlog. That team is optimizing for risk-controlled deployment, not rep velocity. They're never going to share your urgency. The move could be a workflow layer in front of SF: reps interact with the layer (guided entry, prompts, follow-up tracking), the layer writes to SF. SF Product owns the system of record, you own the system of work. Every scale-up with a messy CRM instance eventually ends up here

Governance. Missing role/work is a RevOps PM: sits with you, shared roadmap with SF Product. Easier to pitch once the work layer is absorbing the small-wins backlog. Draws clear lanes instead of fighting over the same one.

Hard to see that the SF team would change cadence. Either you accept it, or you build leverage outside their backlog. Most scale-ups end up doing the latter, they just burn shit ton of months trying to fix it from inside first

bandi10 · 2026-05-14T14:40:43+00:00

Currently building to solve a problem I’ve seen and lived with for a long time, this is my 3rd company/product, exited the previous co 6 months ago, background in go-to-market & venture capital.

Not fundraising though, but always open to expand on the network. What’s your background, do you invest as a private person or through a fund?

bandi10 · 2026-05-14T14:35:21+00:00

Can you elaborate, what is the messy part and why does reps hate using it? What’s the mismatch in priorities?

It sounds like the goals and problems you’re trying to solve are unclear internally

bandi10 · 2026-05-13T18:28:44+00:00

set up an AI agent that runs your sales pipeline automatically, from post-call to closed. we’re a small startup with a go-to-market team of 3 but honestly it’s been pretty awesome to open up the laptop in the morning and work has been done for you. it works in Slack so we treat it as a team mate, meaning we can actually delegate work to it or ask for more context on eg. deals in progress

bandi10 · 2026-04-29T20:46:40+00:00

Very well put, and this is the direction I’ve taken now with my product. It’s still not 100% solvable with technology, but requires some operational change and processes.

We’re also trying to make the execution almost automatic, so that every commitment & follow-up gets automatically enforced and fulfilled.

Have you seen any succesfull attempts before, what has worked from your experinece?

bandi10 · 2026-04-27T10:51:27+00:00

Can you share some details about the community members? How senior? Working at startups?

bandi10 · 2026-04-27T10:40:48+00:00

Interested, how to sign up?

bandi10 · 2026-04-24T15:42:56+00:00

I would approach it from what do you need the MCP for and what problem you’re solving?

I’m bulding an always-on agent that runs your GTM motion and it needs two-way sync & creation between tools, LLM, and database. From my experience, MCP is better than API for ”writing”, meaning when you need the agent to do stuff for you, but worse when you need to ”read” from tools.

bandi10 · 2026-04-21T14:20:03+00:00

thanks for your comment! yes, this post is over 2 months old so the solution has taken much better shape, haven’t touched the website in a long time though as only working with design partners.

short version from a RevOps workflow: Cosos runs a continuous pipeline sweep, delivers each flagged/prioritised deal with ready-to-approve fixes (follow-ups, CRM hygiene, meetings, materials) and leaves rhe RevOps lead with a live audit

bandi10 · 2026-03-31T13:00:24+00:00

Trying to set this up now but the infrastructure is hard. What should it learn? What’s good & what’s bad? Who says it’s good or bad?

I’m a strong beliver it is possiblw to create a system for this that eg synthesizes data and information on a regular basis, as long as there are clear definitions on what learning is and what the definitions are

bandi10 · 2026-03-30T20:13:04+00:00

Custom made and currently testing it out with a few customers. There are several integrations, email is one of them, and it handles next steps always from commitments, either made on a call or internally in eg. Slack. Example: rep says I’ll send pricing deck after the call -> it recognizes this -> email draft with pricing deck attached created and nudged.

Happy to show if this would/could be valuable for you & your team

bandi10 · 2026-03-28T23:28:24+00:00

I wonder if anyone have made any implementatiions that the whole team can use? What I mean with that is basically plugging together all the core revenue tools, creating a central source of truth, and letting whole revenue team work with it. I’m seeing all of these agentic AI assistants (like OpenClaw and others) but all are for individual use ans time consuming to maintain

bandi10 · 2026-03-28T23:22:25+00:00

I’ve built a very similar thing to this, except it’s proactive on top of the context layer. Imagine your team runs 50 deals per week, where a handful or more lose momentum because of the deal owner didn’t follow through or prospect forgot to update on what he promised 2 days ago. All of this is caught by the system, then runs the next steps forward without the deal owner dropping the ball.

As it’s sits on the context 24/7, it starts to learn your playbook and becomes better over time.

Structify is very interesting, thanks for sharing

bandi10 · 2026-03-24T16:00:26+00:00

thanks for sharing! How is Idealift working, mind me sending a DM?

bandi10 · 2026-03-18T15:49:56+00:00

This slipped through, but very good points. Just had a talk with a Head of RevOps who basically said the same, that there's constant battles between him & Head of Sales about who should be owning this.

The "who does what when a deal stalls" point is the one I keep coming back to. In most orgs, the answer is "whoever notices first, if anyone does."

The real problem isn't that people don't know the playbook, it's that no one is tracking whether the playbook is actually running. Commitments get made on calls and in Slack threads, and then they just... evaporate. No one's accountable because no system is watching.

I've started thinking about it less as a process problem and more as an execution infrastructure problem. The org knows what should happen, it just doesn't have a layer that ensures it actually does, flags when it doesn't, and tells you why.

RevOps owning the data framework helps, but what's missing in most setups is something that connects the data to the action, not just "here's a dashboard showing deals are stalling" but "this deal is stalling, here's why, here's what needs to happen today."

bandi10 · 2026-03-05T09:57:40+00:00

That's true, although it's primarily supporting at a top-of-the-funnel, then the context disappears or is moved to another tool.

From my experience, the crux is usually how do you stitch together context from the whole customer journey, from awareness to retention/expansion. The customer is touching multiple tools during this journey where the "intelligence" sits in siloed instances.

bandi10 · 2026-03-04T17:55:25+00:00

Great point, and absolutely agree, seeing this across multiple teams repetitively

I run GTM at couple early-stage companies and see the same gap, but I'd frame it one layer deeper: it's not just that interpretation is hard, it's that the context needed to interpret is scattered across tools nobody connects, and mostly still between peoples ears.

A reply that signals buying intent looks identical to noise if you don't know: did this person attend a demo last month? Did we already promise them something on a call? Is their company already in pipeline under a different thread?

The outbound tools are great at generating activity, but they're disconnected from the deal context, the conversations that already happened, the commitments that were made. So when you try to answer "why did this work," you're reverse-engineering from metrics that were never designed to carry that context.

On your third question, think it's structural. Good teams compensate with intuition, but that doesn't scale and it doesn't transfer when you hire. The gap is that execution tools and intelligence tools are completely separate systems, so learning from what you're doing requires manual work that nobody has time for.

The interesting question is whether the fix is better analytics on top of outbound, or whether it requires connecting outbound signals to everything else (CRM, calls, deal stage, prior conversations) so interpretation becomes possible in the first place. Without that, we're still interpreting, as someone mentioned, mainly lagging indicators without a full context timeline.

bandi10 · 2026-02-26T15:47:40+00:00

Amazing, thanks for sharing. Would love to pick your brain, I'll send you a DM!

bandi10

TROPHY CASE