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

Feedback from one of our users

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

Tasks on the web app
Tasks on the Mobile app

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:

Conversion funnel for Draft Report and Incomplete Expenses

Conversion funnel for Unreported Expenses and Sent Back Reports

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!


  • 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

Abhishek Jain

More of our stories from

Building Products | Requirements & Roadmap planning

Read on to know how we gather requirements, coordinate internally, prioritize, and add them to the roadmap.

How and Why did we build Tasks?

The story of listening to your customers, building quickly and measuring success!

Seeding a Product Org

Here's a breakdown of what to expect when you're joining an early stage product company like Fyle.


All Topics