Why become a product engineer? -- with Volley (YC W18) & Luminai (YC S20)

[Music] foreign [Music]

Thanks for joining! For those of you who don't know, I'm Paige from Y Combinator, where I work on our work at a startup team. Essentially, the team is helping all of our Founders hire great people like you. So, this is why I become a product engineer. This event was inspired because even at YC we hire product engineers, and a lot of times candidates don't know what that role means. Today, we have two wonderful Founders at YC companies who will share their experiences and kind of give more color behind what it means to be a product engineer at their companies.

So, I'm James. I'm the co-founder and CTO at Volley.

I'm Casava, I'm one of the co-founders and the CEO of Illumini.

Awesome! Yeah, so I'm just going to kind of talk a little bit about Volley specifically for a minute just to give you the context there. Um, this is Volley. We make games for Amazon Alexa and Google Home. We're kind of a game studio in that sense. We have a bunch of products. Right now, you're seeing Song Quiz, which is one of our most popular games on both platforms. It's a name that tune game. This is Magic, where it's like a little word game. Um, and this is Hash, sort of showing that you can play our games on Fire TVs as well. So, anything with a microphone, we're trying to make voice-controlled entertainment—voice-controlled games.

We have a lot of products, I guess, which is why we have a lot of product engineers working at Volley. And you know, you can kind of check out our website yourself, but this shows a bit about our most popular products. So, Song Quiz, like I said, is kind of a name that tune music trivia game, super popular with families and friends. It's like a social experience—you can kind of play it in your living room and have a great evening trying to guess the artists and the titles of popular music.

We also license a lot of brands from popular game shows that you probably will be familiar with, so we have a game for The Price is Right, and for Jeopardy, for Who Wants To Be A Millionaire, Wheel of Fortune, Are You Smarter Than A Fifth Grader, and then we also have casual games like Question of the Day, which is like a daily trivia question. We even have sort of stories that are controlled on your Alexa and Google Home for kids and families trying to go to sleep.

So, tons of stuff, and there's even more down here you can check out. But yeah, that's basically the overview of the company. We went through Y Combinator in winter 2018, so we've been around for a while. We're pretty big, at least in my view now. I mean, the biggest company I've worked at, which is, you know, 70 people or so.

We're based in San Francisco, headquartered there, but we're pretty hybrid right now. So, like half of our employees are spread around the globe, primarily in the US, but we've got people everywhere. And we also, you know, are hybrid even in the Bay Area, so people are kind of coming into the office, you know, two to three days a week. It's been working really well.

I can talk a lot more about this later on, but we have this kind of structure to the company that I think is similar to a lot of other game studios where there are a lot of little small autonomous individual teams that are kind of working on individual products at the company. And that's kind of how we've been able to scale our product catalog pretty quickly to become the leader in this new emerging space of voice-controlled entertainment.

So, yeah, that's what we're working on. I'm happy to dig in on any of those topics, but I just wanted to give the overview first.

I've put together a little deck quickly that I thought I can run through, but fundamentally what Illumini does is we take any kind of multi-click, multi-step repetitive manual process and make it one click. But before I tell you why and how we do this, just wanted to share a quick story.

So, I grew up in the southern part of India, so most of my family are all sort of coconut farmers. For the longest time, until I was like 10 years old, basically, you know, I lived in a coconut farm. Then, when I was 11, my parents kind of moved up to the city in the state I'm from and sort of stumbled upon Rubik's Cubes and got very good at solving Rubik's Cubes.

I ended up kind of breaking a bunch of world records and as the captain of the international team and got to kind of travel the world, all funded by the government. And that sort of landed me going to this high school called the United World College. It's a high school that brings together people from, you know, 70 different countries to work on international peace and understanding.

