PROBLEM

Product, Sales, and Marketing were operating on different timelines. Product launched features and products based on internal readiness, not market reality. Sometimes we released things during the busiest times for coaches. Other times, we launched right after the holidays, when parents had just spent their discretionary budget. We also weren’t considering the basketball season itself, pre-season, in-season, playoffs, post-season, and offseason, even though product usage varies heavily across those phases.

On top of that, we weren’t communicating well as an Experience Team. Product would release and hope Sales and Marketing could sell it, but often they didn’t even know how the feature worked, let alone why it existed. This created a gap between how features were designed and how they were positioned in the market.

If we didn’t fix this, we’d keep acting like a feature factory, shipping things without a strategy for when or how they should land, and wasting time on launches that never really had a chance to stick.

DISCOVER

This wasn’t a single-solution problem. We needed a system that helped Product, Sales, and Marketing plan together.

First, I needed to understand what our different audiences were dealing with throughout the year. I mapped out key personas, coaches, parents, players, and trainers, and overlaid their needs and behaviors across the basketball calendar. I also layered in the broader seasonality of the sport itself.

This revealed clear windows of opportunity:

• Pre-season was the best time to reach coaches

• Offseason and holidays mattered most for parents and players

• Trainers were most engaged from the offseason into the pre-season

We also needed shared artifacts. A single place to see launch timelines, features, benefits, and visuals, so teams weren’t operating off of partial context or outdated information.

What surprised me most was realizing that just because something felt important and urgent internally didn’t mean the audience was paying attention. Coaches and parents have full lives and day jobs. Timing and relevance mattered just as much as the quality of what we shipped.

DEFINE

“Going to market” is a big, fuzzy problem, and the hardest part was getting everyone to agree we could be better and commit to working on it together instead of staying in silos.

I chose to anchor the system around a shared GTM calendar because it could serve as a foundation for:

• Product roadmap planning

• Marketing campaigns and content

• Sales goals and offers

• Launch timing and sequencing

We also created lightweight templates and recurring meetings to test how we could improve communication and alignment without overloading the teams with process. We intentionally avoided rigid rules at first. The goal was to learn what actually helped and do more of that.

SOLUTION

We built a go-to-market system centered around three things:

GTM Calendar
This mapped the basketball season, key personas, and business priorities into a shared planning tool. It helped us decide not just what to launch, but when it would matter most.

Launch Brief Template
Product filled out a simple brief for each release that included milestones, what we were building, why it mattered, who it was for, features and benefits, and visuals. This gave the entire company a clear window into what was coming and helped Marketing and Sales prepare much earlier and more thoroughly.

Bi-Weekly GTM Sync
We created a recurring meeting where Product, Sales, and Marketing shared updates, timelines, metrics, visuals, and customer feedback. This became an anchor that kept everyone aligned and moving together.

We also got Product more involved in demo videos and internal enablement. Since we knew the features best, it made sense for us to help explain them. I supplemented this with surveys to understand what parents and coaches struggled with throughout the year, so releases and content stayed relevant to real needs.

The main tradeoff was time. More meetings, more artifacts, and more coordination. But that investment paid off in faster launches, fewer surprises, and much better alignment across teams.

RESULTS

The GTM calendar and launch brief template were used across 15+ releases

• Both tools evolved over time and became core operating artifacts

• Sharing milestones and dependencies actually helped us launch faster, not slower

• Product, Sales, and Marketing stayed aligned on what was launching, when, and why

For the business, this meant we stopped throwing features and campaigns into the void and started being deliberate about timing, messaging, and audience. For users, it meant they heard about features and content when it actually mattered to them, not just when we happened to finish building something.

MY ROLE

• I owned this work end-to-end, including:

  • Researching the basketball season and persona needs

  • Building the GTM calendar from scratch

  • Creating and maintaining the launch brief template

  • Representing Product in cross-functional planning

  • Conducting surveys to inform seasonal content and launches

  • Filming customer-facing and internal demo content

  I acted as the connective tissue between Product, Sales, and Marketing, translating user needs and product intent into clear plans, timelines, and narratives that each team could actually use.

WHY I’M SHOWING THIS WORK

This case study shows how I build systems that help teams operate better together, not just ship individual features. I spot breakdowns in how organizations plan and communicate, then design lightweight processes that create clarity, alignment, and momentum.

It highlights that I:

• Think in systems, not just projects

• Bridge product, sales, and marketing effectively

• Use user and market context to drive timing and strategy

• Build operating rhythms and artifacts that scale

• Turn ambiguity and misalignment into shared direction

Details have been intentionally generalized or modified to respect confidentiality and intellectual property agreements. This case study focuses on my role, process, and decision-making rather than proprietary implementation details.