Welcome back!

In Part 1, I went over the chronological story of Emit, a startup I co-founded and ran with my team from 2019 to 2021. It ended up in failure, but a worthwhile failure with loads of lessons. If You haven’t read Part 1 yet, please do! This post builds off of it.

The Lean Elephant in the Room

There is an elephant in the room that has to be addressed, and anyone who’s had decent exposure to the startup world would probably have alarm bells ringing soon after they’ve started reading the chronological story of Emit.

Startups are supposed to be strategic experiments, where you do as little as possible to get the most information about what works and what doesn’t. There’s a science to the madness, and it’s called the lean startup methodology. At Emit, we didn’t follow it as well as we could have.

Frankly, it’s not something I want to delve into deeply because it’s so fundamental that you can find swathes of material online about it. At the same time, it’s so fundamental that not getting it right was harmful, so it must be addressed. Here are lean startup’s steps:

• You notice or learn about a problem
• You do some bottom-up research on the problem, while also reading on the problem.
• You start talking to people to probe the problem. I write later on in this post about how to do this properly (to summarize – do not pitch).
• Make a value proposition.
• You list your assumptions and understand the variables of the experiment
• You make an MVP (Minimal Viable Product). This doesn’t need any bells and whistles, shouldn’t scale, and often shouldn’t take more than a few weeks to make. Ideally, this MVP should test your main assumptions only, which is why simplicity is important.
• Constantly learn from the MVP through analytics and talking to (and observing) [potential] users. Refine your assumptions and iterate.

 

One of the big mistakes I made earlier on was that I mentally and emotionally invested myself into a full product before talking to people. I didn’t even think of the initial version of Emit as an MVP: I thought of it as THE solution. I think this mistake carried on for the rest of the following two years: a bias had been set. It became even worse when I started pitching to people and received almost unanimously positive feedback, even though it’s known from literature that feedback from pitching to friends is dangerously unreliable.

Biases hold their power because we underestimate them.

When I started doing my first interviews earlier on, I think there may have been some decent signs that the market for Emit wasn’t very strong. People seemed pretty unfazed about the problem and were perfectly comfortable with their current ways of solving it. I tried to stay optimistic though, and mostly saw it as an opportunity to get new features onto my current understanding of the needed solution instead of really assessing my assumptions. To make matters worse, I was doing this alone.

I believe this problem of not critically assessing assumptions and being attached to our solution carried on when my co-founders joined. We did do some things right – we performed several rounds of interviews throughout Emit’s lifetime, and made some informed decisions based on our learnings. However, we never really had a list of assumptions or a static value proposition to vet; we even had trouble narrowing down our assumptions and value proposition over the recovery summer.

I was aware of this problem, but for a while I thought we were lucky. We assumed our assumptions were obvious. Moreover, we had a huge list of apps that had tried something similar to Emit in the past. Some predecessors were big names like Google, some were nobodies like us. Some even became successful, at least for a while. That didn’t signal to us that this was a dead end; it signaled to us that there was demand, and that all these companies were attempting, but failing, to serve that demand.

I think Emit would have failed even if we followed the lean startup better. Under normal circumstances, our failure probably would have been sooner, cleaner and more informed if we did follow lean startup better. However, my inclination is that COVID’s influence on our timeline and testing environment made this murky. Even if we were more methodical, it still would have been difficult to determine if our problems stemmed with the testing environment or the product, and whether they were transient problems or not.

For many students of Danny Warshay, they would see the story of Emit and say we became a solution in search of a problem. This is used to refer to a situation where under-informed founders create a solution ill-suited for its intended problem and hence hop from problem to problem with the hope that they can find a hole that fits their useless key. To some degree, I’d argue that’s something that Emit suffered from; our episodes with tradeshows and Small Victories might be symptoms of that. However, I’d exercise caution on over-emphasizing that characterization, lest you think all the experiments and pivots Emit made were symptoms. We were learning about the problem space as we were building, and COVID made things more uncertain and difficult, so turbulent change and a bit of wandering should be expected. That being said, I think we could have waded through the darkness better.