After I graduated, I was like, okay, what's the craziest thing I could do to, like, live this United World College mission, which was to promote peace. So, very naively, I decided to kind of cycle from Europe to Asia to promote peace, and recycled about, you know, 2,500 miles across these nine countries. Because of that, I kind of landed in the Bay Area for like a summit, and when I came here, I kind of fell in love with Silicon Valley.

And you know, no work visa, no money, but sort of was like, let's figure out a way to kind of continue being here. Ended up actually living off of hackathon prize money for six, seven months, and sort of the first project that kind of came out of it—or so the project that actually started to make money that came out of it—became what we're working on today, which is Illumini.

So, sort of fast forward to, you know, what we're doing today. You know, the reason I mentioned that story is because, you know, ever since I was 10, kind of efficiencies kind of embedded in my personality. It's primarily because of some of these, like, you know, at the end of the day when you sort of start talking to some of the teams you work with, primarily, you know, customer service, customer experience organizations, they face, you know, three or four problems.

So, the first one is that they have, you know, four, five, six different systems they jump between to find information and then perform tasks associated with their jobs. Unfortunately, this is almost close to 50 or 60 percent of a customer service agent's kind of load, and they only spend about 50 actually talking to customers.

The second is sort of, you know, they spend a lot of time getting onboarded and ramped up to be able to, you know, actually do their job. The third is, you know, engineering resources to build support tooling is close to zero. Obviously, you know engineers want to work on product, and so, you know, most folks don't end up actually building any of the internal tooling. The final is sort of security and compliance.

Like, you might have seen the OCTA support breakout, but sort of the big hack that happened with OCTA and the primary reason was because the support team—they're all tier one agents in countries that are not in the US—and they sort of have access to customer data and financial data that is very, very sensitive.

And this sort of yields, like, you know, sometimes tens of millions if not hundreds of millions of dollars in support with increased, you know, average handle time and lower customer satisfaction scores. So, what we ended up building was this external layer that sat on top of these existing systems to take any kind of multi-click, multi-step process and make it one click.

And we do this using this technology we built called robotic process automation. The reason this is sort of important in the context of product engineers is because we are a very productive, event-driven org. We actually, everybody we hire for, regardless of whether you're technical or not, actually goes through a product interview because we fundamentally believe that, you know, everybody should be able to actually understand why you are building the kinds of things you're building for the customers.

And so we have this, even internally, we ensure that every single person at the company is having FaceTime with the customer on a weekly basis. You know, we've raised about $20 million; we're backed by some of the best folks in the valley, all the way from, you know, General Catalyst to Craft and YC's continuity fund.

And you know, this is sort of talking a little bit about one of the customers we work with. It's this very breakout high-growth company called Whatnot that, you know, started with us when there were kind of 15 agents or so and now they're in the hundreds of agents.

And one of the things that these teams mentioned, you know, is that we're actually giving back the creative joy of being a customer service agent because at the end of the day, when you talk to these folks, they joined and decided to do this job because they want to talk to customers and solve their problems. But over 50 percent of their time, they're actually not doing that.

So, we're a little over, you know, half a million, 600k in revenue. We're working with customers you probably know of, you know, Strava, Ordering, Whatnot, as I mentioned. We're also going to be— we're just starting to work with Door National Carta. And you know, the next time you kind of order from DoorDash and want a refund, they're going to be processing all of that through Illumini. So, just a fun fact there.

Finally, you know why you should join us. We've grown sort of 5x in the last five months, but what I'm really proud of at Lumini is actually that product culture. And that comes from one underlying factor—that we're a 15-person team, but we actually have six former YC Founders at Illumini.

That drives this unbelievable amount of sort of want to be customer-obsessed and have this very humble but very, very, you know, urgent and incredibly quick culture. And so that, you know, kind of drives us as a company. You know, we're looking for, obviously, I would hear product engineers but also looking for folks to come in and lead some of the teams we've built so far.

So, you can find us here, and I'll pass it back to Paige, I think, to switch it up.

Okay, awesome! Now let's start with the first question for the two of you: What is a product engineer?

