What Product Engineering Means at Gem
Some companies are design-driven or product-driven; at Gem, we’re very much customer-driven. As we collaborate to build a product people love, we prize the intuitions that designers, product managers, and engineers individually bring to the table — enriched by a shared understanding of our customers and their needs. To forge that understanding on our engineering team, we follow a philosophy of product engineering. This article describes what product engineering is, what it looks like at Gem, and how it helps us achieve our goals.
What is product engineering?
Drawing on Asana’s definition, product engineers focus on user needs, work cross-functionally (chiefly with Product and Design) and take part in the entire product development lifecycle. At Gem, this means joining calls with customers at the earliest stages of feature ideation and research, and again after a feature is launched. It means having strategic discussions with Product and Design, doing user research, devising launch strategies, and synthesizing user feedback. In sum, it means working directly with customers, alongside PMs and designers, at every step in the product development process. We do this so we can continually refine our own understanding of our customers’ needs, as well as our intuition for product strategy and design — all of which translates to better engineering work.
To learn more about product engineering and its unique role in Gem’s culture, we spoke to three members of the founding team. Drew will describe why product engineering is a great fit for the recruiting tech space and how it leads to a more satisfying experience for customers and engineers on the team. Mike will show how it helps us deliver a great user experience quickly. Finally, Einas will outline the opportunities for growth product engineering offers individual engineers. We hope these interviews can serve as a case study for adopting product engineering as an early-stage B2B SaaS startup, or adopting it as your own career path as an engineer.
Customer Happiness
Drew Regitsky, Founding Engineer
As a software company, saying that you focus on your users or put your customers first is almost a platitude. But at Gem we’ve found that those things are not a given in the recruiting space. Despite the multitude of recruiting startups and big incumbents in the space, it’s still common to find recruiters surprisingly underserved by their software: struggling with tedious, time-consuming workflows; juggling emails, calendar reminders, and tracker spreadsheets; and pulling in any tool they can find to fill in the gaps.
At Gem we’ve taken the strategy of empowering these individual users. We directly address tedious workflows with UX, automation, and a thoughtful, iterative approach to product development. In practice, that’s meant taking a product engineering approach from day one. Gem started out as a team of engineers — the founders themselves and most of the founding team were writing code — and product engineering was our secret to success. We were talking to customers every day, and uncovering pain points that sounded almost too basic: recruiters with no way of knowing whether their colleague already reached out to a candidate, or sourcers copying names and job titles to spreadsheets by hand. Simply eliminating the need to manually record candidate data saved teams hundreds of hours a week.
As Gem has matured these opportunities have continued to surface — we’re still constantly finding new ways to cut busywork and make recruiters better at their jobs. And what we’ve built so far has brought us a loyal following among recruiters, massive growth of the business, and many happy customers. Product engineering has grown from an essential tool to get a footing in the recruiting space into a core philosophy at Gem.
Beyond its value for customers and the business, I’ve personally found product engineering to also be extremely motivating day to day. It’s essentially a way of using software engineering to help people, and then getting to directly see your impact. I love seeing a recruiter’s excitement and delight when my code has made their day a little bit easier. At Gem, this happens all the time. We regularly talk to customers, and our own recruiting team uses our product, so engineers are constantly hearing about the impact of our work (and getting feedback on how to make it better). And for recruiting specifically there’s a double benefit — cutting out tedious workflows lets recruiters focus on the more rewarding part of their jobs: giving candidates a better experience and matching them up with the perfect role. At Gem, we felt the full-circle impact of what we had built the first time our recruiting team hired an engineer onto the team using our product — “It really works!”
One other note about how we think about product engineering at Gem: we don’t create a distinction between product engineers and backend engineers. We view product engineering less as a distinct role and more as a skill we employ, whether we’re building features for customers or designing infrastructure to support our teammates. This is apparent in the way we define “customer focus” as a company value: we treat all stakeholders, whether internal or external, as valued customers whose feedback matters. Living by that principle as a team, we’re able to collaborate more fluidly and enjoy a more satisfying development process overall.
Velocity
Mike Pinkowish, Head of Engineering
As a growth startup in a fairly greenfield space, we need to move quickly and deliver an experience users want to tell their friends and colleagues about. Product engineering helps us achieve that. Product engineers strive to form a deep understanding of users and the product strategy — they ask a lot of “Why?” questions and they aren’t satisfied with simply building to spec. At Gem, we give engineers as much data as possible to form an independent understanding of our users and their needs. They do their own user research, have frequent discussions with product and design, and hop on calls with customers where they can ask them their own questions.
The deep understanding of customers that results is what enables us to deliver great experiences quickly. On the one hand, the spirit of a feature is rarely lost in translation between design and implementation — that can happen in design-driven or product-driven cultures where engineers form their understanding of users through intermediaries. On the other hand, having engineers with a strong understanding of users and their needs is a superpower during discussions about what features we should be building — in the face of many complicated, time-consuming options, a scrappy product engineer is able to guide the whole team toward a quicker project that satisfies the same need. The velocity we achieve in this way compounds. Moving quickly today means we can get started on the next project earlier, and so long as we ensure that each project moves us in the right direction, we accelerate our roadmap progress over time. In the end, we’re capable of delivering great features at an unmatched clip.
Good product engineers have a curiosity and scrappiness that helps their whole team move quickly. Perhaps most importantly, they have a strong motivation to build things that truly benefit people — things that delight them, empower them, and make them more productive. When our whole team aligns on that singular motivation, in lockstep with product and design teams, it’s easy for us to quickly and consistently deliver a product people love.
Growth
Einas Haddad, Founding Engineer and Engineering Manager
Product engineers are trusted to make decisions with users in mind. When we ask a question like “How can we make Gem more sticky?” or “What do we need to build to sell Gem to this company?”, engineers are part of the discussion with product, design, sales, customer success. We take part in user research and defining the launch strategy for a feature: what customers to target, how we’ll present it to them, and how we’ll collect feedback; after launch, we help synthesize that feedback into something the whole team can iterate on. In short, we’re involved every step of the way. Being this deeply embedded in the product development process gives us an abundance of context when we set out to build a given feature. We know not only what to build and how, but why we’re building it, and that empowers us to do our best work.
Our ownership as product engineers extends further. We’re responsible for features from end-to-end in terms of the product lifecycle, and typically from the frontend to the backend of the software stack. We collaborate with business functions outside of the product lifecycle, too — with whoever it takes to deliver the best-in-class product to our customers. And it takes everyone: the Go-To-Market team, finance, and operations, just to name a few. At Uber, I had little sense of how these functions operated internally or what it took to do them well. At Gem, I’m able to take an active role in them. We want our team to be a place where people can explore new types of problems within engineering, or outside of engineering, and see how these fit into the operations of a whole business — because we know a more holistic understanding translates into better engineering work, and we want each engineer’s sense of ownership to extend to Gem as a whole.
We’ve attracted a few aspiring founders to the team, including myself, Lucy, and Dmitri, owing to our emphasis on ownership, transparency into the whole business, and talking to customers. For context, in our first two months as a company we did nothing but talk to potential customers before writing a single line of code. It sounds extreme, but certainty that your product meets a real need (a.k.a. “product-market fit”) is extremely important for a startup. In turn, talking to customers is one of a small set of tasks founders spend the majority of their time on.
We’ve found product-market fit for Gem as a whole, but it’s still a gradual process to find it for new features within Gem. The task hinges on your intuition for product strategy and ability to have fruitful conversations with potential customers and at Gem, it falls heavily on the individual engineer who owns the feature — and sometimes that feature is practically a standalone product, like Gem Jobs, our ATS for staffing agencies. In that sense, our product engineering team is a great place to hone the core skills of a founder, and it’s no surprise so many aspiring ones have joined us.
Another place founders spend a lot of time is on recruiting. Engineers at Gem take a uniquely active role in recruiting, as well. We do this to understand our users and test out our product, but also because we care a lot about bringing the right people onto the team — and it’s fun. When we do our own sourcing in Gem, we get to see what the product we built is capable of. We can do really cool things that weren’t possible before Gem, like surface every engineer Mike emailed in the last year who said “Let’s talk later” and quickly send them all a personalized followup originating from his address. Many of us also take initial calls with candidates, and we’re all involved in coding interviews, onsite interviews, and offer discussions — so we have a uniquely personal understanding of the entire recruiting funnel our users live in. This leads us to make faster, better product decisions. It’s also great exposure to skills you’d need as an engineering manager or a founder.
Our brand of product engineering, with its emphasis on cross-functionality and ownership, is easier done at our current scale. But we’ve seen the immense value it brings to us and our customers in terms of satisfaction and growth, so we’ve put a lot of thought into how we can preserve it for the long term. When our team broke into pods for the first time, for example, we designed them in a fairly unique way. Rather than dividing along the stack or distinct product areas, we created three pods that correspond to our three company-wide strategies: Land in every company with sourcing, Drive value with reporting, and the one I lead, Make Gem really, really sticky. Because these strategies are set at the company level, we think they bound engineering creativity and cross-functionality as little as possible.
We’re continually thinking about how to scale our unique culture and preserve Gem as a place for engineers to exercise autonomy and hone a broad skillset. As I mentioned earlier, a lot of us choose to learn about our users by honing our own recruiting skills. That includes taking calls with interested candidates — so if you want to learn more about engineering at Gem from someone who’s experienced it firsthand, feel free to drop us a line at nathalie@gem.com. 😊
