Here are two important principles in managing a startup company:
- Building a high-quality product with value in the shortest time possible, in order to bring it to the market ASAP.
- Prioritizing the use of existing tools rather than trying to reinvent the wheel.
These two principles seem to contradict our decision at Oribi to develop quite a few internal tools.
So why did we decide to invest in developing tools that are not an integral part of our main product?
One topic I plan to address extensively in this blog is the work-life balance. I believe that startups which part of their culture is to work into the night on a daily basis, do not necessarily progress any faster than ‘calm’ startups (on the contrary – they almost never do). I believe that a constant pressure in startups is mainly indicative of a lack of focus and suggests that working methods are not effective enough. This is one of the main issues I’ve been focusing on recently – how to work smarter and more efficient.
A choice I’ve made, which has already been proven successful, is that any project which requires less than a week to develop, and which ‘compensates’ for the time invested after two-three months, is launched.
This is a list of five tools developed in the past few weeks, which required between two days and one week (of one developer) and immediately saved hours of cumbersome manual work.
Kob – Slack Integration with our DB
Handling many DB queries doesn’t only take too much time but is also a barrier for the non-R&D team members (product, marketing, CS) for accessing important data easily. For example, when processing questions from users or trying to understand a problem reported by a user, we had to run various queries in order to understand how many times the user has signed in to Oribi, how many accounts they have, etc. We did make a list of repeating queries, but the process of logging in to the DB and synchronizing the queries between team members was time-consuming. Another thing that had made this process so unproductive was the DB’s inaccessibility from a mobile phone, which in some cases delayed replies to users or finding bugs. Kob (all Oribi’s internal projects are named after antelope species) is a Slack channel querying the DB. The first, most basic question we set for Kob was:
Who is [user name]?
This enables us to immediately access all the information required to provide support from any device. Other planned questions relate to events on a certain day (what happened on 1.7.16), user lists according to different parameters, etc. We are ‘talking’ with Kob dozens of times each day, and it also makes life much easier for less tech-oriented team members, who can easily access the information without having to learn how to work with the DB.
Development time: two days.
Dik Dik – Tracking API changes in 3rd party tools
We are presently working extensively with Facebook’s API and will start working with the APIs of other tools in the near future. One of the common problems in intensive work with various APIs is the frequent changes: setting changes that could lead to malfunctions in our product or additions and changes that should be incorporated as soon as possible. The primary problem we have encountered is that most companies inform about major API changes only, while numerous small changes are made daily, some of which are vital for us to know about. We have developed a tool that scans all documentation in certain root directories and reports on pages that have been changed and on new pages that have been added. We receive a daily email summarizing all changes and an ‘abstract’ from the page which allows us to understand whether anything has changed simply by skimming the email. In building Dik Dik, we used this code package: www.crummy.com/software/BeautifulSoup and Git to compare the different files.
Development time: one week.
Impala – Live UI tests
A problem in UI testing is dealing with all the types of values and situations each component might handle. While it is relatively easy to run tests on various browsers, devices, resolutions, etc., a main obstacle is application input (for example, different text lengths, languages, number and currency types). Impala is defined as a ‘component playground’ and plays two key roles:
- A centralized location displaying all UI components (from a checkbox to complex menus), enabling us to easily identify what can be ‘reused’ and how to make new components more efficient, based on older ones.
- A tool that ‘injects’ any input type to the component. It is possible to edit the code inside the tool itself and input any set of values you choose. To a large extent, this tool parallels the Chrome developer tools; while the latter makes it possible to change element colors/fonts/locations, Impala enables a dynamic change of values. Impala is based on stack.formidable.com/component-playground.
Development time: two days.
Dashboard
I believe that a dashboard is one of the first tools any company should develop. While it is possible to simply update data using Google Docs early on, I think that in principle it’s crucial to have a concept of accurate measurement, setting clear goals, and concentrating it all in one place. You are welcome to read more about this in my post on dashboards in startup companies. It is definitely better to use an existing tool, rather than develop a new one from scratch. Yet we had encountered a problem: all the dashboard tools we had examined rely on utilizing data from another source and did not provide an answer for features which do not involve displaying existing data. For example, creating a list of all of the company’s milestones or monthly and weekly task lists. I chose to display the following components on Oribi’s dashboard:
- A list of goals for the current month and the next week. For me, this is the most important part of the dashboard. A key problem in startups is the lack of focus. Many startups die out after failing to focus on a specific problem and ‘spreading out’ in different directions. I personally define what will be my main focus each month and try to devote at least 80% of my time to this goal. Making these goals clear to the team is crucial and helps make faster progress and prioritizing easier. The dashboard we have developed has no more than five monthly and five weekly goals. I am considering reducing the number of goals to three soon in order to provide the team (and myself) with an even greater focus.
- Keeping track of key parameters – the number of users, the number of returning users, and the percentage using key features. We currently display six parameters. A problem with dashboards is that you tend to add more and more parameters until it becomes unclear what is and what isn’t important. I would like to limit the number of key parameters being monitored to five and remove some ‘feel good’ parameters. For example, we currently display the sum of expenses in all the accounts we have analyzed. It is certainly nice to see a sum of hundreds of millions of dollars that is constantly going up but it is not really indicative of the product’s quality.
- Milestones – a kind of a long log to which every team member can add a company ‘milestone’. These milestones could include a new employee joining the team, completing a feature, changing technical infrastructure or business milestones. Any milestone is legitimate and no milestone is too small. When a team member adds a new milestone, the dashboard is replaced with a particularly happy animated gif (one is randomly chosen out of several dozen options) to celebrate the occasion.
- Traffic – tracking the daily and the monthly number of visitors to the different sites. Based on a basic integration with Google Analytics.
- Details of new users – who were the new users added today? Where did they come from? What company are they from? This component is mainly aimed at helping the entire team connect with our users and get a sense of the people working with the product we are developing.
Development time: one week.
Debug mode
Reducing the time required to detect and check bugs is crucial in all application stages. We invest a great deal of time analyzing the issues reported by users, understanding what they meant and mainly reproducing the problem. Obviously, we usually need to reproduce the problem while the clock is ticking. Both in Takipi, the previous company I was a partner in, and in Oribi, we developed a ‘debug mode’ early on. It enables us to log in to the application as one of the users and attempt to reproduce this bug. The tricky part is to build a tool that enables us to log in as a user without revealing the user’s private data. The debug mode does not return fields including sensitive information but still enables us to detect and recreate most problems.
Development time: three days.