Sure! I can jump in. At Volley, product engineering is super core to how we structured our engineering org. So, like I said, we have, you know, dozens of games and entertainment experiences on Alexa and Google Home. And each of them, especially like the top six that we are focused the most on, have their own product teams.

Most Engineers on those teams are product Engineers, but we also have this whole other part of the engineering organization that we call Core Tech, which is really, you know, how we've decided to split the organization. We have Core Tech and Product, and everyone in these two separate, you know, divisions is an engineer, a software engineer. But it wasn't that helpful to just put out, you know, job or export software Engineers when we really do think of these two types of roles and two divisions in the organization pretty differently.

So, it's almost more helpful to start with Core Tech, where we have, you know, kind of the centralized team that's working on our game engine. So, many of you may know game engine companies like Unity or Unreal Engine. And, you know, those companies tend to be like selling the engine, I mean, you know, depending, but to you know, licensing the engine to other companies, other game studios.

We were the first company to really want to build an engine that would run cross-platform on Amazon Alexa and Google Home, and kind of like make building games for these smart speaker platforms a lot easier and more efficient. So, we built our own internal game engine for that purpose, and that's what the Core Tech team is primarily doing.

But they're also doing things like figuring out, hey, how does that engine get architected, and how does that get deployed into production, how do we debug, how do we add features, how do we like make it flexible enough so that we can build all the cool products that we want to on top of it.

So, there’s a whole infrastructure piece, there’s a whole DevOps piece, and then there’s the engine development itself. And on the flip side, on the product engineering side, you know, those teams are really, really focused on using the engine to build amazing game experiences. So, they're writing game logic; maybe they're working with product management teams to design, you know, game features, right?

Like a new game mode in Jeopardy, we just launched the ability to like do a kind of a final Jeopardy style game mode. We used to kind of just give you a set of six questions each day, but the final Jeopardy comes into play at the end of the week, where you can kind of wager based on how much money you've earned over the course of the week, and it's a whole new feature that we've had to design and develop for voice.

So, that's an example of something you might work on as a product engineer, whereas on the Core Tech side, you'd be maybe working on the underlying systems that power all of our games. And yeah, we, like I said, we have these kind of really small, efficient, autonomous teams. And the reason they can work so quickly and efficiently on customer-facing game logic and game features is because we have this other Core Tech team that supports them and has solved a lot of really thorny problems about DevOps and deployment at scale.

So, it's two very different worlds, but they're tied very close together. And it's almost as if the product Engineers are customers of the Core Tech Engineers internally in the company. So, on our end, the way we're actually structured is, you know, we're not large enough that we're starting to separate any of these, and you probably there's, you know, a point where we will probably have to do that the same way, you know, Volley is structured at the moment.

But at Illumini, what it means to be a product engineer is that you're kind of spending about, you know, 10-15 percent of your time actually studying the customer and spending time with customers on a weekly basis. And so that means going and looking at each of these customer channels and these communication setups, talking to users, and then taking those insights and thinking about how does this tie back into the business case, right?

Longer term, like how do we prioritize the types of things we need to build to drive the constant value and double down on the value that we're today and then take that layer and you think about that, and then you actually go back down to building a very, you know, in our case, a consumerized enterprise product.

And so, right now, you know, we're very, very heavily focused on like a producty org, not just within engineering but across the board. So, question from Carol: Do you have a product manager at the moment?

No, and I think that that's the advantage of sort of where we are today. But I think we're probably closer to that breaking point of like realizing maybe we do need a PM to start kind of tackling in. So, we actually just put out a first job rack for someone to come in and be a PM too.

But that product engineer piece will continue to be the case. And then to answer Scott, yes, it is a hybrid of software engineer and a product manager but more like 80 percent probably engineering and probably fifteen-twenty percent being a PM.

And to kind of build off of that, someone had a question about how the role of a product engineer might change for a company that's pre-product-market fit versus a company that's a little later stage. Any thoughts on that one?

