Product Management
Product Management Philosophy
Real-world Case Study: Re-architecting Licensing & Subscriptions for Scale
Phase 1: Discovery & Definition
TL;DR
Led the discovery and requirements definition for a major restructuring of licensing and subscriptions, separating a single bundled offering into multiple paid service packs. Defined feature distribution, user experiences, edge cases, and internal tooling across district, teacher, and student workflows.
My main priority was providing clarity, scalability, and revenue sustainability documentation ahead of engineering handoff.
Context
As the platform expanded, a growing number of high-value features were being delivered under a single subscription offering, or none at all. While this approach reduced friction for users early on, it began to create challenges as the business scaled.
Leadership identified the need to introduce multiple paid service tiers to separate features into distinct service packs, in order to better reflect the value of the product, and support sustainable revenue and future growth. I was brought in to lead the definition and plan the work required to make this shift possible across the platform.
This initiative is currently in progress and focuses on discovery, requirements definition, and cross-functional alignment.
The Problem
High-value features were freely available, limiting revenue growth. If left unaddressed, this would continue to impact revenue
Goals
Business Goals:
Align pricing with the value of the features being delivered
Increase overall revenue through clearly defined paid service offerings
Learn which feature sets users value most to guide future investment
User Goals:
Give districts and teachers clearer choice over which feature sets they use
Improve transparency around access, upgrades, downgrades, and licensing
Create predictable, understandable paid feature experiences
Success Metrics
Key indicators we established:
Increase adoption of the newly separated service offerings
Reduce support tickets related to subscriptions, billing, and feature access
Decrease misuse or over-allocation of licenses (e.g. districts accessing more licenses than purchased)
Improve user sentiment as teachers and districts gained more control over which features they used
Approach & Execution
My first priority was creating a structure to follow before diving into detailed solutions. I began by drafting up a Feature Distribution table, an organizational view of every product feature, mapped to each of it's intended service packs. This would later become the staple document for others to look to for where features fit in the upcoming work.
From there, I started to increase granularity:
"Happy path" flows for districts and individual users
Detailed use case experiences for each service combination
Edge cases, downgrade scenarios, and upsell opportunities
I created multiple other documents to support clarity and execution.
Four PRDs including:
One PRD for an internal service management tool
Three PRDs for outlining feature separation for each service pack
Sample PRD template I've worked within
While working on these documents, I also created multiple UI mockups and captured screenshots, explicitly showcasing:
Teacher and Student experiences, for all services, when they are both enabled and disabled
Teacher and Student experiences for mixed service combinations
The flow and experience of the internal management tool
Because this work impacted nearly every part of the organization, alignment was treated as a continuous process rather than a single handoff. While working, I held regular syncs and discovery meetings with marketing, operations, and engineering. I gathered feedback, insight, and suggestions to validate assumptions, formalize requirements, and ensure alignment.
My main goal was to keep all the key internal stakeholders in the conversation, and a part of the definition process. While not all requirements were clearly defined, and still ambiguous after meetings, I called out inconsistencies, and commented my questions, thoughts, and ideas directly within the PRDs. This ensured that questions and concerns remained within the contexts they arose in.
Reflections
This initiative highlighted several strengths in my product management approach:
Strong systems thinking, particularly in mapping feature interdependencies
High attention to detail in documenting enabled and disabled states
Clear, visual communication that supported engineering confidence
Proactive, inclusive stakeholder communication throughout early phases
I gained valuable feedback from engineering that reinforced the value of this approach, they said that even seemingly “obvious” screenshots and documentation helped create shared clarity around the intended end state.
Above all, I view PRDs as tools built for the people who need to use them. Understanding what different teams need in order to do their work effectively is central to how I approach product documentation.
