What Building WeWork’s First Software Taught Me

Before I helped WeWork expand across the US and Asia, my friends and I were hired to build its first software platform.

In April 2010, my partners (Eric, Yin, and Matt) and I were looking for an office for our digital agency, Simande, when we found a Craigslist listing for a new kind of office space in New York. We toured the second floor of WeWork Soho, the company’s first building, and were immediately sold. A month later, WeWork’s first two community managers, Lisa Skye and Nathan Seven Scott, helped us move in and began to introduce us to the other members. By that fall, we were hired and began working with Adam Neumann, Miguel McKelvey, and Kyle O’Keefe-Sally on what we called WeConnect, Adam and Miguel’s vision for WeWork’s first software platform.

Early concept wireframes from 2010 made by Kyle

In the beginning, WeConnect handled conference room reservations, member management, billing, and the work involved in running the buildings. I worked closely with Kyle on the business and product side. My partners at Simande focused on design and development.

The 2011 WeConnect conference room design. You can see Simande on the calendar at 154 Grand Street.

That work became the beginning of a much longer journey. I went on to co-found WeWork Labs, WeWork’s incubator program for early-stage startups, with Adam, Miguel, and my best friend Jesse. Soon after, I helped the early WeWork team open locations across the US. In 2015, along with two close friends, Evan and Ole, I went on to lead WeWork’s expansion across Asia and Australia before becoming General Manager of WeWork Korea.

The lessons and experience of building WeConnect have stayed with me, particularly as we build DNK.

Building around the work

Looking back through all of the old communications about WeConnect, I saw there were plenty of conversations about things that sound small: how a building manager books a room for a member, what happens when someone moves offices, how usage gets billed, and who can add a new building to the system.

Each of those details affected someone trying to do their job.

One exchange with Miguel in May of 2011 captures this well. We had described a process as something that could be handled manually. He asked whether that meant an engineer needed to do it, or whether he or a building manager could do it themselves.

That is a pretty important difference.

A process can look perfectly reasonable to the people building the software while still creating extra work for the people using it. If someone needs to find an engineer every time an ordinary situation comes up, the software has left part of the job unfinished.

We were also members of the community we were building for. The people using WeConnect were in the same buildings, and their questions and frustrations reached us directly. That made it difficult to lose sight of the practical consequences of a product decision.

I’m grateful I had that experience so early. It gave me an appreciation for the amount of thought that has to go into making something feel simple to use.

Getting the information right

One of the original reporting sketches lays out questions about occupancy, monthly income, office turnover, and conference room usage. There are views for individual buildings and for comparing buildings side by side.

WeConnect spec document outlining what the software needed to answer

The wireframes that followed turned those questions into screens and reports. Even then, getting the reports built was only part of the work.

In another email from May 2011, I asked for the building information we needed to finish the reporting pages. We were still gathering office and move-in data, keycard information, and building square footage. Miguel asked whether the square footage could be entered and changed through a form, because determining the right figure would take some time.

April 2011 wireframe for WeConnect’s “NYC: SoHo Report”

I find that exchange particularly interesting today. We had a design for presenting the information, but we still needed to establish what the information should be and how someone would maintain it.

A useful report depends on all of that work. The definitions, the source information, and the process for keeping it current affect whether anyone can rely on what the screen shows.

As my role moved further into operating and expanding the business, I had more opportunities to see how much those details truly mattered. Opening another location meant another team, more members, and more information that needed to stay connected to what was happening in the buildings.

Back to that problem at DNK

Today, DNK is building data infrastructure for Japanese real estate. The customers and workflows are different, but I recognize many of the same questions.

Investment and asset managers receive property management reports every month. Those reports contain valuable information about the buildings they own or manage, but they arrive in different Excel formats from different property managers. Before someone can compare performance or prepare their own reporting, they often have to spend time finding files, copying figures, and making the information consistent.

We built Data Manager to bring those reports together and make the data easier to use. Hephaestus, our proprietary ingestion engine, extracts, checks, and standardizes the information inside them.

Building Hephaestus was not easy. It draws on our experience handling more than 3,000 reporting variations. For customers, that means less time preparing data and more time using it.

The connection to WeConnect is also in how we think about the experience around the technology. Can a customer upload reports themselves? Can they find what they need? Can they bring the data into an existing Excel workbook and continue doing their work?

Those questions have guided our recent customer sessions in Japan and the development of our Excel Add-in. Watching someone use the product gives us a much better understanding of what still needs to improve.

Seeing customers upload their own reports into Data Manager was an important milestone for our team. It represented months of work across engineering, product, security, training, and support, coming together in a task a customer could complete themselves.

I still get excited by that.