For us, like, you know, we started, you know, we were a product engineering org from very pre-product-market fit times to now I would say we're sort of at the cusp of seeing very strong signs of product-market fit just with the customers that we have and the usage and the ROI that each of these customers are getting.

So, it definitely changes from like everybody sitting in whiteboarding and figuring out all the crazy ideas that you want to do to a little more structured on like how do you think about roadmap, how do you think about, you know, how do you think about the next phase or start thinking a little bit in months rather than like days. And so that probably is like one shift that's happened.

Is that similar, James, or do you guys have something different?

Yeah, I mean it’s really kind of similar to or like it's interesting to hear how you're set up right now because I think that's how we were at the same size company when we were, you know, 10 to 15 people.

We didn't have any PMs. We were maybe just starting to ramp up the hiring there, and part of the huge benefits of like going specifically after hiring product engineers and embedding kind of like product-type, product-sense evaluations into the hiring process was that, you know, you get these awesome engineers, but they can make those decisions for themselves that are like that maybe at larger companies would require lots of check-ins with the product teams.

And you know, as a startup, you want to be moving a lot faster than that. So, you want to almost like be testing for this in the application process. Like, you know, your initial engineers, do they have a good taste on product and are they making good customer-facing decisions?

Because like not there's not always going to be someone telling them exactly what the spec is should be like in the early days. You know, nowadays we've created a lot more structure, which is good; I think we needed to.

We have scaled up to, you know, each team having multiple product engineers, a product lead, and a data analyst, so each game essentially has those discrete teams. And they are able to create a lot of their own sort of rituals around, you know, their roadmap and their KPIs and, you know, their timelines, and they're moving really quickly.

But it's kind of that studio model except it's internal, right? Like each game has its own kind of dedicated resources on product analytics and product engineering essentially, and then there's the underlying infrastructure team that supports all of our games sort of across the company. And that's been working really well.

The thing that we've done to kind of standardize this so it doesn't get too crazy is we have this quarterly kind of KPI cycle essentially—stolen from YC we call it demo day. So, if you're familiar with demo at YC, there’s a demo day at the end of the batch, and you present it to investors. For us internally, we actually do that with each game, with each team.

We have the teams present to the entire company about what they were trying to achieve that quarter and, you know, what they tried, what worked, what didn't work, if they hit the KPI, and what they're going to try the following quarter. And you know, as we've scaled, we've created a little more structure to these check-ins and, you know, standardization across the games.

But at the end of the day, like the product engineers themselves are still doing very similar work to what they were doing when we were 10 people, which is building great games and great game features that are, you know, played by the customer.

I think the one thing that, you know, that's really interesting that you mentioned, I think that's probably core to the product engineer title in general is actually autonomy. I think that's probably the real differentiator between like a software engineer and like a product engineer is like the ability to go from like zero to one without necessarily like, you know, having to have like check-ins with like five different sets of organizations.

It's like really giving the power to like a technical person to be like, hey, like this is the problem; figure it out; and like, you know, all going from zero to one, I think, is like really the big change.

Yeah, totally! I think you're spot on. It's like, you know, there's so many questions that come up in designing products. When you're in an early stage team, it's often more important that you just make the decision and commit to it and make it fast rather than, you know, get it perfect or get it right before you launch or, you know, to even test it perfectly.

Just the reality of early-stage pre-product-market fit startups is you need to be moving super quickly, and that means that you're probably creating problems down the line for yourself, but that's okay because like you might not make it to that point unless you get the product out and learn from the customer.

Foreign, that makes a lot of sense. And for some of the software engineers who haven't been as like customer-facing before, what are some of the things that can kind of help them transition or think about like why they might be more interested in a product engineering role than just a software engineering role?

