In this #PNHangout, we spoke to Vipin Agarwal, who is the co-founder of enMarkit and an ex-VC turned entrepreneur, about his journey in conceptualizing the product, his team, the tools and the product management philosophy and what a typical day in his life looks like!
Enmarkit comes from a combination of the words: ENabling and MARKETing. We offer product based solutions to merchants who want to start selling online without these merchants spending too much time or money on creating their websites or struggling to deal with outsourcing agencies. We offer simple plug and play solutions to the entire eco-system of companies, SME’s and entrepreneurs using a SaaS model.
We have two live products –
Besides these, we have a couple of products under development that would, we believe, go a long way to revolutionize the online commerce ecosystem even further.
As a venture capitalist I was exploring bottlenecks that entrepreneurs and companies faced in the online transaction space and in the midst of trying to find technology enabled solutions that could solve this I had met Ekta, who was the Amazon head for market places in India. It took about 6 months of back and forth conversation with Ekta before we started. Finally we chose to tackle the online transactions space head on.
We took inspiration from the user behaviour when a person shops for something from a mom-and-pop store. We realised that the entire product discovery, transaction conclusion and post-transaction behaviour of a person in real world is not reflected in the current transaction models of websites today. Buying is inherently a social phenomenon – and yet Social Commerce has distinctly been untouched in all e-commerce business models today.
In my current role I interact with multiple teams and different kinds of customers to bring our product to life. Although I do not have a background in coding, I do have a very strong opinion of the product features that come over from the use case scenarios laid out by interacting with our customers.
With feature additions we constantly communicate with the registered merchants on our platform to get an idea of what their requirements maybe. We usually break our customer demands into two buckets, soft and hard. Soft requirements are minor changes which can be made in our user interface, which improve the user experience and aesthetics of the product. With hard requirements, that are more complex and require a larger change in the product itself, we consult with the front end and back end teams to ensure the changes roll out smoothly, these could be issues such as improving load times, etc.
It’s interesting to note that some of the biggest critics we have for the product are the internal team-members! Pitching an idea and getting a go ahead is one of the biggest hurdles our product has to cross even before we even start the test marketing campaigns. The benchmarks set by our team are very high and that reflects in our products as well.
I had personally made over 2000 cold calls, talking to merchants and demonstrating a prototype to target customers before going whole hog on product development. Even though our product was in its early stages, we received tons of feedback from our users. Out of the 800-900 people I personally met, almost 70 people had actually committed to using our product after it would be ready. Once we knew that we had their support, this encouraged me to continue building the product further. After adding the social commerce features in our future iterations the market for us grew larger.
EnMarkit started off as a social commerce platform which was built with direct contact to our customers. How we ensured continuity and evolution of the product and teams was by not throwing all the features on day 1. We request for a feature, build it, get some feedback and if it does not work as planned, we junk it. It was this type of ladder approach that has allowed us to build our portfolio of products.
Our product development philosophy has always been to build, evaluate and either junk or deploy the feature depending on the feedback we receive. Some-times junking the product affects the team morale, as the team may have spent time and energy building it. The solution I’ve found to this is to make the team understand that even though the work was great, the market wasn’t ready a feature like this.
There are various teams that work on various parts of the same problem, so it’s usually my role to maintain these interactions between the teams and keep the teams in synergy. Team management internally is always a challenge.
I keep a Gantt chart with me to keep a track of the timelines of the proposed and actual build times and ensure that is matched by the team. I also ensure that if a task is a road-block for another task, that timelines are maintained so that there isn’t a delay.
Some of the tools I do this with are Trello(for project management) and although very basic we use Google Docs and Excel sheets track progress.
Before, I get to work, I usually allocate a little bit of time every morning to catching up on the latest news even before I leave for the office.
After reaching work, I allocate some time every morning for catch up meetings with my team. We evaluate the work we will do today and how the backlog looks like.
Around lunch time, we usually take a little a little longer break of 45 mins. We usually discuss all the industry news between the team.
Post lunch, I usually allocate a couple of hours to talk to our customers.
Towards the end of the day is when I sit with the many teams again, often getting into a detailed conversation of the progress made today.
Since it’s just the first year of our product, we do spend a considerable amount of time in firefighting. I usually plan for the future with my co-founder Ekta to evaluate the roadmap of our product and what should be communicated with the rest of the team.
Where Ekta and I help each other out, is that I work as a product manager/salesman with a lot of ideas and demands for feature requests and Ekta is usually adept at giving me an idea of the challenges that we may face in implementing these features, and also the estimated time it may take for the team to do it. By the end of this meeting, we usually end up with a list of tasks in terms of priority that can be handed over to the teams.
I think product management philosophies vary from company to company, and I would suggest each product manager to use tools, styles that suit his/her personality. There’s no one mantra that fits all. The longer plan is balancing the requirements of the customers and the capabilities of the team.
Every member of the product team is important. To succeed, a company must design, build, test and market the product effectively. That said, there is one role that is absolutely crucial to producing a good product, yet it is often the most misunderstood and underutilized of all the roles. This is the role of the product manager. #PNHangout is an ongoing series where we talk to Product Managers from various companies to understand what drives them, the tools they use, the products they work on, how they go about their day and the role they play in defining the products success.
If you have any feedback or questions that you would like answered in this series feel free to tweet to me: @akashj