The blueprint the organization reshaped around.

Launch was a solved problem. The day after launch was not.

I joined weeks after Opendoor’s December 2020 listing as a senior product designer on the operations platform. The company was in 21 markets and had committed publicly to doubling that footprint within the year. It got there: 44 markets by September 2021, 51 by mid 2022, with annual revenue more than tripling, $2.6B in 2020 to $8.0B in 2021.

Six markets could open in a single day. On the Q2 2021 earnings call, Opendoor’s President described “shifting resources away from incremental market launches” toward scaling operations in the markets that already existed. Operations capacity, not launch capability, had become the binding constraint. I was hired into that gap.

Inside, the seams showed. The operating layer everyone stood on was a patchwork of tools that had grown with the company, and faster than it. Coordination ran through chat because no system owned the handoff.

Thirty-five sessions with the people the org chart called support.

The same question sat under every session. What does an operator actually do, and what does the tooling assume they do. The two answers rarely matched.

What am I supposed to do next?

A field operator, mid-workflow. Research session, Q1 2022

Twelve capabilities, and one rule about what it costs to change them.

The end state drew Sales and Support as a hub and spoke system. Three capabilities formed the hub: customer management, transaction management, and inventory management. Nine spokes sat around them, from sales engagement to business intelligence.

One rule came attached. Changing a hub component was a Type 1 decision, expensive and nearly irreversible. Changing a spoke was cheaper, and expected. That one distinction told every later team where to be careful and where to move fast.

The argument for the blueprint was speed. Without a system to work backward from, every team would keep solving its own corner, and the seams would keep multiplying. That was already happening.

The blueprint’s first real job was talking the company out of building something.

The first component to hit the gate was customer ticket management. Support escalations crossed 2,000 a week, all of it moving through chat, none of it tracked anywhere central. The blueprint made the decision legible. Ticket management sat in the spokes, commodity territory where mature products already existed. So I argued for buying. Integrate a commercial ticketing system with the existing telephony stack rather than build one in house.

Prototype in early September. Beta by the end of Q3, first version early Q4. Three categories were explicitly out of scope for the purchased tool, transaction task management first among them. The differentiated work stayed on the platform roadmap, where the blueprint said to build.

The blueprint turned into an address system.

Through late 2021 and 2022 the work became substrate. An engineering proposal to consolidate operator identity and authorization, the layer every tool sits on, went to review across five platform teams. In January and February 2022 I co-authored the operator authorization research on that same layer. Seven sessions with operations managers and leads.

The last thing I worked on was the generalized UI framework for internal tooling. Its first stated assumption was that the framework depended on the authorization work underneath it. The blueprint’s layers had become explicit dependencies.

By the time I left in August 2022, requirements documents routed work to platform teams by name: transaction, tooling, buyer, seller. The organization had reshaped around the platform view the blueprint drew. That was the intent.

The foundation was still open when I left. The authorization layer everything else sat on was in discovery. My own last research on it described the work as figuring out what operators needed. The engineering design doc for that layer had a blank reviewer sign-off column in the last copy I kept. I took the ticketing system through V1. Whether it held after I left, I do not know.

Scope and stakes, not outcome claims. Market and revenue context is the company’s public record.