I think at least at Illumini, you know, I would say about maybe about our engineering org, about, you know, 70 percent are more introverted, maybe even 80, more introverted, 20 more like super extroverted customer-facing folks. And I think the interesting part is actually when you're making the transition from like not necessarily communicating with like an external-facing party who you have a business relationship with and then transitioning into a context where you are communicating with them actively—it's pretty crazy how much customers love when like engineers are actually involved in the day-to-day collaboration.

Because like engineers are the heart and soul of like, you know, the product that they're using, and the fact that they have a direct line access to them in some form makes the customer so much happier and so much more open, actually, to accommodate whatever sort of style of community education that they want to have.

But also, all in all, the reason I say that is because as you make that transition from software engineer to customer engineer or product engineer, it's actually pretty wild how welcoming that transition is primarily because it's driven by the customer in so many ways.

And you get to the heart and soul of like why you're building what you're building and the real impact that it actually has. Like, if you were to kind of build a button, right? Like you'll actually be able to see like what does this little button do for like the hundreds of thousands of people that could potentially be using it, all the way to like—let's say you know we're a very founder-driven organization like we take a lot of inspiration from Rippling.

And so we kind of have a little bit of a business unit set up. So you can actually, at Illumini, see going from fully from zero to one on a new vertical potentially. Like for example, right now in customer service, but the next sort of opportunity we're going to be tackling is actually sales ops and like going from zero to one on like taking what we've had and getting it up and running.

You have that in that power, and it's pretty, it's very, very like sort of a different set of challenges that I would say the new modern businesses are kind of starting to adapt. So, it’s more exciting than scary.

Yeah, and I can add that at Volley, I think a good way to kind of prepare for the product engineering role would be, you know, if you're the type of engineer who's already, you know, thinking a lot about, you know, the customer journey, right? The, you know, a lot of the problems that a customer might face in an application.

I think that's like a key skill set is like you're, maybe you're able to think of edge cases really, really effectively, right? Because you know, maybe the customer is going to hit press this button or get to this flow and it’ll be confusing or they won't, you know, they won’t know where they are in the application or it'll cause some issue downstream.

Like those types of thinking—that type of customer-focused thinking is really important for a product engineer, and you can do it just in whatever engineering role you're in right now already, just kind of putting yourself in the shoes of the customer or the, you know, user in the gameplay in our case.

And you can also kind of like think of it as something you can practice just by, you know, using apps yourself. You know, whether it’s a consumer-facing app or, you know, a work application that you're using all the time, like thinking about the feature set and what parts are hard and difficult, and why they were coded in certain ways can be really valuable.

Like, you know, especially at your current job, being able to feedback suggestions up to the product leads or the product managers to suggest, you know, product improvements or ask the questions of like why was this designed this way? I think that's the best practice for the types of decision-making and thought processes you'll have to go through as a product engineer, specifically.

Great! And this is sort of related but a little different. So, if someone is a product manager and has kind of been in that role, what are some signs maybe that they would be interested in becoming a product engineer again? And what are some technical skills that product managers might want to gain or freshen up on before they move into product engineering?

I generally think I've sort of seen the other transition, and just like going from engineer to PM, I think PM back to product engineers—actually, I would say like probably way more effective because you're kind of, if you are like a by-background technical, and but you've been doing like PM work, then you've already gained all the necessary organizational frameworks to like run a product org.

But then now you're actually going back into the weeds and building, which I think is like very, very, I think that the signs are very simple, which is like if you're having this itch to go back to want to truly kind of get your hands ready and build again in so many ways, but also not lose the product touch and the want to talk to customers regularly—making that switch is probably very exciting.

I mean, on the technical side, I think you just need to kind of be up to date with what folks are using to build. You know, we kind of use the most modern kind of React, Node.js, TypeScript stack, but that's like most companies in the SaaS world.

Yeah, I mean, seconded here as well. At Volley, it's Node, TypeScript, React. Those are the key technologies to be aware of to join a lot of startups. Like, if you're caught up to speed on that tech stack, you're going to get a lot of interest as a, you know, PM who's interested in going back into engineering or, you know, learning, you know, switching into engineering.

