# Get string in binary. s = "0110011001110101011000110110101100100000011101010010000001101000011000010110100001100001" # Go through binary 8 bits at a time. # 8 bits = 1 byte = 1 character. for i in range(0, len(s), 8): # Convert the block of 8 bits into an int w/ base 2. # Finally convert to a char. print(chr(int(s[i:i + 8], 2)))
So. We launched Kanga3 last week - that little social network idea we wanted to experiment with a little. Here is the pitch deck if you want the quick explanation about what it’s all about.
Alvin (our mobile boi) and I built it in two weeks. Probably could have built it in one week but I had to learn React Native so that slowed us down. We wrapped it up last Monday. Me + Alvin just spent the last 5 days giving it to people and talking to users.
It wasn’t a smash hit.
In fact, it wasn’t that great at all.
But, then again, I didn’t really expect it to be. I just wanted to learn from it. I just wanted a place to start. I’m not out here trying to ship an app for it to go viral right now. I’m trying to ship something and see if I’m even on to something and if it’s worth me pouring myself into.
Definitely learned a lot from the Kanga3 MVP and we decided to spend another two weeks on the next iteration of it :). Building a social app is hard and you can’t expect to have a viral success two weeks in. But, two weeks in, you should have some form of validation that motivates you to pursue the idea - which I feel like we got from this MVP!
How I like to build fast.
Before we even touched any code w Kanga3, I very clearly laid out exactly the features the MVP should have. If you don’t do this, you will just randomly start adding features you think are “important”and other random shit you feel like you got to have. Because of this, it will take you much longer to ship a shitty MVP. Write down the 2-10 features you feel like your MVP has to have and stick with it. Was Google OAuth in your MVP spec? No? Cool. Don’t add it in randomly 1 week in.
MVPs are usually shitty and that’s how they should be. If your MVP isn’t shitty you probably spent to long on it. But it needs to have just the right amount of shitty-ness for what you’re out to do. I want to go over the shades of shitty-ness I work in.
Extremely shitty (1-2 days): Your MVP is extremely shitty when it does an extremely shitty job at solving the problem you’re out to solve. This has nothing to do with design or UX and it has everything to do with core functionality. If you’re trying to build a physical calculator that can add 1+1 and the only digits you have on the calculator are “3” and “2” because those were the only digits they sold at Walmart, well, that’s an extremely shitty MVP. But to be honest, this isn’t bad. You can go out in to the world with this extremely shitty MVP and get feedback fast and see if people are even trying to add 1+1. You may find early on that people are just trying to do 2+2 all the time and you can quickly adjust your plan. I want to make it very clear that I think an extremely shitty MVP is extremely valuable and is where every product should start.
Kinda shitty (1-2 weeks): You are here if the MVP does a pretty okay job at solving the problem you set out to solve. It doesn’t look like complete garbage and is a product you feel like will actually help you discover if the problem you set out to solve resonates with users. It’s something you can actually give people and track metrics for. You can see stuff like retention, WAUs, etc. And I don’t want you to say shit like “But Farza! I can’t get good feedback on my product unless it actually looks good and doesn’t crash and unless it has feature X and feature Y and blah blah blah blah”. You’re wrong. I don’t care what you’re building. You’re wrong. You can get quality, actionable feedback on a product at all stages - from idea to MVP. If I’m out to build a concrete company I can cook up my first batch of concrete in my moms backyard in a week, sample it to construction companies, and try to understand if a concrete company even needs to exist. If I make my first sale - I may be on to something. Users and feedback are everything. Building an MVP is just a means to user feedback.
Not shitty (2-4 weeks): You should only be here if you first built either the extremely shitty MVP or the kinda shitty MVP. And you should only be here if you received encouraging feedback or metrics from one of those MVPs. Don’t marry an idea. Just move on. I have like 10 ideas a day. Why would I stick to one? So, at this point the MVP still looks like ass but it never crashes, solves the core problem well, and is something that looks passable sop you can release to a larger audience without them laughing at you. Usually at this stage I take metrics way more seriously because more people are using it and you have a larger sample size to determine patterns in usage.
The whole point of an MVP is to help you validate some idea you have and see if your solution resonates with users. That can always be done in 4 weeks or less. No matter what. I don’t care what industry you’re in. Are you trying to built a smart-watch to detect when someone is having a seizure? Stop worrying about FDA approval. You don’t even have a user. Find one dude with epilepsy. Strap an Apple Watch on to his wrist w/ an app you made in 2 days that can detect repeated jerky movements (easy as heck to make) and see how that goes. Can you even find one dude? Does he even want it? Will he pay for it? This is all stuff you can do right now. Without FDA approval :).
Move fast. Talk to users. Don’t marry your idea. Kill it fast if required. LEARN. And then move on.