Generally, lean startup is great advice, but I sometimes wonder how well preliminary bottom-up research applies to novel non-niche social platforms. When thinking about platforms like Instagram, Snapchat, Twitter or Houseparty, they mainly address wants or conveniences. It’s hard to imagine being able to talk to and observe people to correctly judge how much of a need there would be for these platforms. Neither Instagram nor Snapchat did preliminary interviews; they started as hobby projects.

We often think about these platforms within the context of their attained popularity currently. They often seem so obvious now, but before they became popular I surmise they would have sounded just as washy as anything else. This is something we also experienced at Emit; it made the interview process hard to gauge. When it comes to the social world, people make due with, and get used to, the means they have. So, due to this inherent comfort, it’s hard to tell if people will make use of a new dimension brought about by a new platform. As we know from the temporary success of the Clubhouse^[1] app, we also don’t even know how long they’ll use these for.

So knowing this, I am left somewhat torn. More thorough and critical initial research might have done Emit some good, but at the same time I’m not sure if my optimism from my sketchy initial research was the wrong way to go about it. I don’t have an answer for this specific edge case. I’m not even sure if it’s an edge case, but it’s something alright.

Why Emit Failed – Specifics

This is going to have a bit of repetition from the chronological story, but it is more focused and touches on more nuanced things about the app’s positioning itself.

Ultimately, Emit failed because there was not a great market for our product. There wasn’t enough pull getting people on our platform, and nothing we did changed that. Given our team, our product, and the type of school Brown is^[2], I’m doubt there was much we could do to change this. Eventually, Emit was no longer worth the time it was taking, and it was time to cut our losses and stop racking up the opportunity costs of building something else.

When Emit was just about food, its thematic focus was a benefit. Its focus on just food gave it a clearer value proposition and made it easier to explain its relevance. Additionally, its constraints made it easier to design and brand. Even better, its focus was a high-frequency event: people eat all the time! Biteup would focus on making it easier to see who’s available to eat, prevent the annoyance and awkwardness of messaging people regularly for food meetups, and make it easier to communicate and coordinate amongst different friends and friend groups simultaneously.

At least, in theory.

The problem, though, was that the want for an easier way to eat with friends was lukewarm. People were fine with group chats, even though Biteup was meant to be “more efficient.” Additionally, the network effect worked against us because of our low initial user count. Moreover, people were generally fine with happenstance meetings and, if all else fails, just eating alone.

So eating was a high-frequency event, but further optimizing its social dimension wasn’t really that important, at least at Brown. COVID, of course, worsened this.

When we decided to pivot to a more general meetup app, we were making a gamble as a response to COVID. We hypothesized that since our single meetup channel was crippled, a more general use case might be beneficial, even though it would result in the loss of thematic focus. The associated disadvantages were troublesome, however. Since the app was no longer specialized, people often weren’t able to differentiate it from group chats. As we did the work to teach people the difference, we saw that said said didn’t matter much to many people. They often liked the concept, but in practice, they were already embedded into the social networks of other platforms that this wasn’t worth the switch (Porters 5 forces anyone?). Emit was just making something people already did easier, but it wasn’t fundamentally changing anything.

Our switch to a discovery app (i.e. finding new people and new activities) was the natural response to this, with public flares being the spearhead for change. With this, we hypothesized that the network effect would be less troublesome since the network wouldn’t need to contain your existing friends to be valuable. Additionally, it was focusing on discovery, something that current platforms don’t really focus on.

It was good in theory, but it was its own Pandora’s Box.

One problem was the problem of motivation. Within a circle of friends, the motives for both posting flares and reading flares is clear. Within a circle of strangers, it is a bit less clear why you’d post a flare. For organizations and clubs, it’s an obvious recruiting tactic; that’s why we spent so much effort reaching out to them. For individuals, it can be a bit uncomfortable though, especially if you don’t really have that much of a filter of who will end up coming.

There’s also a little dynamic between introvertedness and extrovertedness. People who are more comfortable with the social uncertainty of posting public flares are likely more extroverted, but they’re also the people least likely to need to post flares since they have so many other avenues to reach people. This is a sad failure, since Emit was meant to be an introvert’s haven.

