I’m not an engineer. I have a bachelor’s degree in engineering, and my last two job titles were “software engineer,” and at least 50% of my day is spent writing code. But I’m not an engineer.
You’ll have to excuse the pedantic and overly dramatic intro there, but this delineation is one that I care quite a bit about. The term “engineer” just doesn’t feel accurate anymore, given the degree to which I interact with customers. I recently joined an early-stage SaaS startup where roles are loosely defined and titles do not impose insulation from other departments. I attend initial sales demos, customer onboarding meetings, feedback interviews, and support calls. And I absolutely love it.
This isn’t what the vast majority of engineers do, and my engineer friends can hardly relate to the kind of experiences I have with this level of customer interaction. So I’ve come to the conclusion — one that I’m sure disappoints some of my older Indian relatives — that I’m just not an engineer. Fortunately, I wouldn’t have it any other way.
Why I love it
And at last, I see the why
All those days watching from the windows,
All those years outside looking in.
All that time never even knowing,
Just how blind I’ve been.
I find that the brilliant song from Tangled makes for a spot-on explanation of the value of interacting closely with customers: doing so allows me to understand the why of our product (and, in turn, our business). When I’ve worked on engineering teams in the past, I was told — by a product manager, a CTO, or a CEO — why people cared about our product. I had an abstract conception of why they used it, and I relied on my trust in the manager/CTO/CEO to serve as assurance of veracity. Now, I see it firsthand. I see customers’ faces light up when they see our Realtime dashboard, and I see the pain they experience when a feature doesn’t work as expected. Seeing the why is the most powerful motivator I’ve experienced to better the overall customer experience (and in turn, the product).
After all, when you forego a cushy, illustrious big tech job to work in a tiny scrappy startup, this is what you’re in it for — high-octane, high-velocity, passionate growth. Watching customers delight and despair drives me to push hard to get things done day-to-day, and gives an overarching purpose to the work I do. While my purpose in my days as an engineer was high-level and distant, my purpose today is concrete — and it makes waking up on a weekday far more enjoyable.
The challenge and thrill of small-team tech debt
Me and tech debt, we go way back. But our relationship has evolved significantly over time. While I used to shun tech debt and actively fight for the time to settle it (In previous jobs, I’ve been known as both the linting guy and the refactor guy), talking to customers has made me a bit of a tech debt junkie. I now view the tech debt market a bit like r/WallStreetBets views the actual markets — ripe for leveraging. When I talk to a customer and see that they would significantly benefit from something, I often experience shifts in perspective around priorities. I’m excited to hold off on fixing that one part of the React codebase that is styled entirely via inline styles (why??) if it means I can help a customer improve how quickly they can apply a template to schedule their staff for May.
To be clear, I still love refactors and style improvements, and anything that improves the health of the codebase. And I still have to carefully evaluate accruing more tech debt against building a new feature, and there are still times where tech debt has to be repaid and a feature delayed. But, I don’t hate accruing tech debt anymore. Instead, it feels like I’m leveraging tech debt to build out a better experience and realize gains immediately, and I can then repay the debt later.
Kind of like going all-in on GME call options.
Triaging with informed agency
A couple weeks ago, a customer and long-time partner was facing several issues with our product, and pressure was building on us to fix it all. With our small team and my limited experience at Assembled, solving all the issues within a day was unfeasible. So I decided to focus my efforts on triaging, and I did so without middlemen. I got on a call with the customer and asked her to show-and-tell precisely what was causing her the sharpest pain. The discussion brought me to a whole new world of clarity; it was immediately obvious what I had to work on first. Turns out, the most important bug to fix wasn’t the hardest one. So I did the engineering task that followed, and reported back to her. Over the course of the next week, I addressed several of her other issues, but the initial triage is what made the difference. Our key partner is happy to be using us once again, and I have to attribute the success of my triage to the decision to talk to the customer directly, show empathy, and maintain a communication channel. She saw that we cared, and it restored her faith in the product.
Having direct lines of communication with customers allows people like me to triage efficiently. Time isn’t wasted through a support team member, and information isn’t lost or diluted by indirect transfer. It also can mean less work for equivalent customer happiness. There’s a tendency to believe that the most challenging problem has the greatest payoff, but that is rarely true when you’re low on resources in my experience.
Why the business team loves it
I had plans to talk about all the ways that a product-focused culture benefits the business team, and I would have spoken about how it eliminates politics in customer success teams, and how it allows for task prioritization that aligns more closely with customer needs, and I would have talked a bunch about this classic XKCD, but I won’t be doing that here. Talal Naboulsi can do it much better than I can. Follow him (or me) to read that story when he does.
Where this doesn’t work
As a quick aside, I should mention that I doubt my approach works in all product environments. There are cases when you’re working on a deep tech product, where you’re inherently going to be disconnected from the end user, and customer interaction would just be a waste of time. On 300+ people teams, or when customers have a large amount of variability in their use cases, I certainly think an intermediary like a product manager can be beneficial. Assembled has 15 employees today, and I suspect that my customer communication habits will scale until at least 150 employees. I’ll report back once we’re past that mark.
Product at Assembled
Remember my melodramatic declaration that I’m not an engineer? Well, my LinkedIn profile agrees — I’m Product at Assembled. The decision to pick that title is maybe foolish (my girlfriend can’t stop poking fun at me — “are you the product?”), and maybe doesn’t matter at all (consider my buddy Taylor Milliman, who according to LinkedIn is tryna win). But I like accuracy, especially when it helps me hone my focus (as Jony Ive can tell you, perhaps the most important quality you can have at a startup). The way a sales generalist might describe themselves as working “in sales”, I feel the most accurate way to encapsulate my responsibilities and goals is to describe myself as working “on product”.
The bottom line
How can expanding your purview to “product” from “engineering” help you? It can give you a keener view into the fundamentals of your business. It can help you develop better product overall. It can enable you to ultimately provide a superior experience to customers. And who knows, it might even give you better chances on Hinge.
