B2C vs B2D - marketing to developers with Ronak Ganatra
Ronak Ganatra's first marketing campaign at Hygraph was a Halloween discount banner — a B2C tactic that had worked fine at his previous VPN company. It generated zero revenue and drove 40% of subscribers to unsubscribe in a single weekend. That failure is what sent him to sit down with the DevRel team and actually learn GraphQL.
Ronak Ganatra is director of marketing at Lano and previously VP of marketing at Hygraph (formerly GraphCMS), a headless content platform, and founder of the Marketing to Dev community.
We get into the disastrous first campaign that forced him to unlearn B2C marketing instincts, why he thinks understanding a technical product yourself is what lets you pitch it honestly rather than dishonestly, how to feel confident in content marketing when performance metrics are unreliable due to ad blockers, and the very different ways DevRel, growth, and product marketing each actually work with a sales team.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
You joined Hygraph, then called GraphCMS, straight from B2C marketing at a VPN company. What was the transition actually like?
I got interested in the idea of a content API and omnichannel content delivery from working next door to Contentful's office while at Zenmate, where we used WordPress and PimCore. When I joined GraphCMS, we were a small team of 15-18 people with only two or three people doing developer relations and advocacy, so a lot of the early marketing work was foundational — SEO, CRM, figuring out channel mix. I had zero experience marketing to developers or working with a technical product like this.
You've described a specific early mistake that reshaped how you approached the role. What happened?
About a month in, coming from B2C's much faster feedback loops, I decided our numbers could be better and pitched my boss on a Halloween discount campaign — the kind of seasonal push that had worked fine at my old company. We launched it on a Friday without consulting engineering or getting any developer perspective on it — banners, a pop-up, a newsletter blast, the whole package. We came back Monday to almost 40% of our subscriber base unsubscribing, a huge backlog of Intercom messages telling us to leave them alone, and zero dollars in new MRR — not one person redeemed the offer. That's when we sat down and realized we genuinely needed to understand developer marketing and the developer mindset from the ground up.
How did you actually go about learning that, given you weren't a developer yourself?
I sat down with our DevRel team, who were genuinely patient in walking me through what developers actually value — companies like Stripe as the gold standard for content and documentation quality, why developers care about visual and documentation aesthetics, and the fact that they actually read documentation carefully, which as a consumer marketer I'd naively assumed nobody really did. They walked me through the basics of working with our API, writing GraphQL queries, and what happens on a Gatsby front end when you change a GraphQL schema's structure. That foundation is what let me genuinely improve how I approached marketing at GraphCMS — shifting toward SEO, quality over quantity in content, real attention to the site's visual design language, and community engagement and events, rather than any more seasonal discount campaigns.
You've said learning GraphQL yourself made you a better developer marketer. What do you mean by that concretely?
At a basic level, if I'm selling you something, I should make the effort to speak in terms you actually understand. A lot of developer marketing advice just says 'skip the fluff,' which is true but vague — what actually counts as fluff comes down to genuinely understanding how developers communicate. If I'm selling a GraphQL API's flexibility with something like Next.js, I need to actually know what I'm talking about. I'm not going to write an entire open-source example for someone, but I can honestly say our GraphQL API and a Next.js front end work well together, your marketing team gets to query content easily, and point them to the docs to figure out the rest. Understanding the technical context behind why developers choose certain tools makes the job easier, but it also makes you feel genuinely honest pitching the product, rather than papering over gaps in your own understanding.
Moving away from performance marketing makes measurement harder. How did you approach proving impact without that quick feedback loop?
As marketers we're always chasing dashboards and numbers, but a lot of developers use ad blockers, so we constantly questioned how much we could actually trust that data. We decided to assume our traffic numbers might be significantly undercounted, and instead started from what we already knew developers value — well-written documentation, good guides, working reference examples — and built a strategy around producing genuinely high-quality content, accepting that not everything would be cleanly measurable, and being okay with that.
If you can't cleanly measure it, how did you know the content strategy was actually working?
We looked at softer signals — are people in the community talking about a piece of content when we share it, is someone finding us organically through SEO or social and signing up, or even someone mentioning in a support chat that they'd been following a specific guide and got stuck. Those all have a much longer feedback loop, sometimes six months or more. One clear example: our sales team was deep into a conversation with a prospect who'd been evaluating us for weeks, and when they finally asked how the prospect first heard about us, the answer was that they'd been considering Svelte, a relatively new framework with little content around it at the time, and came across an example we'd published showing an interesting approach to structuring a GraphQL schema with it. They'd never clicked an ad or attended one of our events — that kind of validation, impossible to capture on a dashboard, was a much stronger signal that the content strategy was genuinely working.
How should developer marketing teams actually structure their relationship with sales?
It depends heavily on the product — Hygraph was freemium, so sales was only involved on the enterprise side. I saw our marketing team split into three pillars, each relating to sales differently. Product marketing worked closely and continuously with sales, translating new product capabilities into commercial value propositions sales could use directly in conversations, and creating a feedback loop back into product based on what prospects actually needed. Partner marketing worked directly with the partnerships team on co-marketing with ecosystem partners like Vercel or Cloudinary — webinars, case studies, that kind of joint content. Growth, meaning demand generation, SEO, and CRM, had the tightest, most regular feedback loop with sales — understanding which target accounts to pursue in ABM campaigns, which ad campaigns were converting into real pipeline, and where leads were dropping off so content could be adjusted to address that specific weak point.
Where does DevRel fit into that structure relative to sales?
That's the genuinely tricky one — nobody quite agrees on what DevRel does or how to measure it, but everyone has an opinion. At one point we thought, since DevRel understands the product inside out, they could help sales close big enterprise deals by digging into a prospect's specific technical problems. That worked for a while, but eventually so much of DevRel's time was going into product demos for sales that we collectively decided it wasn't the best use of that resource, and sales needed its own dedicated technical support instead. Unlike product marketing or growth, DevRel and sales never settled into a clean, sustainable one-to-one working relationship for us. What matters more broadly is that marketing and sales stay genuinely aligned, especially with a paid or enterprise tier — not just through regular sync meetings, but by identifying the specific stakeholders on each side who should actually be collaborating operationally, rather than treating alignment as a scheduled check-in.