And I think it just, yeah, it just like such a powerful skill set to have, especially if you are, you know, working on customer-facing features.

Like I think it's more, it's like if you've been a PM and you're now going to come in as a product engineer, you're going to be like probably interfacing with customers, potentially, you know, like doing customer interviews, potentially, or, you know, just designing the features that are closest to the customer.

It's really valuable, maybe more so than if you were going to go in to like infrastructure engineering or DevOps or something like that.

Cool! If you think of your one or two top product engineers, what are the skills that they really excel at, or like what are their superpowers?

So, I think on our team we actually had a recent YC founder join us who was the CTO of a company. It's been like three months since he joined us and it’s pretty, like, exceptional.

And I would say that the reason why that kind of ramp time from going to zero to them being exceptional happened so quickly was primarily, I would say, very much driven by ownership and a curiosity to understand the core customer problem before doing writing any line of code.

It's like a very YC-esque mentality, which was like, okay, like here's the problems you're telling me, let me go and figure out if that that's really like from an engineering standpoint really how we should be approaching this, right?

And so, basically, you know, we built a core sort of V1 robotic process automation engine that we kind of defined as our longer-term mode that will continuously get better.

And so he went in and kind of dug deep into like actually figuring out if that can all last and become—will grow with our customer base, especially because you know when you're so early in the journey like like we went from like like basically our with onboarding DoorDash, our user base is going to 10x like over like a month period.

And when you're kind of dealing with that kind of scale on a month-to-month basis, like everything is going to break very quickly. And so you got to start like being a little more proactive.

Especially in our world, which is like—and maybe in the games world too—but like I think in our world, like if a customer service like system is down for like five minutes, you're talking about like hundreds of customers not being able to reach you.

And that's like potentially like losing customers—potentially like hundreds of thousands of dollars or maybe more in business impact. And so, when you're dealing with that kind of scale, it's very, very core to be able to understand that problem.

And I think the person who joined our team was able to like really, really take that and then reshape and kind of build our RPA engine like 2.0 in the last kind of three months to get ready for the next phase.

And I think the other part of it, which was like the awareness of like him also saying, “Hey, to me is, okay, case about like, you know, like yes, like you know, we'll build this is a new engine, but this will probably scale for up to this point and then we'll probably have to like rebuild again,” right?

Like and just having that awareness is also like probably very, very key.

Yeah, I think that's spot on, it's like understanding the customer also like, you know, being very data-driven. I think it's just become a must in the current world and startups, especially.

And you know, I think when you're on a smaller team, you know, there's probably like one or two or three maybe at most, you know, top metrics that you're trying to like really grow, especially as you're trying to achieve product-market fit or you're trying to get to the next round of fundraising.

Like, you know, everyone tries to be very focused on improving a set of metrics. And everyone should be super aligned on that so a product engineer who’s really effective is going to be laser-focused on the, you know, the work that needs to be done to move that metric—whatever it is in your company.

For us at Volley, it's things like, you know, how many people are converting and buying a subscription in our games and how many people are retaining on the subscription, essentially paying multiple months over months.

So, you know, those whatever that kind of focus of the business is, you want to be super aligned there. And you know, whether it's like, you know, figuring out what are the trade-offs like if you're going to work on one thing or the other, like how much does that affect the business metrics?

And, you know, maybe there won't be, you know, the product manager or product lead telling you exact making that tradeoff decision for you. You need to be a little bit more focused on, you know, letting the product people in the company know or business leaders in the company know like what how long this feature will take and what the trade-offs are in terms of how likely we are to hit our goals for the quarter or the year.

So that’s kind of like really important is to have that mindset of like, you know, being close to caring a lot about the business metrics I think that maybe differentiates the role a little bit more from, you know, maybe, you know, more infrastructure-oriented roles on our team, at least.

