Doing some backlog grooming. Do you delimitate between requests that are legitimate but won’t get done unless there’s more interest and those that are ready to execute when there is bandwidth? I’m reporting back to a customer on the status of their requests and want to separate these somehow to set their expectations.
3 Likes
That first type of thing usually isn’t even in my backlog, I’d be talking about it being in the discovery phase. So yes. Stuff that’s going to be executed on and just hasn’t yet I’d communicate where it stands in terms of priority and generally some rough timeline like “its ready for the team to pick up but they still have stuff in flight so it should be ready this quarter” vs “I’m doing research on X and Y, I’ll be calling some users/customers/whatever is appropriate over the next few weeks to understand these things better”
But also… It sounds like someone is dictating features to you and you are just passing them to the engineers? Why do they want the feature at all? Are there better ways to meet those needs?
3 Likes
Thanks @NaomiNwosu. My company serves the top-tier enterprise market for our industry so our big customers often have many requests. Many are legitimate and useful, but there’s just way too many for us to ever cover. I like the discovery phrase framing as opposed to the backlog that is actively being burned down.
3 Likes
Yeah I’ve been there - and a lot of those requests are just kind of top of mind shit from whoever happens to have attended the meeting, usually telling them you’ll do some discovery on that feature is satisfying for them.
And half the time, frankly, they don’t even remember they asked for it (depending on the person its probably MORE than half the time…)
So I would just describe all those requests as opportunities for discovery.
And then prioritize discovery around the ones you think sound most valuable.
3 Likes
Basically requests from customers are signals. The way I’ve treated that in the past is to tell the customer that it’s an interesting idea and I appreciate the suggestion - we’re now going to canvas that around other customers to get their input and if there is sufficient positive feedback it will be prioritized against other candidates.
You can read more about this approach here:
2 Likes
Thanks @KaranTrivedi, that initial feedback to the customer makes sense to me and thanks for the helpful article!
1 Like
For me personally I’ve always just allocated them into a section of the Kanban board which says these are all the ideas people have ever spoken about and keep it very distinct from those that actually got validated through discussions or analysis.
This allows people to know that their ideas are being heard and would even be worked on if they are analyzed as useful and keeps them sharing.
They can also see then that there are some smart ideas which get picked up or molded to become useful features and are being implemented.
1 Like
@Nathan, Good idea. I’ve recently started recording and auto transcribing some of my user interviews (with permission) and it helps the team with context.
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.