Finest Diagrams Explicitly Demonstrating Product Management Concepts

Introduction to Product Management | Infinity

There are a lot of things product managers are accountable and responsible for. A product manager is not only liable to strategize by creating a roadmap but also needs to articulate the release cycle of a new product to the team along with everything that comes in between.

They are also required to have the expertise in knowing how to identify the priority tasks and manage the team accordingly. Not just this, but mobile product managers are also given the responsibility to analyze the features added to a product (mobile app) and whether they are in sync with the client’s goals.

All in all, every process, activity, and decision associated with a product is synchronized and aligned by the mobile product manager. What helps these product managers achieve their KRAs is a certain set of skills.

Now, obviously they will be required to explain certain product management ideas to their team members so that they all are on the same page. But, the thing to wonder is – how do they explain all the product management concepts and key ideas?

Well, I think a few useful diagrams for product managers do the trick. If you are interested in knowing what these diagrams are and how and when they are used by mobile product managers, stick till the end.

Diagram 1 – Communication bottlenecks

Small Teams** Every Monday morning the CEO of our 5000 person company would send out an email starting with the words “Hello Team.” We all knew we were not One Team. ...complex product development is a collaborative activity that requires people ...

It is understood that as a manager, you need to be aware of what is going on in your team and how the team members are managing their tasks. But, it is ludicrous for any person to be involved in every communication and decision – one person cannot handle all the things on one’s own, right? Isn’t this why the delegation was invented?

Now, it is natural you would want to be included in all the important inter/intra-team conversations, but you need to reflect on one thing – is it necessary? Is it something you should do by putting aside your other responsibilities?

The answer is – analyze whether the team is capable of communication which is not dependent on you. And if it is, you need to make some conscious decisions to ensure that important things like fluent communication are not solely dependent on you. A diagram that can effectively explain the case in point is given below.

Let’s say, a Web Engineer needs to discuss something with the Product Analyst and then the PA says they need to discuss something with the iOS developer in this regard. Now, the Web Engineer should ideally approach the PA and iOS developer directly, instead of being dependent on the PM (as shown in the image on the left).

The diagram on the left shows the dependency of the team on product manager to communicate with other members of other teams – something that adversely affects the workflow and slows it down. And on the right is the diagram displaying an efficient communication flow that is not dependent, instantly eliminating unnecessary points of contact.

Diagram 2: Waterfall vs agile

Moving From Waterfall To Agile With Kanban

Though there are many resources out there on the internet participating in the debate of the Agile vs Waterfall approach, it may still seem like a vague concept in relation to product management. So let’s clear the fog of ambiguity.

It is generally known that the cost of mobile app development is calculated on the basis of hours it takes to develop that product.

Now, if the product manager of that mobile app development company chooses to use the Waterfall approach (i.e., a large release of the product), this would mean that the product will be launched all in one go.

Now, when a product is released, it is expected to become an instant hit – something which won’t be easy in this instance, since the product is launched all at once and is definitely a home to some issues. The value that they will get from this release won’t be equivalent to the investment (time) made by the developers.  It is because they would require to fix the issues from the start.

On the contrary, the agile approach supporting small releases and iterations would show instant value results, since you are simultaneously identifying errors and fixing them.  The diagram above clearly shows the difference in the end result of choosing these product management approaches.

Diagram 3: Representation of delivery size

What we have learned going live with the Zimmo Prijswijzer | Rockestate

When it comes to delivering a product on time, it is a very crucial part of the whole development process. It can literally make or break the future of any mobile app. If time-to-market is too long, some other app could capture the market and it would render the mobile app in question futile.

Here is a representation of the sizes of initiatives taken when developing an application –

The diagram on the left shows the throughput of the delivery size that only deals with working on big projects (large chunks of work at the same time). It is absolutely clear that working only on big projects of a product would create a blockage at one point of time in the future, since these projects would require more time, attention, resources, etc. And if anything goes wrong, the impact would be devastating on the whole process, inevitably increasing the time-to-market.

