In this Dear Melissa segment, Melissa answers subscribers’ questions about how to use their time wisely, whether they’re trying to support their sales team with a complex product, getting the most out of a customer advisory board, or finding time for discovery work on a Scrum-focused team.
Show Notes
Q: I'm constantly helping our sales team run demo calls and our account managers onboard and set up new customers. What can I do to empower my team so I can focus on improving our product instead? Have you ever used a dedicated team member to fill this space as a product specialist role?
Q: What am I signing up for when setting up a customer advisory board? What should I do to launch it smoothly and get the most out of it? What risks am I facing? Is this a stupid idea?
Q: Is there a way to make product discovery a process and make time for it, like what scrum does for delivery?
Resources Melissa Perri on LinkedIn | Twitter MelissaPerri.com
Episode Transcript
Hello, and welcome to an episode of Dear Melissa, from the Product Thinking Podcast. The lines are now open, and we're ready to answer your most pressing product questions. Which prioritization framework would you recommend and why? Hi, Melissa. Do you have any suggestions on developing a product strategy?
Whoa, whoa, whoa, whoa, whoa. That's a lot of questions. All right, let's dive in. Hello, and welcome to another episode of Dear Melissa. Today, we've got three great questions around spending your time wisely as a product manager, setting up a customer advisory board, and then also trying to figure out a process for discovery and how that fits into Agile, which goes nicely with the topic of conversation we just had with Jeff Patton a couple of weeks ago.
So if you haven't listened to that episode, that's a great follow-up for today. And just a reminder, you can always submit questions to Dear Melissa as well.
So we're always soliciting new questions, and it can be about anything, anything that's related to product management. Let's put it that way. Maybe not something right field that I don't know anything about, but anything related to product management, I'm happy to take your questions on that. So go to dearmelissa.com, and that's where you can submit all your questions.
You can also see our past episodes of the podcast. And if you are enjoying this podcast, I just want to say, if you can leave us a review on a rating on Apple or Spotify or wherever you're listening to this podcast, that would be super, super helpful. We would really, really appreciate it if you could leave us a review or a rating.
That helps a lot of other people find this podcast too. All right, so let's dive into the questions that we have for today. First question, Dear Melissa, we're launching a new product market, and I find my calendar is filling up. I'm constantly helping our sales team run demo calls and helping our account managers onboard and set up new customers.
I'm taking 15 plus calls a week.
I've given both teams tons of information, video demos, docs, and FAQs to set them up for success, but they're still calling. What else can I do to empower them and remove time suck from my calendar so I can focus on improving the product? Have you ever used a dedicated team member to fill this space as a product specialist role?
Good question. I actually was in your shoes as well. When I first started out with product management, I was running this. Well, this actually happened twice. In the first place, I was running the internal tools for the team, and I remember that everybody would just line up at my desk and ask me questions and be like, can you help me with this?
Can you help me onboard new people? Can you show them how to use it? I'd be like, wow, I made step-by-step instructions for everybody. I don't understand why this isn't working. I went to another organization in the future too, and it was the same thing. I got pulled into all the sales calls. I had to demo it all the time.
What I found out from all of this is that it doesn't really matter how many instructions or step-by-step videos you show people if your product's not intuitive.
So the first thing I would do in your shoes is actually look at the UX of your product. Did you design it well? Is it really easy to use? Is it simple to use? The thing about great onboarding is that it should not use a tutorial. I actually went through this with a client a couple of years ago where we found that one of the biggest sink sinks, one of the biggest money sucks in the organization was actually onboarding.
We had to fly people out to show people how to onboard, to get them set up, to get them moving. And it was all because of a lack of good user experience, right? We did not design the product in a way that got people started. And it costs so much money to do that. People were flying all over the place, spending weeks on site, trying to get people up and running.
There is a lot that goes into onboarding that we take for granted. And no amount of instructions could ever really replace that. I look at tools like WalkMe or the things that help you with the onboarding. If you never saw WalkMe, you'll probably recognize it actually if you see it.
You've never been on a website and you get started and it has these little tool tips that come up and they say, click this to get started. Or like, this is where you can find your menu. And over here is where you should track things each day. That's like a WalkMe type tool. And they're pretty common in onboarding.
But I think the problem with that is they're just a replacement. They're a stopgap for bad user experience and bad design. And the onboarding design is so critically important because that helps drive adoption. So if I were you, I'd first stop and say, what makes it so hard for people to get onboarded in my product?
What makes it so hard for the sales team to demo this product? Why don't they understand it? That's also another red flag for me. Usually when I go into any organization or when I help any organization, I say, can you please give me a salesperson, somebody who's demoed this for other people before. I love to watch how they walk the clients through it because they know the use cases super well.
They know the questions that get asked during sales. They understand where the customers are coming from. And I think as a product person, trying to get up to speed on anything, the sales team can be so wildly valuable. So if they can't demo your product correctly or they're having trouble with it, did you set them up for success would be my second question there.
So I think all of this kind of comes down to what's going on with the user experience of your product, right? Like what's going on with the onboarding? It's really important as you consider designs of products to consider null states. So what happens when somebody logs in for the first time and there's no information there?
How do I get them set up so that they can start figuring out what to do first? How do I prompt them? Usually this design, like that whole onboarding flow or that whole first time usage, takes a considerable amount of effort. And we never gravitate towards designing that first. I've been a UX designer just as long as I've been a product manager.
And I see that true for everywhere, right? And I also did a lot of this at the beginning of my career. I'm going to design things that are full, right? That have information. And that's what we try to do. We try to design for full information. And we forget to design the null state. So I will go back and really look at your user experience and say, did I do a great job on this?
And do some user research, right? Like approach this whole problem. This is a problem. Approach this problem like you're interviewing customers, right? Why do you bring me into demo? What is hard for you to understand on how to show this? What aren't you resonating with with the use cases? Why is it hard to onboard people?
Why is this complicated? If you're getting a time sink like this, where you're just always responding to questions about your product, it's usually not the other people. It's usually your product. Now, sometimes it may be a lack of process in the company, right?
You may have some junior salespeople who just don't know how to use these things. You may have a not empowered sales team that doesn't feel up to speed and empowered to actually walk people through the product. They might not be getting as up to speed with it as they should be. Maybe they're just like focused on selling, but they don't actually know what's coming up with the product.
All right, that might be the case. And in that case, education should solve that problem, but you're telling me it's not. And that's what's really making me worried. Now, total caveat, different scenario. If you work in a highly complex industry and setting people up and onboarding them takes like massive integrations and all these different things that are more code related, then you can go use a product specialist.
And in highly complex products, that's fine as a stopgap, but I'd also encourage you to figure out how we could streamline that onboarding process and get rid of that role. I do see product specialists in companies that are very, very complicated.
Like the product is incredibly complicated. And let's say you're selling to a customer who's not very technical and you need kind of a technical support person, product specialist to get up to speed. That's where that really comes in. They might be doing a little bit of custom code. And if your customers are not paying for that, I should tell you that they should be paying for that.
If you do custom work, they should pay for that. You also don't want to get stuck being like a consultant. You don't want to refine your product for everybody. But that's kind of where I see that role sit. Now, if you want that role just to respond to the things that we're talking about here, and you're also looking at your stuff and saying, well, it's not super duper complicated.
I think any industry that is complicated could make simple to use products. I do think that's a possibility. So this is why I gravitate towards thinking about the UX first. Is it possible for us to make this more streamlined? Instead of having integrations be coded, can we do some kind of wizard type setup on it?
I don't know. It might be possible.
It might not be possible in your situation. But I think I would look at the product specialist as a last resort. And I would start with really looking into your product and figuring out, is it solving the needs of our support staff who does the onboarding as well as their customers at the end of the day?
That's gotta be a big part there. Is it easy for people to get set up themselves? How can you help do self-enrollment, self-onboarding? That's a huge part of designing a great product. So I would look at that first. If you are like, no, it's actually super technical to get people onboarded. That's where I would start to look at a product specialist.
But sometimes we, in those cases, we look at getting somebody who's a little bit more technical in there so that they could do custom coding or get people set up with that. So that does happen in much larger enterprise-focused companies that have very complicated onboarding stuff. So I hope that helps.
All right. So moving on from onboarding, our next question says, dear Melissa, I work for a SaaS company with a thousand paying clients from all over the market.
We found the segment we want to target and I would like to start a customer advisory board to get them more engaged and interested in us. We are the strongest brand in our niche, so I'm hopeful they'll accept it. What am I signing up for when setting this up? What should I do to launch it smoothly and get the most out of it?
What risks am I facing? Or is this a stupid idea? Not a stupid idea, I can tell you that. Great idea. I like customer advisory boards. So a couple of things when you're setting up this board, how do you want to use it, right? What's its purpose? How's it going to inform you? I worked with a great company like two years back who had a fantastic customer advisory board in the pharmaceuticals industry full of C-suite leaders in their realm, right?
And they all were clients of theirs, but they were all really forward thinking too. And it was amazing just to see what they brought to the table. We love talking to them. We were there helping out with shaping a new product, figuring out the product strategy. And when we met with the customer advisory board, they always had great ideas.
They were really on top of a complicated industry that us as product people, and especially as consultants, didn't know so much about. And we learned a lot from them that helped shape what that new product would be. So I think they're great ideas, not a stupid idea. So do not second guess yourself there.
Now, when I'm setting up a customer advisory board, I would try to figure out what's their purpose. What am I trying to learn from them? Am I getting feedback on product? I think feedback on product is okay to have for a customer advisory board, but I think you can do more with them. Don't undersell or don't try to knock the value that these people could provide for a forward thinking idea, forward thinking value.
And remember, it's also not a wishlist generation thing. We're not setting up a customer advisory board to just take a list of demands and go and build them. So set the purpose and clearly communicate that intent. We wanna keep a pulse on the market. And so as leaders in the market, we'd like you to join and enjoy, hopefully, our customer advisory board and help us understand what you're looking forward to in the future, right?
Like how is the industry changing? How is your jobs changing?
What should we be keeping a pulse on? I think those things are incredibly important when we think about customer advisory boards. That's gonna help us stay in tune with our customers and with our market, especially when we're not doing their jobs every day. So I would definitely look at that as the reason you're gonna set up a customer advisory board.
So set the intent, set the purpose. This is what this is for, and this is what this is not for. Make sure that people are clear on that. But you can also make it sound really exciting. Like being on a customer advisory board for a product you use all the time is great because you're gonna get listened to.
So people are usually excited to join it. The second thing I would do is make sure that you have a good representation of the types of customers you want to go after and the types of customers that you are servicing. You want to make sure that it's not just your biggest customers on the customer advisory board because maybe that doesn't give you opportunities to think about how you expand your product, change your product going forward to satisfy different needs, right?
For example, let's say 50%, 60% of your business right now is in enterprise, and that's where you're making most of your money. But you've got a strategy to move down market in the future. You want to make sure that you have those mid-market people, if you want to go even further down market into consumers, those types of people on your customer advisory board as well because otherwise you're not gonna be hearing about their needs.
So it's really easy to go after the people who are paying the most right now, but you want to keep it a little bit diverse. You want to make sure that it's a good representation of the things that you want to do in the future. That's really, really important. So that's the first thing I would look at.
How do I make a diverse group of people and not just the people who are screaming the loudest or the companies that are paying us the most right now? I want the people who are gonna be paying us the most in the future too. Second thing to think about, what level is correct for this? So usually, it depends what you're gonna use them for, but if you're doing a forward-looking, where's the market industry going?
You're probably gonna want people who sign the checks on there, right? Like who's the people that you're actually selling into? In the enterprise, that might be the CIOs or head of HR, depending on what software you have. It's gonna be C-suite levels. In that case, you also have to design it so that they can participate and have time to participate.
So that means that this is a once a quarter thing. This is not a monthly thing. This is not a biweekly thing. This is a, let's make it special for them once a quarter. Now, if that's not who you really want to learn from, let's say it's not about market industry pulses, although I think that's where it should be, you're more about how people do their day-to-day job.
Maybe you want to go after the users, right? Maybe you want to actually have people who use it, but that's something to distinguish between what the feedback you get from the customer advisory roles too. I believe it should be the customer, the person paying the check on this panel. But again, you're not gonna learn user experience from them then, right?
Like they're probably not using your product.
It's the users who are using the product, so you still need user research, but the customer advisory role can help you figure out how the industry is changing and morphing in the future. So let's consider it C-level, high-level people who are signing checks. Let's go with that. So it brings me back to my other point.
You don't want to do this too frequently. You want to do it like quarterly. When you do the ask, you also have to ask them for their time. So they're donating their time to this, but hopefully they see enough value in your product that they get to shape it, right? So your pitch has to be really, really good, right?
We're gonna shape this based on your feedback, and that doesn't mean, again, you're saying this, but in reality, you're not just taking a wish list of ideas. Like you're saying this to get them on board. You're gonna distill their information eventually, but you're not just taking a wish list of their ideas, but you're getting them excited about it because they will have an impact on the future of your company, right?
That's an important thing to remember about this. So how do you make it a time commitment where they feel like they can actually participate?
Also, another good benefit there is that they get to meet other leaders in their industry, and they probably don't know that many. I don't think people network as much as they should within their industry. So you're like, okay, you're gonna meet some other C-level people in similar industries who are gonna share how they work as well, which means that you get to learn.
So that's a good boon for people joining the customer advisory board too. But again, keep it short. Keep it not super frequent. I would say quarterly. Give them very specific ideas on what you need from them and how they're gonna participate. Set the intentions for that and then make sure that you really get a diverse group.
I think if you set it up that way, you're gonna have a really nice customer advisory board, and I think it's gonna give you a lot of value as you figure out where your product needs to go and how that market is changing and what you wanna do to solve people's problems in the future. All right, last question.
Dear Melissa, I'm a junior product manager working on a B2B product. Our product team has a scrum-like process with its artifacts, daily scrums, planning meetings, and retro. But the problem is I can't find the right place to do discovery work in these meetings. Things like brainstorming different ideas, gathering and analyzing results, and deciding on actions.
I feel guilty randomly holding meetings. I don't wanna distract my team from doing their job. Any advice? Is there a way to make product discovery a process and leave time for it, like what scrum does for delivery? Great question. And this goes back to all my gripes I have with agile. So the first thing is scrum is not product.
Scrum is not your job as a product manager. Let's put it that way. Scrum has a lot of meetings and they're all about delivery. And you're right. There's nothing about discovery in scrum. That's not the role of scrum. So you do need a process. You do need a process for discovery and you're gonna need more meetings.
This is the number one thing I see junior product managers get wrong when they start to learn how to do product management and when they get into the role. They think that everything has to fit within the bounds of scrum. And that's not true. So yeah, you're gonna have to create a discovery process.
There's plenty of good ideas out there on how to do this. I'd recommend reading things like Lean UX by Jeff Goffelf and Josh Seiden. It gives a nice little process on how to actually do the brainstorming, how to do mock-ups and discovery work. Nice little process in Canvas, also in their new book. Their new book is coming out and it is, I just read it, the third edition.
It's great. That's a fantastic one to follow. You might wanna check out something like Design Sprints. C. Todd Lombardo has a fantastic book on design sprints. There's also the Google Sprints. It's a little bit different, but both of them are pretty good. I think the C. Todd book will tell you how to do the process a little bit more than the Google Design Sprints.
That kind of gives you a process, but it gives you lots of stories.
They're both fantastic, both worthy reads. But there's tons of discovery processes out there. The key is you're not gonna find any of those in scrum. And also the key thing is that you will need to pull your team into this other work. You're not distracting them from their job. Their job is to actually help you come up with what the right thing is to build.
It's not just to keep fingers on keyboards. We take developers for granted and we say like, hey, your only job is to code really, really fast. That's not true, right? Like they have brains. They're human beings. Let's treat them like human beings and come up with great ideas. Now, this isn't to say that you should be pulling them into brainstorming meetings three times a week.
No, like let them do what they're actually great at, which is the coding piece, but you should be tapping them when you need their feedback and when you need to incorporate them into something. So here's an example of how I would do a process starting out, right?
Starting with a new idea, a new feature. Let's say we found an opportunity that we wanna go after and we look at our product vision and we decide like, yes, that's gonna go into it, but I've gotta do some discovery work to figure out exactly the nuances around the problems, figure out what we're actually gonna mock up here and then I'm gonna work with my developers to get it done. We're starting from like an enhancement, existing product enhancement.
All right, so as a product manager, I'd grab my UX designer. If you don't have a UX designer, you're doing this yourself, but I'd grab them and I say, all right, let's look at what our hypotheses are about this problem and let's figure out how we can actually test them and prove them. This is gonna involve some user research.
User research, like I said, happens outside of the sprint. Sprint is delivery focused. This is discovery focused. Give yourself time to do this. So I sit there with my UX designers. We figure out what questions we wanna ask, who we wanna target for customers, how many people we wanna talk to. We go out and we run some user research.
We come back, we look at it together. We start to distill it and analyze results. So let's say we sit there, we start to identify some big pockets and problems that's where I might now bring in the developers or in one of our meetings say, hey, very quickly, I'm just gonna go over some of the things that we're learning to gear you up for what's gonna come next.
Here's some of the issues. Let's brainstorm a little bit about why we think those issues are happening. Maybe this is an hour meeting. Maybe this is two hour meeting, depending on how big the problems are, but you get their feedback, you start to think about it and then you say, okay, thank you for that.
I'm gonna take this away and start to distill where I think we should start and what experiments we should run in prototypes. Now you go back and you work with the UX designer. You start to prototype out what you think might fix the problems. You're gonna go run some tests with it. You're gonna take that feedback and again, go back to the developers.
You're like, okay, we did learn that this is the right direction to go in or we didn't, you're iterating, whatever.
But let's say you get to a point where you're ready to start building. Now you pull somebody in and you might wanna do something like a story mapping session. Jeff Patton wrote a fantastic book on story mapping. It is by far a great way to get involved with your developers. It also helps break down the work for them so that they can see what's going to be needed.
So we're doing story mapping sessions. We're breaking down the work. Hopefully before this, I should just caveat, you and the UX designer and probably your lead engineer are gonna get together and actually build out what the vision for that enhancement is gonna look like. And your lead engineer is there to give you feedback on how they might build it, what's gonna be hard, what you should think about when building it.
So you're gonna involve them. But again, this is not becoming their full-time job, but this is going to be bringing them in as we go. And then the UX designer is gonna take on a lot of the bulk of putting up those wireframes. And then the three of you will check in as you go. So then we get to the point where we have that vision.
We introduce it to the team.
We break it down with story mapping into what everybody's going to do. And then that leads into the sprints and the regular scrum work that you have to test it and iterate and figure out what's gonna get done. So the whole key here is that scrum is not a discovery process and you need something else.
Scrum is not enough for product managers. We need a whole nother process on top of that. And honestly, I'll say this too, scrum is meant to make us work better together towards delivery. Once you get really good at delivering, you should all look at the scrum process and say, what can we keep and what should we leave?
When I worked on a team doing scrum, we looked at it and we said, you know what? We don't actually need to do daily standup meetings. We are going to check in on Slack. Instead, we were a remote team too. So we're like, everybody just post your thing on Slack. And then we just got into the habit of being like, hey, we're in this big issue.
Can I jump on the phone with you for like five seconds? And you're like, cool. Jump on Skype.
I'd look at the issue with the developers and I'd be like, okay, here's my feedback on that. And they go, okay, great. And they go away. And that's how we collaborate all the time. We would just jump on it. We'd set aside time for bigger planning meetings, bigger visioning stuff. A lot of my developers that I've worked with in the past wanted to be involved in the discovery processes.
So I might bring them to some user research sessions, but it wasn't overwhelming amounts, right? It would be like maybe one a month. They would sit in on one every two months, one every three months, just enough to get them in tune with what the customers are saying. So when you think about your discovery process, like you should set one up.
And I think you do set expectations that this is part of your job as well as developers is to be a part of this discovery process. It's not that you're going to be running the discovery process as a developer, but you're just going to be involved in a capacity that makes it worthwhile. Another thing I see people do that does not work is trying to involve the developers in the entire discovery process all the time, making it like a second job for them.
It's usually not where they want to be involved. So you have to think strategically about where do I need their feedback and where would it be helpful for them to give feedback so that I make sure I'm designing this correctly. Then pull them in. Don't waste anybody's time. Don't make them sit there and listen to other people.
If they're not collaborating, that's not an effective use of everybody's time. I think meetings where it's just status meetings are never fun. So figure out how to streamline that away and make sure that it's valuable for everybody. And then everybody will want to participate in the discovery process if they feel like they're contributing and doing good work.
So I'd read some of the books that I mentioned, try to craft a discovery process for yourself. And again, iterate, check and see if it's working. If it's working, great. If it's not working, change something and try something new. I think all of this is super flexible. Everybody's just trying to figure out the best ways to work.
I don't think any process should be super set in stone. And it's like, if you don't do this one meeting, you know, oh, you're doing it wrong. It's like, no, just find what works for you.
The goal at the end of the day is to build great products. If you build a great product, you did it right. And if you didn't build a great product, something's wrong, so change it. So that's what I would keep in mind as you go through this process. And remember that, you know, you mentioned you're a junior PM.
Great, you're gonna be a senior PM one day. And the difference between a junior PM and a senior PM is that senior PMs understand that outcomes are their biggest job and it's not just to follow the agile process. Like that's what people are hiring for in senior PM. So think about what you need to do to shape your work so that you can deliver high quality outcomes that really help your users and your business.
All right, that's it for the Dear Melissa this week. Again, if you wanna submit questions, go to dearmelissa.com and we would love it if you left us a review on your favorite podcast platform. Take care and we'll talk next time.
