Case Study: Enterprise eCommerce marketplace
Competing priorities across engineering, platform, and business strategy with no clear path to resolution.
Context
Company stage
Large, established enterprise with a newer, still-establishing product initiative within it.
Industry
eCommerce
Product type
Developer platform & API ecosystem
What was at stake
I was brought into a newer, still-establishing product initiative with unclear strategy, competing priorities, and compounding technical constraints.
A live security compliance issue demanded immediate action, but resolving it meant pausing a strategic roadmap that had taken significant effort to build. Getting the sequencing wrong in either direction had real consequences: ignore compliance and the platform stays exposed with leadership attention sure to follow; pause the roadmap and a still-establishing initiative loses the momentum it can't afford to lose.
Stakeholders were misaligned with no shared framework for resolution. Each function had its own agenda and its own version of urgency. The risk wasn't just picking the wrong option; it was that no one was positioned to make the call at all.
The Problem
Technical: Multiple CMS alternatives evaluated, each with its own shortcomings across format compatibility, integration complexity, and licensing.
Organizational: Cross-functional silos, high friction, no documentation governance, and manual publishing workflows throughout.
Resource: A small engineering team spread thin across multiple product areas. Leadership investment in this pillar was limited.
Time: No hard deadline, but an active, worsening threat with compounding exposure the longer it went unaddressed.
The Constraints
How I evaluated options
The migrate-vs-build framing assumed two mutually exclusive workstreams, and that assumption didn't hold. The migration required touching all existing content anyway. The question was whether to do that intentionally or not.
Option A treated migration as overhead. Option C treated it as leverage. The difference was execution complexity, which I addressed by building the content team and establishing governance alongside the product work.
My Verdict
Option C.
Each migration component became a content improvement sprint. Nothing was simply ported. Everything was restructured and elevated.
Decision & Rationale
Why I chose this
The migration was unavoidable. Option C meant emerging from it with a meaningfully better product, not just a compliant one.
What I intentionally didn't do
Cede the migration to engineering as a purely technical problem, which would have meant losing influence over the outcome on the other side.
Risks I accepted
A longer timeline than a straight lift-and-shift. The operational complexity of building a content team while executing both workstreams simultaneously.
Outcome
What changed
Compliance resolved. Content quality, structure, and publishing workflows all improved. A functional content team with governance in place where none existed before.
What moved forward
A refreshed product experience shipped as a direct output of the migration. The strategic roadmap advanced from a stronger foundation than a migrate-only approach would have left.
What I'd do differently
Challenge the default framing earlier — before other stakeholders had already committed to a position. Alignment is harder to achieve once narratives have hardened.
Applicability
If I were dropped into this problem today as a consultant, the first thing I'd do is challenge the framing, not the options. The migrate-vs-build binary is the kind of assumption that hardens into fact when no one questions it early enough. I'd map the actual workstream overlap, identify where the constraint creates leverage rather than just cost, and use that to reframe the decision before anyone commits to a path.
The second move would be to assess what's missing structurally - team, process, governance, because the right product decision still fails without the conditions to execute it. Building those conditions isn't overhead; it's part of the strategy.
The broader pattern this represents, a compliance or technical forcing function that appears to block strategic work, comes up often in product organizations. The instinct is usually to sequence. The better question is almost always: where do these workstreams actually overlap, and how do translate them into opportunities?