The concept of value is another problem we ran into.

One part of the equation is the value of the events on the platform. Niche events are great only if you have a niche audience or a very large audience; we had neither. Seth Godin recommends that startups focus on a particular niche at first and spend considerable effort making them as happy as possible. They’ll be loyal first adopters and you’ll learn a lot from them. We didn’t think we could find a niche within the Brown community that was large enough that they’d need Emit, so we decided to keep things general.

So, we postulated that Emit would need more high-value events, like parties and conferences that are generally liked by the student population. Parties turned out to be a fluke; exclusivity and information control happen to be important aspects of how parties operate. More popular open events also already had sufficient channels of advertisement.

The other side of the equation is the value of the people attending the events. As mentioned before, you don’t really have a large amount of control over the people who see and respond to public flares. For both the flare sender and readers, is there much of a guarantee that you’ll like the people going there? The only thing you know you have in common is the interest in the event; is that enough? The only way to tell is to suss them out in the chat and attend the event physically. This can end in disappointment. There wasn’t a way for people to benefit from Emit without taking considerable effort (like going to an event vs just liking a post on Instagram); that’s one thing that separated us from other platforms. So, these types of discouraging factors were dangerous. We considered implementing a, event recommendation system to combat this, but by then our confidence in Emit had already waned.

One other issue that worried us was the issue of graduation. Let’s assume that Emit was successful in getting regular users and regular flares. As people used the app, they would find more friends and more events to regularly attend. Over time, they would build their repertoire and schedule. They’d need discovery less and eventually graduate the app. To take this further, what happens when people leave school? Does the app keep relevance?

Because of the problem of graduation and uncertain value, there’s a low repeat potential for the app, meaning we couldn’t be confident people will always be coming back and stay engaged.

The feeling of commitment is another thing to battle: I may want to attend a flare, but I may not be committed enough to press the “I’m in” button and have my profile actually associated with the flare for all to see. But if everyone acts that way, so many flares will be false ghost towns. This is discouraging for both flare creators and flare writers.

There are even more variables to further complicate the equation that we hadn’t really designed for. Whether or not you go to an event, even one of mostly strangers, will sometimes depend on whether your friends are also going. And what about all the other things you could do with unexpected free time, like reading, exercise, hobbies, extra studying, or YouTube? Emit is simultaneously battling with all of them. People aren’t sitting around twiddling their thumbs

The current solution just didn’t fit into reality and wasn’t addressing a hair-on-fire problem. It was addressing a want rather than a need, and sloppily so. Even us co-founders were barely users of the app.

 

A little note on monetization

From day one, before Emit even got a name, I decided that Emit would not be monetized until it got critical mass. When it did, the first monetization strategy would be partnerships with restaurants. We could suggest restaurants to people wanting to eat together, and even collaborate with venues such that they give discounts if users come in Emit-facilitated groups.

For a little while we considered using this strategy even before we got critical mass to help us through our problems. Plainly, as a Band-Aid. At the very least, we thought it’d help us fix the network problem. We spoke to JJ, though, and were dissuaded. Really, it would involve trying to make a whole new marketplace (users to restaurants) to fix our initial marketplace (users to users). Maybe it could work, but what If people only cared about the user-to-restaurant marketplace in the end? We’d become like a weird Snackpass. JJ told us that the discount business is not an easy one to work in, and that we should work on our fundamental issues instead.

More Lessons

We didn’t know the Mom Test

Anyone who wants to make anything for anyone has to read The Mom Test. It’s a book about how to really talk to people in order to determine the value of your ideas. Though we already followed some of the advice in the book before we read it (only a few months before Emit ended), I’d like to think reading it earlier might have improved our interviews and helped us fight our attachment to our current iteration of Emit.

 

Consumer Tech is the Habit Business

This is a realization I came to after watching Kevin Hale’s video on evaluation startup ideas, and it became more obvious to me when I started realizing that getting downloads was easy but getting active users was very difficult.

When you’re making a piece of consumer tech, I think it’s often useful to think of how habits come into play. Specifically, two behaviors are in play that you’d like to manage: the habit for your users to confront the problem your startup seeks to solve, and the habit for your users to address it using your product (instead of any other product/method).