Foreign from Alfonso. Here, if you're able to share what kind of KPIs do you use for product development?

Yeah! Among all the ones that I mentioned, you know, it's, you know, we're selling subscriptions, so we're kind of a freemium model. And, you know, essentially when a player discovers our game they get a free experience, and then we're trying to upsell them into a subscription.

You know, it's really similar to like the mobile app store in-app purchase model, and you see this a lot on consumer technologies, consumer startups. The subscription model is super effective.

So, but there’s really clear, it’s almost like SaaS metrics, if you’re familiar with SaaS metrics, like they apply pretty well to the kind of consumer subscription model. So, you know, how many people are converting into the subscription?

And you know, usually it’s a free trial. So, how much are, how likely are you to pay after the trial is completed? How likely are you to pay the following month? And also, you know, you want to be looking at like usage during the trial and usage during the first month, and those types of metrics that kind of show you not only like are you maintaining the payment retention, but the usage retention as well.

So, those are a lot of the key things that we're looking at. And also, of course, like a huge driver of our business also is just like discovery of our products. So, there's a lot of work being done on marketing and growth before the user even gets to a product, and there's a whole side of the business there as well.

Oh, yeah! One thing I wanted to just add was like a lot of our product engineers, what they're working on is not necessarily just like designing and shipping a feature for the game or not, you know, just like feed building and shipping a feature for the game in collaboration with the product leads.

But also like, you know, running a lot of A/B experiments, right? So, if you're someone who really enjoys that, like, you know, learning from the A/B tests that you're running in a product, I think that's a great place to, you know, explore as a product engineer because you get to run a lot of experiments.

Because like that’s usually how we learn about the KPIs, you know, what drives the KPIs and what we can do to hit our goals is by running lots of A/B tests in the games.

I think, you know, like Patrick Collison, who's like one of the founders of Stripe, had recently spoken at like a YC reunion, and he spoke about like sort of like what makes teams move fast.

And the thing he said was like, it's like knowing what like a customer wants, figuring out the solution to that problem, building it, launching it, and then actually knowing if it worked.

And that loop, the faster and faster and faster you do, the more progress you're able to make as a company. And so that's something we track very actively at the company—just like going from zero to one on like, no, like defining and scoping, like this is what we're gonna solve for and then actually like releasing it and investing and surveying if this actually solved that problem.

Like that loop is something that we define as like in some form like a KPI we look at just like from the product engineer lens. But then other things we care about, obviously, are like, you know, we're very like numbers-driven org. And what that means is, you know, at the end of the day, we're driving efficiency; we're driving return on investment.

And so these are folks that, you know, before using alumini, they were able to get, let’s say a hundred kind of tickets done; now it's luminized—let’s say they do 124. That’s like a 24 percent increase in efficiency or whatever.

Like that’s something you're constantly tracking, which is like what does like usage look like? What does ROI look like for each of these customers? And how do we continue to kind of double down and increase that?

And so just like a quick two things, but that's probably a few more.

And transitioning to more of kind of the career side of working at your companies and being a product engineer. What does the future look like if you join a company as a product engineer?

Then what I would say at Illumini, you know, we have like—it’s something we just started to define a little more clearly, and probably it's like much more scoped out at James's company. But I'm curious to hear but sort of we have two paths, right?

Maybe, I don't know.

But, you know, there’s sort of the traditional sort of IC path, right? Which is like continuing to become, you know, become a senior staff-level engineer and continue to influence product decisions, especially if you don’t want to be a manager, right?

I think there are lots of folks that we made with who are exceptional who end up like getting blocked at the top of their game being like, “Oh, like I don’t really want to manage, but like I can't really do anything after this.”

Like we believe, actually, that if you are a product person, like you can continue to influence product very deeply without necessarily wanting to manage folks. And so, that’s probably the path on the side.

