The People, Process, & Progress Podcast - How to Produce Powerful Product Solutions in Fintech with Canopy's Technical Product Manager Jillian Funes | KEV Talks #20

Episode Date: February 7, 2023

In How to Produce Powerful Product Solutions with Jillian Funes, I was fortunate to speak with Jillian Funes, Technical Product Manager at Canopy Servicing. During our fun discussion, Jillian shared how she started in the Tech sector after transitioning from Psychology. We also learn how Jillian didn't enjoy Project Management very much, but that led her to a career field she enjoys, Product Management.Essential Product Management Tips:Use the R.I.C.E. +D methodology when working with clientsDetermine if you can solve one or many customer's problemsUse the "5 Whys, 5 Times" approachDiscuss whether the solution aligns with the company's objectivesand more!Thank you for listening to How to Produce Powerful Product Solutions with Jillian Funes. To learn more from Jillian, connect with her on LinkedIn here. Learn more about the Fintech solutions Canopy provides at https://canopyservicing.com/.If you found this episode helpful, please leave a review on Apple Podcasts, subscribe, and share with your friends and family.Godspeed,Kevin

Hey everybody, thanks for coming back to the Cap Talks podcast. This week I get to talk product management, which is an area I am not nearly as familiar with as I am with program and project management. I'm lucky to be joined by Jillian Funes, who is a technical product manager at Canopy, which is a financial technology or fintech company. And we had a great conversation. She taught me about product management and that kind of life cycle, as well as about her background, starting from an engineer, how that helped her,

and the process that she and others at Canopy use to put out good products and kind of that vision of what it takes to look at solutions, not just for the individual, but maybe for multiple people. So thanks for joining us. Let's get into this episode after a brief intro. Thank you for choosing the KevTalks podcast. Let's get logged on and get locked in as we share people's compelling stories, talk about industry-leading best practices, and the hope that we can all make progress together. But for now, let's fly back into this episode in three, two, one. Hey, everybody. Thanks for coming to this episode of the KevTalks podcast. I'm your host, Kevin Pannell.

If you've listened to this and hopefully you have, I talk about program and project management quite a bit. What I'm not familiar with is product management quite so much, but fortunately I have Jillian Funes. I just grouped that up and we just talked about how to say her name. Jillian Fes here with me and she is a technical product manager with Canopy who is going to give us some key steps of how to do product management, some things she's learned along the way. But first, we're going to

thank her for being here. So thank you so much, Jillian, for being on the Cap Talks podcast. Oh, thank you for having me. Excited to be here. Absolutely. Absolutely. Man, I can't believe I botched that and we just talked about it. Oh, well. Yeah. But you know what? We're here and fortunate and I really appreciate the time. Again, I'm looking forward to learning about product management because I am usually a consumer of a product, whether it's multiple projects in a program or I'm doing a project with a vendor that has a thing we're putting in somewhere. So it's really cool to hear about the other side of it.

So let's hear about your side, like where you came from, what kind of took you from your life into product management, and then we'll get into kind of sharing some of those best practices with folks. Yeah, sounds good. So I started out in my career as a software engineer. But to be completely honest, like if I'm backing up to like where I came from, I grew up in like maybe not the best area in the world. Not the worst, but definitely not the best. And we didn't have a lot of computer classes at all. So I genuinely,

this sounds ridiculous looking back, but you know, mind you, this was was 10 15 years ago at this point um in high school i did not know that like software engineering was a job you can get into had no idea the only computer class we had was keyboarding so when i like was looking for college and what i wanted my career to be you know you're 18 i have no idea I've had such a limited view of the world at this point yeah it's honestly the most random one I was like a psychology that sounds interesting I guess I had no real interest in that whatsoever um it was about honestly like a month before classes started maybe even less and I was on I went to Purdue West Lafayette and I'm on their website just kind of looking through majors like getting prepped and I was like oh this one looks interesting and

I'm like reading about it I actually went for computer information technology which isn't pure computer science but you know as I was reading about it, what it encompassed was almost anything you could think computer-wise. So you could come out of there, be a software engineer, you could be a database admin, you could be a business analyst. It kind of covered everything. And the thing that really stood out to me, though, was the web design and development. Gotcha. And the one thing that I got really into for a while, if you remember the MySpace days. Oh, sure. Yeah. Yeah. I loved making MySpace layouts,

like very basic, basic HTML, CSS. But in my head, I'm like, oh, if I can do this for a career, like wait, people would pay me for that that's wild so I was like yeah definitely switch um yeah so ended up going to school for that wasn't really sure exactly what career path I wanted to go into because as I started getting into the classes I was like oh business analyst uh data that sounds really interesting as well um But ended up going the software engineering track, of course, went to a big fortune 500 company straight out of college, got my first job there, moved up pretty quickly. I started leading projects, and then I started leading my own team. But I had to work on a ton of really interesting things there. I primarily worked in the sales and order

management area doing custom order management and inventory management websites for like internal usage. Okay. I also got to work on our very first proof of concept business intelligence project. So I got to be the ETL developer on there. I got to build our chat bot, which like using machine learning, natural language processing, like I hate to make it sound like 10 years ago. Yeah. It's kind of wild to think that

it doesn't feel that long ago. I'm 48. So 10 years is nothing to me. So it's funny when you talked about HTML. And the only thing that sticks in my head when we used to have to, you know, make websites was like Ahref and then something but I know I can't remember anything else. Yeah. And then talking about my shoes. I don't I don't think I ever had a MySpace page, but certainly know how big it was before the Facebook and then before they dropped the Facebook, I saw the movie. But you know,

they talked about that. But yeah, it's interesting. And funny that you started in, it was psychology, right? Or thought, because I would imagine even though maybe you didn't get too deep into that, you ended up using that anyway, when you get in people's heads, like, how do you want this built? What should it be like? And then in dealing with so many different projects and building products with that big company, you probably had to deal with a lot of different personalities that was probably helpful then for now. Is that true? Yeah, that's definitely true. That's not how I viewed it back then. Yeah.

