Design, Launches and Doing it right

Reflections from Chaotix journey

I spent two years building Chaotix before deciding to shut it down a few weeks back. Over that time we raised a round, built a team, and grew to 20,000 users who created more than 30,000 games.

A dear friend advised to take a step back and take stock of learnings from this experience. So, I spoke to some of our power users again to understand what they liked and didn’t like. While a majority of them loved our team and our product, what surprised me was that several of them didn’t even know about features we had already shipped.

That moment forced me to rethink a lot of assumptions about how consumer products actually grow. Looking back, a lot of the things we struggled with were not purely technical problems. They were product judgment problems. Over time a few patterns started to become obvious.

These are some of the key lessons and usable frameworks I took away from building Chaotix.

Part 1: Lessons from building Chaotix

These are some of the key learnings I have acquired:

1. Design is trust infrastructure

2. Speed matters, but quality becomes paramount once the product begins to matter

3. For AI products, the first output matters far more than most builders expect

4. Shipping ≠ launching

5. Product and communication must be a single loop

1. Design is trust infrastructure

Gen Z and Gen Alpha have grown up with internet abundance. They have seen hundreds of consumer products and developed a strong sense of taste. They use design judgement to filter out spam from good products.

A high quality user interface is therefore not a luxury. It is a prerequisite for trust and engagement.

For Indian founders, two forces make this worse.

First, the consumer design standards in India have historically been low. Partly because ARPU is lower, and partly because there are fewer globally successful consumer product companies coming from the ecosystem. This has created a feedback loop: fewer world-class products leading to fewer world-class designers and that, in turn, leading to few world-class products.

Second, we often have an incorrect understanding of how important speed is and at what cost.

2. Speed matters, but quality becomes paramount once the product begins to matter

Speed always matters, but there are moments when it matters more than anything else and moments when it doesn’t. It’s a crucial skill to learn and implement this in a startup team.

We launched fast while we were in the proof of concept phase. An engineered platform got a few hundred users excited about a product AND helped us raise a seed round. For that purpose, leaning completely on speed without caring about design was a great approach. But once we had the right partners funding our vision, we should have instantly thought about the complete product where quality should have become paramount instead of speed.

Quality comes from:

1. Good design

2. Honest and diligent implementation of the good design

3. Especially for AI products, great first time answer

3. For AI products, the first output matters far more than most builders expect

This is something that came up in a few conversations while we were building Chaotix. It was difficult to fully appreciate this while we were building the product. For someone used to traditional design processes, this feels counterintuitive.

If you’re planning to build an AI company, the first time output/answer is more important than you know.

The two ways we found how to reduce the churn from first time answer were:

1. Set the right expectation before the users write their first prompt:

   When we created a REMIX feature in Chaotix that allowed users to see the game template that they will modify with this prompt and then they got that modified template game, the SHARE count went up.

2. Deliver more than promised:

   This is an anecdote from a different company. It is an AI video creation plus editing tool. The initial idea was to show the users a step-by-step process to make a great video. The conversions were close to zero, and when they removed the steps and gave the one-shot output that was more colorful instead of a storyboard, the conversions instantly shot high.

Think from a user journey standpoint and solve for the first time answer as early as possible. Remember, for AI products, the first output matters more than you think.

But no matter what you build, it’s useless if the potential users aren’t seeing it immediately.

4. Shipping ≠ launching

A few days after we stopped developing the Chaotix app any further, I spoke to a few of the power users and took stock of what they liked and did not like in Chaotix. It is a painful thing to find out in hindsight that quite a few users, that we considered power users and our spokesperson, did NOT even know about multiple features that we had shipped.

However, this inspired a simple query, for every feature we built and shipped, how many pieces of content did we make? And the ratio was something close to 1:3. I am including all the promotional contents, ads creative and posts that were made. This means that some of the features got ZERO push from our end. They didn’t make it into a newsletter, a video or even a linkedin/twitter post.

I will never make this mistake again. Shipping is NOT launching.

For startups, you launch every week. Yes. True.

But launching every week is not just shipping every week.

