Episode 82: Dear Melissa- Answering Questions About Transitioning Into A Large Product Team, Collaborating with SMEs, and Internal Tools
In this Dear Melissa segment, Melissa answers subscribers’ questions about what to expect when transitioning from a small to a large product team, how to work with subject matter experts that have strong opinions on product design, and making the case for creating an internal product team to support a growing organization.
Have a product question for Melissa? Submit one here and Melissa may answer it in a future episode.
Subscribe via your favorite platform:
Q: I've heard about the dangers of transitioning to a smaller team after being in a large organization, but I'm curious about movement in the other direction.
A: When you move into a larger organization, they probably have some kind of process or some ways of working that is common across the teams and across the organization, so expect to get up to speed on that. You're not going to just walk in there and just kind of do what you've always been doing - you're going to need to learn when to get together to review things, what types of cadences they you follow, if they have a certain set of tools that you can readily pull from… Try to figure out how all the rest of the product people work, how the product designers work, see what they've been doing and what's considered best practice for the company.
Q: How can I help the team to make the most of everyone's expertise and work better together?
A: Matt Walleart is probably extremely excited about this, he wrote a book on behavior design and product, so it’s a great place to start… If they’re subject matter experts, what they should really be providing is the context and the content pieces to the product managers and the designers so that they can decide what's the best solution to turn that into… but the final say on what you move forward with comes down to the product manager… Now if the designers and product managers are great they should be listening to all the feedback from the psychologist or the doctors or nurses if you're in another company or whatever… Ideally we're all collaborating together, but it sounds like your psychologist might be trying to design the product for everybody… I think feedback is really important, but at the end of the day, are they designers?
Q: Do you have any suggestions for ways to frame a request to start an internal product team?
A: Every company needs an internal product. When you are small, it's totally fine to dig into the back end and not make a huge interface for everybody to do their jobs because you're scrappy and you're throwing things together, but if you want to scale you have to make some internal tool, so I would start there. What happens if you don't make internal tools? You have to hire so many more people if you can't let customer service, sales, or customer success do their own jobs. Not everybody can learn SQL, and if the sales people were learning sequel they're not doing sales. How much time are they spending learning sequel and pulling queries instead of doing sales? These are the types of things that I would put out there, and when you break this information down and show it to executives, they’re usually like “whoa… I would really like them to do their jobs.”
Resources
Melissa Perri on LinkedIn | Twitter
Transcript:
Melissa:
Hello, and welcome to another episode of dear Melissa. Today, we're gonna kick off with three questions. We've got one about internal tools. We've got another one about moving from small teams to large teams instead of the opposite that we talk about a lot, you know, going from a larger enterprise into a smaller team. And then finally too, we have a question on subject matter experts and product managers working well together. But before I dive into that, I wanna remind you that you can submit your questions to me@dearmelissa.com. So if you have any questions for me or you felt like, Hey, you know, I'm not really sure what to do about this, or I just have a general question about my career. Doesn't matter what it is. Go ahead, go to dear melissa.com and submit that question.
And we have this new feature where you can actually leave me a voicemail. So instead of reading your question, I can hear it straight from your mouth, but don't worry. It's always anonymous. So we'll never give you away on the podcast. So without further ado, let's dive into this week's dear Melissa.
Dear Melissa. In the past year, I've been a solo designer at a less than 20 person startup, and this gig also happened to be my first formal product position. I made the transition from almost five years in various customer facing roles. Thanks to applying the advice you've shared. I was able to keep up with my far more experienced colleagues and consistently level up despite being a new product person. Here's my question. The company I'm joining in a few weeks has a dedicated design team that's nestled within a larger organization about 50 people.
It'll be my first time working in an organization this large. And I'm wondering what advice comes to mind. I've heard about the dangers of transitioning to a smaller team after being at a large organization, but I'm curious about movement in the other direction. Thanks in advance. So yeah, we've talked a lot about going from large organization down to small, but this is a great one. What happens when we go from small to large? Here's a couple things that you can look for.
Usually there's a lot more process about the way that this company does it. So when you move into a larger organization, they probably have, it might not be well documented, but they probably have some kind of process or some kind of ways of working that is common across the teams and across the organization. So expect to like get up to speed on that. You're not going to just walk in there and just kind of do what you've always been doing. You're gonna need to learn, like when do we get together, um, to review things, what types of cadences do you follow? Do you have a certain set of tools that I can readily pull from? Um, are there things that I have to use? Are there templates I have to use? Are there, uh, working relationships that I
Need to, like, what do you guys do? That would be my first question. When I get in there, try to figure out how all the rest of the product people work, how the product designers work, you know, see what they've been doing and what's considered best practice for the company. I'm not saying like best practice in general, but like best practice for the company, something that's defined something that's rigid. And then also try to figure out what the bounds are there. Where do you have some freedom to do it your way? Right? Where's the flexibility in that as well. So I would definitely look at those types of things. So expect like more structure, more processes. Now, sometimes that's great. And sometimes people like that. Sometimes people like the boundaries around those areas. The other part of working in a larger organization is you usually have more senior people, which is awesome. Now you get to learn from people. Now you usually have, you know, a boss or colleagues. Who've done this before. Hopefully they've been doing this for a long time. So you get to learn from them as well. So those are some really good upsides. Um, the downside too, that you could look out for is, you know, sometimes you might not wanna work within those boundaries or those processes, and you might have some better ways of working in, you know, that you did in the startup.
Now that doesn't mean that you have to, you know, keep that all to yourself. You could probably bring up like, Hey, we've done this before. I think there's some improvement here, but I would say like, get up to speed on what they're doing, listen to what they're doing, understand it, see if there's any pitfalls before you start to try to make changes or be like, Hey, the way that you're working, doesn't really work. Like I did it like this before I did this before. Right? That's a bad way to start off in a new company, especially when people have been following the same path and the same processes for a while. So make sure you take the time to get up to speed, listen, observe before you offer suggestions. But usually there is a good place to offer suggestions. Um, once you do that, and it's not bad to bring in your own expertise and try to figure out how we can all improve together.
So we talked about how the processes and the structures are probably more defined than you're used to pros and cons to that. If you're a person who, who, you know, felt like they were kind of winging it and needed a path, this is probably a great spot for you. If you were super experienced and only wanted to do it your way, maybe not the best way, right? Maybe, maybe it's gonna be a little harder for you. Depends what the processes are. Depends if it jives with your perspective, but that's definitely something to look at startups versus large companies too. I've worked in both. I'll just say there's usually like different cultures, different ways of doing things in a startup. You're typically moving incredibly fast. You know, we always say the startup mantras are move fast and break things. I, I don't know if we should be breaking things, but <laugh>, but that is what we talk about.
When we talk about startups, larger organizations tend to move a little bit slower. So you're gonna have to have some patience with that. You're gonna have to know that it's usually gonna go through many different departments. When you get into a bigger company. Usually we're getting like legal involved, compliance might be involved. Other things might be involved. It might not be as easy to usher things out as it was in a startup where maybe you could, you know, put something together in a week and have like a whole feature launch to a team at the end of, you know, end of the week, that might not happen in larger companies. So speed is definitely a thing. Um, but there's usually also more defined roles at larger companies too, which is nice. So in a startup, you sometimes play, you know, all the roles as a product manager.
When I worked at a startup, I was digging into the database and trying to, you know, figure out what the data was, cuz we didn't have a data system set up. Um, we didn't have people who could pull the data. I was also sometimes designing well, a lot of times I was designing all the interfaces cuz I was both a product manager and a designer. So I was doing it all. Uh, when you get bigger, all the roles usually get a little bit more specified. So you're probably not gonna be doing it all. And you have to ask yourself, which are the pieces that I really enjoy doing. And what's the pieces I don't enjoy doing because if you find like, Hey, I really like that piece or that's where I was thriving and it's now somebody else's job.
That's a good inkling that maybe that's more of your role rather than the one that you're in. But if you are like, Nope, I really wanted to focus on this role. I joined a larger organization, so I didn't have to do all the other stuff that I was kind of doing off the side of my desk. Larger organization could be a great place for you. So those are things I would think about like, you know, define templates, processes and structures, usually in larger organizations. And again, not all large organizations have this, but <laugh>, you'll typically find more of it than you would find in a startup. So they're gonna have a way they do roadmaps. They're gonna have a way, um, they'll probably have their own set of programs of whether they use Figma or something else to do. You know, the design, you might not be choosing your own.
Uh, they probably have a lot more people there. So hopefully you'll get some experience mentors, which would be awesome. And uh, there's probably a little bit more overhead in politics though, going on to probably more departments involved, more stakeholders, all of that stuff to look at as well. So when I talk about dangers, you said, you know, I've heard about the dangers of transitioning to a smaller team, but what about the other direction? There's pros and cons for everything. And I would say at the end of the day, when you look at, do I wanna be in a large company or a small company, it's up to you, do you thrive in uncertainty? If you thrive in uncertainty, startup world is great. If you don't thrive in uncertainty, you don't love figuring it out on your own. Uh, larger organizations are fantastic for you. Now you could also be a hybrid and I will say this ebbs and flows, I feel like with how experienced you are and how much you know, what you're doing.
When you get really experienced, it's easier, easier to thrive in uncertainty cuz you already have your own toolkit and your own framework for doing things. So you can walk into a place that's a mess and be like, this is how we do it and apply all that structure that you know, everybody else needs to thrive and you need to thrive. when you are less experienced. It's usually better to join a bigger team rather than a team with no structure or no processes or no people to learn from so that you can build up that toolkit. So that's also something to look at it, ebbs and flows in your career. So you, you know, what you want now might not be what you want in five to 10 years and that's totally fine. So that's what I would think about. What do I, what do I thrive in? What can I learn? What can I take with me on this journey about moving into a larger team?
All right, next question, dear Melissa I've recently joined a digital health company as a VP of product. Our product trios or quartets are comprised of a PM, a product designer, a tech lead and a psychologist. The psychologists are key members of the squad. They bring a deep domain expertise to translate traditional therapies in a digital format. Some of them are also behavioral change scientists, which is also an extremely valuable expertise to positively influence or nudge the choices that users of our products make. However, when it comes to behavioral change, it's not clear how product managers, product designers and psychologists can collaborate together. Product managers know how to work with product designers, but they don't know how to also work with a behavioral change scientist who has a lot to say regarding product design. There's a lot of overlapping between roles. There are disagreements regarding processes.
It's not clear who can decide what and overall at leads to frustration and frictions. How can I help the team to make the most of everyone's expertise and work better together?
Well, the first thing that crossed my mind when I read this is, uh, Matt Wallaert is probably extremely excited about this. If he's listening to this podcast and if you don't know who Matt is, you should definitely go check him out. He wrote a book on, um, on behavior design and product. So I feel like it's a great place for you to go look. But, uh, Matt Wallaert, uh, is one of the best behavior design, you know, thinkers when it comes to product management. Now I think there's a couple things to dig into with your question. Are the psychologists basically being subject matter expertise because you said they bring a deep domain expertise to translate traditional therapies into a digital format.
Fantastic. Okay. So if they're a subject matter expert, what they should really be providing is the context and the content pieces to the product managers and the designers so that they can decide what's the best solution to turn that into now, I've worked with a lot of healthcare companies where we've done this in the past. We've had subject matter expertise who were like nurses and doctors and they understood all the content that needed to happen. And the processes that the doctor is went through in order to care for their patients. So basically the doctor would be like, yep, I see a patient. They come into my office. Here's the things that need to get done. These are the types of things I need to like submit into insurance or fill out on their charts, blah, blah, blah, blah, blah, product managers were like, great, cool.
I'm understanding your process. I'm writing down what the requirements are. I'm trying to figure that out. And then they're working with the designers to figure out how do we make this flow better? And the, the doctors and the subject matter experts are over, you know, giving them feedback on that, oh yeah, this is easy to use or this is great. Or I really like these competitors out there. We should be learning from them, those types of things. But the final say on what we move forward with, uh, comes down to the product manager. The product manager decides like these are the features, this is the product that we're going after. Here's the business value. Does it meet those goals? And the actual firm design of the product comes from the UX designers. Now if the designers and the product managers are great, they should be listening to all the feedback from the psychologist, but at the end of the day or the doctors or nurses, if you're in another company, whatever, but at the end of the day, it's the product managers and the designers that have final say over the solution, psychologists should be giving input on there.
They should be using them as subject matter experts. And I think the behavioral change is incredibly important there because they can get that psychology behind it, but you can't override the team that knows how to build software in their area. So ideally we're all collaborating together. But what it sounds like is your psychologist might be trying to design the product for everybody. And my question is, are they designers? Like you can give feedback. I think feedback's really important, but are they designers at the end of the day and behavioral change scientists, I think make great product managers. So if there's an opportunity as well for, you know, one of those people to become a product manager, like by all means, train them and, and let them do that. I think, um, you know, if they have the aptitude for it and they can, can learn the skill set, I think that's great.
But if they don't have that skillset, then you gotta defer back to the product managers to be able to do that. So you need to think of this as a subject matter expert, uh, you know, giving input and advice to the team and letting them understand the context in which the, you know, the, the psychologists and the patients live and utilize these tools and therapies and all that stuff. But then you also have to trust the product managers and the designers to do their job, which is to create the product. Now, one thing here too, sounds like you don't have that set. Um, it sounds like they're vying for control and there's probably a lack of trust around this team. You could see there's clear delineation between product managers, designers, and developers, because everybody's got very clear roles there on, you know, who owns what, who has the final say on what pieces, uh, you need to set those roles too for the psychologist. Is the content correct?
Is this therapy being delivered in a compliance way? Is the therapy being delivered in an effective way where it actually will help the patient feedback from that nature will help the product managers and designers. But if they're giving feedback like, Hey, that button needs to go over there and it needs to be orange. That's not their job. That's a designer's job at the end of the day. And that's where I think you need to clear up that tension. And that's what I would make incredibly crystal clear to everybody is, you know, these are where our roles are and this is where we overlap. But you know, this is where one person has final say, here's where the other role has final say. And here's what this other role has final say. Um, and remember at the end of the day, like, uh, psychologists in your case are the subject matter experts. They're not the product managers, unless you take one of them and make 'em a product manager, but it has to be, you know, it has to be a defined role. And I'm not saying that's the only path. I think these two roles can work together. Having a subject matter expert and a product manager work very closely together, but you have to have definitions of who, who gets final say over what?
All right, last question, dear Melissa, I work for a SaaS company where we are very good about building products for our customers, but we lack a development team to build product for our internal customers. For instance, sales, customer service, customer success, and our database team rely on SQL queries to determine product usage. I'd like to approach leadership about starting an internal product team. Do you have any suggestions for ways to frame the request? Thanks.
Ooh, this is a great one. Um, I was actually the internal product team for, uh, for open sky and I worked on internal products a lot. So here's the thing. Every company needs an internal product at the end of the day, when you are small, it's totally fine to like dig into the back end and not make like a huge interface for everybody to do their jobs because you're scrappy and you're starting it together.
You're throwing things together. But at the end of the day, if you wanna scale, you gotta make some internal tools. So I would start there. Um, what happens if you don't make internal tools? Here's your, your, your business case right here. You have to hire so many more people if you can't let customer service sales customer success, uh, do their own jobs, right? Like not everybody can learn SQL. Also think if everybody's, if the sales people were learning SQL, they're not doing sales. How much time are they spending learning SQL and pulling queries instead of doing sales, right? Like these are the types of things that I would put out there. And actually when you break this information down and show it to executives, they're usually like, whoa, I didn't realize that I hired a salesperson and I'm paying them a lot of money. And I would really like them to do their jobs.
There are things out there to have product usage, right? Like, and if you are gonna, a lot of companies hate implementing some product usage tools like Pendo or amplitude or anything like that, because it takes some time to actually get it up and running. But what you need to do is calculate it out and lay the business case for, Hey, if we do this now and we spend the time doing it now, this is how much money we'll save over the next year or two. And we won't have to hire more people. And this is how much more time sales can spend on sales. And this is how much more time customer service can spend on customer service. Like that business case is very important to get out there. And in front of executives. Also, you will not stay this small forever, right? Like hopefully you're growing and that's what your executives want you to do.
They want you to grow. They want you to get all the sales. They want you to go crazy. So, Hey, if you wanna go from making $5 million in ARR to $20 million in ARR, how many more people do we need? Well, at the rate that we're doing this <laugh> how much time would those people be spending learning SQL, right? How are we gonna tell somebody that we need to hire, that they have to learn SQL or that they learn how to code, or they have to do all this other stuff at a certain point. You're not gonna get great people to come work for the company either because they don't wanna do that. Like, it's just gonna be time consuming. Um, for them to learn all these new things are not really important to their job. And I'm not saying product usage, isn't important to their job.
I'm saying they shouldn't have to learn SQL. Right. There are tools out there that do this for you. So those are the cases that I would really make. Um, I had a, like, I worked at a startup and I had the same problem. Like we couldn't get the data out of the systems. I learned MongoDB, uh, because that's what our database was in. So I literally took all the MongoDB classes when they came out. I got certified in MongoDB, just so I could pull my own product usage. Do you know how, like, time consuming that was, I was spending, like, I, I don't know. I spent months learning MongoDB and of course, like I could be a little bit effective immediately and I needed to learn it because they just wouldn't prioritize putting the product metrics in there, but you know what? I've never used it again.
<laugh>, I've never used it again with my career. And I, for the like, you know, I, I wanna say probably 120 hours or more that I spent learning MongoDB. And then let's not even add in all the time that I spent pulling all the stuff out of MongoDB, cuz it comes out in a really weird format. And then I had to sift through all those metrics and everything. Like I could have been doing much more valuable work. I wasn't hired to pull queries out of a database. So this is what we need to look at. Like what are we hiring people for? And do we wanna hire other people to like do that type of work? Or do we wanna just take, you know, a couple sprints and put in some internal tools and some product metrics and all those things, because you will not be able to scale one day when you get too big and then it's gonna be too late and then you're gonna have a lot of important things to be doing.
And you're gonna have no time to implement this stuff and you're gonna be flying blind because nobody's gonna have the data that they need to make decisions. Because one day people are gonna start like, just stop pulling the data. I guarantee you you're gonna get tons of requests in from customers. You're gonna get tons of requests in from other people inside the company. And one day all those people are gonna go, I think maybe we'll just, you know, try to figure out how to prioritize these things on our own. And I'm not gonna bother to write the SQL queries. I've seen this happen a lot. People will get tired of doing it and then they'll just start guessing and you don't want that for your company. So I would make that case. That's what I would really look at. And if you want to play this back for the people who are making the decision, I hope it helps them realize that you need these things to scale and you might not be scaled right now, but I really hope one day you do start to scale and it will break.
It's gonna break if you don't do this now and you don't want that to happen, you wanna do it now while you're still growing, you don't wanna throw a wrench into the machine when it's really big. So now's a great time to start looking at all the internal tools and what we need to do to streamline our, our company so that we can grow and we can make more revenue, but we keep our costs low. Right? That's what we're trying to do here as businesses. It's all about margins. Your margins will thank you. Your investors will thank you. If you just take a little bit of time out now and start get started with these things and then you can scale them and grow them as you grow as well. So that's it for dear Melissa this week. Again, if you have any questions for me, please go to dear melissa.com and drop 'em to me. Otherwise we'll be back next Wednesday with another episode of the product
Thinking podcast. And if you really enjoyed this podcast, I'd love it. If you let us know, please subscribe wherever you're listening to this. And if you could go to apple podcasts and leave us a review, uh, we would really, really appreciate it. Love to hear what you're thinking about. Also drop me some suggestions on Twitter about what you would like to learn or hear next on the podcast. My Twitter handle is at Lissie Jean L I S S I J E a N. And I look forward to talking to you all next week.