PM Musings: Part I
What we read v/s what it is.
Lets set the expectations straight:
Product Management is an emerging field. There is no hard science yet, just schools of thought. With time, some principles or practices will be tested and established as more accurate over others. What you read about Product Management on various blogs, may be very specific to the organization and the principles may not be applicable in your context. One outcome, common to all school of thoughts is “Action”/ “Exec. It is in this space that a PM must thrive.
The methodologies followed by larger organizations (e.g. Google, FB, LinkedIn, Uber, AirBnB) which either have huge revenues or huge user base or multiple rounds of funding, and multiple PMs, will be different from the ones you would have bandwidth of executing in startup space. e.g. Google can afford to run A/Bs around the shade of blue which is best, or LinkedIn may take a long time to execute Reactions on posts, but the problem your organisation would be facing at the moment, could be entirely different. You would be facing both time and resource crunch in a startup, and you would rarely be able to execute textbook cases.
Just to give you an insight —
e.g. a Food-tech startup AFoods runs a on-demand food delivery model. It is trying to get people onboard. It has a functional app. People can select a restaurant and order food and food is delivered. However, it is not scaling up. Customer retention is not good. What should it do?
—> If most of you are thinking about solutions to improve UI, restaurants listing page or algorithm, think again. The problem may be deeper. A good design goes along with good functionality. A good design, still won’t be able to hide functional issues.
When you dive deep in, you may realize that for startup AFoods -
A. Food delivery times are higher or
B. Supply is lower than demand or
C. App load time is higher and performance lower as compared to other apps or
D. Payments to restaurants are not going on time, so, prominent partners are de-listing themselves.
And suddenly, you would be exposed to “problems” to solve, and prioritise what needs to be done. While a typeface change, or a new social feature to “chat with friends”, or “chat instead of calling the delivery partner” or “UI redesign”, may seem nice to have, you would realize it falls way less in the priority and urgency of things that need to be done.
The common theme though across organization is “problem solving” and “Execution”. Every Product Manager is aiming to get a problem solved. You need to solve problems that will have an impact to the organization in terms of business improvement or customer activation, engagement etc., but at the core is solving a problem that is crucial to the organization (which is paying your salaries), and you may have less than desired time to follow all the best practices you and I read in books or blogs. Remember though, the user should still be at the centre of your universe.
What you do should be solving an important problem, and not masquerading as to be solving a problem. To put it in terms of what you may already have read, prioritisation may be the keyword. The problems that Google and LinkedIn are trying to solve may be different and have a way different context from the one you would be solving.
However, all this involves “Stakeholder communication”. You can’t do much, without relevant stakeholders communicated or kept in loop. We’d try to cover this in one of our later posts.
Reminder: All you read above is still into the space of thought. You may identify the best and most painful of problems, and you may identify the most novel of solutions, but none of it matters without “Execution” or “Action”. You have to see a problem through, and take ownership of getting it solved. No one is going to do it for you and, this is easier said than done.