That's a little bit more insightful than I was at 21 coming out of college. But yeah, in retrospect, that's definitely true. Cool. Well, it's easy to sit here and listen and go, oh, here's how it goes together. I know it's hard for ourselves sometimes. But yeah, so the reps that you got to put in with the big company, right? Did that give you kind of a big flavor for all the different things you can build? And certainly it sounds like you built on building the MySpace pages and those skills,

but then did it start to also expand your skill set into other areas that started leading you kind of down a path of product management? I wouldn't say really there did too much. Oh, okay. While I was there, I actually worked on getting my master's in project management. Yeah, didn't end up really loving that either. I jumped around a lot trying to figure out a place. But yeah, so I ended up being there for about four years and then moved to a FinTech company. And I there as a software senior software engineer for

four years and then we got acquired. So then I stayed there for about another year after that. But before we got acquired, we were such a small company. This is where I really started picking up those product skills. Okay. We were so small that there were three people on the IT team. Oh, wow. And I mean, like anything tech related, because there was no designer, there was no product team. There was none of that. It was, hey, Jill, we have this idea. Hey, we have this problem, like very vague.

Like, can you build it? Right. I loved that. I loved the autonomy to be able to like run with it, to just deeply understand that problem. Okay, like, how can we best solution for this, I got to design it, build it, architect the database, and own it all the way through. So when we got acquired, they had a product team, they had a design team, they had all those different things. So I knew a lot of those responsibilities were going away. Okay. So I started looking at, okay, like, what am I going to do now? And that's when I realized, okay, I think product is definitely more of what I'm looking for and where my interests truly lie.

And so you weren't into the initiation phase and planning phase and going through that whole thing or, or agile, which will, will, I'm sure we'll touch on, you know, process here in a bit. What about project management? Did you not like, what was your kind of overarching thing or was it a series of things? I would say it was like a series of things and I don't want to offend you because I know you really like. Hey, I am super objective about it. Yeah. Good and the bad. It just, it didn't feel like I had a lot of autonomy for problem solving.

It just felt a little bit more like tedious work to me instead of like tackling bigger problems and um i'm a little bit of an outlier when it comes to engineers i am very analytically and data focused by nature but i have like this deep need to be some type of creative outlet. Okay. So like that problem solving and a little bit of design and working with marketing and just wearing all those different hats is really weird. So making a fancy PowerPoint wasn't enough design work. Yeah. It wasn't really doing it for me.

Yeah. Updating the project plan. Also, I also partially blame my microsoft project that was what a nightmare it's something it can be great super easy like let me plug some dates in and watch the magic that this thing does to make a game chart or whatever and then yeah it's it can be tedious i just i in the episode um that just came out um i actually interviewed my former pmo director and so it's interesting

you touch on one of the great things she did is the balance of like, let us think with you're locked into this process, which can be awful, right? I mean, when you're sitting there going, wait a minute, I'm right here. And it doesn't make sense for us to do this. And then either the process or a person or something is like well you have to because this is what it says in the book and this is and you're like that's great but the book's not here doing the work right um so yeah honestly not surprised not certainly offended as a pmp uh we touched on that too but but anyway yeah so i i can see how the creative you know part of you needed more expression it's funny I just thought about,

did you see the movie, the other guys, Mark Wahlberg? And he's like, well, Peacock, I need to find you're like, okay, I've got to break out of this, whatever we're using this project management and do something. And you had a taste of that, which is awesome to build things and liked it. And so how did you make kind of the switch? Did you kind of request the change or was it just, you were able to stay in the same position, but then, then branch out with a different focus? Oh no. So I jumped companies completely. Yeah. I, I sat on, I mean, so after we got acquired, I, you know, thought about it for a while. I knew pretty quickly. I'm like, I, I know where this is going. It's going to be. Here's requirements, do them. I don't want to know what your ideas are. Maybe I'm being

exaggerating, but yeah, I, I sat on it for like a year. I was like, I think I want to move into products, but that sounds pretty scary to completely shift career paths and shift companies at the same time. Because I did think about, you know, what if I just asked them to move into products? But having I just the situation that I was in. Wasn't the right fit. Yeah, they really needed engineers. Okay. So I knew that wasn't going to be their preference at all. It was going to be an uphill battle.

And also, product isn't, it's a little bit nuanced between companies. It's not the same across the, like, if you're an engineer, you're an engineer, and you're doing different things, and it varies slightly. But product can vary quite a bit. There are a lot of organizations where you're really more of a project manager than a product manager. So I just didn't feel like staying there was the right fit for me. I had been there for five years, like getting back to the peacock reference, like, I can't fly. I got to get out of here. It's interesting you say that about the product manager would seem more like a project manager. Because if you just look at kind of the landscape

of what's out there for jobs and things like that, and you can see that in different postings, and you're like, you know, or even if it's a project or program manager, like they really want an engineer that they're calling this, or they really want something that they're calling something else, you know, and it's confusing, I would imagine, too, for folks just getting into the workforce that are transferring that want to do things too. Yeah, so it's, I mean, it's,

it's good. You saw that, though, and we're like, I'm out, you know, so did you were you able to find, you know, that connection to the product management world? Just kind of like folks do, like, hey, I'm gonna look for job go somewhere else. Did you know somebody that connection to the product management world, just kind of like folks do, like, hey, I'm gonna look for a job, go somewhere else. Did you know somebody that was doing product management that gave you kind of more scoop? I didn't know anyone in products. I mean, so I didn't utilize my LinkedIn maybe as much as I should. I knew a few folks from previous colleagues that ended up being in product after I looked later. But the direction, I mean, all my close colleagues were all engineers, so had lots of engineering friends, not many product friends yet.

