Four months ago, we embarked on a journey to create a new AI-powered product at Assembled. While there are many ways to launch a new product at a Series-B company, we decided to create a “startup within a startup” and put the team through a modified version of YCombinator (YC). We had 3 months of intense building and a demo day at the end. Though we knew these initiatives don’t always pan out, I wanted to recreate the early startup atmosphere that I had experienced when founding Assembled in 2018 and when I was a YC founder back in 2014.
So we formed the New Products Team to build something that enhanced the efficiency of customer support agents. Here’s how we approached our mission:
Talk to users
A classic YC mantra says that the two most important tasks at a small startup are to write code and talk to users. We took that to heart, especially the “talk to users” part.
Since we’re building for support teams, we focused really heavily on listening and interacting with support agents and managers. We’ve done many dozens of shadowing sessions where we watch a support agent work. These shadow sessions really enhanced our knowledge of agent workflows, but there’s still a barrier of observability where you’re not actually on the hook to finish out a support ticket and you don’t have to deal with the consequences of your replies.
That’s why we also do support takeovers: our team of 4 takes full responsibility of support for a few days and relieves the Assembled customer support team so they can work on other projects. These sessions really helped hone our thinking of what it’s like to literally be a support agent.
By being the backstop for Assembled customers, we started to understand small intricacies about a support agent’s day to day that would be difficult observe passively. It’s hard to fathom how much context switching support agents do until you actually run into a ticket that requires the internal admin dashboard, the metrics dashboard, a help center article, and 3 other tabs open to solve. It’s also hard to understand the cognitive load it takes to write an empathetic reply until you spend 5 minutes rewriting the last paragraph over and over again.
One room, one team
A core belief we held throughout our time was that everyone on the team would be in person, 5 days a week. We ended up commandeering a conference room for the team and we set up a little pod of desks. We even bought a professional sound system with an amplifier to blast electronic music as we were working [0]. We nicknamed it “the dungeon.”
The dungeon did a few things for us:
- It made changes in direction easier and faster. Early in our journey, we were making micro-pivots to our strategy every few hours. One hour, we’d be working on a settings page, and the next hour, we’d realize we didn’t really need that setting to be customer visible, so we’d only make it a backend configuration. We were also making larger pivots to strategy every few days. For example, should we investigate that sales use case that came up in our call? Being in person let us brainstorm and adapt quickly to new information and ideas, especially since our strategy was constantly shifting.
- It helped separate us from the rest of the company. Everyone on the team had expertise in Assembled’s core product of workforce management. However, we needed space to think deeply about our new product, and our separate room helped make clear that we were focusing on a new problem and allowed us to set more specific times on when we’d work on Assembled’s core product.
- Most importantly, it was way more fun. There’s something magical about working and goofing off late into the night in a small room. It makes you feel really connected to the people you’re working with. Disagreements were addressed more candidly, ideas were shared more freely, and the team grew closer. This connection translated into a more cohesive vision and execution of our goals, making “the dungeon” not just a place, but a symbol of our team’s identity and mission.
Existential crisis? That’s a feature, not a bug
On our fourth day working together, I made an announcement to the team: what we were doing wasn’t working. We had started out writing code 12 hours a day based on a cool prototype. This prototype wowed our executives, so we jumped into building a real version. But I realized that we had already broken the first rule of startups: you have to build something people want.
We hadn’t yet validated the problem and we hadn’t spoken to users about what their problems were. So we went back to the drawing board and focused exclusively on booking user interviews. We ended up doing ten user interviews the next week. Happily, three of these turned into sales calls and would eventually be our first three users.
Another existential crisis occurred the week after we had launched to two large teams. During launch week, we saw all of our metrics skyrocket — we were hitting all time highs for number of power users, messages sent, and daily actives. But the week after, usage dropped like a ton of bricks. We sat down as a team and tried to introspect what had gone wrong. We realized that this skyrocketing usage was merely people testing our product, and we still weren’t sticky enough to keep users. We needed to keep adding functionality and value before we could keep these users, so we threw out our plans to make it easier to onboard onto the product, and instead focused exclusively on making the product itself more valuable for existing users.
We continued to have many more existential crises. In fact, if we went a week or two without one, we’d start to get worried and introspect if we were being honest enough with ourselves. These existential crises are a feature of startups though — you only lose your existential angst once you find product market fit and a repeatable business model. By design, we were always questioning whether our product provided sufficient value and always introspecting how to add more value.
Tuesday dinners
Our YC-inspired approach extended to extracurriculars as well. Every Tuesday night, we would invite folks like Dan Robinson (ex-CTO of Heap), Josh Ma (ex-CTO of Benchling), Harry and Peter Xu (co-founders of Wanderlog) to grab dinner with us and share their startup journey and the mistakes they’d made along the way. That said, even though we had quite a few illustrious people come chat with us, the dinners I enjoyed the most were the ones where we had failed to find a speaker and instead went out to eat as a team.
I remember one night, we went to an Indian restaurant, ordered gobs of food, and talked about what we wanted in life. Each person had a different motivation. One team member grew up in a world with adults telling him he wouldn’t amount to much. Because of his early experience, he became hyper competitive and wanted to prove everyone wrong. One team member was a true non-conformist and wanted to carve her own path. Yet another team member wanted to be constantly challenged and was scared of ever being too comfortable.
While everyone had a different reason for being on the team, all of our motivations were deeply rooted and had nothing to do with career progression or resume padding. We were quite far from what you would describe as folks who wanted conventional success. Each of us had a chip on our shoulder in our own way, and this bound us together in our desire to craft something meaningful.
If you’re interested in joining the team, we’re looking for a few hungry, product oriented engineers. You can apply on our careers page https://www.assembled.com/careers-at-assembled or shoot me an email at john@assembledhq.com if you want to chat more.
Thanks to Anthony Duong, Brian Sze, Kaytlin Louton, and Ryan Wang for reading drafts of this article.
