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