So Many Ideas, So Many Products: How Do You Scale Ideation?
Speakers
Samantha Hamlet, Revathi A Menon (Gainsight)
Session Abstract
Most community ideation programs share the same quiet problem: feedback gets collected, but never truly owned. In this session, we'll walk through how we rebuilt our own ideation process from the ground up by turning an unowned, decade-old backlog into a system with clear accountability, enforceable SLAs, and improved customer experience. You'll leave with a process model you can apply to your own community, illustrated with our own before-and-after picture and the honest parts of scaling this beyond one product
Related Videos
[Speaker 4]
Thank you.
[Speaker 1]
Okay. Hi, everyone. Thank you so much for joining us today.
I love seeing a full house. So thank you for being with us. Just to give a quick introduction of ourselves.
My name is Revati. I lead the community, Gainside community team. This is my rock star teammate, Samantha.
I know there are a few familiar faces here who we see around on our community. So I'm glad to see you guys as well, joining us today. Okay.
What we're going to share today is sort of like a glimpse into what happens when you start giving a talk. So I'm going to start with a quick question. How many of you have enabled ideation a lot of your time?
Now, before I jump into the details of things, a quick check within the group. How many of you have currently enabled ideation or used feature requests on your community? Just a show of hands.
That's quite a few. Nice. And how many of you are considering kicking it off?
Okay. And how many of you currently don't have it at all? Okay.
Looks like everyone's... Okay. Looks like people are leaning more towards, like, having it already or in the process.
So it's a good mix of folks. And if you're already not considering it or if you're in that early phase of it, it's one of the best things that's happened to our community. We've seen it move from being unaddressed to a place where our customers are starting to feel heard.
One of the best things that ideation can do for you is that it'll help you have your customers have a say in the way your product evolves, which means they feel more closer to your company. At the same time, it's also a great way to catch any churn of frustration signals and threats that you go through, which will help you sort of go back, talk to your CSMs, catch it at the right time before it turns into churn. Now, quick question, and I'm gonna go into the slide right after that.
What happens when ideation is not a priority? This is what happens. As much as...
Again, ten years, that's not a typo, and I'm not exaggerating either. Ten years we've had ideation on our community, and it has stayed unaddressed for all of those times. And it's not that someone got lazy or someone didn't care, it's just what happens when you have a feature and you're unsure where ownership generally sits completely.
So if that sounds uncomfortably familiar, I'm kind of glad because what we're about to take you through is gonna help you, and we're hoping it helps you scale ideation at a much larger scale in your own community.
[Speaker 2]
So here's where we're taking you. First is the process we built, and I promise it's reusable, not just something that happens to work for us by chance. Second is the proof.
The actual numbers, the actual mess, and we're not just going to show you the highlight reel. And third is how we're scaling it. Once you take this past one product, what actually changes, and where we're taking it next.
[Speaker 1]
All right. Let's get into the actual mechanics of how we built this. Like any other community team, there are moments you have to have a reality check for yourselves when you look at your community, and it was the first thing that we did.
And I have to give kudos to Nadia, who's here, because last year, right after Pulse, we went back, and Nadia shared a list of customers who were really, really upset that our ideation was not getting its due attention, and that's where the whole project sort of kicked off. So I'd say almost close to a year that we've been doing this, and what we actually did was we sat down and looked at what our customers were living through, and there were three things over and over. They'd follow up on the same idea, they'd quietly disengage, and then sometimes there was a point where they'd completely stop.
So we started noticing customers who were really active were not active anymore, and this obviously led to us missing real intense signals about how our products could get better. But here's the thing. None of those were actually just the problem.
They were just symptoms, and underneath each was something that was much more fixable and much more... I mean, we kind of missed it at the end of the day, but it was easily... If you found it, it's easily fixable.
Those were no visibility, inconsistent engagement, and unclear ownership. Fixing the cause is what really mattered for us to make sure these symptoms don't exist anymore on the community. 10,000 plus ideas sitting there, and I want to be clear about something.
The number, obviously, we've moved it to 5,000, sounds great, and it's very easy to run an archiving script and get things off the radar. The hard part was us to look back and be like, yeah, we've had 10,000 ideas in the community unaddressed, right? It's very courageous for a community team to come up and say that to business that, you know what, there are 10,000 ideas that probably could have helped the product scale better.
We ran an archiving process as soon as we heard about this. We used the help of our product ops team, community team, as well as our PM. I would say it's a team combination.
It's not something the community alone can drive. You need to get the other teams on board as well. Once we ran the archiving process, this is something that you can easily do on the CC platform or any platform you're on.
You're basically setting thresholds to ideas to make sure they don't stay in the active pipeline and move into an archived category. And this archived category is something that your customers can still access. It's not something that we've hidden and they can't access any of their ideas anymore.
We still value these ideas, so they can always go back, tag us in, and be like, we want to bring this back. It's extremely important. Is there any way we can have these discussions again?
So these thresholds are set based on, you know, how your product works. I mean, I'm just giving an example of a rule you can borrow. For example, you have, say, an idea with 100 votes versus an idea with 5 votes.
So you could set a threshold saying anything that's less than 5 votes and has had no engagement over the last year gets archived into the archived category. And this is something that we do every year now. Like, that's a process we've set.
And the one decision that we did completely change the noise level for our PMs because our PMs were looking at 10,000 plus ideas, which is insane. So this helped us bring it down to 5,000. And then, obviously, there were further processes to fine-tune it and make it possible for all the teams to work together.
[Speaker 2]
Okay, so the backlog was clean, but a clean backlog on its own doesn't stay clean. If we didn't change anything about how ideas were handled day-to-day, we'd be right back at 10,000 within maybe a year or two. So we asked ourselves, what actually causes a pileup in the first place?
And it came down to four things we needed to clear at the root. Moderation, so ideas get looked at often instead of going cold. PM response SLAs, so every high-signal idea has an actual name attached to it along with response timelines to keep things moving.
An ownership model, so nothing sits in limbo without a team responsible for it. And customer signal tracking, so frustration gets caught by a team member before it turns into a churn conversation. And almost as a side effect, our reporting grew up right alongside all of this.
We now use AI-surfaced dashboards on top ideas, ARR signals, and RISC signals because, basically, the foundation became solid.
[Speaker 1]
Now I could stand here and tell you, all of this went really smoothly. We've been super successful. Great story that I could tell.
But obviously not, like any other community, we struggled through all of this. The dashboard that we built started overwhelming our PMs. They were looking at so many ideas through so many years. And they just...
I mean, I'm not even kidding, just like a week ago, I still had an update from PM saying, like, I'm still looking at some ideas that I probably shouldn't be looking at because the thread says I upvoted and that should not be a reply I need to tag, which makes sense. So we had to go back and start fixing things. So for example, the dashboard that overwhelmed PMs right now has Slack automations.
And what we do is we've started tagging the Slack automations with the product area as well as the PM. So the PM gets exactly what they need to look at. We're also using AI to sort of do a sentiment triaging.
We're looking through threads to see if there's any frustration signals, churn signals, anyone who really is showing any signs of urgency. So our PMs are using their time to address that. And honestly, the most embarrassing one in all of this would be that if you were someone who were coming into our process for the first time, there was no way you would understand what we're doing.
So we started documenting this. There were internal coders and processes and spreadsheets and all of this set up so that anyone who needs to access it gets it. And the CSMs, and I'm sure some of our CSMs here could agree, there was no way for them to let our customers know what was happening.
So we ran enablement sessions internally to keep our internal teams updated on the changes we were making. And it wasn't just an internal mess. Our customers felt the growing pains, too, honestly, even more than us, of course.
We quietly did a massive overhaul, and they didn't know what was happening. Suddenly, you know, you could see ideas are changing, updates are coming through. So we started giving updates on the community.
We started sharing a public post on the archiving process, letting them know that ideas will be getting archived regularly or yearly on our community, and an executive node explaining the ideation rework. Now, this is a very, very important part, and I know a lot of us struggle with it, which is getting executive alignment to get things moving. So one of the main things that we did when we kicked off was to make sure that our teams, our executive teams, were aligned in the process so that we were able to publicly announce the effort we're putting towards this process.
Another one was the public post that spells out exactly what each idea status meant. Ideas were moving to development, for released, they were moving into parts. So no one knew what this was.
A few of them did, because they've been legendary community members. But some of them were new, and they didn't know what to do. We started having another post that explained each of these statuses, and customers also couldn't tell if anything was moving, which means we needed to be even more proactive about what the movements were, and we started putting out quarterly CC reports.
For example, with CC, we have a report that goes out every quarter letting our customers know what ideas have moved, which aren't released, which aren't in development, and that helps our customers get a bigger picture of where the product is moving.
[Speaker 2]
So this isn't theoretical. Here's what it actually looks like in practice. That's a PM dashboard on the left, natively within our CC instance.
In the middle, you'll see a sample of a Slack alert firing every week, and third is a public archiving post. We're at 60-plus of these dashboards now across our teams, and still counting. We're also across 75-plus refined product areas, which a year ago didn't exist at all, and will continue to be revised based on how our products evolve.
On the customer side, this is what transparency actually looks like when it's not just a buzzword. The status update post and our quarterly report, all public, all real. This next part mattered more than we expected going in.
Our leadership didn't just approve this quietly behind the scenes. They got involved. They posted about it on the community publicly, and something interesting happened internally because of this.
It stopped being a priority, a project that we could deprioritize. It became a deadline we had set for ourselves in public for our customers.
[Speaker 1]
We've gone through a lot in the last few minutes, so we'll take a moment to just go back and zoom out. You see all of the points as written here, something that we've covered, and they all work together. One of them leaves the picture, and it struggles to balance.
The naming is what actually... The problem is actually what we did initially, which is find out what the customers were going through. Then we started finding the root cause behind it, which is we didn't have a process, or there was no SLA set internally.
Then we had four levels that we pulled that Sam was explaining. We set up an SLA cadence, which Sam's going to give you a little bit deeper look into, and then a backlog reset. Now, this has been majorly useful for us because going from 10,000 ideas to 5,000 means we're giving so much more room for our PMs to look at ideas in a much more bigger picture.
Six moves totally, but it's really one connected system. All right. There's a small question that I'd like to ask before we can actually go into the next slide.
For the folks here who've already got ideation going on, do you guys have an SLA template, or do you have a process template that you follow internally right now? Just a show of hands is good.
[Speaker 5]
Okay.
[Speaker 1]
Great. Then I think this is going to be useful.
[Speaker 2]
That's a good one. That is perfect. We actually have something you can take home today.
On the next slide, we're going to show you an actual example of an SLA template we use internally. We've obviously made up some numbers on there in place of the real ones, but just so that you have a starting structure that I hope will be useful. You can take this, drop in your own thresholds, and use it to set expectations internally on response timelines.
We can pause for a moment on the next slide. Feel free to take a photo of that.
[Speaker 1]
Just a heads up, these are not real numbers. Don't hold them to us if you're a customer on here. This is just an illustrative example that could be very helpful.
Again, it depends on how big your ideation looks like right now. If you've got multiple statuses, again, you'll have to depend on that to define how each of those statuses have to be addressed over time. Some of our statuses are marked here.
It depends on how complicated that can get, but it's very, very doable. We've tested this out multiple times before we finalized what this looks like. We tested this out on one product, and then we are obviously expanding it to other ones.
[Speaker 2]
Thank you, Revs. New ideas here with five or more votes get moved to open and onto the PM's dashboard within 10 days. Open ideas that cross 30 votes get a status change or a thread update every 30 days, and discovery and development get a PM check-in every 60 days.
[Speaker 1]
Okay. So, the process is one thing. Let's actually talk about how this worked.
Now, this is the exciting part that we'd love to show off. Here's the part that still surprises a little, but also we're really, really proud of this. Last year, around the same quarter time, we were at 25 shipped ideas.
We're almost like at four times that right now, and we still have six more months to go. And I'll be honest, when I say 94, probably like 60 to 70% of this are actually shipped ideas. That's a 20% in there, which is just us doing its due diligence of updating older ideas that never got a status update.
But this happened because the process was obviously working.
[Speaker 2]
Honestly, numbers are easy to be proud of quietly. What actually convinced us was hearing from customers directly. Julian wrote in to say he's very happy that the feature released, and continued to share new idea submissions to expand his released idea further.
That last line, where he's already planning his next idea submission, that's an important one, especially to us, because he trusts it will actually go somewhere now. These notes coming back when things get moving tells us we're slowly heading in the right direction. Beyond the stats, here's what tells us this is real and not just a quarter of good luck.
PMs are actually in the threads, having real conversations, and not just posting status updates and disappearing. Customers are coming back and responding, reengaging, and instead of that slow fade into silence that we all know, teams that used to work in isolation, community, product ops, PMs, are actually coordinating now. Ideas that have been sitting untouched for months are finally getting a response.
[Speaker 1]
Now, this slide is actually something that I really care about, and I'm sure all of you will as you continue to scale ideation in your community. The left side, if you see, obviously talks about the really good numbers, which is 122 ideas across all products are shipped. Amazing.
But the right one is a really tough one for us community members to talk about, which is the parked ones. And by parked on our community, it means it's not addressed right now. We will look into this very soon.
So probably during a roadmap planning phase, we'll go back, look at all the parked ideas to see how can we bring them into our development picture. And it's very difficult to have this conversation as well with the customer because it's slightly tending onto the negative side, not the positive side, so it's not a big win. But it's also very, very important because this is how you develop transparency and trust with your customer.
Your customer's really clearly understanding where your product's heading and are you actually looking at ideas? Are you skimming through what they've been submitting and making decisions based on that? So this has been a really proud moment for us as much as we're still triaging, and I'm not going to lie, it's never an easy job to tell a customer something's parked.
We still struggle with it. But I think this would change the way you build your relationship with your customer. Okay.
So here's another one that you can walk away with. Everything we've shown you, the process, the thresholds, the parked versus released numbers, none of this matters if your customer doesn't have a place to go find all of this and know how to use ideation. Playbook.
One of the things, and I have to, again, give kudos to one of our customers who actually suggested this to us because as a community manager, we didn't realize this didn't exist for a really long time. This is like an actual public guide that we have up on our community which basically takes our customer through the whole process of ideation. It tells them what a good idea looks like and what are the FAQs that we get.
So there's multiple aspects to it. We also have it linked to the status update, the status explanations, the announcement from our executive, the archiving process. So all the resources are coming together inside OnePost, and this is obviously a work in progress because your ideation process will also change based on the number of products you have, and it's going to be very different across each product.
So we've been very loud and clear about how we're approaching it, very transparently back to our customers. And we'll continue to build on this so that the transparency aspect does not fade away eventually.
[Speaker 2]
Now here's where it gets genuinely harder. What happens when you need to scale this through multiple products? How can we continue to develop this to be more seamless and powerful?
We wrote this directly into our own guide because we wanted to be upfront from day one. Everything above currently applies fully to CC. We're reworking the process from scratch for CS, and other products will follow.
Every product has different SLA needs, different roadmap realties, and different levels of community maturity. So the rule we'd actually give you is avoid copying the same playbook that you build. Define it fresh for each product.
Some pieces may transfer cleanly. Others will need to be rebuilt entirely.
[Speaker 1]
We've been there. I mean, to be honest with our products itself, there are parts of the process that didn't work with the other products, so we've had to scratch that, rethink that to work with the PMs within that product or with the product ops focus within that product. So be open to, and it's also the best way to say it, I would be, it's okay if the process fails with the other product.
It's a learning moment. It's also point for you to understand that we just need to modify it to suit the needs of the product. Now, where we're headed next is actually pretty exciting, because there's a lot of learning that we've had in our own processes, and one of the things, and I'll be very transparent about it, was when we started working on this process, we were already done with roadmap planning, so it was sort of like at a place where we were trying to fit in ideation after roadmap planning was done, which is a funny place to be in. Right now, we're at a place where we're trying to do the sort of like vice versa. We're trying to start with bringing in ideation into roadmap planning when the conversations are happening, and on the tooling side, we're investing more in AI, and that doesn't mean we obviously still want to use our native CC dashboards, but we just want to make it much more lighter to carry for our PMs, for the community team, and for product ops.
We're also pushing feature requests straight into our own product team, so if there's something that we're doing with AI, which we think should be there within our native dashboard, that would be something we push internally back to our PMs to say, why are we not thinking about this within our dashboard, because it seems like an obvious thing that we should be doing. Here's four ways AI is quietly doing this for us. It reports on the automation.
We push into Slack channel, where PMs will look through high-priority notifications, so we have like a notify side that's running, picking up which PMs not responded to it, how many days is it overdue, so it helps us sort of like hold them accountable. It's also generating full reporting dashboards for the products processed through Claude. Claude's been our third community team member, like we like to say it.
It's flagging which threads are genuinely very, very important for us to look at, not just how many replies piled up. It's also surfacing trends. Now, this has been very important for our PMs, because one of the things our PMs asked for was, could you tell me what are the trends and what are the areas or themes within product that people are asking for?
So AI has been really helping us with setting that and bringing it back to our PMs. Now, we started with exactly one type of reporting, which is what you see, the idea pipeline, where we had like a bunch of 5,000 ideas put into different products. Now, we've kind of expanded, and I think we're still continuing to work on it. We have more than, like we're close to five of them right now.
The open pipeline gets its own dedicated space, because open status is one of our biggest buckets. Most of our ideas move to open for acknowledgement, and it stays there for a while. It has to be looked through very often to see when it can move into development.
AR at impact ties actual revenue back to the accounts behind the idea. So this stops being just a community metric and actually starts being a business one. PM engagement is actually basically like a leaderboard.
It's also great for morale. So we've got like, we usually say, like on a quarterly basis, we say, oh, these PMs, like three PMs who top the leaderboard for like engaging most with ideas, right? So we're trying to make that even more into like a rewards and recognition program for our PMs as well.
And customer sentiment tells us what's quietly heating up before it becomes a loud problem. I'll take a moment to give a shout out here to one of my partners from product ops, Prashant. He helped us build this amazing AI reporting dashboard, which we now share with our executive teams to let them know what are we trying, what does ideas look like, where does it sit.
We'll show you like a glimpse of that as well very soon.
[Speaker 2]
So here's an example of what that looks like. We can pause on this for a moment, but you'll see some of the items that Revati mentioned over here.
[Speaker 1]
Illustrative example, don't hold us to the numbers. But if you see here, there are a bunch of things that you can see that I mentioned earlier, which is the idea pipeline, open pipeline, all of that. This is something we share with executives.
We're also refining this a little bit to make it even more, I'd say, shorter and concise. But right now we're at a place we're trying to get as much ideas that we can to understand where ideas are sitting within each product, because we have a lot of products. So it can get very complicated.
So we have this separately for all products. It's not a combined report, per se, because it just doesn't make sense that way.
[Speaker 2]
And here's the PM facing version of a similar system. This is something that we truly love and was developed by our legendary PM, Deepin. He created an app version of what we envisioned to be able to switch between PMs and get a glimpse of their workload, SLAs, and pending work.
[Speaker 1]
Now, I'm also going to double down on this one, because this happened very close to us coming into Pulse. I was running behind the PM saying, like, we need something that can help even our PMs. One of the things the PM said was, we're looking at a lot of ideas, but we don't know which one we've responded three months ago versus, like, ten days ago. So this one goes into, like, heavy details.
If you see this, this kind of, like, I mean, it's not very clear here, but I can just tell you. It tells you exactly, like, where the idea was submitted, when the PM responded last. So it kind of gives them pushes to tell them, like, hey, you still have 90 out of 100 ideas that you haven't even touched.
Or you have 30 out of 50 ideas that you haven't responded since three months. So it's much easier for us to hold them accountable. And this also obviously helps us, because holding someone accountable internally becomes easier, which means our customers are getting timely responses.
So this is done completely with the help of AI. It's not something that's on the dashboard. Hopefully very soon.
Okay. We're almost at the end of the session now, and I want to close that with a very few important notes. So if you're trying to take this home and actually run it yourself, here's the shape of it.
Start with diagnosing, right? And don't stop at what the customers are complaining about, because that's not really the issue. Customers are complaining about something because the processes are missing internally.
Fix the root causes, not just the symptom. Make it enforceable, right? And expect the process to break at first.
Like, we've had multiple processes break. We've had frustrated movements. That's going to happen.
There's no way you can get out of that. But avoid rules that you can't modify. Make sure that it's modifiable based on the products that you have.
And also the life scale of your product. Like, some products could be really, like, running really long. Some could be very new.
So it depends on all of that. Prove it publicly. I honestly love this, because I think it's a very nice, I'd say a very smart way to get your teams to be accountable for things when you get your executive to talk publicly on community.
There's no way for your teams to back out from doing something. And lastly, adapt, don't copy. Again, something that I think Sam said a few slides before.
Every product is going to need its own version. So be open to, you know, sort of, like, editing it, modifying it, letting things go where it needs to go. And we hope you never stop focusing on ideation.
Cool. We've come to the end of the sessions. We're very, very open for questions.
And I'm going to use the mic. I have an idea for that. Thank you.
[Speaker 3]
Yes, we do have some questions. Perfect. I love this.
Thank you also, Samantha and Frank, for this really open and honest session that you talked about today. Yeah, let's start with the first one. How do you make product ops and PMs invest in the future?
[Speaker 1]
I love this. Okay. I'm going to say this.
We still struggle with this. Like, I'll be honest. We still struggle with the sense where right now we're at a stage where we're trying to bring in one of the things.
Okay. I think this is the best way to say it. One of the things we've done is we've picked up from each of our product the top 15 votes.
I mean, top 15 ideas with the highest votes. We've taken that to executives as well as to our PMs to be like, okay, what are we doing about these ideas? How long have they been sitting?
What does the sentiment look like? What are the customers in there? We've also tracked ARR.
So, if you're looking at that, I think that makes a huge difference to take it back to your teams to say, should we be investing in this feature right now? Does it make sense? How much ARR?
Does that help? So, that's been a big pivot for us the minute we brought revenue and ARR into the picture. But otherwise, I would say it is a tricky place, guys.
I'm still struggling with it. But this has helped us move a few of our shift ideas. I think for CC, I can confidently say that 15 out of our top 25 ideas are in the process of development, which is a big, big one.
And that's also because we brought ARR. The number of people who watched it brought all of those data into executives and our PMs to say, you know what? This is what it's looking like, and we're not doing anything about it.
So, that's a great way that's helped us. So, yeah.
[Speaker 3]
Yeah. Make it feasible in multiple ways.
[Speaker 1]
Yeah.
[Speaker 3]
And you need to redo it over and over again.
[Speaker 1]
Over and over again.
[Speaker 3]
It's a process. All right. Go to the second one.
How do you manage the priority of IDE implementation when the roadmap is already in place? I love this question.
[Speaker 1]
I love this question. Whoever asked this. So, I'd say try to...
I'll be honest. There's no way all of the ideas that you see on the community are going to get into your roadmap. It's impossible.
But you need to find a way to get the representation of ideas into roadmap. Best way would be go to your executive and get that into their V2 moms. One of the things that we're also trying to do is get a percentage of reflection of ideation into V2 moms of our executives so that we're able to say 25% of ideas that we've shipped today this year has come from community.
So, that's a great way for you to get prioritized. We are very close to getting it done, so I feel good saying it. I know it's difficult.
It's a few months of running behind executives to do this. But that's a great way for you to make sure that IDE implementation never falls off the radar.
[Speaker 3]
All right. Thank you. Let's go to the next one.
How do you make customers feel special when their IDE is shortly implemented?
[Speaker 1]
Oh, my gosh. I think we did this when Nadia shared a bunch of... Last year, we got a list of...
A really huge list that Nadia sent us of customers who had a bunch of ideas. I don't think we had 100 ideas in there. One of the things that we did was we...
Obviously, there was a bunch that we were not going to do, we were going to do. And the ones that we did, we tend to add them into our release notes. So, when we send our release notes, we start writing their names into it saying who submitted this idea.
You know, thank them publicly on the community. The release notes goes everywhere else, right? Through marketing.
So, everywhere their name is mentioned when they're able to get out an idea that they've submitted, like, eight years ago or five years ago, right? So, that's a great way to get it done. Another thing would be if you have got them in your betas, right?
For example, like, we do that for a lot for CC. We have a lot of our customers who are active on our betas. So, anyone who has been in betas who has actually written any of these ideas, also congratulate them talking about how they're a beta group buddy.
So, we have something called a beta group buddy that we give as a badge. So, we give them that badge as well on the community to sort of, like, appreciate the work that they've done.
[Speaker 3]
Yeah. That was a really powerful way also to showcase it and make it, again, visible also on your own community. So, using that is really powerful.
We struggle because people upvote the low-value items rather than think strategically. And the challenge is why we're not doing the most voted.
[Speaker 4]
Yeah. How would you manage this? That's a really good one.
Very, very good one. Honestly, really good one.
[Speaker 1]
I'd say there are two sides to this. So, I was talking to a customer yesterday, and I love this question because of that. One of the things is what is low-value for you could not be low-value for your customer.
So, think from that aspect because some of the customers want even the basics to be fixed when we're thinking like AI and, like, the big picture, and we're trying to, like, go into a different world of our product. There are some basics that, for them, are not low-value, but it's very functional for them in their daily work. So, I think you have to look at it from that angle.
The other aspect would be to set thresholds. I think thresholds make a huge difference. If you're saying low-value item has, like, 100 votes on it, then it's clearly not a low-value item.
A low-value item with, like, 10 votes, 20 votes, I get it, right? So, set your thresholds based on what low-value looks like on your community more than about how they submit something, and that'll help you sort of, like, get that out of your pipeline into, say, an archived category or we'll revisit later. Some sort of a status that'll help them understand you will revisit it later.
So, look at it from both angles. A threshold helps you sort of, like, save face, I would say, when you reprioritize something. But on the low-value aspect, if you think it's low-value, I would say always talk to the customer to understand why it's high-value and why have they submitted it.
[Speaker 3]
Yeah. Totally love it. How do PMs balance implementing features suggested by the community and the long-term roadmap?
[Speaker 4]
Okay. Great.
[Speaker 1]
I'm glad for this question because I had this chat with Yori from RCC, our group product manager. He's amazing. So, we were talking about how do we bring in roadmap planning and features suggested by the community into the same picture.
That's where we came out with the one thing that, one, get your V2 moms from the executives. Make sure ideas have a representation in that. The minute your executive is aligned in that, it's much easier for your PMs. It makes PMs' life a lot easier because there's only so much say that they can have as much as they're also very supportive. They will be on board with you. They will support you. It is difficult for them because of the bandwidth that they have.
So, the minute you get V2 moms aligned with your executives of what the representation looks like, it's going to save a lot of time. The second thing would be try to be on roadmap calls. Try to understand what the picture is being painted by your PMs. Bring data to them, right?
They don't have this kind of data, so it will be on us to sort of bring this data out, tell them, like, okay, this is what the roadmap planning looks like. These ideas seem like it's related to roadmap, but these are also still high voted. How can we find time?
Obviously, you're going to face issues. There will be customers who might be big paying customers or there might be customers who have been promised certain features who are still going to take time from the roadmap. But that being said, that's helped us a lot personally with our PMs when we've sat with them on roadmap planning because we're already currently doing that because that was a miss on our part last year because we started the project later.
But that's something we're doing where we're sitting with them, bringing into the executives V2 moms as well as we're also looking at the roadmap and being like, okay, how much of the ideation represents the roadmap, and if it doesn't, what's the gap here, right? So that, again, becomes a discussion you take to executive to be like, you know, there was a point we did have discussions where, like, why do we have ideation if we're not representing it on roadmap? Like, what's the point, right?
Like, that's a big question. So the way that we can push that barrier through and tell them is to actually bring the data to them and show them that, hey, you said roadmap looks like this, this many ideas matter, but these ideas are not even getting represented. It's been eight years, 250 votes, right?
Push the barrier a little bit through. It's going to take time. I'm being very honest.
But you'll get there. Like, trust me. Yeah, buy-in is really, really key.
Buy-in is so important. Oh, my gosh, yes. Like, I feel like the 10 years of ideas that we've had unowned on our community was just the lack of buy-in and the effort probably we also put into not getting that buy-in, right?
But the minute we changed that last year and we pivoted and started showing data back to our executives, it was much easier to get that buy-in. And now they understand that we want, I mean, more than understanding, they also want ideation to be shown into the V2MOMS and into the representation of the roadmap.
[Speaker 3]
Yeah, we shoot it really high. We flag that with our own... With Erica.
[Speaker 1]
With Erica.
[Speaker 3]
Erica was just a boss at getting it done for us. If she said, like, this is important, then it's important for the rest of the organization as well. So that's really important, I think.
Right. Let's go to the next one. Where does the ownership of creating a model like this lie?
The CS, PMs, leadership, all three of them, and how to influence leadership to prioritize this?
[Speaker 1]
The last question, I feel you, because I was there last year. But I would say the ownership, to be honest, lies on community, because this is on your community, right? At the end of the day, somewhere you have to take ownership because it's easy to fall off the radar for others.
We've had that situation where we've picked it up, we've set a process, and then we've handed over the leadership to someone else, and then it just fell off the radar. So we're still looped in for every discussion that we have. Like, we prefer community being, like, the higher-level looped-in part from the community side because ideas are on our community.
And how do I influence leadership to prioritize this? Very good question. I would say, again, data.
You have to take data. Use ARR. Use business numbers to take it back to the executives to show.
If you've got big, paying customers on your community whose ideas are not shipped yet, if you've got high-voted ideas on community that are not shipped, collect the ARR data. Take it back to your executives. Show them what that number looks like.
Also, catch even churn of frustration signals, right? Like, look for signals where someone's feeling, you know, like they're not being heard or showing some sense of urgency. Like, we've had those situations where customers have come and just been, like, giving up.
They're literally giving up on our threads. Like, we can see that. Use those.
Let them know so that the CSMs can step in for you. There'll be more people to support you in this scenario.
[Speaker 3]
Yeah, 100%. Let's go to the next one. For a team with no PM dashboards and a small headcount, what would you do in the first 30 days?
[Speaker 1]
Well, I wish you had dashboards. Like, it would make your life so much easier. Okay, for the first 30 days, I would suggest that you go back to your ideas and start.
So, the one thing we did for the first 30 to 60 days, I would say, was a backlog reset, which is you go back to your oldest idea and then work your way through to the latest idea, because your oldest idea probably also has a lot of votes on it, because it's been sitting there for really, really long. Also has really low votes on it and can be easily deprioritized and moved aside. So, go back all the way to, like, backlog resetting your ideas.
Fix from the basics, you know. Like, for example, we had 10 years of ideas, which means 10 years that we had to skim through. But if yours is much lesser, that's a good thing.
And start from looking at things from the vote perspective. Obviously, I wouldn't say just because something has a high vote, it is going to be shipped by your business. Like, that's not how it works anywhere.
But the truth is that you still need to use votes as a threshold for having customer conversations. So, look through the votes. Try to triage the high-voted questions.
I mean, high-voted threads or ideas first, and then work your way to the low-vote ones. That's a much easier way to, like, communicate better to your customers. And you don't really need dashboards for that either.
Like, you could, like, filter. Like, put them on a spreadsheet. Filter them based on votes and, you know, things like that.
So, that makes it much easier if you're a much smaller team.
[Speaker 3]
All right. Let's go to the next one. This one's a really long one.
And I think I have a little bit of a reading problem.
[Speaker 1]
That's fine. That's when I can read it. I know it's also an odd angle for you.
Have you consolidated all ideas raised by customers into one place? Well, it's a mix of both, I would say. Obviously, our CC dashboards help in getting everything into one place for us, right?
But the only difference is that, like, for example, the app version that you saw that our PM built, that's a different space that our PMs are using. But that doesn't mean they forget our native CC dashboards, right? They still use that for, like, triaging important things.
This is just to hold them accountable. So, I'd say a mix of both. But primarily, we have it all in one place.
I mean, obviously, we don't have the SLA thresholds on our native dashboard. Like, that's not there because it goes on Slack and, you know, other spaces. But the data that we need is currently sitting within our dashboards for all of our PMs to access.
Even our executives can access it. It's just a bunch of customized dashboards that we've created there.
[Speaker 3]
Great. Yeah. I think we have just time for one more question.
Cool. Yeah, let's go forward. How do you stop AI sentiment triage, misjudging tone or missing something important and who checks it?
[Speaker 1]
Right. We got our IT team involved in this because we really needed a lot of help when we started going into sentiment analysis. And I'm not going to lie.
We're still working through it. We still get false positives. Something comes up and we'll be like, oh, this doesn't feel like an urgent request or, like, it doesn't go into our frustration signals that we've defined.
But there are some defined metrics and keywords that we have picked up from all of the ideas that we've had before. We've picked that up and then we have the AI run the sentiment triaging. But, yeah, I would say take it with a pinch of salt because there will be moments.
You have to train AI for a while, right? So we're still in training. We're at, like, what, three months, two months into using that right now.
I'd say minimum three months. You have to train it to, like, get it to a good place where you can trust it. But you will get there.
Like, we still do get really good. Like, we went from 20 notifications in a week to, like, five, which I think is big, right? And there are still false positives in that.
So there are opportunities like that, but it's very possible. The minute you start training your AI, you can get there. But get your ITs involved if help is needed.
Like, we've taken help from a lot of teams to get to the place we wanted to.
[Speaker 4]
All right.
[Speaker 1]
Thank you.
[Speaker 4]
Are we on time? Yeah? Yeah, we're at time.
[Speaker 1]
Thanks, everyone. Thank you so much for today. Thank you.
Have a great time.