From Product Code to GTM Engineering

Since October I have been working as our GTM engineer. I still write code for the platform, so I haven’t left the product, but a big part of my week is somewhere else now. In practice that means I work with the sales team on the CRM and on everything that happens between someone hearing about us and someone signing.

Knocking on doors

From the start I wanted context for everything I built. My lead could tell me what to do, and that was fine, but I also wanted to know who it was for and why the business needed it. I wanted to understand how the company actually works: who we sell to, what we help them with and how we bring them value.

I wanted to improve the product, and the same two questions kept coming up. Who is this for? How will it help them? To answer them I kept knocking on doors, and more often than not the answers were in sales. In a team this small, the people who know how customers use the product are a few desks away. I’d ask them what they needed from the platform, or why a deal had stalled. Nobody asked me to do it. It just seemed like the best way to know whether my code was helping anyone.

At some point I started to see that a lot of what the company needed was on the commercial side, and a couple of weeks before October those conversations turned into an offer to work with them on the CRM as a GTM engineer. Saying yes was easy. Connecting the code I write with the business it’s supposed to help is pretty much what I’d been trying to do on my own anyway.

What sales taught me about being a dev

Being a developer is solving problems for users, and users want whatever they came to do to be as easy as possible. So the easiest path through the product should be the one that solves the problem you’re building for. If the thing you want people to do is buried three screens deep, they won’t do it, however well it’s built.

You also have to assume people need a lot of clarity. They don’t know the product the way you do, and they shouldn’t have to. Every screen should make it obvious what to do next and why it’s worth doing, and if using it doesn’t give them something back, they’ll stop.

None of that is new. It’s easy to agree with, and much harder to keep in mind when you’re deep in a component. Sales sees it every day, because they’re the ones explaining the product to people who have never seen it, and listening to them made it a lot less abstract for me.

What the company needs over what I enjoy

I like code. I like cleaning things up and slowly turning a component nobody wants to touch into something you can read. I wrote about that in my six months post, and I still enjoy it.

What I’m after, though, is to be part of a story. I want to work at a company that grows and scales, and to be there while things go well. It matters to me that this one can save costs and improve people’s quality of life, so I want it to get there. If that’s the goal, my time should go where it moves the company forward, and right now a lot of that is on the commercial side. Some weeks that means less time in the editor, and I’m fine with that.

Learning who the customer is

Part of the new job has been going to conferences in different parts of the country. I go there to learn who our customers are, what kind of people we end up talking to, how deals actually get made, how we sell the product and what people get out of it.

In the codebase I see how features work. At a conference I hear how someone describes the problem before they know we exist, and which part of what we do makes them stop and ask more. That’s something I was never going to get from reading code, and it feeds straight back into how I think about the platform.

Studying the pipeline

When you join something that already runs, the first job is understanding it. The sales process works and the people in it know it well. What I wanted to find out was why it works when it works.

So the most engineer thing I’ve done so far is a historical study of our pipeline. I went back through our deals and traced each one from the first contact: where the lead came from, what kind of company it was, when we reached out, how long each stage took, and what happened right before it moved forward or stalled. Then I did the same with the ones we lost, to see what has worked, what hasn’t, and which kind of customer we have the most success with.

Now we’re building a campaign to reach more of the customers who look like the ones that already work for us. Before we judge it, we need to agree on what “working” means and measure it, so we can check our ideas against real numbers instead of gut feeling (mine included). It’s early, and I’ll write about the results once there are some.

Same habit, different codebase

This feels a lot like my first weeks on the product. Back then most of the work was reading and asking “why the hell is this here?” before touching anything. The pipeline is the same exercise with deals instead of components. Every field and stage has a reason behind it, and the work is finding that reason before deciding anything.

That’s the plan, really: treat the pipeline the way I’d treat a codebase. Understand how it works before touching it, measure it, find where it can get better, change one thing and check whether it helped. It’s the only way I know how to work, and so far it fits the job pretty well.