###Question###
Describe the most significant/impactful continuous improvement project that you have led? (What was the catalyst to this change and how did you go about it?
###Answer###
This is about Griggi, a side project I & my partner have been working on since Mid 2015 . The motivation behind the project came to me when I use to travel to my hometown & the lack of broadband in my home made me think if I could haved used the WiFi of my neighbour in an abuse free way & without the hassle of disturbing them / asking them the WiFi password
The project looked like Uber for WiFi sharing where anybody with a broadband could share their WiFi with people nearby either for a cost or for free but in an abuse-free manner so that their own usage does not get affected.
We have to validate if the proposition is good enough for people in terms of adoption. I put together a nice website tricking users to believe that the product is live & clicks on 'call to action' button will help us decide the interest level. For user acquisition, I put this as Hacker News post & it drove around 10k users on the site.
We have some valuable learning which is documented on this Yourstory blog post . In short, the idea is not good enough for people to adopt it as the offering has chicken & egg network problem. Why would I share my WiFi if there are no takers for it. Also, if there is slim chance of finding Griggi shared WiFi, the recallability is pretty low.
We came back to drawing board thinking of a different way to acquire customers. We pivoted to targeting people who
- Have pressing need to share their WiFi with unknown people
- Are largely under-served
We figured cafe owners are one such audience. We interviewed a few cafe owners who said since they have no control over who is using how much data, they run the risk of exhausting their internet FUP limit & hence wary of exposing WiFi to unknown people. This looked like a sweet spot that we could target.
We had not ditched our original model yet. The strategy was - while cafes have a pain point that we are solving, they eventually help us acquire customers as anybody using WiFi at their location is eventually signing up on Griggi. The hypothesis was - we should be able to educate & convert these guys to try Griggi at their homes.
Now that we have our first set of customers, we started to build the product. My partner took over the tech part (this is the way we did division of labor between us). Largely, the product needed following features
- Identifying users & their devices through a unique value like his phone number.
- Letting WiFi owner actively or passively control how much data an identified user could use. Plus create ways to change this setting overall or at user level.
- User's internet should stop once his quota is over.
We figured there are two possible tech implementation
-
Make the router smarter to have the information of the user as all data goes through the router & configuration could stay on it.
-
Give control to WiFi admin & users through mobile apps where the user mobile app communicate to the mobile app of the WiFi admin as they are on same WiFi. A tech similar to what Chromecast deploys.
The selection criteria was - how soon can we deploy the chosen solution. This required open source availability &/or our domain expertise in the chosen area (mobile apps versus router firmware development).
For point 1, my partner figured there are open source WiFi hotspot solutions that we can pick & modify for our need. Such a solution required an open source router OS like DDWrt, Gargoyle, Openwrt etc as the base firmware. The issue with the approach is - a particular OS has only a limited set of router hardware support which limited our user base. Also, the onboarding becomes difficult as now user has to flash the open source firmware on his router or buy a supported router from us.
The mobile app path as per point 2 looked easier as per user acquisition, but the most prominent issue with it was the significantly complex tech. This was not a run-of-a-mill mobile app development project. Also, our target audience (cafe owners) needed a strict control on the data usage which can be more effectively controlled from the router. It is core to what we are building. So we traded better & easier to develop solution off against large user base.
Now that we had chosen to go the router way, the next step was the architecture decision. We chose a client-server architecture where the client resided on the router & continuously talked to server for decision making. All configuration related to users & their data stayed on the server. This let us keep the client thin & hence we were able to deploy the solution on a router as cheap as Rs 800 .
Going lean on router was an important product decision as in the long term, we have to support cheap routers for our target audience who are normal users looking to set this up in their house. Also, cafe owners did not look too willing to spend a lot of money on router/solution, so this looked like a good short-term decision too. Also, all data on the server enabled us to let the WiFi owner have his dashboard accessible from outside the Griggi WiFi location, which also became a welcome feature.
This model to target cafe owners faced following challenges
- building features that are not fit in the long term model - cafe owners needed a lot of features that looked tangential to us in our long term goal.
- funded player i2e1 poached some of our customers - i2e1 is expanding heavily with an already launched product & a heavy biz-dev workforce. While a good amount of effort was spent acquiring customers, the RoI did not look that promising as we are loosing them fast too.
The marking on the wall was clear - we had to find a new target segment.
Our core feature was - data accounting at user level. This feature created interest among small corporates & co-working spaces. Unlike big corporates who have leased line internet, these places are using a data limited internet connection (also called FUP) so it becomes imperative for them to divide & pass on their data limit to their users, ensuring their FUP does not get over.
Incidentally, we have been building features that aligned with the above target audience, although we had started to build them for a different reason altogether. Most notable of these was - getting rid of login page everytime you walk in to Griggi WiFi. The device OS detects hotspot & show up the login page. This feature is present in the latest OS versions but old Windows & Linux machines do not have it. As a reason, these users dont get the login page & since they can not login, their internet never starts. There is an alternative way to go to a non-https site which eventually redirects to the login page, but most users are unaware of this hack.
We had spent significant energy on getting rid of this login page & it so turned out that this aligned with the corporate & coworking users. They did not want to be bothered with login every time they enter their office location. This particular feature is the most impactful feature we built in Griggi. So I am going to detail more on the implementation aspects.
Traditionally, user identification at corporates is done through a WPA Enterprise encryption that requires you to enter username & password both while you connect to WiFi . So on every connection to the WiFi, the WiFi client takes care of the authentication part.
While corporates do authentication through WAP encryption, we were doing it through a hotspot mechanism. This mechanism has advantage over the former, as it takes care of user creation part as well. A user is identified by his phone number which he has entered during the login process. Neither cafes, nor small corporates/co-workings have luxury to have their own user database management system. So this works well for them.
While our approach has advantages, the repeat login page was a pain. We evaluated following options to get rid of it while keeping the user creation advantage in following ways
-
Bundle WAP encryption alongside Griggi. Have 2 WiFi SSID - one open to which a user connects, create his account & once done, connect to the WAP encrypted one to stay connected in an un-interrupted way.
-
Figure out a way if we could make the login process seamless on repeat visit on the same Griggi WiFi.
We decided to explore point 2 more as it meant accruing less technical debt & keeping our router lean.
We did some changes like putting a username password creation page post OTP to get away with 'waiting for OTP' hassle everytime, use 'Remember Me' feature which autofill the username password for the user on the login page etc. I realized that these changes are incremental & we are largely trying to fit into the features provided by the softwares we are using.
At this moment, I paused, went back to the starting point & started to work on completely different approach. Below steps summarize my effort
-
The Griggi server side code is using cookie for the 'Remember Me' feature. I changed that to use the mac address of the device. The motivation for this change was different as on OS X device, the login popup browser does not store cookies & hence the autofilling was not working.
-
I hacked into the DHCP server code & changed it to call the login url on behalf of the client through Wget whenever a new client connected. The DHCP server gets the mac address of the client & eventually assigns the IP address. Both of these are needed in the login url so DHCP server looked the right place to hack into. DHCP server held passing the IP address back to the client till the login process gets completed & the client is logged in.
With the change in point 2, now users did not see any login screen on a device that has already been identified (the user has executed the login on the device once before). This is a very unique way in which I solved this problem. We should probably patent this but I am not sure about that.
The above change is impactful as it now made Griggi as one stop solution for all the WiFi sharing needs - be it cafe, hotel, small corporates or coworking. At some point, we decided to let go of our original vision of being Uber for WiFi. The current vision is to be Whatsapp for WiFi where anybody who has to share their WiFi with more than 5 users should be able to setup Griggi & have a better & cost effective control on his WiFi & internet.
Having made Griggi powerful, the change did come with its own set of issues. The latest OS X version start differentiating between hotspot & normal WiFi & has tendency to switch over to mobile data when screen locks in some mysterious situation. There is a work around for this but this requires user input. We are still trying to sort this out.