{Also read our article on “Project Managers vs Product Managers: Difference, roles & challenges”}

The diagram on the right is a classic “to do”. The advantages of adopting the Agile approach have rippled down to this stage in the product management process as well. This approach advocates the mixture of performing small tasks with large chunks of work (blue), something that we also follow at Anteelo.

As visible in the diagram, unlike the one on the left, here small chunks of work (Pink) can easily pass through the funnel (can be done easily). If these prove successful, the product managers can carry on with this idea (yellow circles) and invest completely. And if otherwise is the case, then they can iterate again and invest accordingly.

{Check out this extensively detailed article on “10 most important documents product managers must prepare”}

Diagram 4: Level of leadership involvement

Level of leadership involvement

The diagram below comprises two models for elaborating this product management concept. One on the left displaying the initiative size, number of tasks done at a time, and the risk factor in them, and the other concerned with the level of involvement of the product managers (leadership) correspondent to these tasks and initiatives.

The one on the left is a pyramid of tasks/initiatives to be performed by the team. The bottom of the pyramid means many tasks being performed at once, and the diagram on the right shows the amount of involvement with respect to these menial tasks having low to none risk.

As we move to the top of the pyramid, the number of tasks decreases while the risks associated with these tasks increase as well, this is where the product manager MUST be consulted, while in the formed he/she can be just informed. This diagram would help not just help mobile product managers but also the team members in knowing when to depend on the leadership.

Diagram 5: Analyzing segmentation value

How to automatically segment customers using purchase data and a few lines of Python | by Tristan Ganry | Towards Data Science

There are a few practices that organizations are accustomed to following. One of them being the habit of optimizing for the average instead of a segment. Meaning, they tend to focus on the average instead of particular segments that need improving.

In the circumstances where the targets and hypotheses are fairly broad, it becomes challenging for the product managers and development teams to create an impact via product. It is because you are here trying to satisfy a variety of targets at the same time, which is not at all possible.

Diagrams, such as given below are a way to analyze each segment for identifying which ones are impacting the performance of others. All this to resolve the prevailing issues.

The diagram above consists of three hypothetical experiments 1,2, and 3 with segments A, B, C, and D. Out of three experiments, in the first case, there was an uplift in the segment A, followed by a decrease in the second case, and third with no change.

Taking an individual look, in experiment 1, segment A performed well with others, except segment B. Now, the diagram has highlighted the decline in this segment juxtaposed to the others. This could help product managers in finding the reasons for this happening which will eventually improve the average in the longer run.

A similar situation occurs in experiment 3, where segments A, C, D underperform in opposition segment B which showed significant change. Again, a study would clear out the reasons for this happening.

These useful diagrams for product managers can easily be customized to one’s needs, irrespective of which industry the product managers are operating in. As far as  Anteelo is concerned, I think these models really help our teams in simplifying the process and maintain open communication between inter/intra-teams.

What Does Product Management Look Like in Data Science?

Becoming A Data-Driven Product Manager | by Luciano Pesci | Towards Data Science

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 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 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:

How to Estimate Demand: How You Can Get Ahead of the Curve - Fulfillrite

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:

The Problem of Repeatability | Lab Manager

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. Wallstreet, investors and boards are lapping up the buzzwords – cognitive, AI, embedded ML.

Cloud enabling global scalability:

Scalability in Cloud Computing - IronOrbit

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 half way across the world in Brazil.

And, then adapt the solution.

So, who’s game is it anyway?

Given the above guard rails, 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 management successful.

Product Designer:

The job of the 'Product Designer' and its importance in a startup | by Carlos Beneyto | UX Collective

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:

Agile Development: What is a Product Owner? Roles and Responsibilities? | by Lazaro Ibanez | The Startup | Medium

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

What companies should look for when picking an AI training solution - Tech Wire Asia

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.

error: Content is protected !!