Skip to main content

Product Management

Product Management

Once I had a conversation with one on my friends who just happened to join a startup. He said he worked as a Product Manager and was talking in general about roles and responsibilities .

What surprised me was that his roles and responsibilities differed from what I have seen in the market. Nothing wrong with it, this happens with other roles also. 

Product management roles vary depending on organisation to organisation. It is hard to define the roles and responsibilities. Though all have a common goal to making the product successful but vary depending in what department you are in or what phase part you are working on. Example : Some folks work in the analytics are Product Manager.

Talking about my friend, he was more into forecasting for the application, looking at the revenue growth. When asked about who builds the road map, his answer was that the tech team and the business decide.  A fairly common scenario. 

So what are the Roles and Responsibilities of a Product Manager?

Setting up the right vision since he is the one who is  the CEO of the product

Making sure that there is a road map for the product which he needs to update from time to time

Market Research - This is the area on which lot of decision are made based on the the outcomes of the research. A simple example would be  - you want to build out a mobile application. Your market is targeted towards a particular country which has less number of iPhone users and majority of them use Android. This makes it easy for PM to decide that initially  the product will be released for  Android mobile users instead of making just iPhone or both iPhone and android which will be costly and time consuming

Writing user stories -  A PM knows best about the product since he is the one who has been doing a lot of talking to the customers, stakeholders, doing market research. PM should write requirements and prioritise them. These requirements serve as a product backlog which gets on added every know and then and also become a part of the road map. For one of my Banking project, we had given access to Business and a team of product owners to create Product Backlog. We used to write user stories based on the needs of the customers and analysis of various factors. This helped us in achieving the best possible features for the product in less time. It also helped us in cost analysis and resource allocation. 

Analysis of competitors market - As a PM you should constant research on competitors market. This doesn't mean that you blatantly copy the features of the competitor but instead take a strategic level decision and work on areas which solve customer problem. Classic example is of whatsapp where they copied feature of Snapchat called Stories. In parallel they also removed the ability to add text based status messages. This attracted a lot of criticism. 

Analytics - How customers interact with Application? They is represented by Analytics. A lot of PMs after the product launch start working on the next iteration/release based on the product backlog. The only problem is that they at times underestimate the analytics. Example : As a PM you should know the heat map of the app and how to track user behaviour. Analyse the dropout ratio. There would be a scenario that when a customers on a certain screen drops off frequently and this is evident enough. This gives us an idea of something is wrong on that particular page and we can come up with ways of tackling it. There are some very interesting apps available to track analytics of various forms. here is some list

a. Google Analytics
b. Kissmetrics

c. Optimizely

d. Mixpanel

e. Segment

UX - The PM should have knack for UX .PMs need to apply craftsmanship and science to design product.They constantly keep a check on the  user behaviour and churn out designs based on the experience. In smaller organisations generally the UX team might act as PM with limited control but in bigger organisations or big size products the PMs have the full control since they coordinate with multiple departments like Marketing, sales, strategy, technology Finance and many more. In these type of cases UX team has the benefit of just focussing on the user experience completely. 

Testing - The PM should make sure that they do quality checks on the application frequently since they are the proxy customers. This gives them the idea of how much baked the product is.

PM should be good at sales, support, marketing since these 3 are the departments which keep the product alive. Having continues dialogues with these departments can help in great level insights on where the product is heading and the growth. 

Popular posts from this blog

Do you really need a Business Analyst in your project ?

Do you really need a BA or a similar fulfilling role in your project?

My Aunt has been in a Real estate and construction business for long time. When I was a kid, I used to visit her to every now and then to spend some time. As a part of the visit, I was often told by my cousins that she is at the construction site. 
Building a small house over a chronological period I got to experience how the house was built from scratch. I saw how the construction workers did the job as they were guided by the contractor. 
I also experienced that when it comes to big buildings, there is always an architect who creates the blueprint of how the house is going to be, what dimensions the rooms are going to be.
Notice how this is an analogy for any system we build. Our systems can be small where you don’t really need a Product owner/Business Analyst or we need somebody exclusively who is just for gathering/writing the requirements.

 If you are building a mid to large-scale system, you do need to have a dedi…

User Stories Simplified!

User story writing guide
When I was introduced to the world of Agile, I kept on hearing the words  “User Story”. I couldn’t apprehend what it meant and how it possibly could be a fit for requirements management. This was all due to the traditional waterfall methodology which was omnipresent in most of the software projects. Early in my career we totally relied on creating massive amount of documentation which included but not limited to *Business requirements document Software requirements document High level design document Low level design document Use cases
 You can clearly see where the problem lies if you are planning on to maintain all these documents. On top of that, if you are working on mammoth projects, good luck with that!
How does user story  might prove to be user full?
First of all, User story is not a Silver Bullet but a convenient way to represent requirements. More precisely what a user intends to do.
In my case study, I am going to use example of “loremipsum” which is a social …