But what I ended up doing was, you know, like I said, I was owning the process from an end. So a lot of the things I was doing already was product was one of the many hats that I was wearing. So I really just doubled down and focusing on those aspects, making those one of the many hats that I was wearing. Okay. So I really just doubled down and focusing on those aspects, um, making those more of the highlight of my resume rather than like, I know Java and C sharp and I, you know,

like these really specific technical terms, uh, put more highlight and emphasis on the product items. And, uh, I was really particular on what company I wanted to go to. Like there was specific things I was looking for. So once I decided to like make that shift,

I actually put an alert on LinkedIn jobs and would just check my email every day and apply to the ones that I felt like were really what I was truly looking for. Cause I wasn't in a rush. I loved my last company. I really liked everyone I worked with. I loved what I was doing.

So I wasn't in a rush. Just kind of took my time and waited for the right thing to come through. That's good. There's tip number one, not necessarily in product, as we say in the biz. I'm just saying it cause you said it. LinkedIn alerts seem to be pretty helpful, right? Let you know what's happening and what comes up. Yeah. It's actually how I got my previous job as well. I, again, wasn't in a rush to move. I

was mostly happy. I just felt like it was the right time for me to spread my wings. Gotcha. That's awesome. And so circ circling back and i meant to do this because i know so i came from like public safety emergency management world and in the military we have acronyms all over the place right so when we say fintech we're talking about financial technology yes right yeah and so yeah i was like oh yeah i should have said that earlier um but so to that point did you the company you wanted to go to also in FinTech, is that accurate? And so, so then you jumped over there, the alert went off, you jumped over there, it worked out. I mean, yeah, there were, at the end of like my interviewing vetting process,

there were three companies that I was kind of between. And yeah, ended up going with Canopy largely. So there was a few things that made me go with them. But the primary reason that really shifted, you know, you kind of have like a mental priority list. Like, oh, I like this company. The thing that really bumped Canopy to the top of my list was the interview process. And like the people that I met with. When you're in an interview,

it could feel like you're being judged or they're just like, ask a question, take notes. Like, what did you write on that paper? Interviewing with Canopy really felt like I was already working with colleagues and the types of things and case studies we were working through. I was like, oh, if my job with them is anything

like the problems we're tackling in this interview, I know I'm going to love it, which ended up being true. So that's great. We are. Yeah. That's such a huge difference for, you know, especially in the past, what year, year and a half with people leave and lay out, all that stuff is that people connection right from the start seems huge, right? And how you can tell it's great insight that you share there. When you go to an interview, particularly if anyone's listening, you're just getting into the workforce or haven't been in or whatever, and just haven't been in the interview process for all or we're somewhere for five years, that's a big gap between interviews, right? Of that feeling of, oh, this feels like I'm here is

awesome. And it's great to hear that and to hear that about Canopy and for you, because I imagine that real excitement you get when you're going to a new position and you're happy to go there. So that's pretty awesome to hear. What. What else about their process kind of made you choose them? So there were, I mean, the company as a whole were things I was looking for a startup. I preferred to stay in FinTech. I was looking for something that was remote. You know, like the basic things. But also on the job description, I can't remember the exact breakdown but they put a breakdown like

here's roughly how you'll spend your day you'd be like 30 doing this 20 with the you know meeting with the team and socializing ideas and 10 of your time will be having fun and relaxing and it just i like i i could picture myself working, that sounds like a day, like, if my day actually went that way. Yeah. And the last thing was, and it kind of gets back to like making that people connection, prioritize their values. They have like six values. Most companies have values, most companies throw them up on the website, but they specifically look for values matching in the interview process. Oh, wow. Which is what I think helps make that people connection, right?

Because if you have shared values, it's going to be a lot easier to work together and get along and feel that connection together. Yeah, Great point. It, yeah, it is nice that they're tangible, not just on the website or the, you know, and that, and the full company meeting, if we will leave that one there where they're like, here's what we're going to do for the world. Like a poster on the wall. Like, okay, we did it. For sure. Yeah. I mean, there's, there's no pun value in having the values, but yeah, when you can actually kind of personalize them and make

someone feel them, that's great. That's awesome. So how, how was your first, let's talk about maybe your first year with a canopy, not official things that HR will get us in trouble with any, like, you know, behind the scenes secret sauce, but when you kind of got to where you wanted to go and then let's, let's share with some folks, you know, some best practices you started picking up and, and with that. So, you know, how did they, how did they bring you in and kind of, how did you become part of the team, build a team? How'd that go? So I will start with saying, I should have clarified this, but we want to know how my first year went. I will let you know in six months. Cause I only started there back in July.

Boom. There you go. Yeah. Yeah. Pretty. This is all pretty fresh. Everything I'm talking about is very, very fresh for me. That's great. Yeah. And as far as like coming into the team. So one of the other aspects that reminds me of like why I went with them, there was no team at the time. There wasn't a product team, it was a product person. It was our head of product and they were building out the team. So it felt like a really amazing opportunity to be on the ground floors of building the foundation of what could be a really big team ultimately. So yeah, after I hired in, shortly after that, we had one other person join and we just had someone start this week. So we are now a team of four. And what's really fun about that is you get to like help figure out what's the best way to operate.

What are the processes? What are the norms that we want to adopt? And one thing we've done that's made a huge difference we just started this in july um up until july or i'm sorry january like you know 26 days ago yeah yeah um prior to the new year we were like straight departments really like product engineering back in engineering front end engineering design you know whatever um At the beginning of the year, we rolled out a little bit of a structural change in the organization to more so focus around pods. It's like a team. So teams that have shared goals and metrics and areas that they're focusing on.

Okay. So that's helped a ton, like create focus and feel alignment as a product person. It's interesting looking back having been an engineer, and, you know, working with other departments, it, it feels like, how do you not know what the status is, like, this is all I've been working on. So like, as a product, like coming on the other side, I'm like very cognizant of like, Hey, kind of need to know where this is at, but I don't want to bug you. Right. So trying to figure out what the right way to do those things are and to make it as frictionless as possible has been, you know, that's not the primary point of my job, but it's been a fun

