How and Why did we build Tasks?
How and Why did we build Tasks?
I am Abhishek, the Director of Engineering at Fyle. I joined Fyle ~6 years ago and this is my first blog post (I know, long time)
At Fyle we're very obsessed about being customer first and everything we do revolves around that motto.
We pivoted our product to cater to the US market recently and I had a nagging feeling that the first time users of our product were finding it difficult to figure out the easiest and fastest way to be done with their expenses (Who wants to spend time doing this right? :P)
Lo and behold, this is exactly where my team and I were 6 months ago, we had a bunch of users complain like
After analysing the feedback and a bunch of tickets we came to the conclusion that these fall into two different buckets, like the below ones
I didn’t know my expense was incomplete
I didn’t know I had to submit an expense report
The right way of solving this would be to have a proper document with various stages like
Customer Research
Defining the problem statement and requirements
Low and High Fidelity Designs
Beta Release
General Availability
Even though the above process is how we generally build things at Fyle, I wanted us to deliver something in a week's time. Sometimes like they say just go with your gut
We decided to build a very rudimentary version or as they say in the startup language, a POC
We name our feature, Tasks - things that the user needs to take care of
@Aiyush the awesome engineer he is (now Engineering Manager), pulled off the entire feature in a week for the web app and in another week for the mobile app.
Here's what he pulled off in a week's time
We were hoping some good usage and conversion numbers, but were astounded to see the usefulness of this.
Some of our Mixpanel reports with respect to usage metrics:
After the feature went live, we ended up dropping one of the initiatives called Help users to complete expenses, why you ask? Because it wasn't needed anymore, we saw the complaints regarding incomplete expense go away!
Learnings
Always listen to your customers and understand what they need and not what they want
Try to build a solution quickly and put it out in the wild
Always track usage and understand how users use your feature
Iterate based on the usage metrics