Product Management in the data science world

The topic related to ‘Product Management’ has received several laurels in recent years. Several rounds of discussions have happened to create an analogy out of the client's stand point.

As I heard more of these conversations, there was an uncomfortable ambiguity stemming from disbelief – is this another fad or is there meaning to it? Well, the initial rumblings were from the cool kids in the bay. But, why did the grounded Midwest and shoot-from-the-hip south latch on? Must be something deeper, right?!

Product management has been around forever in the software, e-commerce world. But, today, mainstream IT and AI teams in fortune 500 companies are thinking of a product paradigm shift. Leading consulting firms are also developing products or beefing up their technology as an eventuality.

But, the question that begs attention here is – why products? What happened to software as a service, platform as a service, ML as a service? Do we need another paradigm shift? Or as the saying goes – Old wine in a new bottle?

IT teams are today being led by progressive Chief Digital Officers, Chief Data officers. Conventionally, CIOs have been leveraging their value by app dev teams, BI teams, infrastructure teams et al. While this may have become a table stake, it has been around for a while already. The question is – ‘How to deliver incremental value to business?’

So, what has changed?

Demand:

IT is today called upon to be a true business partner. And, given the rate at which business is facing change, the time to deliver value is compressed.

Glocal innovation:

For a fortune 500 firm operating globally, innovation is striking at its core from multiple directions. While the USA is still the biggest revenue (EBITDA generation engine), problem and solution innovation is happening in other markets faster than the USA. For starters, they have less legacy to deal with. The local markets are facing competition from nimbler players. VC money is flowing into firms in China, Israel, Korea, India which are encountering newer problems in e-commerce, voice commerce sectors. Other traditional revenue generating markets, individually facing slower growth, find it difficult to make a business case to invest in solutions led by such innovations.

Problem repeatability:

This is going to sound rhetorical. But, I must state it because it is relevant. Business problems in today’s enterprise are constantly changing. Few of them get recreated, and hence are not available in large volumes. Few others are becoming common across markets and thus moving into a constant state of being a tightly defined problem that can be applied globally. Repeatable.

A good indicator to this is AWS recent product launches – out of the box image, text, voice, reinforcement learning, forecasting. Common problems which are finding repeatable solutions.

The AI candy shop:

Today, nobody wants to use process automation tools that are not embedded in intelligence. Passé, inefficient. Wall Street, investors and boards are lapping up the buzzwords – cognitive, AI, embedded ML.

Cloud enabling global scalability:

Cloud platforms such as Azure, AWS have ensured that once you have these AI capabilities developed, they can be deployed globally. The global-local adaptation is a key design criterion in this context.

Glocal solution adaptation…er,… maybe Glocal problem adaptation:

Each market has its secret sauce in terms of the market structure, drivers and customer nuances. Thus, before adapting a solution from one market to the other, it is essential to adapt the problem as well. For example, it is an interesting pursuit to adapt the problem structure from the modern trade Australia market to halfway across the world in Brazil.

And, then adapt the solution.

So, who’s game is it anyway?

Given the above guardrails, it is quite evident that the business case should be developed by a country specific P&L or ROI measure. It must be a global mandate. IT is one of the few functions which is ideally poised to ride this wave. That, they own the data systems is coincidental. Or, well.. was that the whole plan! Go, Trojan..

Finally, after rambling about half the things in the world – we come to the initial topic of this article. Products. Why?

A product has a life – it evolves constantly. The focus is on continually making the best product for its end user, ever possible. It has a roadmap. In a world of multiple users, it needs a strong owner who plans and decides well. It has a clear value proposition in each update/release. It can be developed in a sprint like manner. It can be defined with a bounded scope and sold internally in enterprises, with greater ease. And, be defined, abstracted, customized for a global roll out.

Looks like a duck, walks like a duck, sounds like a… must be a duck. Yes, I guess it does look like a product.

But, how do we help organize people and teams to get the products rolled out?

While the below roles are common to a product-oriented firm, the thought process is different from conventional IT projects. Sharing of resources across projects being the biggest drawback. The smartest of each of the below folks will perhaps still fail, without an organizing framework. The roles to work in a closely integrated manner, dedicated to making a single product successful.

Product Designer:

The role of a product designer is someone who can completely immerse himself in the shoes of the end user, without worrying about the AI or Tech related issues that may occur sometimes. Just solve the end user’s real problem and keep tracking the end user’s behaviour as the product usage evolves. In product management, there is a contradictory school of thought which mandates that the designer must appreciate “how” a product works. This, however, might dilute the designer’s objective of empathizing with the end user.

Product owner:

A functional expert of impact analysis who can connect the dots and identify the nuances of each problem. A great problem solver, with functional expertise, has the knack to see through the commonalities, and the uncommon aspects too. Prioritization between the must-haves, nice-to-haves and must-not-haves is a key skill required in the role.

Product BAs

Products are quite massive in terms of their scope today. Primarily, each product usually is broken down into sub products which are owned by individual product Bas.

The AI solution developer(s)

Usually, it is very difficult to get a product owner who really gets AI solution development. By and large, individual intelligence is anyways overrated. It is important to have a dedicated AI solutioning team which can translate the problem into a modular AI solution.

The AI deployment team

It is not enough to develop a modular AI solution. To be able to deploy it in globally scalable platforms requires seasoned IT big data engineering & testing capabilities. The plumbing and wiring required to take the AI concept to enterprise last mile reality is no mean task. It is a specialized function. Truly speaking, they give the product its real-life form.

Scrum & Program Managers

Last but not the least, you need the scrum team and program managers. Everyone benefits from their discipline and order amidst the chaos.

So, what kind of product management tools would you require to deal with the existing concerns within your organization?

All said and done. Is it enough to stand up a product team and deliver the product? More to come in the next article – adoption

AUTHOR - FOLLOW
Editorial Team
Tredence