But then, obviously, if you end up wanting to manage folks, there’s obviously the, you know, the product engineering lead, and then there's the head of engineering, there's the, you know, VP of engineering, CTO—all the way up that ladder while continuing to, you know, be focused on product.

But, um, yeah, I think we’re a little far away from that at the moment. Nah, still a 15-person company, so...

James?

Yeah, no, I think we have a pretty similar, you know, set of paths, right? You can level up, like you said, into kind of a product lead role or an engineering management role.

And yeah, what's I think what's interesting at Volley or unique is like the fact we have so many of these kind of games that are fully staffed teams, you can actually move around a lot. Like if you come in at Volley as a product engineer, and you're working on Jeopardy, maybe that’ll work on that for a year and say, “Hey, I really like this song quiz stuff; it sounds like you're doing really cool stuff over there!”

Like we have a very fluid org in the way that our product engineers can move between our games, so I think that's really unique and something people really value about Volley when they get here is like, you know, they can learn the stack, they can ship some awesome stuff on one game, and then, you know, request, kind of check out another game a year later, two years later, whatever it is.

And they're bringing all the knowledge from their game into the other game and kind of that helps the business. And I think because of the way we've structured the architecture where all the games are running on the same internal engine, you know, that's cross-platform, it’s a super quick learning curve to like get up to speed on the other new game that you're working on.

So, maybe it'll be like a brand new game that we're launching, you know, and we're trying to like staff up that team.

So, there are a lot of really cool just initiatives to work on, you know, on all the teams—but I think like the ability to like kind of chart your own course is pretty unique at Volley and really valuable to people leveling up in their careers really fast.

What is your favorite story from your company that is related to someone who works in product engineering? Can be technical or can be non-technical.

Well, one thing I think that is a good story is just like, you know, don't be afraid of like, don’t think too far ahead, I think, because if this sounds interesting, you know, about being a product engineer and, you know, working at a small startup—I know I’m sure a lot of people here aren’t used to working at startups or, you know, mostly worked at larger companies, and that can be itself challenging or intimidating.

But like, you know, what's amazing about these smaller companies and working in these customer-facing roles is that you learn so many critical skills that apply no matter what happens in your career.

And you can level up really quickly in a startup, and that's really valuable for your career. Just the story I was going to say is like, you know, why Combinator has work at a startup, where you can apply to work at companies like Illumini and Volley—but you can also, there's even like work at a startup intern programs, and we've hired people right out of master's programs like they were an intern for, you know, three months, and now they’re managing, you know, a team of 12, a few years later.

So, you can level up really quickly, you know, and also, you know, from my perspective, I love that this work at a startup program exists because we get amazing applicants through that that have gone on to do incredible things at Volley.

I would second that, what James just said. I think it’s super, super true. By reaching out or just, you know, putting in an application or just shooting an email, it doesn't mean you have a binding commitment to join that company. Just like kind of, you know, come chat with us.

It's our job to kind of show you that it’s possible. In the end of the day, but I would say the one thing that sort of strikes me is like, you know, we were like a two-person company for a long time, and that was because like we were just kind of iterating that we kind of really found product-market fit.

So close to like, you know, 12, 18 months, but the first person we actually hired was this like person—like you know, he was like 19, kind of just like on a hacking around, right? Never talked to a customer before but just kind of like building things.

And right now, he kind of, obviously a little older, but sort of, you know, very much is like, you know, every day, the first thing he does on our daily kind of Slack is like, "Here’s what—like here’s like the crazy insights I learned from like customers" like every week.

So, like every conversation he has kind of summarizes the things about it and then kind of shares that with the engineering work. And like that kind of shift that mentality from like not knowing how to like—and this person was not like a first language English speaker either, and so it was like kind of like for him it was like a combination of all of those things to come in and, you know, get himself up to speed then also like make sure he brought everybody along for that same customer journey, which I think was quite beautiful.

So, yeah! Amazing stories! Thank you both again for joining us and sharing more about what product engineering is at your companies. [Music]