portion of it. It is. And so these pods you said there, so the pods are multidisciplinary. Yeah. So it's okay. Cool. Um, you know, a PM, I'm one of the PMs on a pod, and then we'll have some backend engineers, a couple of front end engineers designer devops and

all working together on different projects and tasks so cool that um for all my incident management public safety goal that's a task force with mixed resources uh that's that's really cool to hear and it is a challenge right with um and i'm experienced that now or another um you know when i've been kind of the program manager of other project managers, like how do I get status without making status a pain in the butt and extra administrative overhead? Cause there's gotta be some, there's, you can't get around it like, or how do I grab it on the backend of a system that if they just do their job, I can just have it. You know what I mean? It is interesting too, which I'd be interested.

Are there any tools that you can share that you all use, whether it's product management or even program management, but it's used for products or all of those that can do that, that kind of grab, you can see like percentage complete on this or stage of whatever build or something like that. Absolutely. So you might have to reel me in on this one because this is turned very quickly into my favorite product so

when you go into product interviews they always ask you like what's your favorite product um this would probably be my answer now it's notion notion okay yeah so when i started i had no idea i had never used Notion before. Canopy was already using it. And I didn't really get it. It's like a shared note-taking. There's a native app for desktop, and then you can use it on the web as well. Okay.

But the incredible flexibility of it, so you can on the spot, the way you do it is create a date table be really creating a database and until it's really hard to explain so shout out to the notion product and marketing team because it's a little bit of a difficult concept until you really get in there and start playing with it okay um when i very first started i I was like, okay, it's like a, like an Evernote or a OneNote or something. Gotcha. Okay. And then it was like, oh no, this is way better. Oh, wow. Yeah. So I'm probably going to butcher explaining this. Like I said, cause it's a little bit of a difficult concept to grasp conceptually, but you can create tables in a notes page.

So we can have like, so one thing we do is we have a giant table of all of our product initiatives and excuse me, within there, we have columns that for all of our like rice scoring. So for product world and anyone listening that's not familiar with rice, rice is reach, impact, confidence and effort. It's a way to it's a prioritization framework. So you can have columns for that. You can have columns that are relevant to engineering and then you can do different views of that. So anyone listening is familiar with database structures. It's like you have your raw table, and then

you can create all these different views from it. And you can slice those up, put them on different pages, paste them around, and it just makes it insanely flexible. You have multi-select dropdowns. You have checkboxes, like all different types of controls and data types within it. It's just so flexible. So I'll get off my note. So that's cool.

But yeah, check it out. It's very cool. So it's good for the team user friendly wise. And then it's also good for like a team lead to then grab info. So if like your head of product says, Hey, Jalen, what's going on with your pod? You can quickly go boom and grab info from any of those tables or columns or anything that's happened there. Exactly. Or just share the page with them. So I can have a page that's got a view that's better fit for engineering. It's got more details. Then I can have like a more executive level page.

It's like, Hey, here are the columns you really care about. Here's the status. Here's the day we plan on having it done. Here's the leads on it. Whenever you want to see where we're at with something, this is where you can go. We're still refining that a little bit and learning as we go along. But yeah, they're not paying me for this, but they should. We can tag them in the post and all that. Yeah. With the asterisks. No compensation. Yeah, that's one thing for me I like about Teams is it can be pretty dynamic with apps and things and not as we're talking about Microsoft Project and other, we'll say, older tools and things.

Teams, I think, is pretty flexible. I like it from that, from the boards and things. And to your point, it can be dynamic and just pull data from somewhere else, those kind of things. But I'll be very interested to check out Notion. So I'll give that a Google and get my expert search going on there. So with Notion, with what you're doing in your pod, what are some things that you've picked up that we can share with folks listening as far as kind of from, hey, I'm a client. I have this idea. If that's even how it starts, correct me if I'm setting up this scenario incorrectly. And then I say, can't pay any fintech solution. And this is what I want.

Here's my proof of concept, which I would imagine varies in its completeless or not, completeless or not, but don't let me guess for my aspect. So can you kind of walk us through the process from my thought as a customer to when the products release? So that's a pretty common thing for a customer to come to you and be like, Hey, I have this idea. What if you did X, Y, Z, like very specific solution. And that's a, it's a common thought. It's like the way we think about things. It's the way most people tend to go. As a product person, it's part of my job to go, okay, that sounds cool. But like, let me really understand the problem you're trying to solve. Like the root of the problem you're trying to solve. Like the root of the problem

you're trying to solve. It's not like, oh, well, the problem I'm trying to solve is I don't have a page that has a date picker on it. I don't, you know, that's a terrible example, but you get where I'm going. And it's like, okay, but at the core, so you like, if you think about first principles, five whys, if people haven't heard of the five whys before, it's like, okay, well, why do you want that? And then you ask why five times in a row. And the idea is that the last time asking why, you get to the actual core thing that they're trying to solve for. Now, I don't very tactically go through that with a customer, but just kind of asking them questions, understanding what they're trying to solve for. And then also part of product role is to understand their problem, understand the pattern

of, you know, are other customers asking for that same problem to be solved for. Two, three customers might be asking for different solutions, but at the end of the day, excuse me, I've been talking all day. That's all right. At the end of the day, the real thing that they're trying to solve for is the same thing. So if we did this one thing, it solves for everybody. But the other thing I need to take into account for is what's the company objectives? What's the direction we're going? What's our strategy? How does solving this problem for the customer, does that align with our strategy? It may or may not. And if enough people are asking for it, then it should, or maybe we need to think about the direction we're going.