For example, imagine you were new to the e-commerce space, and you were trying to open an e-commerce store for fresh produce. You have to both get people into the habit of purchasing produce online instead of in stores, and to get them to do this on your platform, instead of someone elses.

Of course, the dynamic of these habits changes depending on whether you’re making an app that’s trying to solve a relatively untouched problem space, or an app that’s entering a crowded space.

For Emit, I think we started to realize that we had to cultivate both of those habits. People were generally fine getting in touch with friends through existing channels and meeting new people through happenstance. We had to convince them that those channels weren’t enough and that our channel was better, and ensure they keep coming back.

Gamification is a great way to cultivate habits. However, I sometimes find it to be insidious, for two main reasons. First, I think it’s a bit of a Band-Aid, because people may rely on gamification to compensate for the fact that their product isn’t a great solution on its own. Secondly, gamification can become addiction-oriented design that flips the equation from the startup serving the consumers to the consumers being trained to serve the startup. I think this is a failure of startup design.

Of course I’m not saying gamification should never be used; I’m aware it’s a tried and tested method that works. However, restraint could be exhibited to determine if it should be used and to what extent.

 

The tech is sometimes the easy part

Emit’s codebase is something I’m very proud of because it’s the best and most complex product I’ve ever worked on to date. Regardless, there were many parts in the startup journey where deciding whether to add a feature was far harder than actually adding it.

Initially, I had to put a lot of effort and research into architecting and designing Emit’s stack and design. But as time went on, I became used to the technical kind of thinking Emit’s code required. That’s not to say some features didn’t require a good amount of thinking and head scratching.

But understanding users, how to improve user retention, deciding which features to add, and the direction to take Emit were less deterministic than programming. I felt like a master of my codebase, but not so much for these other things. Learning was constant and my knowledge of the playing field, other platforms, and strategies increased steadily over time, but a feeling of mastery was elusive.

 

Being flexible

People handle times of uncertainty differently.

During the recovery summer, I saw this dynamic play out between Brandon and I. We both saw the summer as our last shot to get Emit right. To him, that meant we should only put effort into updates and experiments that had a high probability of success or a high probability of teaching us something if they failed. I, on the other hand, thought of the summer as a way to consider many things to increase the possibility of finding many maxima.

Both of us were right in our own respects. In general, it’s up to the team to find a culture that balances both. Note that this culture should be explicitly talked about. Brandon and I did not talk about it until we noticed that our differences in responding to uncertainty made it progressively harder for us to agree on even the most minute decisions. But once we did, the culture was agreed on, and it made things smoother.

I surmise that there is a similar dynamic for people (and companies) and how they handle success, where some may go into lockdown mode to ensure they mess nothing up while others try to experiment because they know they have something to fall back on if they fail.

 

Suss out your team

Without a capable team with good team dynamics, you cannot succeed. Whichever way you look for co-founders^[3], you need to be precise, frank and factual about who you choose to eventually work with. These are people you’ll potentially be in the trenches with for years, hence you need to optimize your chances of success. Be honest about assessing the competence and compatibility of team mates. Be very attentive to early red flags concerning things like commitment, dedication, attention to detail, and proactiveness. Find people with competency in a variety of applicable skills, and see if you can get people from the Six Thinking Hats.

I want to re-emphasize the importance of sussing out early red flags: from what I’ve experienced they often get more and more frustrating as the stakes rise. That’s not to say any presence of a red flag merits action, but sustained presence early on definitely does.

Additionally, be aware of the 4 stages of team formation: forming, storming, norming and performing. My knowledge of them made going through them less confusing and frustrating when my co-founders came on board.

 

Talk to your co-founders

During Emit’s recovery summer, Brandon, Nate and I were in 3 different corners of the country – Providence, Seattle and San Diego. For a while, we were only virtually meeting and talking shop, especially short-term things. But after a while, our interactions started to feel transactional. So, I started doing spontaneous one-on-one calls with my co-founders. I asked how they were doing. I asked them about what they thought about features. We’d have long brainstorming sessions. I wanted to be able to gauge their mentality irrespective of the other person. I wanted to get to know them more again. I needed our team to have a human component, and I also needed us to have more honest conversations about our thoughts about Emit’s trajectory.