But the definition of launch must be that you have made every effort to inform your current users and your prospective users about the things that you’re shipping.

I’ll lean on the side of “ship once, sing a hundred times”. I would even go to the length of building less OR stop shipping new things altogether, if you’ve not yet done the launches properly for the things built so far.

This only happens when product plus communication is a single loop instead of disjointed responsibilities.

5. Product + communication needs to be one loop

This is almost a consequence of following “shipping is not launching” rule carefully. If you’re committed to launch everything you build and ship. You will want to take a step back before building to see if you can actually launch it.

It’s almost as simple as asking can you explain what you’re building to your core audience comfortably before you go ahead and start building it.

In Chaotix, we built a feature card “AVATAR CARD” while it sounded cool and we felt excited about it. We were never fully able to explain to the users what it was supposed to do for them.

There are some more examples of features built, shipped and then deleted from Chaotix which went through the cycles of us struggling to explain it after we’d built it.

The objective of that feature was to give a glimpse of the character that the user will be playing as in every game and a moment for them to experience it.

If I were to do it again, I’d have kept simple “PROFILE PICTURE” where we placed “AVATAR CARD” and instead of “AVATAR CARD”, I’d have built a simple interactive experience like “TEST YOUR CHARACTER” where could make a character and test out how it looks while moving around.

The simplest way to solve the product and communication gap is to try and communicate the product before you build it.

If you cannot communicate it simply, maybe wait out a couple of days/weeks. Maybe you’ll decide not to ship it at all or, at the very least, you’d find a better form of that feature that is easier to get through to the user.

While these are some of the key learnings, I find them incomplete without a simple to list or a framework on how to execute them well. If I were to start a company today, this is the framework I would use.

Part 2: Framework for starting up with a small team

This will be my tactical framework for a small team. Let’s break it down into three parts:

1. Before you begin

2. Product

3. Communications

Before you begin:

Before you begin building anything or even decide on an idea, find a few key users. They’re going to be your pseudo-bosses.

If you cannot find multiple, at least find one person whose interests you seek to serve through building a company.

You want to have a specific set of people in mind who you’re solving for instead of a vague persona.

Unless you have at least one specific person in mind, do not start a company.

It sounds extremely simple, but it’s a step many people often overlook.

We were fortunate enough to do it right in Chaotix as well. And this used to help a lot.

Product:

This is a good framework for running product meetings. Note that this will typically end up being a long meeting often running over 3 hours. But this should be the ONLY product meeting you have in one cycle. For us that frequency was once a week.

1. Gather pertinent data. Data means:
   1. Status of the north star metric like revenue or DAU
   2. Status of contributing metrics. For Chaotix, it used to be active creators, content created, active players, share counts etc.
   3. Usage numbers on the features launched a week ago

2. Get all ideas on the board.

3. Categorize the ideas into:
   1. Bug fixes
   2. Feature deletion requests
   3. Feature recommendations

4. Bug fixes take priority. What’s out, should be high quality.

5. Feature deletion requests are an important category to keep on the board. It’s great if this is empty every week. That’s ideal. But having this category creates room for everyone comfortably acknowledging that we may have made wrong choices and that it’s our responsibility to fix them moving forward.

6. For feature recommendations, you want to define how it will move the north star metric. For example, adding a “FRIEND SUGGESTION” increases the FRIEND REQUEST SENT and creates more reasons for creators and players to interact with the app. This leads to increased DAU.

7. You want to further categorize, how difficult will it be to build that feature. Typically, you want to keep it simple in the form of dev days. We had the categorized them as easy, medium, or hard feature if they took less than one dev day, 1-2 dev days, or >4 dev days respectively.

8. Try explaining each feature as simply as possible. For this step, the key responsible person for marketing in your team, must be present in the meeting. Make sure you have 1-2 sentence long clear marketing friendly explanations of that feature. Unless you have it, consider shelving that feature for a week or two and revisit it next week. Do NOT build it, unless you can see a clear exciting path to share it with users.

9. Decide clear written spec. Not just that, throw it into Figma make and get close to 90% of the design of what you want to make. This is NOW possible and it works great! This removes uncertainty from the process and adds transparency.