Sure. And customer, these are internal or external or both? then it should, or maybe we need to think about the direction we're going, but. Sure. And customer, these are internal or external or both? External. External. Okay. Yeah. Past life was old split, internal, external. But right now is all external. So cool. Cool. So yep. Keep going. Sorry, guys. No, go for it. Yeah. Just running down. So you're really helping them go. So what is the actual problem? And then it sounded, and then you said, are we going to figure this out for one client or at the same time, can we figure this out for multiple clients? Right. Cause then you

have a more kind of evergreen, so to speak, product, if that's accurate. And just honestly, you can sell more of them because more people use them, right? As a product, I really never want to solve something that only solves for one customer. Even if only one customer ends up using it, it should be done in a way that can be used by multiple customers. Gotcha. That's a great point. You know, adding a dropdown that says customer XYZ status. Like, okay, well, instead of adding a very specific status, if the problem is that the statuses that we provide in a dropdown

aren't dynamic enough, then maybe we need to think about providing a solution that allows any customer to add any status. That's just a little bit more of a concrete example, but it's not something we've done before. That makes sense though. I mean, because then a customer's not stuck, so to speak, with this, and then you change a little bit for the next one. And I would imagine maintenance-wise, if it's for multiple folks instead of a bunch of one-off products that's just easier to do right and more efficient definitely easier more efficient higher impact higher reach and also ease of maintenance moving forward you're going to create some insanely difficult code to maintain if you're doing very specific static solutions for each customer request.

Gotcha. That's a great point. There's always a laundry list of those types of things that you need to think about. So prioritizing them, thinking about the big picture. And I think I mentioned already the RICE framework is what we use to prioritize. Can you repeat what that is one more time? Yeah, the RICE framework is just a way for prioritizing product features. And it just stands, it's an acronym for REACH. So REACH being how many customers is this going to be helpful for

impact? What's the impact? Is it going to, you know, it's helpful or is it like, whoa, this is a game changing differentiator for us. Confidence, how confident am I in, you know, this, these assigned values and the task that I'm referring to and then dividing that over the amount of effort that it's going to take. It's like, yeah, all those things might be great, but it's going to take us three years to build. Like, OK, well, it's going to drop the score quite a bit and just ends up giving a number at the end. So it's a formula and that produces a number at the end. So it's a formula and that produces a number at the end. We have internally actually rice is a very well-known product framework. Okay.

We've added our own spin on it and we call it rice. The D standing for date committed. So if you hear that going around and like, we totally came up with that. So. Awesome. You heard it here first. Cap Talks podcast. There you go. Breaking news. I said earlier, it sounds like radio, even though nobody's going to hear this until I upload it, but that's cool. But then the world will hear it literally. That's great. And

that's a cool with my, as much as I am a program project manager and like process i also from knowing when i used to show up somewhere and someone was missing or there's a big fire we needed to just feed the whatever it is like your process helps you know the base but when you show up and it doesn't fit like throw away what you don't need and use what you do so is that a similar in one you preempted the other follow-up i was going to ask is, is there like a, like a weighted score associated with each of these? So you kind of plug it in and it's not like, well, that's about that percentage.

So it's, so you kind of use a scale, which it sounds like, which is great and, and makes going through that measure easier. Right. Cause there's, there's less guesswork.

Exactly. Yeah. Yeah. It's a formula. So each letter of the acronym, you assign a numeric value to, and then you. It's a formula. So each letter of the acronym you assign a numeric value to, and then you plug it into the formula, spits out a number, but to your point, yeah, definitely can't just take it at face value. It's like, oh, well this is the highest race for let me just blindly start, you know, you, you know, use your, your other knowledge and context to fill that in and

make the best decision of what needs to be tackled first and what's going to have the biggest impact to the company. So, yeah, I was going to say, I imagine something can get a really good rice score, but it doesn't fit with the company's objectives. And so you're like, could we do this? Sure. Is that a road we want to go down? Maybe not. I guess. Does that happen very often? I don't think that's come up too much yet. No? Okay. I mean, I'm sure it will. I think the reason that hasn't really come up is because that board that we're looking at has already been mostly vetted.

Okay. Okay. Yeah. These are things that we feel somewhat inclined to consider at least putting on our roadmap. So they've been riced when they get to the board ahead of time. Maybe more like finger in the air, like, eh, that doesn't, that's very clearly not the direction you want to go for one reason or another. Or honestly, more often than not, it's like getting back to when the customer suggests a solution, it's like, oh, well, the core problem

that's solving is already solved by this other thing we're tackling over here. Oh, nice. Yeah. And that's a good thing. It sounds like too, too, in product management to know, right? You can know how to solve a problem when someone brings it to you, but it sounds like you should already, what are the other solutions you already have, right? So you could steer them either way. Yeah, I mean, that's a big one too.

You ask for a very specific solution and it's like, oh, well, now that I understand your problem, we actually already, this is not an uncommon answer. Like we actually already support that. Nice. And here's how you achieve it. So in that aspect, it's more feedback on me of maybe I'm not communicating the power of our system or maybe we need to adjust our documentation. But something, you know, a big part of product management is communication. And so that's an indication to me that there's a little bit of a disconnect in the communication portion. So, okay. Great. Ownership to say like they didn't understand as a, I mean, to not say that and be like, oh, we need to, we need to communicate that better. That's, that's on us.

That's, that's awesome. So we, so I brought you a problem. You asked me why five times. I'm frustrated because you just asked me that and I'm shaking. Five times or so. You can. Yeah. Does it match the objectives? Five. It's been rice, which means we evaluated the reach, the impact, that we're confident or not, how much level of effort it seems for all work is something that should be applied in every industry every industry right and that's one thing i've seen with folks like yeah let's do this project here's all the money and you're like oh it's going to take two years and you're like oh

wait that's we didn't know that you're like you should probably do that up front that's one thing i've talked about and and talked about with my former funeral director and on other episodes of just like the intake of whatever process like it has to exist because you'll because there's plenty of stories with millions of dollars spent and and a couple of details could have been like that's going to be too much effort or it's little to no effort and we should have done it and it would have been awesome or something so um and then the date I do like that the y'all added the date because that does give kind of a concrete like we've committed to having it by this date right or could it also be that the customer wants it by a certain date or or is it more that that

