From Content Bottleneck to Product Platform

Context

At Oracle Cloud Infrastructure, a global sales organization of nearly 20,000 relied on internal product documentation, training materials, and competitive intelligence to position a rapidly evolving cloud platform against AWS and other competitors. But the internal system used to distribute this content had become a major bottleneck.

The existing platform was built on Oracle WebCenter, an enterprise content management system. In practice, it behaved like a static file directory. The interface resembled a database table with document IDs, titles, dates, and authors rather than a product knowledge system. Content lived in nested folders with no structured navigation, no rich media support, and no way for product teams to organize information around the services they were building.

A representative Oracle WebCenter interface, showing the document-table pattern typical of the legacy system.

Publishing required a centralized gatekeeper. Every contributor had to be individually provisioned through an archaic access management process. In practice, most product managers couldn't publish at all. Instead, they emailed files to a single administrator who had the access and permissions to upload content into the system. That administrator managed formatting, file placement, and access control manually.

The result was predictable. Updates moved slowly. Content went stale. And the system designed to help sales teams sell was actively slowing them down.

The Problem

The platform suffered from three structural constraints.

First, publishing velocity was bottlenecked by a single point of control. Product managers generating the content couldn't publish it themselves. Every update flowed through one administrator, creating delays and discouraging iteration.

Second, the system supported only static file uploads. Rich content like training videos, interactive demos, competitive comparisons, and structured product messaging couldn't be incorporated. Sales teams were limited to downloading PDFs and slide decks.

Third, the experience was organized around a file repository rather than a product narrative. Sales reps had to navigate folder hierarchies and search by document ID rather than access contextualized product information designed for real customer conversations.

For an organization trying to compete with AWS on a rapidly evolving platform, this structure created friction at every step.

Building the Case

Rather than treat this as a documentation problem, I framed it as a systems design problem. Oracle had no shortage of product managers, marketers, and engineers generating information about the platform. The constraint wasn't content production. It was publishing velocity.

I built support for a redesign by aligning stakeholders around three goals: remove the dependency on external contractors and centralized administrators for template updates and page additions, improve the user experience to support rich content alongside the existing asset repository, and simplify content management to scale the number of active contributors.

With sponsorship secured, I engaged a cross-functional team spanning engineering, design, and the existing content operations team to scope and deliver the solution.

Designing the System

The goal was not simply to build a better content repository, but to remove the structural bottleneck that prevented product knowledge from reaching the sales organization at speed.

The redesigned platform homepage.

I defined the product requirements and led the design of a new content management platform that allowed product teams to publish and maintain their own pages directly. The core of the system was a WYSIWYG publishing interface. Instead of emailing files to an administrator, product managers could create and update content inside the platform themselves.

The site structure was organized around the components of the Oracle Cloud Infrastructure stack rather than file directories. Navigation reflected how the sales team actually thought about the product portfolio: by service area, by use case, by competitive positioning.

The platform supported rich media including video training, diagrams, and structured messaging, allowing product teams to create field-ready content rather than simply upload static files.

We maintained editorial control of the homepage and featured content areas, allowing leadership to highlight strategic priorities while still enabling distributed ownership across teams. This balanced governance with speed.

I led the design review and approval process, owned MVP feature prioritization, planned the content migration from the legacy site, and delivered training to content stakeholders to transition day-to-day management.

The Flywheel

Removing the publishing bottleneck didn't just improve speed. It created a compounding loop.

The easier it became to publish, the more teams contributed content. The more content available, the more useful the platform became to sales. The more useful it became, the more teams wanted to contribute. Each cycle raised the quality and coverage of the platform without requiring top-down effort.

Content publishing flywheel

To make this loop visible, we instrumented the platform with analytics that tracked views, downloads, and engagement at the content level with human-readable names rather than document IDs. For the first time, content stakeholders could see which materials were actually being used by the field and which were being ignored. That feedback signal closed the loop: contributors could see what was working and invest accordingly.

Impact

In the first comparable month after launch, the new platform showed a 12% increase in visits and a 56% increase in downloads compared to the legacy system. Over time, overall engagement with the platform grew by more than 50%, as the site scaled to serve upwards of 10,000 visits, 30,000 to 40,000 page views, and 5,000 downloads per month.

The number of contributors publishing content increased by roughly 25 times, dramatically expanding the volume and freshness of product information available to the field. Content that previously took days to publish could now go live in minutes.

Perhaps the clearest signal of success came from inside Oracle. Teams outside Cloud Infrastructure began asking to adopt the platform for their own product organizations, turning what began as a sales enablement tool into a reusable internal product.

What I Learned

Two lessons from this work continue to shape how I think about product systems.

First, many platform problems are organizational design problems in disguise. When knowledge moves slowly through a company, it's often because the system concentrates control rather than distributing it. The technology may work fine. The workflow is what's broken.

Second, the highest-leverage product investment isn't always a feature. In this case, it was changing who had permission to publish. Removing a single bottleneck unlocked more value than adding new functionality ever could.