 Tonight we have Mary Alexa Dipper from Stash, who will be speaking about product management, so welcome. Thank you. Alright. Okay, like Brad said, my name is Mary Alexa. I'm a senior product manager at Stash Invest, and I'm here to tell you a little bit about my product journey, but I also want to emphasize that my journey is going to be different from your journey as it's going to be different from the person next to you. So make sure you take all of this and twist it into your own story. I'm going to start with my trajectory, pretty common, but then I'll get into the nitty-gritty of what it's like to be a PM at Stash. I started at a small bootstrapping company called Consumer Bell, and it was five to eight people, depending on the day. Angel-funded, early-stage, jack-of-all-trades type of role where I started as an intern, and then ended up becoming a full-time marketing position. But as I mentioned, it ran the gamut, and that was where I got my first introduction to user experience by doing wireframes with the CTO. About a year after that, it went under, so I lost my job, which will happen when you're working in startups. But fortunately, we were working out of the General Assembly offices, and I was able to get a part-time gig working a little bit of the operations, the front desk there. So I was able to network and freelance and still keep myself in the industry, despite the fact that I wasn't fully employed. About four months later, a friend of mine reached out and said, there's this role open at AmEx. I think you'd be great. It's a user experience analyst role. Five interviews later, she was right. I ended up getting that job, and this is where a little bit of luck comes into play. The business unit that I was joining was jumping into a huge investment in tech, and really wanted to make this business unit the start-up of AmEx. So we did a full-on Agile transformation, and I got my first title as a product owner. So we were focused on the American Express Serve product, which I'm not sure if any of you are familiar with it, but it's the prepaid platform at AmEx. They have their own self-branded serve. There's a partnership with Walmart called Bluebird, and a partnership with Target called Prepaid Red Card. So I bounced around Web, mobile, and eventually got into the R&D team as well, which is kind of funny because we were working on facial recognition, which is now the big thing that Apple's launching with, so it's kind of cool to see how that has all come full circle. And then about three and a half years into my time at American Express, I got an email from a guy named Ed at Stash Invest. He was, or is, one of the co-founders of the company thought the mission rang true for Stash as it did for serve because we're trying to promote financial literacy and give access to products that most people across the country don't have access to or are intimidated to get involved in. And after a couple interviews there, I decided this was the perfect time for me to take a risk, and I jumped over and joined a 13-person team from a very large company. So to say that it was an adjustment is an understatement. That team of 14 is now a team of 92 in a year and seven months. So hyper growth is an understatement. It's actually been insane to watch. I've been in four different offices. You've knocked down walls in two of them and we're about to expand again. As well, our product team has also expanded. The first product manager, now there are six of us. We have UX researchers. We have designers. It's just the growth is incredible to watch. Just a bit about Stash itself. The mission is something that really resonates with me and we are doing something to help people across the country. Stash is about your financial life simplified. It's to not complicate things, to make it approachable and easy to understand. Just a quick fact, 46% of Americans can't afford a $400 unexpected expense. So we at Stash believe that a lot of that has to do with the lack of financial literacy. So in addition to offering the products, there's a huge educational component to what we are building. A little bit about product at Stash. Big launches are important, but so are the smaller iterations. That's where you're going to keep iterating and learning and using the feedback that you get from your customers. Some of the launches that I've been a part of are the Stash Invest Android launch. Auto Stash, which is our recurring feature. Our in-app referral system as well as what is now my baby, the Stash Retire product. And I'll get more into that in a little bit. Process. Your process has to evolve as much as your product. The way we worked when we were 14 is not the same way we're working now. So constantly iterating and moving into the directions where it's working to scale is something that is constant. When I started, there were no sprints. There was just a bunch of euro tickets and engineers were doing haphazard, whatever they kind of felt like. So we started doing sprints. Then we started doing camp on. Then we went into squads. The squads were framed in one way and now they're framed in another way that's more product oriented and product line oriented. So you can see that none of this necessarily has to stick. You just need to be able to evolve the process along with the product as you grow. Lean startup, I don't know if any of you have read the book, but our founders drill all of that into us. Lean just learning and iterating from that and constantly digesting all of that information is super important. A little bit about the team. The squads themselves are full stack, which is great because that small group can put something into production without the help of... Well, I shouldn't say that because it takes a village for everything and if anybody is product manager, they'll know that. But like I said, you're working with compliance if you're in a regulated environment like us. Marketing, you need to be able to message to your customers so planning out those messages along with the product launches is super important. And last but definitely not least is the customer service team. They are at the trenches of your users. They know about the problems before anybody else does in the company. So keeping that feedback loop constant is super important. Something that we do at Stash that's super exciting is Stash Labs. So one day every two weeks, the engineering and product team get to work on a passion project that relates to Stash. And then once something has come to fruition of that, they'll be able to present to the rest of the team during our demo Thursday. So every Thursday we have a happy hour in a presentation where there are company updates and some of these lab projects get presented. For example, one of the most recent ones was one of our engineers built this streamer that every time someone signed up for an account, their location would show. Or if they made a deposit, the amount would show. This was like this little streamer that just kept going and we implemented that on our website. This was something that came out of like a random Friday idea that's now live on our website. So those little things do add up. And as I mentioned, Stash Retire is what I'm currently focused on. The whirlwind that that has been has been a great experience. We started, we had our kickoff in March and had our first soft launch 86 days later, which is kudos to the engineers building this because I couldn't have done it without them. And now we're working on iterations and the lifecycle messaging as well as increasing the conversion rate. Some of the challenges I've had with this product as well as any product that you would find, well, this one is specific, but retirement is not sexy at all. No one is thinking about retirement when they're trying to pay off their student loans. So getting them to put even just $5 away at a time is a huge challenge. As a product manager, you're going to say no all the time. And like it or not, you don't want to be a dream crusher, but in order to stay focused and prioritize, saying no is necessary. You need to say no with the right reasons, but you also have to have the data to support why you're denying or saying I can't do this right now and focus on X because you're constantly interrupted by engineers, by founders, by investors, marketing, QA, which is all a good thing and all necessary to keep the machine running and the product improving, but it does take away some time during your day. A huge challenge is conversion for retirement. When we launched, the number of accounts per day is frankly embarrassing, and I'm not going to tell you what it is. But we've been iterating and learning by calling our users and we've actually improved the number of accounts by over 100% since we've launched. So we're trending in the right direction. Each day is going to be different and difficult, but the key there is that you need to celebrate the small wins. The big wins too, but definitely the small ones. And as a product manager, you have to be the one rallying that. You want to get your team excited and together. For example, when we did the soft launch for retire, it was 3pm on a Wednesday and our first retired user came through, completed their account within an hour of launching it. So we decided we're going to go to our little bar cart and we're all going to take a shot because we're going to celebrate all of the hard work that we did in the past three months. So rallying your teams to do that is critical. A few skills that I think that would help you be successful in getting to a place like this is first and foremost innate curiosity. It's funny because my uncle used to always tell me, why are you asking me why all the time? Like stop. I don't need to ask me this all the time. Turns out it's really good for my career. Asking why and asking these questions and trying to challenge the status quo is super helpful when trying to build and learn and iterate on a product. Communication is also key, clear, concise as possible. But the biggest thing is your context switching all the time. You have to be able to talk to an engineer and turn around and talk to an investor. And frankly, they speak different languages. So you also need to be able to translate between the two. Being the user advocate is key. You need to take the problems that their customers are having and tie them to the business goals. Otherwise you're not going to have a product that succeeds. It could be all fun and games, but if there's no business, it's not going to work. So we need to make sure that the problems that we're solving are the problems that our customers are having. And being the protector of your team. Just as you rally for celebration, you need to make sure that they're protected from any outside sources or distractions, especially when they're trying to be heads down and get something done. Building that trust within the squad that you're working on and within your product team is super important. And something that I like to tell people that are trying to get into product manager roles is that you're giving all of the credit away when something goes well. But if it blows up, it's your fault. You take all the blame. You shield the rest of your team from anything that happened because more often than not, it probably was a laxed requirement. The Jira ticket wasn't up to date. Something wasn't tested properly. The lack of communication. So creating that trusted environment within your squad is super important. And the last skill that deserves its own slide is making decisions with data. People talk about it all the time. And there's a reason. It's because you can't argue the numbers. It's really hard to be like, well, this is working better when obviously A is converting at 50% and B is converting at 25%. So when anytime you're interviewing at a company, make sure you know what their KPIs are. And if they don't know what they are, I would dig deeper into that to see how they know what they're doing is being successful. Anytime you start a test, knowing the baseline makes all the difference in the world because otherwise you wouldn't know whether your test is working or whether it's dropping somewhere else. And this data can go for qualitative as well as quantitative. You need to integrate the user research. If you're lucky enough to have a user research team at your company, use them as much as possible. They're talking to the users every single day, and they bring back such critical data that can make such a difference in everything that you're doing. So the other thing is if the test fails, that doesn't mean you failed. And you still learn something. You learn that the track that you're going down is the one that you should continue going down rather than trying to still throw out-of-the-box ideas out there. And software is definitely not personal because it evolves. Like I said, the way we work changes every other month. The product is going to change every other month, and the software should be keep iterating to solve the problem of today and the future of that user. And if you don't have the user research team to figure out what some of those problems are, pick up the phone and call your users. I can't tell you how many times I just spent afternoons in one of our office rooms or a hallway sometimes, just picking up the phone and seeing what pain points these people are having, how can we help them, what are they expecting of the app, and all of that fun stuff. A few of the lessons that I've learned along the way, you have to be comfortable being uncomfortable. And for example, this is my first talk like this. I'm super uncomfortable right now. So putting yourself in positions where you can kind of navigate the waters when you've never been there before is great, but you're going to be thrown into them all the time as a PM every single day. And it's okay that you don't know how to do it, but every time you're in a situation like that, make sure you bring it to the next time, you're just going to constantly improve on those ask questions. I know I said this before, but it's so important, and it's not just to the users. Ask your engineers what this means. I think I had the same conversation five times today with one of my engineers because I couldn't figure out why something wasn't showing up in the app. And when he got me to that aha moment, we were both like high-fiving each other and super excited that I finally understood something that he was saying the same thing five times over. Failing gracefully. People talk about failing all the time when it comes into product. It will happen. It happens all the time, and it's okay. Again, take the lessons you learned and move forward with it. I'm not going to just tell you that you should learn how to fail. I'm going to tell you a couple of times how I failed. One, we launched a version of an iOS app, and we messed around with the pin screen, and we didn't test marketing tags. Next thing you know, our CMO is freaking out because all of our apps flyer data is missing, and we're not getting any users, and we don't know how to do this. So we had to do a quick hot fit. Well, first we had to diagnose the issue because we had no idea what we did that would move this because you would think the acquisition one would be on the first landing screen, not on the pin screen after a user had made an app or made an account. So we did a hot fix, and now we have a very rigorous testing round for our releases around marketing and other tags as well. A more recent one. Stash retire, we're doing payday pushes because we see a higher conversion rate around complete when people have money in their bank account. It was converting pretty well at 3%, which given the audience is really good. This last one didn't even hit one. It's like, okay, this has been working for the past two and a half weeks. Why isn't this working this week? But you just learn, have retros, talk it out, and try and think of new ways to move forward. Networking is super important, but it's also important that you make it work the way you want it to work for you. You need to have a support system in a product world where you can go and ask all different kinds of things and be comfortable. And whether it's at events like this or in a smaller setting, you just have to make it for you. And finally, change is going to be the only constant when it comes to working on a product team or on a product. You have to be super flexible, roll with the punches, and just keep everything moving along the way. Project or product? Product manager. There's a difference. Sure. How do you recommend, what kind of exercises would you recommend or how would you test yourself in just being a product manager that you would incorporate in an interview process? There's a variety of things. A good one is always asking someone to build a clock. Something that everybody uses. You want to make sure that they're asking the right questions to see who am I building this clock for? Why am I building this clock? What's the goal of this? Are you trying to create an alarm clock? Or is it just to tell time? Just having them ask those questions, it really doesn't matter what they come up with. Are they asking questions to help them along the way as like a whiteboarding session? Verbal. Yeah, so like... Yeah, I think that it depends on... I would do one along with other questions around collaboration, data, if they're not asking about data or how they would affect a conversion rate. I think those are super important, too. Thank you. Yeah. Anyone else? How do we prioritize? It's a bit of a mix. The larger features are a little bit more top-down at this point because we are still venture-backed. But once the product is out itself, we've been given pretty much free range, and as long as you present it with the right data, you can get that prioritized. And it's honestly a matter of trying to solve the problems that are most critical and most important and urgent at that time. And those items are the ones that usually float to the top. Would you be able to describe a time when you did say no, but you got... Turn it around and ask them, why does it need to get done? Is there data that they have to support the reason why it's so important that this happens now? Sometimes it's truly, this investor wants this in, we need to do it, and that's happened before. That doesn't happen often, depending on where you're at. But I would turn it around and just say, what do you have to support this decision that will completely derail everything that I've prioritized, everything that we have planned, a potential release that will get everything off schedule? Is it more important than what we're currently working on or can it go into the next release? Saying no is important. So when you've gotten pushback backed, where it's like, no, you have to do this, you can't say no to me. Both, both. Definitely both. We're obviously looking at the product data itself. Seeing how that evolves and converts and AB testing is super important and we do it all the time. So utilizing those types of tools is great. But we also have squad level retros, which is, if anybody's familiar with the agile methodologies or retrospective, you get together with your team every two weeks. You discuss what went well, what didn't go so well, and the action items coming out of that and constantly improving that way. We also do that at SASH, at a product and engineering level at a whole, but just not as frequent basis. Sure, sure. So I don't work so closely with sales. It's more of an operations team as well as marketing. Marketing, I talk to every day. And for example, we're launching traditional IRAs next week in addition to the Roth IRAs that we have. So, sorry. So part of that is making sure that all of the outward facing items are done ahead of time as well. So I didn't have any app work start until the FAQs were done because I know that will take a certain amount of time, a certain amount of revisions. Then we're creating this lifecycle messaging together as well. My marketing partner obviously owns most of that, but I've kind of seen it through the process, thrown a couple ideas here and there, but it's pretty constant communication, and that's going to go with any product launch. There's a whole list of go-to-market things that you need to make sure you're doing, whether it's working with a marketing team to get FAQs out, running customer service through the new experience, because guess what? People are going to pick up the phone and call them, and if they don't know what's going on in the app, that customer is going to leave because they just had a really shitty experience and they weren't helped at all. So all of those kinds of things, and if you're in a financial or insurance or anything that has heavy regulations, you better have that stamp of approval with your compliance or legal team because you don't want anything going out that wasn't vetted and accounted for because audits happen, and you want to make sure everything is covered. Honestly, it depends on the engineer. My communication with engineers vary based on their personality, more so than anything else, and fitting to them. It's never what would work best for me. It's whatever would help them be most efficient.