These were some of the most productive and impactful calls of the summer, and definitely brought me closer to Brandon and Nate. I wouldn’t necessarily say I was the leader of the group – we tried to remove hierarchies at Emit. But as consultants Morriss and Frei revealed during their consultancy work with Uber, it’s important for leaders (or, in our case, team members) to show that they care about their team members in more than just a business manner. It built trust and understanding.

 

Funding isn’t always default or a goal

Oftentimes when I talk about Emit to folks, one of two questions is the first one asked by my audience: “How many users do you have right now?” or “When do you guys think you’ll seek investment?”

I had no problem answering the first question, even though sometimes I’d be embarrassed exposing how poorly Emit was doing quantitatively. For the second question though, I often had to remind folks that my team and I were consciously not placing investment in our timeline.

I understand where this question is coming from. I can imagine that from the outside, the startup world sounds like the world of investments and acquisitions. That’s what’s in the headlines, and that’s what excites many. And for many startups, investment is a must in order to scale, especially if you’re R&D-driven or capital-intensive venture. Investments, however, come at a cost, like equity and control costs; investors will likely influence decisions. But more than that, there’s the cognitive overhead of looking for investors, of changing the startup to be favorable to investors, and of factoring in this favorability into further decisions down the road. For a fast-moving startup with lots of variables to balance, it’s not always a good idea to bring in additional variables that are not needed.

I’ve had conversations with folks that were trying to contribute to Emit whose perspective was solely investment based. Their sentences often ended with “that’s what X did and they got Y amount of funding,” or “because investors like that.” I’d argue that it’s not a good way to think because it shifts the focus away from the problem and users.

Getting investment capital should never be the goal, you need specific reasons for every penny of it. It’s only a means to an end, don’t go for it if you don’t need it. It can be a great distraction that can derail you. If you can, see how far you can go without it. Its absence may keep you more focused; the scarce resources may stave off complacency, and the constraints may bring more innovation. The best innovation is birthed from constraints.

Want some examples of companies that went far without any funding ever? Mailchimp and DownDog.

No one outside your team should be relied on early

 

Everyone has their own reasons for wanting to work with you, and no one cares about your startup more than you. When dealing with folks outside of your team, you have to make it very obvious early on what the benefit is to them. Additionally, you have to understand that since they have considerably less skin in the game than you (if at all), they often have little to lose from just abruptly cutting contact and stopping collaboration with you if they no longer think you’re worth the time or effort.

Many people are just flaky.

Numerous people we’d been in the middle of talks with for partnerships or symbiotic relationships simply stopped answering calls and texts. They had nothing to gain from even stating that they no longer had interest.

Don’t rely on folks too early, and expect flakiness from many.

 

Momentum is a valuable resource

For student founders, there is a lot to distract you from your startup, especially studies. Studies are technically a fulltime job! One of the things I realized is that if you don’t maintain momentum in your team, everything else steals time and mental bandwidth, and the startup lulls. There’s been times where the whole team would get discouraged or sidetracked, and one blink afterwards we’ve gone three weeks without progress.

Be sensitive to lulls, dips in momentum, and dips in motivation. Short bouts are natural; long ones are dangerous.

 

Be strict, but not possessive, over code

When my co-founders first started adding their code to Emit’s codebase, it had already existed for a year. I had a large attachment to it, and they had a lot to learn to be able to contribute cleanly to it without adding lots of technical debt. So, initially, I tried to silo them. I tried to make sure people only worked on the simple things while I took on the harder tasks. For a while, this worked, since it also provided a relatively simple and safe way for them to learn about things without breaking stuff, blocking people, or making code that would have to be thrown away.

But after a while, when I got busier (especially over the Amazon internship), I became a blocker myself because everything that needed to be done was considered a “hard” task and hence under my jurisdiction. So, for the benefit of the team and the product, I had to let go. Delegation increased. Back-and-forth code reviews increased. Production was broken a few times. I wrote more documentation, and taught more.

