We got our shit together just in time to run out of money

The rift

In 2016, I was the “Director of Storefront” at ScoreBig, in charge of the engineering behind the part of the site that enabled people to browse and purchase tickets to live events.

The relationship between the engineering team and the product team had become deeply exclusive and bordered on adversarial. Engineers felt like the product was being developed behind closed doors without regard for feasibility or clearly-communicated timelines, and product managers felt like engineers were sandbagging and resisting change necessary to reach customers.

The rift was made most evident by the choice for the product team to use a different chat tool from the rest of the company. We weren’t talking and we mostly stuck to conversations within our siloed teams. When we did communicate between teams, the conversations often meandered and spawned new concerns without putting old ones to rest. This threatened our ability as a company to fulfill our mission to help people enjoy live events.

I was part of the group of people who changed the conversation around product. In that work, it became clear that the path to a better product lie in open, inclusive conversation. Our interactions with one another changed. And by September 2016, we made an exciting product that represented the very best ScoreBig had ever made.

On repairing relationships

Because our problems included siloed and exclusionary communication, it became necessary to set clear ground rules and start rebuilding trust between members of each team. It’s tiresome work that required each of us to show up, listen well, and get curious.

Throughout our work together, I started to see a concept of “inclusive conversation” form: communication between people with a mutual purpose and a high regard for one another. Talks about a topic were open to all who shared a purpose and explicitly and they intentionally spanned across teams.

In order to adequately address the meandering and off-topic conversations, we worked out a way to acknowledge the new topic and plan to discuss it as needed after addressing the topic at hand. This required that people act assertively to stay on topic and also make good to follow up when appropriate.

We also noticed that getting off topic can be a result of disengaging from a conversation while lingering “in the room.” An inclusive conversation is open to all, but is held with the understanding that not all need take part in the whole conversation. It is acceptable to acknowledge when a person no longer has value to add to or gain from the conversation, and to excuse themselves from the conversation.

Building on renewed trust

Conversation is vital for cultivating ideas, but good product needs to record these ideas consistently. Good documentation fills this need by breaking down big ideas into components. It defines the relationship between components. Each component is described by four things: intentions, inputs, states, and actions.

Intentions are the purpose of the component. It is a succinct definition of why the component exists. If a component cannot be succinctly defined, consider breaking down the component further.

Inputs are the information a component will need to fulfill its intentions.

States are the different modes of being that the component will exist in. It is a description of how it works in each mode. If describing the states is cumbersome, consider breaking down the component further.

Finally, actions are the different ways the component may cause something to happen.

It is normal for documentation of components to refer to visual designs. But the designs must complement the documentation instead of replacing it. Documentation is a collaborative work involving people across teams and responsibilities. Product managers primarily curate and cultivate this documentation. They are responsible for communicating a unified vision of the product.

Documentation is malleable. Cultivating documentation requires keeping it relevant and up to date. We integrated component documentation in our interactive style guide, and by keeping the documentation close to what it described, we saw when it needed to change. (Or when our implementation needed to change.)

With renewed trust among the members of the teams and a new common language among us all, we set out on a focused project to reimagine the ticket-buying experience. After 50 days, we launched the new experience and saw verifiable success in our conversion rates.

Epilogue

Only three weeks after our exciting product launch, ScoreBig ran out of money, couldn’t land new VC investment, and shut its doors. The reasons were complex and varied. But at least part of the final analysis shows that we took too long to get healthy in product development. We got on the right road, but for ScoreBig, it was too late.