The technical
Product approach has been around for quite some time in the world of software development, and nowadays product managers are in charge of transforming business requirements into technical solutions together with their development teams.
However, in the world of
analytics things are a bit different, and many
analytics teams still take a reactive approach when responding to business needs despite the growing willingness to adopt a more proactive product approach in analytics. In this article, I’ll list some of the main challenges that could potentially cause a delay in adopting a product approach to analytics in many organizations.
Organizational Structure
Unlike the world of software development where the responsibilities to deal with the front-end, the backend, and the database components are split by different team members or even different teams, in analytics, the expectation is that everyone will ideally know how to deal with all these components at least to some degree. In reality, it’s almost impossible to find “full-stack analytics developers” who mastered all these components and often times organizations need to hire professionals who are only good at one or several parts of the process (coding, modeling,
ETL, visualization, etc.) because the organization lacks structure that gives an exact definition of the skills that are needed to complete a task (front vs. backend). In addition, the world of analytics tends to be very individualistic. In software development, brainstorming ideas for new features, stand up meetings, and team celebrations of success are part of everyday life at work. In analytics, teams are usually required to deal with a lot of ad-hoc requests over a short period of time and they usually just split the work between the team members letting each and everyone take their own approach in order to speed up the process. As a result of the lack of adequate organizational structure as well as the current individualistic nature of the work, agile practices such as Scrum that are easy to implement in software development teams where the work is broken down to components, are a lot harder to implement in analytics.
Confusion Regarding Agile Practices
Building on the previous point, since the nature of analytics teams resembles the nature of tech support and customer service teams where a lot of requests that are ad-hoc in nature come in all the time, many of these teams have already adopted the Kanban approach that works well in these cases. However, many companies
aim to automate a lot of their reporting processes as much as possible by building applications, dashboards, and automated reports and that leads to time-consuming requests to build these applications that end up in analysts’ Kanban “to-do” queues, even though the nature of these requests is complex and they can often take a few weeks (if not months) to complete instead of breaking the tasks down and adopting a Scrum approach. Most analytics teams are confused regarding the proper use of
agile development methods and they simply apply ad-hoc practices to long-run projects that need an entirely different approach such as scrum that is often used in technical product teams.
Background of Team Members
It’s enough to look at most career sections of companies websites and LinkedIn and see that the
skills required for a typical data analyst position in most organizations include a bachelor degree in business, math, or other quantitative fields, knowledge in
SQL, preferably a bit of Python or
SAS, as well as knowledge in a visualization tool such as Tableau Software or Qlik. While this type of knowledge is great if the team members only deal with ad-hoc analytics requests as well as simple automation requests, it is usually not enough for complicated automation requests that require knowledge in query efficiency, data-warehousing, and pipeline engineering. Regardless, due to the confusion around what these skills actually mean, those professionals who are hired as data analysts and possess most of the listed skills are still expected once hired to successfully deal with
BI and even backend development challenges even though many of them do not possess education in computer science and
BI development where this type of knowledge can actually be found. In order to change that situation, organizations will have to start handing over all those complicated infrastructure development-related requests that require knowledge in DBs, cloud, and advanced coding to experienced data engineers and developers in their future product teams and not rely on their data analysts to do those things. They were simply hired in order to analyze data and provide insights, even though they can contribute to different parts of the product (e.g. visualization, initial query development, QA, etc.)
Product Ownership
A product owner is a common position in the world of software development, and it is sometimes performed by actual product managers. The idea is to have someone leading the development of technical products and owning the process. In analytics, due to the individualistic nature of the profession, projects are often completely developed from a to z by one person. A good example can be a request for a complicated automation application that requires a pipeline, a front-end interface, and a bit of QA, all done by one person over a period of months. Moreover, sometimes these projects are initiatives that start by individuals and not even a specific request by the business. While this situation may be good in the short-run (especially if your organization is lucky enough to hire full-stack analytics developers) it is very bad for the long-run. Once those experts leave their position, it is almost impossible to keep those applications running since there’s no proper
documentation and context since those experts often work in isolation and care more about the delivery of the application more than anything else. Product teams usually tend to create all these add-ons for applications and features so it’s easier to maintain them in the long run.
KPI for Success
Most product teams define metrics for the success of their products (e.g. new user acquisition rate, average time on site, average transaction amount, etc.). While it may be easy for external product teams to measure the success of their products with external clients, it could be a bit harder to come up with metrics to measure the success and
ROI of analytics initiatives inside the company.
To sum it all up, organizations are at a point where they need to start understanding the big picture about the nature of their internal and external analytics needs as well as the process of building products related to analytics. If an organization sees the need to start adding more depth to its BI and analytics capabilities beyond ad-hoc requests, then understanding how all these points play a role in moving towards a product approach to analytics is crucial.