Over time, though, my co-founders got better, and needed my help less with every pull request. There were even times I saw flaws in their designs, but because I wanted them to feel ownership over their features I didn’t mention solutions until they came to me explicitly.

You cannot expect your team members to learn and improve if you do not give them the space and trust to make mistakes and feel ownership.

 

Having a marketing-oriented person

Startups are really only as strong as their teams. There were many respects in which I think Emit’s team was strong. We had good technical prowess, useful networks, good chemistry, and some decent branding and UX capabilities. One thing we missed though, was a strong drive to get out and market the product face-to-face with strangers on campus. We did it a few times, but I think it was harder for us than it should have been, and it was infrequent.
Next time, I think I’d put a higher value on a team member who’s able and willing to do such marketing frequently and intelligently.

 

Sometimes good design takes data and time

This is something I got used to when I was really into game design and graphic design before Emit. I’ve even written a bit about it. Good design, like logo design or UX design, often requires intentional constraints and immersion. This is something I encountered many times when I was designing the brand, UI and tech behind Emit.

I’m super happy with Emit’s logo, but it took several weeks to get. Before Emit, I had already learnt a lot about logo design for previous projects. Nonetheless, I spent weeks looking at hundreds (if not thousands?) of logos and determining what I do and don’t like for Emit’s intended brand identity. I also spent that time looking at which designers I can and cannot afford, and started reaching out to some. I wrote brand specification documentation for my to-be designers. I learnt how logo designers think and prefer to be treated. Even after all this, the first designer I hired didn’t make something I liked; it was a sunk cost.

A similar process goes for many parts of Emit’s UI: they were the products of hours of looking at what worked and didn’t work for other companies and how that blends in with our constraints.

If you want to be able to make consistently good designs, you have to make sure you’re constantly feeding yourself data to draw from, and that you’re also giving yourself time to ruminate and iterate in your mind and on paper.

The team realized the hallmark of a good designer is someone who has optimized this process to make a profession out of it. They always ask for constraints and what we do and don’t like. They’re always immersed in the designs of others, and often need time to make gold.

 

Please mind the paperwork

This is a simple point, but an important one. Remember that startups are small companies. Trademarks, contracts and copyrights are important, even if the startup feels too informal to require them. If those are not taken seriously as a precaution, copyright claims, equity, trademark conflicts and more may come and bite you in the back when you grow and incorporate.

Take the time to make even basic paperwork for this. Emit was trademarked (we did this the semester of our launch). The founders had an MOU. We made contracts for contracted designers.

 

Off to a new journey

That’s it! I hope you were able to take something away from this long post.

Emit was quite the journey, and it’s one I’m extremely glad I embarked on. I made great professional and personal connections, learnt a lot about entrepreneurship, and discovered a career path I will seriously consider for years to come. The journey of being a founder is a hard one, but it’s extremely fun and rewarding, even when faced with failure in the end. The journey is the reward.

I’m always happy for folks that I see who are embarking on the journey. I have an even higher level of respect for the successful ones I see around me. I sometimes even advise folks who are early on the journey  – imagine that! For example, I advised a group who was early in the process of starting a platform similar to Emit; it was such a “full-circle” kind of experience.

To all else wanting to give startups a try, please do. Learn the process, find a problem, get a team, and start. There is nothing else you need to do; you must start. You’ll be way ahead of most of the curve already. Once you start though, you must put in the hours. Half-assing is a ticket to true failure: your startup will fail and you’ll learn nothing. It should consume you and you should give it your all, akin to an obsession.

It’s funny, though. Many career paths now seem mundane or insignificant to me after such a journey. I’m now stuck trying to find the next problem to solve that will captivate me as much as Emit’s did, and I wonder how long I’ll be in the standard 9-5 software world before I can escape and try once again.

No matter; I’ll search as long as necessary.

Signing off for now.

 

 

^[1] Clubhouse is an audio-based social media platform that exploded in popularity in mid 2021. Its peak in popularity was temporary.

^[2] Brown, especially during COVID times, isn’t necessarily the biggest party school.

^[3] You might want to look into the “power of loose connections,” a piece of advice on how to properly look for co-founders.