What tagging structure is helping you manage insights?

  • 21 November 2021
  • 10 replies
  • 76 views

Userlevel 5
Badge +2

Hello Product People 👋

We’ve been scaling our Product and GTM teams, now we’d love to get smarter in handling insights.

I’ve watched the clinic “Managing Insights - At Scale” as well as the (excellent) session “How Productboard uses Productboard” from last month’s customer event. Both point to the importance of a decent & documented tagging structure to create shared understanding and onboard new contributors.

I’d appreciate to hear from other teams how you’ve approached tagging insights. What worked? What failed? Interested in both the actual structuring approach as well as the governance around it (documentation, change management, training etc).

If anyone from Productboard is reading along: in the recorded clinic, @Jake Sawyer mentions a “Maker & Contributor Management Toolkit”. Is that available anywhere?

Thank you!


10 replies

Userlevel 5
Badge +6

@pstrouven_pxc Given my company owns multiple products which are divided into 2 core pillars we use essentially 2 tags per insight. Pillar + Product. As we begin to utilise Productboard for more specific items I believe we will roll out more tags for example we would want specific insights from a new feature then the tag would be that specific features name. There is a fine balance between to much tags and not enough so that is probably the hardest part for us at the moment

Userlevel 7
Badge +12

@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:

 

Tag type

Examples

Descriptive

CSS, ajax, Minnesota, drama, gardening, zen, microfinance, music, networks, sushi

Resource

Blog, book, video, photo

Ownership/source

NYTimes, author name 

Opinion

Cool, funny, beautiful, defective

Self-reference

Mine, me, mystuff

Task organizing

read, todo, work

Play and performance

Squaredcircle, seenlive, poetry

 

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.
Userlevel 2
Badge

Hey @pstrouven_pxc!

That toolkit certainly is available - you can access it right here. It’s great for helping set up the documentation you’ll use to implement the other suggestions here.

Userlevel 4
Badge +1

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?

Userlevel 7
Badge +12

@plainclothes I’ve used type in the past, and shared some examples in this thread that might help (see ‘content type’) as well as the table where I outlined different tagging approaches you can consider. Overall tagging is very flexible, but should work for your org’s needs.

Userlevel 4
Badge +1

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.

Userlevel 7
Badge +12

Yeah, that can all work and work together.

I’d generally avoid bugs coming in as notes — those should really go directly to your engineering teams to triage and action.

In general, tagging allows you to filter/find content and is a great way to get some of those details so go with what works for your team and org. Also keep it structured yet flexible so that it can adapt over time (you can always merge and remove tags as well).

BTW, we already do lots in-product to help you identify insights trends and patterns across your feedback (plan dependent).

Let me know if you need something more.

Userlevel 4
Badge +1

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.

Userlevel 7
Badge +12

Pain points is a good one. A few others we have in this support article include things like ❤️ love, 🏎 performance, as well as other factors like churn and loss.

Userlevel 4
Badge +1

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

Reply