you all say you you can or can't or kind of a mix of that it's more so actually the customer aspect so when you're dealing with um external customers obviously they have date expectations so if we've committed to them yeah we'll have it by this quarter. That should significantly bump that score up because we've signed a contract with them. So yeah, we should probably make sure we get that done. Yeah, that's great. That's a great, I like that. I love that acronym.

That's great. And it's not rest, ice, compression, elevation for my former medic days or when you sprained your ankle. But that's what I thought of and I bet I'm not the only one. So if you're listening and you thought of that, we're over the same mind, but it's not, not this time. But if you do sprain your ankle, rice, or you're making a product.

You need to prioritize products. So for, okay, so let's dive into, so you've got your rice score. This one's at the top. Hey, Jillian, you and your pod knock this one out. How do you take that back to the team and kind of bring them together? What, how do you, how do you get that multifaceted strike team working together? So two things there. One, if we have enough conviction evidence behind it, I'll just take it to the team. But if we're like, okay, we really

want to vet this out a little bit more. We'll do an intermediate step where, and before we, you know, to your point about like cost and effort and all that, before we start committing engineering resources, I'll go out and build a prototype, put it in front of customers, get their feedback, and then bring it to engineering. You know, maybe it fails immediately. They're like, this isn't, and then bring it to engineering. Maybe it fails immediately. They're like, this isn't useful. So, okay, great. We saved all kinds of time and effort there. Let's say all of that is done. We have a ton of conviction. I'm super big on collaboration. I have a lot of value in thinking that engineering no one knows the system like the engineers do so not including them in that those initial planning phases you know there's some different opinions there but I'm very much of the opinion of let's just get everyone together because this

is whatever we decide here when we're like doing initial scoping and planning is going to affect everyone so if it's just me doing that well i don't know how that might affect engineers i don't know how that might affect the designers or if you do it in more of like a siloed waterfall approach yeah okay i came up with this scope and now i take it to the designer and they make designs and then engineering goes, what? We can't, no, we can't do it. So now you have to go back and say, let's just get everyone together. Make sure the solution that we come up works for everyone.

And then it really just kind of goes into normal project planning phase. You know, just doing initial, that gathering to talk through the problem and proposed solution how can we go about this doing the scoping okay how can we now we know the scope is going to be what's in scope without of scope who our target customer is like having those personas and user stories of like okay when while we're going through this process of designing the solution, we should all have the same persona in mind of who we're building for. Because that really changes how you build something. Right. So if I'm building for an admin type user that's not technical at all, that's going to be a very different solution than if I'm building for a developer who's very technical. So going through

that process with that persona in mind, breaking it down to milestone tasks and regular project planning stuff after that. Then the exciting stuff. Yeah. Yeah. That's great. I couldn't agree more with or disagree if somebody disagrees, but it's my podcast, so I can say it. If you don't involve the people that know what to do early and tell them, like, here's what we're doing, that's just not helpful. Especially for me, I'm not an engineer at rights or a coder or anything, so I'm not going to take that to me. So real quick on that, how long, what's a, what's a appropriate kind of, like, if you can build it in this amount of time, then you'll, you know, do a proof of concept. But if it takes over kind of X amount of time, like, would it be like two days or something or, or longer than that? Or what do you think? Yeah, that's a great question. I don't really have a very specific defined way of thinking about that. I probably should.

It's a good call out. Boom, we're going to add a letter to Rice. What else can we do? It's more like an intuition type thing where, you know, based on the Rice score and it's like, well, you know, the Rice score is really high, but we haven't heard a lot of feedback from customers on this. So I guess it's more so like, yeah, the Rice score is really high, but we haven't heard a lot of feedback from customers on this. So I guess it's more so like, yeah, the rice score is really high. We have a lot of conviction behind it, but we haven't heard from the customer. So we can hypothesize around what would be helpful to them, but will be way more helpful is if we just get something in front of them. Because if you ask, you know, like that is that Henry Ford quote where you he says, if you ask a customer

what they wanted back in the day, they would have said faster horses. Yeah, really. What they wanted was a car. So you get a lot better feedback when you get something in front of them to look at. So that makes sense. And I love the concept of the persona and seeing this, especially in, I mean,

and what you do and what other folks do, it's easy for, and when I, you know, did any technical stuff to get lost in that and be like, well, this is just how it works. So they're just going to use it like this.

And you're like, that's an awful way to push stuff out, whether in any, in any way. Right. I mean, it just, it just is. And sometimes though, but also balancing some of the requests can get crazy, I would imagine.

And just do this or just turn that on. You're like, it takes a lot more than just flipping the switch or hitting this keyboard. But I think thinking of a persona of who is the customer, who's the person using it and keeping that front of mind. It sounds like in product management and similar for if we're going to work with someone that made the product to then do this program or project, same thing because the behind the scene folks can get lost in that. And I think it sounds like that's where you as leading product managers and then getting in the project stuff, that's

an invaluable thing to keep that front and center, right? Especially it's, we've been doing it a while. We're all tired. It's working. It's not working. All the back and forth of that. It sounds like that can be challenging too. Exactly.

And I will add, it actually makes things a lot easier. So if you're struggling like, oh, should we do this or should we do that it's like okay well let's the more you can really deeply think about okay I am this person I am using this thing right now what are the the things that I care about what would I want to do and usually the answer becomes a lot more clear at that point like oh should we do this or should we do that it's like well if I were this person and I'm very technical and the thing that I really care about is doing my job faster, the answer is clearly A over B or whatever the situation is. It actually helps answer questions and makes things go a little faster.

