Our biggest crisis was a product strategy blessing in disguise

“We need another concert page by Friday.”

I’d been hearing this phrase weekly at eMusic Live, our commerce-focused livestreaming platform that was launched during the pandemic. Each time, I watched our lead frontend developer disappear into a four-hour black hole of custom HTML, CSS tweaks, and back-and-forth emails with artist teams.

As the Senior Product Manager leading the platform, I knew this wasn't sustainable. eMusic Live was built to help musicians monetize performances when live venues shut down—offering ticketed livestreams, merchandise sales, and direct fan engagement. Our original thought was to be a premium, white-glove service where every concert page was meticulously customized for each artist.

Every concert page was a snowflake. Unique backgrounds, links and information, custom sponsor logos, specific ticket configurations. It looked professional, but behind the curtain it was a relic of the initial MVP — a process held together by Excel spreadsheets and developer goodwill.

But as we moved beyond MVP and started to grow, the problem became clear. We only had one developer handling both feature work and concert pages. Every time an event needed a page, platform development stopped. I knew this wasn't scalable, but I couldn't get stakeholders to prioritize a solution.

Then one day our lead engineer announced he was leaving.

I remember the exact moment. We were in a Monday standup when he made the announcement. The room went quiet. My first thought wasn’t about hiring or handoffs — it was the sinking realization that if we don’t do something soon, our entire platform is going to grind to a halt.

Prior to that moment, I had been trying for a while to move the business in that direction to no avail. I tried framing it around costly dev time, around scalability… The stakeholders wouldn’t budge.

That’s when I knew it was now or never: we could find another developer to feed into this unsustainable process, or use this crisis to build something better.

The real problem hiding behind the obvious one

Most teams would have panicked about losing their frontend expert. Instead, I saw this as the perfect forcing function to solve a  problem I’d been thinking about for months.

Our “boutique” approach wasn’t just inefficient — it was strategically limiting. We were running a high-touch consulting service disguised as a product platform. Every new artist meant more manual work, more context-switching, more opportunities for things to break.

But the deeper issue was the business model. We treated all types of artists in the same way — with a high-touch white-glove experience. This was one of our differentiators, but it was not a sustainable one. If we wanted to grow this platform beyond a loss-leader, we had to find a different approach.

The conversation with our CEO was straightforward: “We can hire another developer and keep doing what we’re doing, or we can spend his remaining time building something that transforms how we operate.”

Building the bridge from chaos to scale

I had four weeks to turn our departing developer’s time into a foundation for a different kind of platform.

First, I cataloged exactly what went into each “custom” page. Every DB field, every component, every connection: artist name, event date, ticket types, streaming settings, sponsor placements.

The customization was real, but it was happening at the presentation layer, not the data layer.

Working with our designer and engineers, I mapped each piece of concert data to CMS tabs and input fields. But I wasn’t just solving the immediate problem. I built in user permissions, API integrations, and database architecture that could support future artist-facing tools and analytics.

The goal was twofold: make our marketing team self-sufficient for page creation while laying groundwork for a self-service tier of artists who would eventually build pages themselves.

Testing reality before building dreams

Before writing any code, I ran the proposed CMS flow past both internal stakeholders and external artist managers.

The feedback was immediate: “Why do I need to scroll through 12 fields when I only care about 3?” and “This dropdown doesn’t make sense — we call them ‘VIP packages,’ not ‘premium tickets.’”

Each piece of feedback shaped the final design. Field labels matched industry terminology. Optional sections collapsed by default. A preview function let users see results before publishing.

And when the first iteration was ready, I ran usability tests with real musicians and artist teams— gathering feedback about where it felt complicated, what felt out of place or was not intuitive. They were next year’s users I had to keep in mind.

Four weeks, one platform transformation

Our departing developer spent his final month building the CMS instead of manually creating concert pages. It was the best engineering investment we’d made all year.

The immediate wins were obvious:

• Page creation time dropped from 4+ hours to under 1 hour
• Engineering bottleneck eliminated
• Marketing team empowered to move independently

But the strategic foundation was transformative: We’d built infrastructure for a tiered business model — premium white-glove service for major acts, self-serve options for smaller artists. Instead of being locked into high-touch consulting, we could now scale both up and down market.

A few months later, when we hired our replacement developer, they didn’t spend their first week learning our page creation process. They spent it building new features, because the CMS could now handle the routine work.

Crisis as catalyst: The unexpected path to better products

Looking back, losing our lead developer was the best thing that happened to our platform strategy.

Without that forcing function, we would have kept hiring our way around inefficiency instead of building our way through it. The crisis gave me the urgency and political capital to push for a solution that stakeholders had been hesitant to prioritize.

The lesson isn’t that you should hope for crises. It’s that when they inevitably happen, the teams that thrive are the ones who use disruption as an opportunity to build the solutions they’ve been thinking about anyway.

Sometimes the path to building better products isn’t about avoiding problems — it’s about recognizing when problems are actually pointing toward the solutions you need most.