All episodes

Developer Marketing at a startup with Zivit Katz from Zigi

Before writing a word of Zigi's messaging, Zivit Katz interviewed 50 developers who had never heard of the product, asking just three questions — including what they'd want an assistant sitting next to them all day to take off their plate. The answer that reshaped everything: developers don't want help with "tasks," they want relief from cognitive overload.

Jack Bridger
Episode 2419:11

Zivit Katz is VP of Marketing at Zigi, an AI-powered assistant that handles developers' non-coding, day-to-day busywork directly from Slack.

We get into the three-question interview script she ran with 50 non-users before writing any messaging, why she disagrees with the common dev-marketing advice to lead with a blunt 'here's what we do,' and the four questions she thinks every dev tool needs to answer about its market position before writing a single word of copy.

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.

What's it actually been like heading up marketing at Zigi from the very beginning?

Joining a founding team at the earliest stage is genuinely the most exciting part for me, and very different from joining an already-established company or team — building from zero is where I feel most comfortable. As Zigi's first marketing hire, I'm responsible for crafting the messaging and story, creating its persona, tone of voice, and visual identity — the brand around Zigi. I think that's the first and most critical stage, well before you start thinking about how to drive leads or traffic to the website.

How did you actually go about understanding the market and users before writing any of that messaging?

It's critical to take real time to understand your market and users properly — it sounds trivial, but I take identifying with users' actual problems, in their own words, very seriously. Zigi offers hands-on help with developers' day-to-day tasks, instead of the more common approach of measuring developer output through manager-facing dashboards. Figuring out how to position that took real time. I read everything I could — social posts, community conversations, articles — but the most critical part was a series of interviews with around 50 developers who were not Zigi users, reached through my own network and referrals. I've started calling myself the 'Developer Whisperer,' because understanding developers as deeply as possible became my main goal, and I still make sure to talk to at least one developer every single day.

What did those 50 interviews actually consist of?

Just three questions: what do you like about being a developer, what do you not like about being a developer, and if you could have an assistant sit next to you all day, what kind of burden would you want them to take off your plate? Those three questions shaped nearly all of Zigi's messaging. I learned developers see themselves as creators, and code as a creative process. I learned they suffer from what they themselves called 'cognitive overload' and 'context switching' — their own words, not mine. And when asked about an assistant, they said they wanted help with the 'mundane' work — a word I hadn't been using myself until they gave it to me. My goal was that when a developer eventually saw our website or any content we published, they'd nod in genuine recognition.

A lot of dev marketing advice says to lead immediately with 'here's exactly what we do.' You've said you disagree. Why?

Marketing takes real time, and there's a genuine learning curve to building your story — not every dev tool can or should just open with a blunt statement of what it does. There are so many dev tools competing for attention that developers already use dozens of tools daily, so you need a strong enough story to actually be remembered, and a position your company can keep growing into as it inevitably pivots and evolves. It's long-term thinking, not just about generating leads today — though I can say we did eventually see that reflected in strong conversion numbers on our own site too.

What are the practical first steps you'd recommend to figure out that positioning?

Start by talking to your actual or potential users directly, even before they're customers, to learn how they naturally describe their pains and what they love — but underneath that, you need clarity on four specific questions. First: what is your product's actual category — are you a code collaboration tool, an IDE solution, a system of record? You need to define what kind of tool you're telling a story for. Second: who exactly are your users — 'developers' isn't specific enough, since different kinds of developers look for tools in completely different ways.

What's the third and fourth question in that framework?

Third: what is your user's actual intent — meaning, have they ever gone looking for something like what you offer before? For Zigi specifically, I realized there essentially was no existing intent, because developers had never encountered a tool like this helping directly with their day-to-day work — the tools they knew were built for managers, measuring 'velocity' on a dashboard. The only way a developer might have felt something like what Zigi offers before is through an unusually good team lead. Understanding that intent, or lack of it, shapes where you look for users and how you frame your messaging. Fourth: how will users actually get your product — if they can't immediately install and test it themselves, and instead need to add you to an entire organization's systems, building trust and clearly articulating the underlying problem becomes even more important, because you risk disappearing into the pool of tools nobody's ever heard of.

Beyond positioning, what's the other major thing you focused on early?

Social proof — or in plainer terms, developer love. If there's one thing I'd generalize about developers, it's that they trust other developers above almost anything else. Once developers genuinely love your product and identify with the problem you're solving and the brand itself, even if the product is still small and narrowly scoped, they'll share it and talk about it with other developers themselves — and that's the path to real growth.

How do you actually structure a marketing plan at this early stage?

I always start with an empty deck that sets the ground rules for how I'm going to work, refining or rebuilding it every few months as the company evolves. When I joined Zigi, it took about a month to build, starting from those interviews with non-users approaching the product as a completely blank page. The deck starts with a short, clear statement of who we are, the three main benefits, and the specific pain we solve. Then comes the bucket segmentation — where does the product actually sit: code collaboration, system of record, a BI or predictive tool, an integration layer — and mapping out the developer's existing environment and where we naturally fit into their day.

How did that process translate into Zigi's actual brand identity?

Once the plan was set, branding came next — for Zigi, we distilled it into three words: gets you, gets things done, and sets you free. Every branding decision was built around reinforcing those specific values, with real attention to how strong and memorable the brand needed to be. You need to remember, as a startup, you're not just describing an existing brand — you're taking the very first baby steps of one, and it needs to be strong enough to be remembered and to leave room for the company to grow and pivot into over the following years.

Keep listening