Hiring assignment - Tooljet

• The tool is used to build internal applications used within a company

• Focus of Tooljet is on internal tools only

• Mostly people(both startup teams and independent contributes) will rely on self hosted Tooljet to build applications. Web browser is probably just to get a overview of the product. Confirmed from Slack channel too.

• Non developers with some knowledge of sql, javascript are able to build their first app within a week - from Byju’s, Emeritus and BFKN case study

• Once a user gets a hang of how to use the platform, the time taken to build apps will also reduce
  
  From Byju’s case study on Blog - ”It just took 5-7 days for them to build the first use-case, and later it took just 1-2 days to build other applications depending on the usage. Other than developer cost, there was no additional cost or additional risk associated with it.”
  

• Each user session logs out by default after 10 days

Assumptions taken:

• Assuming startups as existing users looking for adoption (asked Pankhuri)

• No usage data is being tracked for self hosted Tooljet. Assuming teams will disable the ‘ENABLE_TRACKING’ flag in most cases.

• Percentage of people who opt for paid plans - 5% (asked Pankhuri)

• Assuming a company has set USER_SESSION_EXPIRY = 1440, i.e one day session expiry, so that a member has to login every day at the start of work

• Also assuming a team would want to stay up to date with the latest version of Tooljet builder and would have set the flag CHECK_FOR_UPDATES to true

You are charged with increasing the adoption of ToolJet.

1. What would be your north star metric? What data point will prove that adoption has
   actually increased?
   

2. What other data points would you track daily/weekly/monthly and why?

3. What is the overall timeframe of this study?
   
   

After doing some analysis, you realised that 95% of users are not sticking to the
platform just after 3 weeks of working on it. What would you do? Please come up with a few
hypotheses and possible solutions.

From our assumptions, we know only 5% users are on paid plans and also lets assume its a monthly billed subscription, because people would probably want to try Tooljet apps within their teams before switching to a yearly subscription. Also with the amount invested and support provided, they might not want to drop before the monthly cycle ends.


Hence it’s safe to assume that the 95% drop off are of the unpaid plan customers.

Now I cannot do a traditional funnel analysis because from my assumptions, no usage data is collected on self hosted Tooljet.

So the user segments that leave the platform are then:

1. Startup teams on unpaid plans:
   1. App developers:
      
      Hypothesis:
      
      App developers might be leaving due to limitations in unpaid plans or because the tools that they want to build are highly complex and customisation for those complex tasks may involve a lot of head scratching.
      
      
      
      Solution:
      
      In case of users leaving due to unpaid plan, we can provide them a free 14 day trial of paid version. A paid plan will provide enhanced features like unlimited tables on Tooljet db or workflows or even copilot later on. A dedicated customer support team that comes with the paid plan can also help them solve for complex tasks and help them setup their application end to end. The first app hiccup will then be resolved and the builders can take learnings from this to build further apps. Tracking app building time from here onwards can also hint if the developers have become comfortable with building apps on our platform, ideally the time to build should decrease from the first app.
      
      A summary of resolved issues for each organisation can also be provided after the trial, which can serve as their
      custom documentation for further reference.
   2. End users
      
      Hypothesis:
      
      End users leaving after 3 week means that - 1) Having end users come to the platform in the first place means that the developers were successful in creating the application and rolled it out to end users for testing 2) Leaving the app during testing phase by end users can be because of multiple reasons:
      1. The UX is different that what they were used to in previous internal application and thus they are having a hard time to adapt to a new UX, and thus went back to using the previous internal application
         
         
         Solution: We can put up guidelines in the documentation in a separate section like ‘Things to remember while replicating existing internal apps” so that the builders are aware of the consequent problems that can occur if the UX suddenly changes for end users. Not a lot of people think about UX of the end user of internal apps
      2. While testing out internal tools built with Tooljet, I think it is safe to assume that the builders might not stop the existing internal services and run the Tooljet build internal services on a different url as a different service. It could be that the end users out of habit, fall back to going back to previous tool’s url
         
         
         Solution: Check with the builder team of the organisation once the drop is observed, if the end users are accessing the right application.
         
         

2. Open source contributors on unpaid plans
   1. Beginners
      
      Hypothesis:
      
      Setting up the builder locally and then setting up the integrations might get frustrating.
      
      From slack channel I could find people having trouble setting up Tooljet on their servers and on further looking at filtered messages posted by the ones having trouble, that was their last interaction on the channel. It indicates that the setup might be a major hiccup in the user journey and can cause drop off.
      
      
      Solution:
      
      Add more tutorials on Youtube channel for self hosting. There is one right now which is on Heroku, but from slack, Docker seemed like a choice among people. So having one on Docker might help.
      
      Also integrations need some work outside the Tooljet space too, like getting credentials, or getting a table id of a Notion database, etc. Having an end to end video tutorial of integrations including getting API credentials from other sites might be helpful for beginners.
      
      A channel just to get community support from each other might also be helpful. Right now there is just one general channel which includes the Tooljet team and people might shy away from asking
      dumb questions. Having a separate channel, just for the peer learning can help take away that inhibition.
      
      
   2. Seasoned
      
      Hypothesis:
      
      Stopping to contribute to the project by a contributor can be due to multiple reasons:
      1. Long review cycles:
         
         Solution: Beyond a threshold cap of a decided number of days within the team, lets say 30 days, the maintenance team should be reminded of the open pull requests and asked to review them once. An intimidation through comment or slack could then be provided to the contributed in case more time would still be needed to review their pull requests. This way the contributors will feel acknowledged.
      2. Lack of recognition:
         
         Solution: We can have an internal tool for Tooljet itself - a leaderboard for contributors