That makes sense. So we've made the product, we're going through the phases, we're building it. There's a lot of back and forth, I would imagine. Build a little, test a little, build a little, test a little. We've gotten our feedback and we're going to do some steps. What are the steps to get us to release this product? Is there something similar to kind of a user acceptance type of thing? Or how do you conduct that and then kind of get it, I guess, either to just the customer or to the market? Or that can happen, you know, kind of a hodgepodge question there, but can that happen

simultaneously? Yeah. So again, I hate answering it depends, but it depends. It makes sense. Yeah, sure. Yeah. It really does depend though, because if we are building something that's very specific for a customer, so Canopy for a little bit of context here is a loan management software. So the thing we're really, really good at is honestly math, like doing all the calculations for your money. That's our sweet spot. So, and it gets insanely complex. So if we're building a new calculation, say interest calculation for a customer, it can be a pretty complex thing. So yeah, definitely getting use cases in front of them saying, here's what the calculation is. When you put this input, this is the expected outcome what was the actual uh normal test cases but

there are also products and that aren't built for a specific customer so if we're just building some so i'm on a project right now where we're building that we know that all the customers moving forward are going to find it useful, but it's not for one in particular. Then, you know, it's more internal testing and, you know, regular testing stuff, integration testing, QA, that sort of thing. And then obviously I'd be playing with it as well. So you track all that all in Notion. So it's kind of the all in one system. Again, not sponsored, but it was brought up earlier.

So we're talking about. Yeah. We do also use linear for engineering ticket tracking. Okay. But yeah, Notion as much as possible. I'm really big on like, it will be used and seen if it's all in one place. But you have 10 different tools going around, it's going to get lost.

People aren't going to look for it. They're going to forget about it. So yeah, I try to keep everything in Notion outside the fact that I love it. Keeps it all in one place, easy to find and see. That makes sense. Is that a process you would recommend? Because even though it's internal, the ticket, right?

So tickets for the engineers. So working on these, tracking with tickets, as we know, and I imagine you have seen sometimes requests come in via email, maybe not a great way to track things. So is your standard to use ticket tracking for change requests, updates, enhancements, those kinds of things to the product as it's going? Yeah. So we do use internal tickets. And then, like I said, we have like a big product planning board. So it's like all the product initiative tasks. And we like to tag or tie each of those initiatives to a linear ticket, like a parent ticket. And then within that ticket, yes, I'm like,

as I'm saying it, like it sounds like a lot, but it's not that bad. It's just making that divide between product and engineering, but then also having that bridge. So there's the product planning task and then there's the linear parent. And then under that are all the smaller linear milestones and tasks um but having that link so getting back on my notion soapbox yeah there's a lot of

integrations as well so when you paste a linear ticket into notion you get like a little preview and you can see the status so okay cool yeah i'm more familiar with like service now, but the parent kind of child ticket concept is great. So you can, so if someone says, Hey, what's going on with this, you can give them the overarching parent ticket. And then of course, if they want to dive down into everything, they, they can, that's, that's great. And then, you know, coordinating the pod, imagine you can just get to everything there instead of having to have 15 different links to the different, you everything. But yeah, for folks, track it

in a system, not your email, I think is a good thing. Or chat, right? I mean, something that's actually... And I think the other benefit of doing that in general, and correct me if it's for products too, is that then looking back from future work, it's kind of archived better. Exactly. And I mentioned this earlier, but we are still working through what works best for us. All right. So it's going to be a little bit different for everyone. Definitely don't recommend email.

Definitely going to get lost in there. Yeah. for everyone. Definitely don't recommend email. Definitely gonna get lost in there. But we do have, so like our product planning board, like I said, it's already been vetted a little bit by the product team. To get on there, I don't wanna say we're gatekeepers or anything, but we should know what's going on there. You shouldn't just be willy nilly throwing stuff on there. We have an internal, another Notion board table,

an internal area that you can throw ideas up onto. Like, hey, you know, it'd be really cool if we added a product or feature that does this. We also have one to track client feature requests. So product managers, both of those to go, oh yeah, that's a good idea. Or, you know, no, that one's not really the, you know, you asked earlier if it doesn't go the direction of the company, probably doesn't go on there. Gotcha. Yeah. Bugs are tracked totally separate as well. So. Cool. But.

Nice. So when, once the, once the client has it, is in the earlier part, you've kind of talked about, hey, we'll support this. Here's who you call for help, those kind of things if you have issues like that. And then training, I imagine that's part of kind of the handoff for the customer, right? Like, hey, here's your products. Here's how it works. Or do you find as you're developing it, are they involved kind of the whole time? So there's not kind of like at the very end, we're going to do a week of training, you know what I mean? Because they've been involved the whole time. So there's not kind of like a, at the very end, we're going to do a week of training. You know what I mean?

Because they've been involved the whole time. Definitely that. Okay. They've been involved the whole time. If they go live and we need to give them a week of training, well, we've really dropped the ball there. But that's the nature of our product.

Like our product is kind of like a core that you build. We'll say we're the core Lego, and then you put other Legos around. You put your system on it. At our core, we're an API. So there's a lot of integration that goes into that. So if they are integrated with us and they need direction at the end. Yeah. And what is an API?

Yeah. Yeah. And what is an API? Yeah. Yeah. I think that's a big difference for sure. And probably what you've seen in like product management and then like a project. So depending if it's a software development project, obviously it's probably more similar to a product development verse. We're going to buy new devices and put them somewhere. You know what I mean? And we're going to then train you on them right before they go out there um but yeah it seems like to uh just in general good practice to train folks up the whole time so maybe you're just kind of polishing off some tips and tricks near the end or something or uh yeah that's really specific to you know the type of

company that we are but that might not be the case for another company so you know okay best judgment of course you know if you don't have a big integration portion if you're like a pure sas company where someone can sign up online and go through your product without any actual contact with the company or a specific person you put your credit card in and now you have a free trial or whatever that's right um you know then you need to think about again getting into that user's shoes in their head and what are they thinking so you know videos or obviously like everyone has a documentation center but maybe you do a automated walkthrough you see that on a lot of websites and stuff.

