#109: Inside Maven's shift from EPD specialists to flexible builders | Rishin Banker (VP Product @ Maven)

Hey everyone, this is going to be a special episode of the podcast from a conversation I hosted live in New York with Rishin Banker, who's the VP of product at Maven. It's part of a new in-person series I'm hosting with Asker AI called Blurring Lines, which is really exploring how product, design, and engineering are coming together and how these clear swim lanes are no longer as clear as they used to be. So you're going to hear a little bit of a different kind of soundtrack introducing the episode. And I just wanted you to know as our audience why this episode is a little bit different. So with that said, I hope you enjoy. Say bye, Gaia. Bye-bye. All right, so thanks everyone for joining. This is the first in what we're calling the Blurring Lines series here in New York, bringing together product people, initially starting with what I'm most familiar with, which is product management and people that are product leaders, but really exploring the intersection of how design, engineering, and product are coming together. And I think our whole craft is kind of evolving in a new way. So there's a lot we can do online about it and talks and lightning lessons, which I'm a big fan of what Maven's doing to help educate people with courses and stuff. But for me personally, I think I've been craving a bit more of kind of like real-time dialogue and also just like learning from other people without screens in the way and just kind of like people learning from people and talking about stuff. I feel the same. I spend a lot of time learning behind a screen through Maven too, but I still really appreciate this. Yeah, so just some context. I've been teaching on Maven for coming up on two years, and I've mostly used the platform as an instructor. And I got to say, I've noticed that the pace of new features and new capabilities that are being rolled out has increased. I've also had Goggin, your CEO, on my podcast. And it sounds like you guys have been really experimenting with ways of working faster, not just because of AI, but certainly powered maybe or fueled by some of the innovations with AI. So I'd love to kind of maybe start by hearing a bit more about like, what have you guys been like experimenting with process-wise? And then any early learnings from you on maybe ways that you've found to move faster as these kind of, you know, the old way of working is starting to fade into whatever the new way of working is starting to look like? Yeah, it's been very exciting times, I think, for everyone. And for some context, I think a lot of people in the room are familiar with Maven, but something that sometimes surprises people about Maven is we are a pretty lean and scrappy team. So we are about 25 people overall as a company. And for most of the time, I've been at Maven for about four years. For the first three or so years, our PDE team was two PMs, two designers, and about eight engineers. Today, we are three PMs, three designers, and still eight engineers. So the shape of it is still pretty similar and pretty clean. The biggest change has been with each of those formats, before we would be usually covering two to three projects at a time, and that's how we would organize. So three to four engineers per project. We are now doing five to six concurrent projects at a time, and that's primarily how we have re-organized. So smaller pods, fewer people, more decision-making within those pods. And that's probably the main idea that has led to a lot of other process shifts, but the question that we've asked ourselves is, how much more can we do at the same time, given new tooling, new ways of working, and push ourselves on the extreme of that and then figure out where things, maybe create some holes and patch it up as it comes along. Yeah, so I'm hearing kind of like the ratio of PM and design to engineering has increased. So like more PM and design firepower per engineer and then more projects running in parallel than there used to be. Are you still following what I might consider like kind of like a linear development process that starts with like a problem, you know, idea, design, prototype, you know, ship to production? Have you guys made any major tweaks to like what the product development lifecycle is looking like? I think each of those steps still has to happen. I think what has changed is who is doing each of those steps and how those steps get sequenced. I think what I'm realising now is a relic of the past is that because if you have a person that is fully focused on, let's say, strategy and the problem phase, you have an assumption that you should always be doing X percentage of time in strategy and problem phase because that's what that person's role is. What has changed now, I think, is the idea of a bottleneck is that it's a shifting definition where if you get a lot of clarity on the strategy and problem collectively as a company early on, you might be able to put way more firepower towards the solution prototyping building phase. And that's been, I think, the biggest change, which is we, I think what you've noticed over the last couple of months is we got to a lot of clarity on a defined strategy that we wanted to implement, and that enabled us to be able to define these five to six pretty clear work streams. So bundling strategy and the problem phase up front allows you to deploy more people to go into the solution phase at once, which I think before in a more waterfall-y type of structure, you don't get into that because you're following more of these defined roles and you're assuming that, okay, everyone's going to continue some amount of strategy and problem, whereas now anyone can be a builder. So you can think of your roles as a lot more flexible and get to the same outcome a lot faster because you're flexibly changing what your role is going to be. So hanging out for a second, like the who does what maybe part is evolving, and that's maybe enabling you guys to create more parallelized work streams towards like a more clear kind of strategy and vision. Outside of EPD, are you also seeing people kind of step into the builder role? Like, you know, you guys have some great folks on like the customer, like the operations side, the marketing side, the community side. Like, are you seeing other folks kind of stepping in? Totally, yeah. I think that's been a really exciting way of also extending who you might think of as doing the product role within your company, especially where parts of the product role, I think, are having a lot of the domain context and the business goal part of it. And for sure, there are people that are not traditionally part of the EPD organization that are thinking about that. So one example, we are working on a big launch coming up in a couple of weeks, and we're redesigning a marketing page that will pull students into Maven for the first time. And playing around with a lot of fun ideas as to what an interactive experience might be for that. That is entirely being vibe-coded, iterated on by our marketing lead, Rachel Kai, along with RJ. Shout out Rachel, she's awesome. And with Jeroen too, who has one of our designers who is jumping in. And this traditionally, I mean, based on these prototypes are so cool, it would traditionally have been a much bigger team looping in a lot more people, probably a slower cycle in terms of how many iterations we can play with because you're basically carving out some percentage of different people's time. And so, yes, we have way more people that are becoming builders and beyond just product and design. Got it. Can we go maybe, because I think this is a good kind of priming for maybe talking about some more specifics or like examples. But like, can you share anything about a project that you guys are either actively working on or something that you've recently shipped that kind of followed a different, like if that project happened six or 12 months ago, the people working on it would have probably been different or the way it got done would have been different. And what did you guys do that you might be applying to like upcoming projects? So like, you're like, wow, that worked really well for this. Yeah, I think that was, so the landing page is one example. We have another page that is the entry point for our instructors. If you're on Maven and you want to begin teaching, that is also a outward-facing marketing page that is mostly front-end. So it doesn't require a lot of interaction. And in the past, we would have involved a lot more people to be able to get something like that out. In this case, Yuen, our head of design, basically was able to own it end to end. Including shipping the code to production. Including shipping the code to production. Yeah. So this was a little bit of an experiment, which was, as we have been entering into this phase where more people are builders, there definitely is the question of when do you install some of the gates and checks in between because you don't want a code base where anyone is adding anything. And so this was one of our first tests into that of the engineer for sure is reviewing it, making some adjustments. But when you are able to basically apply the risk level of the project up front, you can also clarify how rigorously you need to be able to have more people on it. And in this case, it's a front-end only page. It doesn't really connect to any other data that we are tracking. You can apply a relatively low risk to experiment and keep it in its own container within our code base. So even if it's not the way that an engineer might've built it entirely, the benefit of having someone else be able to create it and operate in its own space with reviews, but still the ownership is clear, is very much worth it. And I think but in reality, people are actually spending way more time with other people than they were before, which us being remote, us being an early startup as remote, has always been a challenge of how do you recreate that in-person tapping someone on the shoulder feel? And I think we are getting a lot closer to it, partly by having fewer people that are more responsible for parts. But the, we also used to have a product design review that was set time, weekly, limited number of slots. That was an important time for Gagan, our founder CEO, to give a lot of input. And we've totally broken that up too, where instead of that being a single slot that happens, I mean, his time is definitely still one of the bottlenecks. So we have kind of this more flexible office hours slot for him that happens almost daily. And there's an expectation that every week someone is gonna be grabbing his time. So you have quicker reviews based on wherever you are at, and you can, there's an expectation across everyone that you will make your time for more based on when something is ready, as opposed to waiting for when the standing meeting was set before. It's kind of like an artificial, it's an artificial scarcity of CEO level attention to say like, this only happens like one time a week at this time. It's actually something I'm, I was recently, we had Nikki Skarstad from Duolingo on our podcast. And she talked about how the CEO of Duolingo still, they still do daily design reviews, product reviews at Duolingo. Oh, and yeah, and they have a five minute, I think I was watching it. They have a five minute version and a 15 minute version. Yeah, I mean, you know, there's still like preparation that goes in, like, it's not a bunch of slop, right? But the mechanism for getting like Duolingo's leadership level taste and intuition and product sense, let's say, kind of like dispersed throughout the organization still happens, like the primary mechanism through that happens is these daily product reviews. And you are expected to kind of like, you know, if you're trying to learn the company culture, like you could join your new PM or new designer and you could like see the kind of feedback that comes in there. But she said that that's way better than she's worked at Airbnb and Etsy, like other companies that have great design culture too. And she said this is probably the one that's like leveled up her, you know, kind of design intuition in a lot of ways by having more regular touch points. And yeah, and when you can move really fast, like why wait a week? A week feels like a really long time right now to like to wait to get feedback on something, which brings me kind of maybe to like where I wanna go next, which is change management and people. As PMs have been able to build more, designers have been able to build more, engineers have been able to design and PM more. I have heard some, like PMs are not, are basically the people I hear complaining the least right now. I think PMs are really happy. PMs can, they're less blocked by people. They have the tools to kind of come prepared with more stuff to show and get feedback on. Great time to be a builder, I think, for a PM. Designers, I think, are really excited. They can, especially like the best designers that I know are really excited right now because they can build their ideas. They can prototype. They're less blocked by engineers. They can just like go into their design cave and get way more done. And they're not blocked by a PM writing a spec for them or a PRD. They can do all that stuff on their own if they see a problem and wanna solve it and get alignment around it. Engineers are really interesting right now. There's some engineers I know that companies that feel like they've dramatically increased the amount of time they spend reviewing PRs because now that everyone can like ship PRs, there's, I'm not saying it's all slop, but there's just like an increase in the overall number of lines of code that are being, you know, kind of committed to the code base at the moment. And then some of them are really excited by that. Some of them, some of them feel like they have a lot more time to build and they have better tools to build. So I'm just curious, like, that's a very long way of asking my question, which is, what are you observing on kind of like the change management side, how people are reacting to this new wave of working without, you know, divulging confidentiality. Have there been any tensions or things that kind of like have been needed to get resolved? Yeah, it's interesting. I think there is a natural cycle that I've observed in other companies, especially startups too, where you start from this team first collaborative model and PMs are usually often at the center of thinking about the, you know, the context engineering within your team. You're all working together towards that goal. There's, there's the defined roles that the most extreme other push, I think is completely unbundling the team and everyone is a, is a builder in a silo. And seeing how far you can, you can push that and only bring in the team in the collaboration points at the, at the parts that are, that are necessary, which happens to be closer towards the end when you're shipping things into production. And I, I think a real con to that approach is it like we were mentioning earlier, it creates this handoff moment to the person that ultimately might be responsible for performance or security or the system architecture in a way where that person has not really been brought along or been a part of the project before is a bit of a crummy situation. And I, I think that she does lead to, to worse outcomes if you don't get some of that, that input upfront or along the way. So I'm still in the camp of teams and collaboration matters and matters upfront. The, I think that the adjustment is still, you can, you can be in smaller teams and the way that you divide between the team might, might look different. But the, I think that the tension that I have seen so far comes from unexpected handoffs that maybe are also at differing levels of, of excitement and urgency. So it's, you know, if one person in the corner has been thinking and getting really close to wanting to ship something, it feels like you are so close to being able to get there, but in reality, there's, there's a lot of stuff that maybe if you have a specialist designer, a special, a specialist engineer, especially applying their lens, it it's not as close. And, and if they're in a silo building their own thing, it feels like it's, it's a little bit more of competing priorities. So that I think has been a thing to navigate, which is still trying to identify upfront who, who is the right team to involve. And even though everyone can still be a builder, that doesn't mean that everyone should be building everything. And I think finding a way to play to each person's strengths and get the benefit of different ways of thinking too, where I think there's some examples where it makes sense for a designer and that the more creative way of thinking to be the lead and primary responsible owner of something. And there are other ways where you might want someone that is more of a system architect to be the primary lead on, on a certain project. So I think that the tensions have come about from, I think unexpected handoffs and also maybe, maybe a misappropriated staffing in terms of who the lead is and who, who some of the other contributors are. Yeah. It seems to me like maybe the more the more given project is like using existing Lego blocks, you know, moving things around on a page, re re reorganizing maybe the UI or the information architecture, but not necessarily creating new, you know, endpoints or messing with authentication and like more sensitive things. Maybe there's more like wiggle room to kind of let people try stuff. But if something is kind of pushing, if there's like a security concern or something that comes up, then, you know, being more mindful of how do you get the team to know when, when that's the case is important. Predictions are, are really challenging, but if, if you were to kind of like take any of the early learnings over the last six months, six to 12 months, and maybe extrapolate them a little into six to 12 months in the future, are there any things that you think you guys are doing right now to get product out the door to like build, research, design, validate that you think will not, like will like most likely not be happening in six months? Like things that you feel like are on the way out. Things that we are doing today still, because we have changed a lot today versus, versus before. And I, I believe it, it is in the direction of where I expect more teams to be in, in six to 12 months, but the, One, one question I, I think I have in terms of how well we will be able to scale, especially as we have, we're expanding our product surface area quite a bit is we're in this sprint right now, a pretty defined sprint of stemming from a clear, basically company-wide strategy and, and finding ways to divide six work streams that feed into, into that single strategy. And it's really exhilarating and it's, it's really connective and, and allows for people to make easy decisions within those, those work streams. But also it's anchored on something that has to be really clear upfront and how much that can continue as a, as a steady state versus allowing more independent autonomous units that, that relate to different parts of the other product surface area. I expect we'll go into, into ebbs and flows with that where, for example, you, it's in some ways, it's, it's kind