Before we got started with PriceBaba, both me and Tirthesh had almost zero experience of building a product. We are passionate about Internet and web services that create an impact. Building PriceBaba over the past two years has been a learning experience and we have been blessed to have some amazing friends who have guided us throughout the process. Here are a few learnings (while we still continue to learn and grow):
Developers cannot build in silos
To create a great product, it is great to hear feedback from the horse’s mouth. That is why our developers have a lot of interaction with our users directly. The best way to raise the product quality is to let your developers see the product in use.
We have also benefited by having the operations and dev teams sit next to each other. There is constant flow of feedback and developers accordingly iterate and prioritise their roadmap. All incoming user feedback is shared with the developers and content teams, thus everyone has sufficiently enough data points when debating new features and upgrades.
People don’t listen, keep repeating, keep listening
We often assume that communicating something once is enough to make the point. However a learning with PriceBaba has been that we need to recreate the importance of an approach repeatedly!
For example, most of our team has grown up using desktops. Especially developers who have also had pro systems with large screens and keyboards to work on. Thinking that mobile is the medium that majority of our users operate from isn’t a natural thought. Our thinking begins from a large screen while mobile remains an ‘optimisation’ task. It has taken a lot of unlearning and relearning for our team to adapt the thought of mobile first. Any new feature or interface has to be thought for mobile and tablet just as much as for desktop.
I relentlessly share our mobile usage numbers, industry reports and keep mentioning MOBILE as a keyword to my developers. They are listening and building a great mobile interface for PriceBaba 🙂
Mobile Mobile Mobile, but not Mobile App, Yet
While I already mentioned how important mobile is, we have often been tempted to build a mobile app. However we have consciously stuck to mobile web for several reasons.
Our product offering isn’t something that a user wants to use daily. In its current form, building an app would lead to very low repeat users and uninstalls. The way the app business works is that you get ‘x’ thousand downloads and a fraction of those would be active users. For an app like Zomato or Paytm this makes a lot of sense as repeat usage is very high; we love using them on a regular basis. But we need to evolve the value proposition of PriceBaba much more before we release an app.
Development resource is another big reason! While mobile is growing, mobile web is serving most use cases just fine. An app is good to show off on your resume, but not the need of the day in many scenarios (like ours). We like to focus our developer resources on the most crucial things first.
Manual first, Automate second
PriceBaba isn’t a usual technology startup. A large part of our work is to integrate offline retail with the internet. A lot of operations, back office and systems to manage the same has been built over the last two years.
Almost always we have begun our ground operations with manual work and then work towards automating them slowly. Doing things manually has allowed us to iterate quickly, learn more about our customers before making solutions and eventually prevent wasting development time.
We have realised that trying to automate things either before hitting a critical mass or a ceiling isn’t always a good idea. While we have made our mistakes of building things too early, for PriceBaba it has mostly worked better to do things manually and then automate once we have a better understanding of the landscape we operate in. Depending on the situation, you may well need to build systems in advance but do ask yourself if you can do better if it’s delay it a little.
Every feedback is not a new product feature
This is fairly simple and straightforward. Once you are out in the market there is a plethora of feedback that comes to you. Every single day users tell us what new features they want, experts suggest new cool stuff that we can do and our team brainstorms world-changing ideas while sipping tea every other day.
After a few cycles of jumping to every new cool looking feature and trying to develop it, we learnt that unless something is a really pressing need or would add significantly great value to our users, we shouldn’t launch it. That meant saying ‘no’ to adding new product categories, product reviews and some more features that are too early for us right now. We instead chose to focus on local prices and store locations; which is our key value proposition and narrowed down our focus on a single category that we could dominate.
We keenly listen to every feedback that comes our way, we note it, discuss it to death, but we don’t build it right away :). We have in fact removed a major feature few months back that we felt was half baked, needed lot of maintenance and served a very small fraction of our user base. This may sound cliche, but we are starting to learn how to say ‘NO’ to a lot of great sounding ideas.
Fake it, till you make it + an alternate to AB tests
This one is my favourites and we love doing it from time to time — adding fake buttons to our site. A simple way of testing if a new feature is worth adding to the site, we add a fake button on the site and measure how many people clicked it. It is a quick and dirty way to get a feeler of what will click with our users.
For a long time we had a fake ‘set price alert’ button on PriceBaba’s product pages. The same captured email IDs but sent them no alerts, for we had no backend built for that purpose. When we started to see significantly enough email IDs being entered everyday, we built and delivered that feature. We went an extra mile and added a SMS alert feature along with it. Today the SMS alerts are the most popular user interaction on the site.
We have often been suggested to do AB tests and we would eventually start doing that. However in early days when the user base is very small, we do a A>B>C test. We change a particular product attribute, measure user interaction and change it further if the results aren’t great. Most startups can afford to do that in the early days and move faster with their product.
Speed Is Crucial
We have learnt first-hand that speeding up your application can greatly improve usage. Earlier this year we saw a 25% spike in traffic overnight by just moving to a better hosting provider. On another occasion, removing a 300ms delay in our search’s auto suggestions saw a 60% increase in the number of searches by our users. While we wouldn’t claim to be the best in optimising for speed, a good part of our time has gone into learning and implementing ways to accelerate our page load speeds, thus improving user experience.
Disclaimer: My experiences are from building a consumer facing Internet product.
Guest Post by Annkur P Agarwal a retailer turned technology blogger who got bitten by the product bug recently. PriceBaba.com is a shopping research engine that helps consumers connect with small retailers. You can connect with him on twitter @annkur.
