Bringing a decade of player creations forward
Millions of people have spent ten years building things in The Sims 4: households, homes, whole neighborhoods. When a next-generation platform initiative began, someone had to answer a question nobody had answered before: how does any of that come with them?
There were three real options and no obvious winner.
The gallery. Already built, already familiar to players. But it uploads one item at a time, so someone with a thousand creations would spend hours clicking. And it's public by design, which means asking people to publish private work just to keep it.
Device-local detection. Read the player's existing files directly. No uploads, no privacy tradeoff, almost no interaction required. But it only works when both products live on the same machine, and plenty of players move between console and PC, or have drives too small to hold both.
Cloud upload. Guarantees the data is ready on day one, at real storage cost for data that's mostly irrelevant — every object state, every photo, every Sim the player never touched.
Different parts of the organization had settled into different camps before the question reached one room. I ran the options analysis, wrote the tradeoffs honestly rather than advocating for a preferred answer, and brought the stakeholders together to decide against the same set of facts.
I also filed a player research request. I'd rather make a call like this on data than on the loudest opinion in the room.
What the work required: holding a genuinely ambiguous problem open long enough to actually understand it, translating between technical constraint and player experience, and getting people who disagreed to a decision that held.
What stands in for something that doesn't exist yet - Fallback Mapping
When a player brings a house into a world where half the furniture doesn't exist, something has to stand in for what's missing.
The old approach was a grey box. A carefully built kitchen would arrive as a row of featureless placeholders. A Sim wearing clothes from a pack that didn't carry forward would show up with nothing on. It worked, technically. It was a terrible first impression.
Building a better answer meant mapping every object in a catalog of 11,000+ items to a sensible substitute, across 30+ distinct resource types, each with its own loading and serialization behavior.
Three things had to be true:
The initial mapping had to be automated. No team has the capacity to hand-author tens of thousands of fields, and nobody should have to.
Designers had to be able to override it. An automated guess is a starting point, not an answer. When a specific object has a good stand-in, someone should be able to say so.
It had to stay current. New content ships continuously, so the pipeline needed to ingest updates rather than freeze at a point in time.
I produced this rather than engineered it. In practice that meant understanding the system well enough to scope it honestly, sequence it against its dependencies, and know when an estimate was real. I was handed this work because I'm comfortable in problems most producers route around.
Targets: 75–95% of the back catalog available at launch, under 5% entitlement error.
Ten years of purchases, and what players get to keep
Players who spent a decade buying content expect it to mean something in whatever comes next. Not all of it can move. What does move has to be defined, priced, bundled, and delivered. I stood this program up from nothing while figuring out how to convert the 3D items that are staying get upressed to modern expectation.
It has three parts, and none of them can be finished without the other two.
What the content actually is. Which items can exist in a new product depends on which underlying systems carry forward. If the system that makes an animal work doesn't come along, nothing built on top of it can either. That meant auditing an 11,000+ item catalog and coordinating with the team defining carry-forward scope before I could finish scoping my own.
How entitlement gets delivered. Players who already own something should receive it without buying it again. That's an architecture problem — tracking ownership across two products and two backend systems, and getting it right, because being wrong means charging someone twice for something they already paid for.
How a player finds and buys it. New players who never owned the old content need to discover it, understand its value, and purchase it, alongside a storefront already full of new content. A pricing question and a discoverability question at the same time.
I wrote the PRD that got leadership alignment across all three and unblocked the downstream work.
Success criteria I set: 75–95% of eligible content available at launch, under 5% entitlement error, and enough differentiation from new content that the product doesn't read as a re-release.
Cross-team operating model - Every team was delivering. Work was still getting stuck.
The failures weren't happening inside groups. They were happening in the space between them - a decision made in one pod that never reached the pod that needed it, a dependency two teams discovered only after it was already a problem.
I could have escalated it as a complaint. Instead I went and asked.
I ran structured interviews with leads across five functions, asking each of them the same questions: where does information reach you late, what do you find out too far downstream, what are you assuming someone else is handling. Then I synthesized the answers into a single assessment, the patterns, not the anecdotes, and brought it to senior leadership with specific recommendations.
That work is now reflected in how the organization is being structured.
Afterward I built what was missing: coordination playbooks and tracking structures that other teams adopted. The design constraint was that they had to be lightweight enough to actually get followed. Process nobody uses is worse than no process, because it creates the appearance of coverage.
None of this came with authority. It came from asking good questions and being useful with the answers. In many cases, different teams speak in different languages: Computer Engineering with C++ versus a user experience designer working through ideation in Figjam - the key is understanding what each is saying and being able to translate and work out a plan.