Originally published on Reprime blog.
Here’s the scene —
A small team working out of a room; launches an MVP; gets more than 50k people using the product.
What comes next? Feature requests. Lots of them.
We’ve built a couple of products previously and in pursuit to make something people love, we built everything that our early users requested. Need an option to download an invoice as PDF? There you go. Need a feature to manage business expenses along with the incoming cashflow? There you go, sir. Need us to take your son to school? Yes, sir. That taking-son-to-school never happened exactly but you see the point. To have us do something, you just had to tell us once. We were young. We were the makers. We were yet to evolve into people who could say ‘No’ to someone. We were yet to learn the art of building products.
Before we built our first product, we used to do client projects. Unfortunately, we carried the habit of saying ‘Yes’ with us when building products. Eventually, we learned that in the 101 book of building products, the very first rule is to learn to say ‘No’. The sure shot way of killing your product is to make it do everything for everyone.
After learning the lesson, we tried to apply it on our latest experiment — Reprime.
THREE PROBLEMS
Since the private beta of Reprime, we’ve been getting amazing messages like these.
Making something people love
But along with these, we also started receiving solid constructive feedback to help us build Reprime better.
Things we need to build
Among all these constructive feedback that we got, there were three things that we always had in the “ASAP” list in Trello.
Three Problems
THREE SOLUTIONS
In the first glimpse, it seems there are three different problems and therefore there’ll be three different solutions. We thought so, at least, to be honest.
- Search Solution to first problem was to put all of our data in a full text-search search engine (eg ElasticSearch) and let people search the schedules we maintain using the title and description of the schedule.
- Suggestion Box Solution to second problem was to put a big box on our website where people can put in suggestions on what they want to follow that we currently don’t have.
- Modify relationships between schedules and events: Our proposal to the third problem was to make events belong to more than one schedule. At first, one event belonged to only one schedule. Our idea was to make it able to belong to many schedules. Nothing tricky.
Three problems. Three solutions. All we had to do was work for 80 hours for two weeks and we’d be ready to announce three new things that we built in three different blog posts. I announced to the team — “It’s time we do it.” The whole team nodded. I, too, pulled up my sleeves and sat with a mug of coffee to begin coding.
In the evening, when everyone wrapped up and left for the day, I decided to take a 15-min nap in the office before continuing the work ahead. And like all the good ideas I get in sleep, I got another one.
EARTH IS NOT AT THE CENTER
For half an hour before going to the nap, I read Jacob Bronowski’s “The Ascent Of Man”. In it, I read how people believed Earth to be at the center of the universe. All the heavenly bodies including the sun and the moon, which humans could see, moved across the sky in no fixed pattern.
To keep track of the movements of these throughout the year, people had developed clocks where Earth was depicted at the center of it and there were arms for each heavenly body — the sun, the moon and the planets that we knew about then.
The catch was that the arms didn’t move in circular motion around the around. Each arm had multiple gears that made it move it weird fashion around the center of the clock. People spent years recording the motion of the heavenly bodies and then perfecting the clock. It was a nightmare.
Then, came Nicolaus Copernicus, who said – “Hey, what if we move Sun at the center of the clock and then everything moves in a fixed circular pattern around it, including the Earth.”
Things weren’t smooth for Copernicus to hold and preach the thought of Earth not being at the center of the universe – not just the solar system, but it gave me enough food for the thought.
With this story in my mind, I went to the nap. And I kept asking myself – “What if the solutions to our problems are not hundred different things but just one simple thing that we need to figure out.”
I woke up from the nap and spent the rest of the whole night wondering of a better way to store and manage events. Until then, I was thinking of “schedules” to be center of the architecture and now I moved my focus to “events” being the center of the architecture and “schedules” being just a mechanism to define a collection of events.
Sometimes you’ve to give up your pride and really think what is it around which everything revolves.
KILLING THREE BIRDS WITH ONE STONE
The next day, we came up with a new architecture to think of the events that we are maintaining. Earlier, each of our event belonged to a calendar. Now, each event is defined using a list of labels.
Example: A football match between Team A and Team B is defined using the labels – “sport”, “football”, “team_a” and “team_b”.
And there’s a similar list of labels for each schedule too, i.e. “Schedule for all matches of Team A”. We made a quick script that would produce the potential labels for each of the 100,000 events and 9000 schedules we maintain. Everyone in our team spent a day verifying all those labels and then we imported this labeled data in Algolia.
And we were done. The work that earlier amounted to two 80-work-hour long weeks was reduced down to two days of labeling data. That’s it.
1. Search
Using Algolia and its powerful open source tools, we were able to ship the Explore page on our website with just a couple of hours of development.
For users, it removed the effort of digging into the sea of sub categories to find something. Having something in mind? Just type in.
2. No Suggestion Box
Solution to the second problem came bundled in with the first one. In our Algolia dashboard, we started paying special attention to one report – “queries returning zero results”.
This list worked as proxy for suggestions, that too, without explicitly asking users to suggest something. Everyday we compile this list and start working on collecting the required data.
Looks like, people want something for yoga and dance.
3. Single copy of an event
Now, because our events are not defined using a schedule but by a list of labels, we have removed all the duplicate events and maintain only a single copy of an event. If you want to know the exact architecture of our labels on schedules and events, highlight this sentence to let me know. I’ll be happy to share in followup blog posts.
This change in the architecture also allowed us to offer a few more things to our users in next few days. We are exploiting this architecture of labels to it fullest – till it breaks.