10. Clearly allocate the tasks to specific individuals along with the timelines and expected deliverables including the written spec and the Figma design.

11. This is an add on that can be done during or after the meeting which is to prepare a summary for the pseudo-bosses. This summary should contain, usage numbers on the features launched a week ago, status of features launched last week and details of features planned for launch this week.

Note: Michael Seibel, from YCombinator, has a great video on building products. My framework is made with tweaks on his.

Communications:

This is the framework that I believe that we can implement in the early stage teams. This is NOT fully tested yet but I feel confident that this is an implementable framework with significant benefits for a small team.

Note that this is not a framework around how to build marketing and distribution.

This framework assumes that you already have a few users and a few prospective users i.e. top of the funnel.

This is about a basic plan for communicating with your top of the funnel. This funnel consists of your mailing lists, your followers on social media and relevant communities.

Note that you need to do a lot of extra work to constantly increase your top of the funnel.

You want to run a communications meeting immediately after the product meeting.

For small teams, barring anyone who is exclusively only an engineer, you should include everyone who posts content or handles any community channels in this meeting.

The summary document that you prep for your pseudo-boss in the product meeting becomes the ground work for this meeting.

1. Gather all data. Data means:
   1. Data gathered for the product meeting
   2. The note you prepare for your pseudo-bosses

2. Every feature must be mentioned in every funnel at least 3 times. I.e. say you enabled reacting to comments in your product. Then you must mention in at least 3 emails, 3 posts/reels on social including TikTok, Insta, Twitter etc. and mention it in at least 3 reddit communities.

3. These are the three easy category of contents that you can build:
   • Teaser: You can make this content directly when you come out of the product meeting. This announces to the users what you’re planning to build this week. This can even include screenshots of Figma, your thought process on why you think it’s relevant, the user story that triggered this feature, or what you think it will change in the users’ lives. To create this content, the marketeer will have to step into the users’ shoes again and it will likely also help with figuring out any gaps remaining in building the feature.
   • Launch: This is where you want to inform the users and prospective users about what you’ve built and shipped. Don’t worry about this being on the exact same day as the feature is shipped. All you want to ensure is that it goes out in the same week as the feature is launched.
   • Results: This is the results of the feature. It can be something as simple as the stats about the feature use or a user story that emerged from this feature use. This goes out a few days after the feature has been live. This helps making sure that a feature doesn’t go into a feature deletion request bucket just because it wasn’t utilized quickly.

4. These are the funnels that I would easily utilize:
   • Mailing lists

     Without spamming the users, I would want to send a weekly update email/newsletter to the users and prospective users.

     One mail would contain all three.

     The teaser of features to be launched coming week, the launch info of features launched this week, and the results of features launched the week prior.

   • Social media videos

     Videos is the format that masses are consuming especially short form videos.

     Here you have much more liberty to create interesting content ranging from demos, sketches, to talking head videos.

     The teaser, launch and result is a good starting point for this but be creative here.

   • Community

     You should build a 2 way community on Discord and Insta.

     But even if that doesn’t yet meaningfully exist, you want to identify the right topics on Twitter and Reddit and post some things about your content in similar lines of teaser, launch and result.

5. Only once you know that all 3 category of content has been created and shared on all three types of channels you know should consider that a feature is launched. Remember shipping ≠ launching.

On the surface, this may seem excessive. Especially to a first-time founder. But it isn’t. It is the absolute bare minimum.

In a world where building software is getting easier every year, the scarce resource is attention. If you build something useful, it is your responsibility to make sure people know it exists.

Build once. Sing a hundred times.

— Ankur Goel

I am brewing a few experiments. I might do some interesting things soon. You can reach me at:

• ankur@chaotix.ai

• https://x.com/goelankur1996

• https://www.linkedin.com/in/goelankur1996/

You can check out another blog I wrote at:

Pi0.7: utilizing bad data to teach good things

Building a personal automation system on the graveyard of past attempts

When AI hallucinates what it sees: notes from a robotics sim

Less Clueless