Skip to main content

Hey there, fellow mapper of product features! 

 

Let's dive into the wonderful world of product mapper naming conventions without overthinking it. @link_black and I have your back! Here are some tips to keep things easy and straightforward:

 

To Start: Name Modules and Features based on how they are talked about and referred to with customers  in the product and documentation so even non-technical people understand what they are and what they mean. 

  • (e.g. Analytics section becomes “Analytics” module, Scheduling sections becomes “Scheduling” module, Running a report becomes “Run Report”, Adding a new contact becomes “Add Contact” etc.)

Then: Use Feature name suffixes to further indicate what the user really did in the application. 

  • Examples:
    • “Dashboard View” or “Dashboard PV” == loading the Dashboard page
    • “Run Report Button Click” or “Run Report BC” == clicking the Run Report Button
    • “Submit Job Custom Event” or “Submit Job Event” == custom event linked to a Feature
    • “Filter Dropdown Selected” == picked an option from a dropdown list
    • “Scheduling Navigation” or “Scheduling Nav” == picking a main menu item to get to the  Scheduling section/module

These names will flow over to PX Analytics, Engagement Audience rules and in the CS platform exactly as you have them.  As a bonus, in many places, you'll see the full module path all the way to the feature. It's like a breadcrumb trail through your app, making it super clear where the user was.

  • Example from CS: “Gainsight CS (Primary Tree) / R360 / R360 Timeline Section / R360 - Timeline Add activity

 

The key here is to be concise, descriptive and obvious. No need for secret codes here! 🔍 As a reminder, All names can be changed later if necessary as well. 

 

We would love to hear from you! What other tips do you have? Share in the comments 👇

 

Happy PX-ing!

This is timely!  We implemented PX early this year and have multiple products which were tagged/mapped by different product managers or devs.  Now that the data is flowing into Gainsight CS and Adoption Explorer, we see our work is cut out for us:  some Feature names are used in multiple places in one product, but in different contexts.  Some of the names are cryptic or vague.  So we have a ton of data, and the CS team has no idea what it means.  😅

We’ve had our first meeting with a product manager to talk about this and, thankfully, he was very receptive to a conversation about renaming features for clarity.  Once we know what we’re looking at, the next stop planned will be to work with product SMEs to help us filter the data down to focus on some more high-value metrics that will really speak to value.

Then just 17 more products to go!  If starting over, I would look for feature mapping to be a collaboration between success/support and product.

Really great point @andy_roy!  

This is both a blessing and a curse, using the breadcrumbs in the product require a lot of extra touches in the product - just to read the full bread crumb. It would be great if the breadcrumbs could be presented in reverse order when they are being used for configuration of the product or interacting with the mapper - in gainsightPX.

 

I spend too much time just trying to grab the stretcher to see all of the content.

 

As a bonus, in many places, you'll see the full module path all the way to the feature. It's like a breadcrumb trail through your app, making it super clear where the user was.

  • Example from CS: “Gainsight CS (Primary Tree) / R360 / R360 Timeline Section / R360 - Timeline Add activity

 

 

Reply


Terms & ConditionsCookie settings