That's a great point. Yeah. I didn't think about that from not being familiar with, if you don't even talk to someone because they're buying it just on their own right online or something. I had a flashback of actually going into a store and buying a box that then had a DVD in it that you then loaded on your computer. But those days are gone. Yeah. Long gone. But yeah, I didn't even think about that. So that's a whole other aspect of strategy, right? How do we make this friendly when we never talk to anyone? And I would imagine not that you're not ready and willing to help them, but minimize them even having to call us at all because it just works.

Yeah. I mean, the whole helping your customer understand how to use something, even though we're with them through the entire integration process, like their onboarding implementation process, it is still a challenge that I'm trying to improve every day to help them understand our product. Lending and money calculations is just very complex. And couple that with the fact that we're doing all of these calculations for you. So helping them get visibility and understanding of our system, it's hard to give instruction on things that are happening under the hood. Sure. it's hard to give instruction on things that are happening under the hood. Sure.

Show you anything. So how am I going to communicate this in a clear, concise way of what's happening and how this is going to affect you and what you need to know? So that's a great point. Communication is key to our communicating via podcast here. So a couple key takeaways for folks is one, if someone like you found yourself interested in product management, what do you suggest? Like you use the notification, you look

for jobs. What are, in fact, let me kind of rephrase it. What soft skills do you think you brought to the table before you got into kind of product management proper, so to speak, that could work for folks that maybe aren't even thinking about doing it? I mean, it's so generic and we kind of touched on a few times, but communication is really key. And it's actually something I'm still working on because you feel like it's kind of a joke in product management. It's like if you're over communicating, if you feel like you're over communicating, then that's just the right level. Oh, yeah. So like, you know, because I'm going between customers and I work with senior leadership

and engineering and design and like every department, you feel like you're repeating yourself a lot. So if you feel that way, then you're probably doing it just enough gotcha that's the main one um and then i you know organization of course like all the generic stuff sure but i'd say the we've kind of also touched on this one, but a big one is that idea of getting into the user's mindset is the biggest, for me, is the biggest takeaway from a product perspective. The more you can deeply feel their pain points and understand how they interact with your product, that's really going to be the main thing that's going to help you a ton. Coming back to that psychology, you thought you got out of it and it pulled you back in. I mean, honestly,

all those skills you mentioned are awesome and good advice. And it really sounds like, and I'm sure there's some conflict resolution in there of folks. And I would imagine as part of that communication, you have to be comfortable with telling customers now. of folks. I would imagine as part of that communication, you have to be comfortable with telling customers no. Do you have to do that often? Or maybe not no, but maybe

not that way. I would say not that way. I don't like saying no. It's like, hey, I have this problem and I use your product. I'm like, no. Right. Not a good no, it's usually, you know, no, but, or here's a way you can achieve that.

Or I totally hear you. I understand the pain you're feeling. It's on our roadmap. Like we're going to get there. It's, it's not happening right now, but like you're letting them know that they're heard. Right. And also not just leaving them in the dark, like, okay, well then what am I supposed to do? Right. Okay. Well, let's, let's work together and figure out at least an interim solution, either, you know, maybe it's even an operational thing, manual workaround for now, but giving them something.

Yeah, that's a much better answer than mine. Now that I say that all the time. So what about kind of the hard skills, technical skills? So you were pretty technical getting into this. Is that something that you think you need to have if you want to get into a product or does it depend on the product or both? Or what's your answer? It probably depends on the product and the nature of the company.

So, you know, I mentioned I work for a FinTech, a financial tech company. We're tech focused, tech first. So to be able to understand and do my job, I need to understand the foundations of how software works and with the software development lifecycle and how it all connects together and what's possible, what's not possible. I wouldn't say it's like an absolute must to have that depending on where you're working at. But the one hard skill I would say across the board, if you're looking to

gain knowledge in that area is learning SQL, which is a querying language. And that will help you like dissect the data and understand customer usage and just, you know, whatever data is at your company, but being able to query that and look at different slices and that sort of thing is super valuable, no matter where you are. I can't imagine a place that wouldn't be helpful. So that's awesome. That is helpful. It's helpful to me to know that. And for folks out there aspiring, so SQL will be able to communicate, but also if folks want to communicate with you to pick your brain some more, learn or get in touch with Canopy, how can folks connect with you? LinkedIn is definitely the best place. I have Twitter, not really on there too much,

sometimes lurk around, but yeah, LinkedIn would be the place to find me and always happy to help if possible. Cool. And it's Jillian Funes, J-I-L-I-A-N-F-U-N-E-S. Correct. Spell that correctly. Finally, looking at the screen with your name on there. So please reach out. Again, I'm going to give away your time for you. So just see a bunch of connection requests on LinkedIn.

But yeah, this was really helpful for me. I appreciate your time. So for folks, again, find out what the problem is. Ask why a bunch of times. Does it match your objective? RICED and we'll put this in show notes too. So unless folks have their notebook with them, which I'm sure everyone does when they spin up this process. Yes, we can get credit for coining the term RICED. Yeah. I'll put an asterisk, corn you know corn by the canopy folks um and you know hard skills if you're looking to get into product management helps to know that sequel so um get those uh jillian any parting words for aspiring product managers or anything else you want to

share with audience you know i wish i had some inspiring words of wisdom as like a like a writing out on in glory but no i we, we really touched on everything. So I just appreciate you having me. Yeah, absolutely. Thanks again for joining Jillian and I in our conversation about product management and about financial technology or FinTech, particularly about canopy. Please follow me on Instagram and Twitter at Penel KG P A N N E L LE-L-L-K-G. I also have KevTalks Podcasts

on Instagram where I post pretty much the same thing, starting to post more on my own board there. And check out KevTalksPod.com for this episode, for more resources, templates, discounts on things like Jocko Fuel products, and more. Thank you again. Remember, have a plan, stay informed, and get involved. Godspeed.