What tagging structure is helping you manage insights?

@pstrouven_pxc here’s my thoughts:

Tags are metadata and can help you filter, create collections, identify patterns (see tag cloud) and help speed up note processing (processing notes with similar tags means you’re not context switching).

Back when I worked in UX, my former colleague Gene Smith wrote a book on tagging and called out seven kinds of tags:

The best practices I recommend are to tag notes at three levels:

• Product or Product Line. If you have multiple products. Use these to identify feedback relevant to particular product managers — helpful to speed up identifying owners that will triage
• Theme. Use these to represent the content of a note — helpful for identifying patterns and categorizing further. Example: usability, SEO, performance, API
• Content type. Use these to help you find particular notes. Example: research, usability test, customer call or customer interview.

Reviving an old thread …

I’m implementing a feedback processing system for my new employer. This is a team of experts, not “product people” so I’m rethinking all my go to processes.

For one, how should I categorize insights. Metadata about product lines, sources, and the customer are all pretty straightforward. But what about insight “types”?

Do you categorize by type (eg need, feature request, comp intel, etc) and if so, what does that structure look like? Is it working for you?

Thanks @scott.baldwin. That table is really interesting. That’s actually what made me think this is the right thread to have this discussion. It made me think of how hard I thought about my tagging strategy back in the “del.icio.us” days … wasted brain cells 😂

What you refer to as “content type” I’ve generally considered the source. I might have a combined set of source tags on an insight like context--prospect-call (source context) and system--gong (source system).

When I say type tagging I’m thinking more about the intent or implication of the insight. Was the submitter …

• Reporting a defect (“Form A is broken and never does …”)
• Describing a solution they envisioned (“I really need a purple button so …”)
• Explaining how a competitor is doing things (“App B offers me a voice-activated …”)
• Telling us about their struggles or job context (“I’m having a hard time dealing with the volume of new leads when …”)
• And probably lots of other things

The simple tags used to frame things like this have an unintended impact on how others perceive and use it. And I’m sure I’ve missed categories of “intents” that have caused categorization mistakes. We can put policies and definitions in place to mitigate that, but it’s always nice to make things as self-evident as possible right out of the gate. I also run trend analysis on our insight metadata so getting it mostly right up front is helpful.

I might be creating some Pb terminology confusion: When I say insight, I’m really referring to a whole Pb note. That note may contain multiple “insights”. In that case, the note would get multiple “type” tags.

Thanks again @scott.baldwin 👍 Great perspective.

I definitely have an opinion on how it should all work together. Before I implement this new org I wanted to make sure I could see past those opinions and provide them with the best structure.

As far as bugs -- I totally agree they should go right to engineering. The insights I’m referring to are really more about workflows that don’t “flow” or features that aren’t doing what the customer expects. Thanks for pointing that out -- I’ll be cautious about how I label that one. Maybe pain-point or missed-expectation would get the point across.

That’s exactly the kind of example I was looking for! Thanks again @scott.baldwin 🏆