TL;DR To build a data team, you would need a business analyst, a data analyst, a full stack developer, a data engineer, and maybe an ML engineer.

Have been asked this question several times, I thought about writing about it. Now, this is essentials on how to hire and build an in-house data team for your business, whether you have a product, or you do projects.

Image for post
Image for post
Photo by Kaleidico on Unsplash

There are several types of data teams if we consider the terminology, but for this post, I am concerned about teams that build an artefact, whether it’s a product, a feature, or a dashboard or anything in between using data, and technologies like machine learning, data analytics, etc. …


One of the many questions I have received from my colleagues in product management is on what is the depth of a user story to be written when you are giving out an API as a product feature to the market. It is a contentious issue, and depending on the culture of the product organization, it differs. There are no right and wrong answers, but as a product manager, it is important you have a discussion with your product team and come to an understanding on what is required by you, and what they will do on their own.

There are certain organizations that require writing of an API specification by the product manager (or the corresponding role; product owner, business analyst). They might require you to write every single information, like what are the request methods, what are the error messages, etc. I am not going to talk about that. There are more than enough established practices on how to write those. …


With the justifiable interest and the unjustifiable hype around artificial intelligence, the businesses are trying very hard to join the game and make early headway in the market with this new technology. With early adopters using in-house and outsourced teams to tailor solutions using artificial intelligence, the vendors have been looking for ways to generalise the solutions to a wider market.

With some experience in the field with intelligent products / features delivered, these are the 5 things I would want you to consider as a decision maker before building AI products.

Not Everyone Will Understand AI

Not every decision maker in the market will understand AI, and that is okay. One of the key mistakes vendors make is worrying too much that the decision makers who will procure their services does not understand AI. …


One of the experiences you get when you are brought up in a war-ridden country is the constant paranoia of the parents, who expect dangers from all around. This was the case of my upbringing during the 1990s and 2000s when the civil war between Sri Lankan State and the home-grown terrorist organization LTTE was escalating rapidly.

LTTE was different from other terrorist organizations at that time due to its targeting of the critical infrastructure of the state using varying methods of bombings. Notable examples include the bombings of Kolonnawa Oil Tanks (1995), Central Bank (1996), Katunayake International Airport (2001) and air bombings of Kolonnawa Oil Tanks (2007), Muthurajawela Gas Storage (2007), Kelanitissa Power Plant (2008). …


When we talk about products, we think of them in two different ways, either as physical products that are manufactured or software products that are developed by software developers. Despite the manufacturing sector and software development sector having completely different structures and processes, the two have been nourishing each other for quite some time by inter-learning between the two and I want to talk about one such instance.

The Two Great Ideas: Agile and Lean

Agile software development came into prominence in late 1990s with the development of software using Rapid Application Development (1991), Scrum (1994) and Extreme Programming (1996). However, a group of prominent developers in 2001 set the agile methodology in stone by publishing Manifesto for Agile Software Development which you can currently see in Agile Manifesto. The philosophy centered around providing workable software to the clients in close iterations which improved collaboration between the developers and clients. …


One of the best things about IT industry is the low barrier to entry for software startups. Unlike traditional industries, you do not need massive capital expenditure, working infrastructure or large supply chains to deliver your product to the market. Just a well powered computer, maybe a cloud account and a decent internet connection and you are good to go.

Or is it? Is it the case that this is more to do with the type of the software startup and the type of products you are shipping? I think we all know that it is the latter.

Image for post
Image for post
Clean codes and neat working space? Not so much! :D

I am currently working in an early-stage Sri Lankan startup that develops mission critical IT/OT software for manufacturing and supply chains sectors. We have been quite happy to exploit the fading barrier between Information Technology and Operational Technology brought by the Fourth Industrial Revolution and has established ourselves among the clients we are currently serving. However, our work has not been without some inherent difficulties we have undergone and I would like to tell you about it in case you and your team have a similar idea. …

About

Sameera Weerakoon

I’m an interested in the technology adoption in the modern world and its effects. Also fascinated how consumers make, often irrational decisions about products.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store