Real and Honest Growth Hacking and Lean Startup Story of Bindly Development
What is Growth Hacking in practice? What is Lean Startup in practice? These are the questions I want to answer in this article. I am developing visual notebook app Bindly on Android platform.
There are enormous lessons I learnt in hard way and I want to share the lessons with you. Bindly was just launched a month ago. So this is not a success story. This is not a failure story either. This is an honest and ongoing story of an entrepreneur struggling to get product market fit and traction using lean startup and growth hacking.
I believe in startup is sharing.
What really is MVP? Three is the magic number!
It took me one and half year to release Bindly as a product with full product features. In hindsight I could have released a product with core feature in half year.
I thought I understand MVP by reading book, attending workshop, practicing paper prototyping. But I was wrong. I still wanted to make it right. Let’s say “100%” is the realistically achievable state of product with given resource. I was aiming at making MVP with “80%” effort. “80%” was still big compromise comparing with my dream product. If I put it in the same scale, the dream idea about the product requires “500%” resource and energy which is not achievable with available resource.
Failing at scale of “100%” effort is disaster. Failing at “80%” hurts, really hurts. If you fail at “30%”, value of lessons is far greater than pain of failing.
Failure is something you cannot manage. No matter how much effort you put in, no matter how great idea you think you have, you can still fail for many reasons. What Lean Startup and Growth Hacking try to teach us is this.
Work on meaningfully digestible small batch. Measure and improve.
Many people are afraid to lose face. See themselves in their products. These are the things we care (and I cared in the beginning)
- Want to make sure design look good enough
- Want to make sure it runs fast enough
- Want to make sure it doesn’t go down too often.
These were ego statement of entrepreneur. Nothing to do with users. I just did not want to lose face. The ego got me working on 80% MVP rather than 30% MVP.
The more important questions were these.
- What makes the product look good?
- How fast is fast?
- How often service can go down?
You cannot answer these questions without shipping a product. The faster you can ship, the faster you will fail. It means you can learn and improve fast too. And don’t worry people are not paying attentions to you. There are tens of thousands of people making app everyday and you and I are one of them. So forget about losing face.
Measuring for business
The one metric that matter for Bindly was “Number of note created by a daily active user in a day”. Bindly is visual notebook app that helps you organize notes by people and place. The more notes created, the more value to the user.
Our initial value hypothesis was this.
People want to take notes to remember things. But they don’t want to use a pen or keyboard. They are using Facebook and camera on the phone anyway. If we can help them convert Facebook and camera into their personal note, it will help them remember.
Bindly was very reactive note taking app by design. Use tools you are already using. We will create notes from them and organize the notes by people and place for you.
We can validate the value hypothesis if “Number of note created by DAU” is at a certain level. For Bindly was featured at Product Hunt, we saw healthy increase in DAU and MAU.
But not many notes were created by users. Not as much as I wanted. It meant value was not delivered to users and DAU would soon decline. So we changed our value hypothesis.
One of the common feedback for the version one is “I don’t know what I can do after installing Bindly”. Well, Bindly was reactive note taking tool. Users do not have to do anything. Just connect Bindly with Facebook, Instagram, Swarm and local folder. Wait for Bindly to capture notes.
But number shows this is not working and we needed to change our value hypothesis.
People want to take notes to remember things. But they don’t want to use a pen or keyboard. Bindly turn camera into a note taking tool so that people don’t use keyboard in small screen.
Bindly did not have so called primary CTA because of its reactive nature. The absence of CTA confused users. So we decided Camera is the primary CTA for Bindly. We just changed the color of camera icon for the latest version. But we will introduce more changes in future updates. We continue measuring and improving the metrics until we validate the value hypothesis for product market fit.
Measuring for development
What we need is working codes not beautiful codes. Maybe it runs slow. Maybe it goes down. Maybe it looks sucks. But it’s OK. We just need to understand how to improve based on scientific data and business priority.
What do we mean by reliability? How fast is fast? What does lookin good mean? Set clear numeric goal. The code base for the first release of Bindly was chaotic. But we used data to improve performance that can impact one metrics that matter “number of note created by DAU”.
Monitoring Tool
Our backend is microservice architecture with Node.js. Sounds great but it was fat slow system that went down too often. It consumed too much memory with leakage. Availability was below 90%.
We believe we need 99% availability. We first needed to reduce memory consumption and memory leakage. We used Trace and our own dashboard with Grafana and monitor memory and CPU.
Static Code Analysis and Profiling Tool
Profiling tools helped us identify area we need to improve for 99% availability. Flame Graph helped us analyse core dump and identify potential memory leakage and area we can reduce memory consumption.
We also used static code analysis tools to reduce complexity and duplications. The tools we use is SonarQube and Infer.
We reduced the memory consumption by 1/3 and achieved 99% availability. Well, the number also shows us how messy our code base was in the beginning. The latest system is about 99.98% availability.
Profiling Frontend (Android)
We knew the launch speed of Bindly was slow. About 7.3 sec to launch. Ouch! The feedback from users were “You are slow”. Yes, we knew it. We were planning to move our architecture to “Offline First”. It will require making front-end and backend from scratch — almost. The launch speed issues will be removed by offline first approach. So launch speed was law priority for us. Again, Bindly was reactive note taking app!
But what if we spend time on implementing offline first without measuring business metrics? We could have spent more time releasing Bindly and we would have leant this lessons much later.
Now Bindly is more proactive note taking app with Camera as primary CTA. Launch speed matters. So we set a goal of 2.0 sec launch time which is faster than Twitter and Snapchat. A bit slower than Instagram and Facebook. Many photo apps are about 1.5 sec. So 2.0 sec is realistic target to start with.
We used Nimbledroid to profile Bindly app. Like Frame Graph on backend. Nimbledroid visualize Bindly profile and helped us identify area we can improve.
Now the launch speed of the latest version 2.0.3 is 1.6 sec. I think this is fast enough for photo related app.
UX
UX is the least priority for the first version. Wow!? Really? Yes, really. We don’t know what defines “good experience” with solid numerical goal in the beginning. Good looking elaborate design need time. For example, we released the first version of share.bind.ly after a month of the first release of Bindly app. You can see how it looks at this point from below.
Does it look good? Not as much as it should be. “Hey, you are designer and this is a crappy design!” Yes, it is and it’s OK. This is 30% MVP release so that we can learn from. We hope we can learn what defines “Good” sharing experience. What make user says “wow”. We need to ship and measure first. Use heatmap and web analytics tool to understand engagement.
