What do users want?
Ok, so this was a rather vague question I asked myself when we were coming back from Mandai.
Instead of coming up with a solution, now we had to find a better problem to solve.
We also had to meet Colin the day after so we decided to shift our target audience to students, whose problems we knew better.
Initially the group were discussing about an idea for attendance taking, but that problem was already solved, when we spoke to Colin about it. Also the problem was that the target audience was too small, also the advantage of the teams doing games was that the target audience is already large if they can do a decent job.
So while we were discussing with Colin about shifting our end-users to be students instead of VWOs he suggested continuing on with the volunteering jobs idea but doing part time jobs instead. I then remembered that IVLE Student events were going to be closed down in DEC 2016, and that a lot of requests for student helpers and participants in paid experiments were listed there.
Seeing that there was (or was going to be) an unmet need we shifted our ideas to tracking ad-hoc and part-time jobs instead. Fortunately for us we had already built the backbone of the app, so we could change it without much trouble/ wasted work, and we could present the staging version of the website for the progress report 2.
So the way we answered the question was to look at what was lacking currently, afterall the need was already validated for us, all we had to do was build a better version of it. To put it more abstractly, Timing.
This also reminds me of a TED video on the single reason why startups succeed, which also argues that ‘timing’ is the reason for the success of startups. Personally I thought it was too safe a statement to make, as although generally speaking the ‘timing’ would makes sense on hindsight, every situation is different and the specific conditions that one looks out varies widely. In our case the change was specific to IVLE and ad-hoc jobs on campus. But still, I thought it was apt that one had to be opportunistic to exploit changes in the landscape, either situational or technical that tended to have better results.
Listening & Pivoting
So, one thing that future batches of CS3216 students can learn from my team is that talking to your users is key. My previous blog post was listening to feedback. But all these people we talked to were not our end-users. For many apps, the users are it’s currency. And at the time of the previous post we had talked to exactly none.
The problem is that while the feedback may be great to hear, it wasn’t strong enough for us to change direction. On hindsight, we should have went straight to VWOs instead of linking ourselves up with people who knew VWOs and volunteers. That was exactly what we did around 4 weeks before STePS, when we went down to St. Joseph’s Home in Mandai(!), and talked to Geraldine, their volunteer manager.
We found out that the needs of the VWOs were more than we could accomplish in a month. It wasn’t just tracking but a whole host of other interconnected problems, from before volunteering begins, when they recruit volunteers and screen them, to after volunteering when they want to engage them. Verifying volunteers’ attendance at first seemed like a well-defined problem, but after speaking to Geraldine we realised that most volunteers don’t actually have the level of incentive that we had envisioned, and even if we could solve, that there just was not much demand.
There is a saying by Paul Graham that
“A startup founder should be writing code and talking to users. That’s it.”
We got the writing code part down, but again it was talking to users that was the missing link.
In hindsight, maybe it was just easier not to talk to the users, I think the mentality that we as programmers (or at least I) have is that “talk is cheap” and I would rather someone just “show me the code”, which I still think is true. If only I could have convinced my past self that while that is true in programming iteslf, building a product isn’t the same thing. Other people are involved in the creation, the main and maybe only important group being users, and understanding their needs is the core of whether that creation has a reason to exist.
Building & Growing
From IVLE student events, we manually filtered through the paid surveys and research opportunities. We added them to our site, but at the same time emailed each of the researchers that we had done so, and when there were interviews we emailed them the interested participants.
We had also emailed Anthony unknowingly from the previous CS3216 batch as he was managing the IVLE announcments as part of NUSSU CommIT, and he even advised us to learn from AirBnB’s growth hacking tactics. We didn’t have a craigslist to take users from but IVLE student events was a good starting point.
Some of the emails that Xu Jie sent out did not get any replies, but a few replied enthusiastically, even commending us that they had built something better than IVLE. Well, that was definitely encouraging, we could also use it in our STePS poster.
We also managed to get an event posted in IVLE!
Other things we did were also to go down to the paid studies themselves and advertise to the participants as well as researchers. Research studies were our main user base as they had an urgent need for their FYP research interviews and surveys especially from the Psychology department, and IVLE student events would be unavailable in December.
Within around 3 days we had around a hundred users, I’d say it went ok, and things were (finally) looking better (even great) for our team.
We also talked to OSA, who initially agreed to help us send an email blast, but at the last minute told us that they were not allowed to due to no clearance, which was kind of expected. But at least they helped us share it on their facebook page, which also helped our marketing.