Akshay Deo

Akshay wrote his first code for a construction company at the age of fourteen; his favourite toy in his childhood had been his father’s precious Intel 286. At twenty-three, he built a product that raised seed funding and was later acqui-hired by one of the top five global ad-tech companies; and presently works as a Staff Engineer at Slack.

He has passionately built more than ten products over the years, idea after idea through a journey of rewards, failures and realisations. He also contributes to the industry by mentoring start-ups in technology under an after-hours, self-initiated program called – Alpha Master.

My increasing interest in the nature of digital businesses made me seek a ground zero perspective on technology from him.

Notes for start-ups from our conversation –

Serve a niche

“Identify a small problem or a need gap,” he urges. “Begin with developing a simplifying solution that addresses this need gap. And if you have a big product idea, break it down into multiple solution-oriented stages and launch it part by part. This optimises output.”

He thinks that some start-ups spend too much time building an elaborate ecosystem that is not required at the beginning and advises against this beating around the bush. Besides, he believes in the healthy maturity technology has arrived at today and the opportunities it creates.

“Start with a basic framework. Build over what already exists. Build an extension to begin with!” he exclaims, driving home the point that creating solutions with a cost benefit analysis matters more than how one did it. Once the product is validated with enough early adopters or a community, you can invest and begin to create the then much needed ecosystem to further scale up.”

Inspired by Pieter Levels, Akshay has started a side project called 12x12. The aim is to build and launch products in quick iterations, one product per month (built in four days) for a year. At the end of 12x12, he will shortlist two or three products that display high user engagement and develop them further.

For parallel B2B projects – avoid the critical path

“And if you’re experimenting with many ideas (self-initiated side projects) with a focus on B2B, ensure that the product functionality itself is of secondary usage and not on the critical path of the user,” advises Akshay.

“Very few businesses would trust a single or two-people team, moonlighting a product for their critical needs. Recognising this, allows you to keep creating and to even have a consistent user base. It leaves enough room for user feedback and improvements done only in intervals when time permits. If the idea clicks and there’s scope for growth, you can then plan to develop the infrastructure and the team it demands.” 

This insight came to Akshay when he built and tried selling Viwr, a software that detects Android app performances for businesses.

Keep no two unknowns

It often seems exciting to work with new ideas and strive to work with new technology, simultaneously. “We all tend to do that at the beginning,” he warns and urges one to avoid this rather amateur approach. “If you’re building a boring product (read – a product similar to one that commonly exists, for example, a social network) use exciting technology and if you’re building an exciting product (read – a new, fairly unexplored idea) use boring technology. Keep no two unknowns in a single workflow!”

Akshay believes in the stability that standard technologies bring in.

“We need to remember that the world’s best products were first built using a standard technology stack. Facebook was built on PHP, Twitter was built on Ruby on Rails and were later rewritten to support the booming scale they were at.”

“New frameworks and languages are faster and reduce infrastructure expenses. For example, if you need ten servers to run a particular code in PHP, you will end up using possibly fifty percent or less with Golang. But, Golang developers may not be easily available and they are expensive.”

“Having a microservices architecture style – one that is highly maintainable and testable, loosely coupled (different code bases used for different functionalities interacting with rest APIs), independently deployable, organised around business capabilities is essential. It keeps scope to migrate from one technology to another without compromising on the seamless experience.”

Abstain from obsessing over a technology or a product

“Although microservices isn’t an unknown architecture in the industry, the mindset sometimes creates a hindrance,” continues Akshay.

“As soon as a particular technology stops working for what you are building, move on from it and adopt what’s necessary. As soon as you realise a product is inching towards failure, kill it or pivot!”

He stresses on the importance of team agility for optimised performance.

Be user-centric; be data-driven

“If we’re building a functionality or improving an existing one, the decision to do so must be supported with data. To create highly acceptable products, being user-centric begins at the development stage, way before marketing takes over.”

“That’s how development should work but the importance of it may often be underestimated, allowing intuitive decisions to take over, giving rise to multifold trial and errors.”

“Integrating analytics with your development framework and analysing user behaviour is key. While most big companies have their own data warehouses and tools, starting with Google Analytics is a good first step.”

Don’t wait for perfection to strike

Akshay reminisces to his first few days at Slack.

“There was an error. I was new, I was not supposed to push changes to the product. And I did! Creating a glitch. When my manager learnt it was me, he simply messaged me – ‘Welcome to Slack! 🎉’ That’s it. When I apologised, he said – ‘Don’t say sorry, it’s not your fault. You were trying to fix something and it’s okay if it failed.”

This incidence was a learning in empathy, and understanding that shipping is the only constant.

“Don’t wait for perfection to strike. If you believe in something, simply do it. Learning and enhancement will follow.”

CreatE run books

Akshay advocates documentation, a habit that he has always believed in and exercised at work and otherwise. “Often in the hustle of a start-up, documentation is given less importance. Documenting ideas, process followed and solutions deployed, helps a team to reflect back and improve with speed. It optimises time taken to solve a problem during a crisis.”

He helps the start-ups he mentors create their own run books as they continue to develop.

—

Product failures bring in real insights, like a spear sharpening for what’s next.

Dare to fail fast to succeed.

—

Akshay Recommends

—

Words: Akshay Deo, in conversation with Nikita Vhora