Product expertise doesn’t appear overnight. The entire product development process is what creates “experts” around certain features and functionalities, and is the foundation for all of the documentation that precedes and follows their release.
Teams using Guru for product enablement recognize the importance of having a single source of truth for knowledge encompassing the entire product release lifecycle—from early development through ongoing support and maintenance. By giving every department one agreed-upon, reliable place to put expert-verified information, everyone involved in these cross-functional processes can do better work. Let’s walk through a recent feature release at Guru as an example of product enablement in action.
Throughout January, our newly formed Monetization pod worked on the first part of an upgrade to the billing experience in Guru. This project involved the usual product development team—product management, design, engineering, and product marketing—as well as several other stakeholders including finance, support, and sales operations. This was a technical update that required tight communication and coordination across all involved teams, as well as substantial prep work for enabling our customer-facing counterparts to speak confidently about these changes. The following three phases encapsulate the main ways in which we use Guru for product enablement around feature releases like this one.
Phase 1: Feature planning and development
Product enablement truly begins the minute a Product team’s project gets the green light. This could be for a minor functionality enhancement, a page redesign, or an entirely new feature. From the time project specs are drawn up by a Product Manager (PM) and shared with their engineers, designers, and other stakeholders, everyone needs access to reliable, up-to-date documentation from a variety of authors.
Our planning began in December, with our PMs identifying a few key places throughout our billing and checkout experiences that were in need of refreshing. From there, they spun up a project plan and began drafting up the early feature spec for the first project in the series. Once they were ready to share with the team, they scheduled a kickoff meeting to walk the team through the proposed changes, and discuss timelines. From this point on, it was critical that everyone involved in the project had access to all of the related documents, including the project specs, designs, related billing documentation, and more.
Since these documents change frequently, and may be added to often throughout the early stages of a project, it’s important to have a reliable source of truth that the team can come back to. To make sure everyone had a single place to share and access these resources, we created an Active Project Resources Card to share with the team. We put this within the Monetization Pod Board, where all of the appropriate stakeholders have author access.
Throughout the development process, our engineers didn’t have to worry about bookmarking design files or double-checking if the copy given to them last week was still up-to-date. Instead, they could refer back to the Active Project Resources Card as they worked, ensuring they were building off of the most up-to-date information. See how engineering teams uses Guru.
Phase 2: Release prep
We see feature releases as a team sport at Guru. As we near the end of development, we need to ensure that we’ve met all requirements, tested for potential customer pain points, and properly communicated the upcoming changes to our customer-facing teams. Since this is the phase where information is most likely to be changing rapidly, ensuring that all knowledge is verified by respective experts is of the utmost importance.
For our recent billing project, we allotted one week for the team and our stakeholders to conduct quality assurance (QA) and test out the new customer experience before going live. As this was a particularly technical project, there were several steps involved in getting environments set up and ready for testing, including enabling feature flags and working through a specific set of replica check-out steps. To ensure everyone had all of the information they needed to participate in testing, our engineering team lead spun up Card with step-by-step instructions for participating in QA. We sent this Card to our Pod and stakeholders via an announcement to make sure they had read it before they began testing.
While QA was in progress, it was also important to notify our customer-facing teams of the upcoming changes to prepare them for any questions prospects or customers might have. While these changes were largely usability and reliability-focused (vs. a larger interface change), some parts of the legacy billing experience were going to be altered with this project. To communicate these changes with plenty of time to review and ask questions, we refreshed our billing feature breakdown Card.
You’ll notice that this is the first time in the process that we’re using the word refresh instead of create, and that’s intentional. We use feature breakdown Cards as the living source of truth on features for our customer-facing teams, which means that one exists for all of our live features at all times.
When we update and improve upon an existing feature, we update and improve upon the feature breakdown Card accordingly. This prevents the age-old problem of a sales rep being uncertain about if they’re looking at outdated documentation about a feature and Slacking engineers in a panic while on a call. They can be certain that the Card about the billing page that they relied on last year is just as accurate this year, as verified by the team working on the enhancements.
Phase 3: Release and Beyond
The most obvious application of product enablement may very well be around the launch of the new or enhanced feature. From overviews like the feature breakdown Card above to highly technical, specific troubleshooting Q&As, a lot goes into making sure customer-facing teams are equipped with all they need to sell and support each release. And as features are iterated and improved upon over time, it remains critical that all documentation is kept up to date and reflective of the current state of the product.
It’s no surprise that billing pages are incredibly complex and nuanced, meaning there are no shortage of potential questions that customers may have as they complete a checkout process. While our billing experience isn’t something that our sales team will likely have to speak to in too much detail, it is an area that our support team often helps customers navigate. To prepare for this launch and additional upcoming improvements to our checkout experience, our engineering team lead worked with our customer support champion to curate a list of technical FAQs, which is added to as new questions arise. This gives not only the support team, but anyone answering customer questions about billing a consistent place to check first before reaching out to our team (and then, adding to the technical FAQ Card!).
In addition to keeping the FAQ Card up to date as iterations progress, the feature breakdown Card is kept evergreen too. In addition to noting the official launch date and important talking points about the new billing experience, we’ll link to other related Cards and resources, just like this blog post. By creating a one-stop-shop to access all available information about a feature, we give our customer-facing teams confidence to speak to customers and prospects with a fully-informed perspective.
To close this loop, we can’t forget about how customer and market feedback play an important role in the product development cycle. As our teams bring new and enhanced features to our existing customers and our market, we gather valuable insight into what helps them do better work, and what they hope to see us focus on next. Documenting and sharing this information with our product team is an important part of our iterative development process, and helps us deliver the most value possible to our customers. And documentation for how to share different modes of feedback (call recordings, emails, etc.) is kept in—you guessed it—Guru.
Product expertise doesn’t appear overnight. The entire product development process is what creates “experts” around certain features and functionalities, and is the foundation for all of the documentation that precedes and follows their release.
Teams using Guru for product enablement recognize the importance of having a single source of truth for knowledge encompassing the entire product release lifecycle—from early development through ongoing support and maintenance. By giving every department one agreed-upon, reliable place to put expert-verified information, everyone involved in these cross-functional processes can do better work. Let’s walk through a recent feature release at Guru as an example of product enablement in action.
Throughout January, our newly formed Monetization pod worked on the first part of an upgrade to the billing experience in Guru. This project involved the usual product development team—product management, design, engineering, and product marketing—as well as several other stakeholders including finance, support, and sales operations. This was a technical update that required tight communication and coordination across all involved teams, as well as substantial prep work for enabling our customer-facing counterparts to speak confidently about these changes. The following three phases encapsulate the main ways in which we use Guru for product enablement around feature releases like this one.
Phase 1: Feature planning and development
Product enablement truly begins the minute a Product team’s project gets the green light. This could be for a minor functionality enhancement, a page redesign, or an entirely new feature. From the time project specs are drawn up by a Product Manager (PM) and shared with their engineers, designers, and other stakeholders, everyone needs access to reliable, up-to-date documentation from a variety of authors.
Our planning began in December, with our PMs identifying a few key places throughout our billing and checkout experiences that were in need of refreshing. From there, they spun up a project plan and began drafting up the early feature spec for the first project in the series. Once they were ready to share with the team, they scheduled a kickoff meeting to walk the team through the proposed changes, and discuss timelines. From this point on, it was critical that everyone involved in the project had access to all of the related documents, including the project specs, designs, related billing documentation, and more.
Since these documents change frequently, and may be added to often throughout the early stages of a project, it’s important to have a reliable source of truth that the team can come back to. To make sure everyone had a single place to share and access these resources, we created an Active Project Resources Card to share with the team. We put this within the Monetization Pod Board, where all of the appropriate stakeholders have author access.
Throughout the development process, our engineers didn’t have to worry about bookmarking design files or double-checking if the copy given to them last week was still up-to-date. Instead, they could refer back to the Active Project Resources Card as they worked, ensuring they were building off of the most up-to-date information. See how engineering teams uses Guru.
Phase 2: Release prep
We see feature releases as a team sport at Guru. As we near the end of development, we need to ensure that we’ve met all requirements, tested for potential customer pain points, and properly communicated the upcoming changes to our customer-facing teams. Since this is the phase where information is most likely to be changing rapidly, ensuring that all knowledge is verified by respective experts is of the utmost importance.
For our recent billing project, we allotted one week for the team and our stakeholders to conduct quality assurance (QA) and test out the new customer experience before going live. As this was a particularly technical project, there were several steps involved in getting environments set up and ready for testing, including enabling feature flags and working through a specific set of replica check-out steps. To ensure everyone had all of the information they needed to participate in testing, our engineering team lead spun up Card with step-by-step instructions for participating in QA. We sent this Card to our Pod and stakeholders via an announcement to make sure they had read it before they began testing.
While QA was in progress, it was also important to notify our customer-facing teams of the upcoming changes to prepare them for any questions prospects or customers might have. While these changes were largely usability and reliability-focused (vs. a larger interface change), some parts of the legacy billing experience were going to be altered with this project. To communicate these changes with plenty of time to review and ask questions, we refreshed our billing feature breakdown Card.
You’ll notice that this is the first time in the process that we’re using the word refresh instead of create, and that’s intentional. We use feature breakdown Cards as the living source of truth on features for our customer-facing teams, which means that one exists for all of our live features at all times.
When we update and improve upon an existing feature, we update and improve upon the feature breakdown Card accordingly. This prevents the age-old problem of a sales rep being uncertain about if they’re looking at outdated documentation about a feature and Slacking engineers in a panic while on a call. They can be certain that the Card about the billing page that they relied on last year is just as accurate this year, as verified by the team working on the enhancements.
Phase 3: Release and Beyond
The most obvious application of product enablement may very well be around the launch of the new or enhanced feature. From overviews like the feature breakdown Card above to highly technical, specific troubleshooting Q&As, a lot goes into making sure customer-facing teams are equipped with all they need to sell and support each release. And as features are iterated and improved upon over time, it remains critical that all documentation is kept up to date and reflective of the current state of the product.
It’s no surprise that billing pages are incredibly complex and nuanced, meaning there are no shortage of potential questions that customers may have as they complete a checkout process. While our billing experience isn’t something that our sales team will likely have to speak to in too much detail, it is an area that our support team often helps customers navigate. To prepare for this launch and additional upcoming improvements to our checkout experience, our engineering team lead worked with our customer support champion to curate a list of technical FAQs, which is added to as new questions arise. This gives not only the support team, but anyone answering customer questions about billing a consistent place to check first before reaching out to our team (and then, adding to the technical FAQ Card!).
In addition to keeping the FAQ Card up to date as iterations progress, the feature breakdown Card is kept evergreen too. In addition to noting the official launch date and important talking points about the new billing experience, we’ll link to other related Cards and resources, just like this blog post. By creating a one-stop-shop to access all available information about a feature, we give our customer-facing teams confidence to speak to customers and prospects with a fully-informed perspective.
To close this loop, we can’t forget about how customer and market feedback play an important role in the product development cycle. As our teams bring new and enhanced features to our existing customers and our market, we gather valuable insight into what helps them do better work, and what they hope to see us focus on next. Documenting and sharing this information with our product team is an important part of our iterative development process, and helps us deliver the most value possible to our customers. And documentation for how to share different modes of feedback (call recordings, emails, etc.) is kept in—you guessed it—Guru.
Experience the power of the Guru platform firsthand – take our interactive product tour
.webp)
