🏴☠️ ⚡️ Issue #20 - Product / Feature Release Playbook (OKR Teardown)
This newsletter is dedicated to Acquiring and Operating Micro SaaS firms. Join us every Saturday morning for acquisition case studies, operational tactics, growth frameworks, and more!
TABLE OF CONTENTS:
Part 1 — 🎯 DEAL TEARDOWN - Seafood Supply Chain SaaS Doing $750k ARR
Part 2 — ⚙️ OPERATING CONCEPT - Buyer / Acquirer Profiles in Micro SaaS
Part 3 — 🛠️ OKR TEARDOWN - Product / Feature Release Playbook
Part 4 — 🤔 MUSINGS - TBD
🙏 PRETTY PLEASE ROCK THE SURVEY BELOW 👇
(…so we can fine-tune our efforts accordingly)
🛠️ OKR TEARDOWN
As a point of departure, I’ve included the full OKR below to set the foundation for a teardown of our approach thus far…
OBJECTIVE: New global components earns 85%+ user approval
KEY RESULTS:
User Communication & Expectation Management - Execute multi-channel communication plan (email, social, in-app) to educate and orient users to the improvements
Testing and QA - Establish dedicated QA period prior to release and execute all relevant activities in staging environment to uncover and resolve issues
Rollback Plan - Establish a comprehensive rollback plan for each release allowing for immediate action in case of unforeseen issues
Monitoring & Issue Resolution - Establish a method for flagging support issues re new releases, and assigning high priority
Training and Support - Provide training materials and resources (canned email responses, support articles / how-to guides) the customer support team, ensuring they can address 90% of user queries without escalation
User Experience and Feedback Collection - Execute user survey (’How satisfied are you with XYZ product release? 1-5 Stars)
Process - Translate this OKR into repeatable product release checklist
USER COMMUNICATION & EXPECTATION MANAGEMENT
We execute release communication 2x weeks before the release is scheduled. Our primary communication tactic is a 1min screen recording (via Loom or Vidyard) to talk through the release as you navigate within the application, which we embed in email communication, an in-app pop up (via userguiding), and a post in our Facebook group. It’s important to note that we have indexed away from in-app guides (where a user clicks through prompts aligned with specific areas of the SaaS), as our users immediately exit these guides 85% of the time (per data from the preceding 2x quarters). Anecdotally, I find myself instinctually / subconsciously exiting in-app guides as well so we’re not very bullish on this tactic in general, but mind your specific context.
TESTING & QA
It goes without saying you should have a dedicated staging environment to ruthlessly test new features before shipping. Ideally, you can include someone from customer success as well to provide a vantage point beyond product / engineering. We budget 1.5wks to identify and resolve bugs with .5wks of slack, should a bug prove very challenging. We use Clickup to manage engineering and sprints, in general. Once a bug is identified, we add it as a subtask to the sprint item in Clickup to provide appropriate dialog and visibility into resolution.
ROLLBACK PLAN
Best case scenario is the feature release is isolated to a specific branch of the code base. This way, if shit totally hits the fan, you can roll back the entire release with a few clicks. No matter what, you need a rollback plan of some kind, which ideally covers the key surface area of new code and can be contained based on specific feature (to avoid a wholesale rollback). The most important thing is to have a plan so you aren’t caught flat footed with a tide of frustrated users at the door.
MONITORING & ISSUE RESOLUTION
We established a dedicated support ticket category for ‘Feature Release Issues’ (via Hubspot) so our team can quickly label a ticket accordingly. From there, the urgency is subjective, though we’ve established the sentiment that all feature release issues should generally be treated as urgent. Nothing sours an amazing release like issues out of the gate. Worst case scenario, you erode the user base’s confidence re your ability to execute product roadmap. In the long run, it’s worth treating everything release-related with a sense of urgency.
TRAINING & SUPPORT
There is a ton of variance in depth and breadth here, which maps to the level of substance the release entails. At a minimum, you should assume resistance to change and/or user disorientation so pre-built support articles / videos stepping through the new feature and showing the intended outcome are non-negotiable. This way, if a user is tripped up, you can link the article in a support article response and away you go.
If patterns start to emerge in support issues; again, create scalable content ASAP and avoid responding to the same issue over and over. You might also build email templates that include links to the newly created content to further reduce redundant activities.
USER EXPERIENCE & FEEDBACK COLLECTION
We index hard toward an in-app surveys here versus an email survey or poll in a facebook group, as in-app surveys have demonstrated the best response rates. A simple ‘how satisfied are you with XYZ release?’ with a star or numerical-based, one click response is the best starting point. Should the score come in lower than an average of 3.5 stars, you can follow up with a more pointed survey (via in-app, email, etc.) to investigate the root of the responses and proceed / react accordingly.