Do product marketers need to learn to code now?

Marketing is communication, and the medium that makes a message land across a distributed team has become a small piece of software. A PMM writing code is not a PMM with a hobby. It is the same job in the current medium.

How do you know whether an internal tool is worth building?

Ask whether it multiplies your time after it ships. A tool that turns hours of manual work into zero, permanently, multiplies. Rebuilding something you already own and pay for does not, however satisfying it is to make.

What kinds of tools should a marketing team build?

The ones that solve repetitive coordination problems: the thing you explain over and over, the process you run by hand at 11pm, the workflow that requires clicking through four different services. Tools that integrate APIs, preserve state, and keep everyone on the same message.

Why build an app instead of writing a document or a deck?

A deck degrades the moment it closes, because people remember the gist rather than the language, and the gist is where alignment falls apart. An app serves the same framing to the last person who opens it as it did to the first.

What should a marketer build first?

Pick one annoying, repetitive coordination problem and build the small version. You do not need to be a real developer. The thinking still has to be yours; what collapsed is the distance between having the idea and having the working thing.

Why PMMs are coders now

In the past year, I built three tools that are essential for how we run product marketing in our company. One makes Customer.io easier to use. One makes it easy for us to run meetups. One manages our annual offsite. Nobody asked me to build them. I knew I had to get the job done, and building a tool was a lot easier than working around the myriad of other SaaS tools we have at our disposal.

Marketing is communication and nothing else

Marketing is about communication. It's about listening to what product is building and carrying it to customers. It's about listening to what support is hearing and folding it back into product. It's about listening to what customers have to say and making sure that we're paying attention to it. That's the job.

For 30 years, I've asked myself one question: How do I make the message land? Over that time, the tools have changed, but the question has not.

That's where code comes in.

The ringleader does not juggle

I've always said that the product marketer is "the ringleader of the circus." Not in charge, not the star. The one who points the spotlight and makes sure the juggler and the trapeze artist and the lion tamer are telling the same story to the same crowd at the same moment.

Inherent in all that is communication. I used to do that with documents, decks, meetings, and a lot of repeating myself. But now we have a new tool in our arsenal: software.

Three things I built

The three tools I built are worth talking about:

An application that helps us manage our offsite. As a remote-first company, being together once a year is one of the most important communication moments we get. This app not only helps the entire team coordinate the agenda, the goals, and the key priorities for the event, but it also makes logistics a lot easier for the people team.
A tool for Customer.io. Customer.io is a phenomenal product, but it's missing numerous features. I built a command-line tool in Python that helps us use Customer.io to its fullest. It uses the Customer.io API, and it saves a substantial amount of time.
A meetup application. It helps our field marketing team coordinate the logistics of running multiple meetups around the world. A community program with no structure is a pile of well-meaning people doing slightly different things in slightly different cities, drifting away from the message. The meetup tool I created not only helps with the logistics, but it also helps organizers (who are not employees) understand the core messages of Supabase and repeat them.

These tools not only help with logistics and save time but also improve communication across the organization, within the marketing team, and with our customers. We could use static tools like documents or slide decks to coordinate these things, but the problem is that those tools degrade. Code allows us to integrate with external APIs, preserve state, and create workflows that reduce effort, improve accuracy, and help the team stay on top of deliverables.

The rule that decides whether to build it

Those are the tools I did build, but there are a bunch of tools that I didn't build. Being able to discern when one thing is worth it versus not is important.

The test I always use is: Does this thing multiply your time after it ships? A meetup tool helps us schedule and manage meetups and saves us clicking through four or five different sites just to coordinate everything. Now I have one form that fans out API calls to several tools and keeps everything and everyone in the organization on the same page.

In my personal life, I've also built several tools that made absolutely no sense. In one blog post, I talked about building my own version of Granola. That was a dumb idea. The tools I built didn't improve on the tools I could have used off the shelf in any way, shape, or form. I wasted time and energy for no actual gain in either.

Nothing is not my problem

The other rule I live by is "nothing is not my problem."

This concept has served me extremely well throughout my career. I've always believed that in the absence of leadership, any leadership will do. When you are faced with a number of seemingly insurmountable problems, if you're the person who goes heads down and solves them, you end up controlling a lot of your own career destiny.

It's not exactly my job to build internal tools to help make marketing a lot easier, but it is my job to communicate more effectively. It is my job to keep my team as productive and as happy as possible. Going heads down and building software tools, when I have both the ability and the means to do so, helps improve the organization overall.

One of the most impressive statements I've heard Supabase CEO Paul Copplestone say is: "Companies are just people and processes."

When you codify processes and build tools, you are helping to maximize the output of all your people.

Seen from that angle, going heads down to build a bunch of internal software tools is a very good use of time.

What to do about it

Another thing I always say is that I value innovation over tradition. Tradition says that complex events should be managed with spreadsheets. Innovation says that we should lean into everything amazing Notion has been doing over the last 18 months. Tradition says that competitive battlecards should look like static documents. Innovation says that competitive battlecards should be ChatGPT applications that give people answers while they're on a phone call.

Lean into the power of coding. Lean into how easy AI coding agents have made coding. Lean into the ability you now possess to build tools that can make you immediately more productive in ways you never could have imagined before.

Coding is destiny. Control yours.