Product Management - In a Context

A thread on Twitter around how important context is in product management made me think about the context of my current job at redBus, and write this post to articulate these thoughts better. But before that, a bit about the thread. It talks about how context of the business and the organization is very important to the style of product management. There are varied styles to it, and the one which is successful in a team/org might not work very well in another. For example, a PM who is very detail oriented and gets involved in all things - from detailed data analysis, to spec creation, design feedback, testing all possible scenarios and charting out the marketing strategy - will be very effective when working on a specific product with a small scope (say the referral flow) but might struggle while working on a large scope product (say user engagement and retention). The former requires an eye for detail v/s the later requires, most importantly, identifying the right areas to work on and getting things done on time. Similarly, a few other product management styles could be - a 'salesman' PM, who is working on product where adoption is the most difficult and critical aspect; a 'market analyst' PM whose job is to identify the next big thing in the domain and build it before the competition, and so on. 

Now, the next logical question is - what is the context of my job? I am the product owner for the Singapore and Malaysia business of redBus. This includes the primary booking experience on redBus, customer acquisition via SEO and SEM, customer support for passengers, and the operator facing experience. The scope of the job is very wide and i have just one more product manager working with me. On a average day, i have to monitor the ongoing business, problem solve existing development, meet with stakeholders to plan for the immediate future, and also create a roadmap for the long term future. This means my bandwidth is really stretched, and it is most critical for me to figure out the priority items and focus only on them. This also means that i need to be efficient with the items i pick up and not spend more time than necessary.

Another way to think about the context of the job is that bus travel is more of a commodity - users want to spend as less time in booking a bus as possible and wants the travel experience to be easy and hassle free. It is not an aspirational experience that the user looks forward to - like a resort stay or a cruise. To put it simply, a passenger wants a bus travel experience to not be 'not bad', more than they want it to be good. And the booking experience is expected to imitate the travel experience - the experience need not be the most pleasing one, but needs to be fast, reliable and hassle free. 

The third dimension to the context of this job is the business situation that redBus finds itself in Singapore and Malaysia. redBus is one of the 3 big online players in the market, each with almost equal market share. The biggest share of the market though is still with offline counter booking. This in spite of the fact that most Malaysians are used to online purchase and the internet penetration is close to 85% - as good as any developed country. There is a sizeable convenience improvement in booking bus tickets online, and the first player to tap into the offline bookers customer segment will gather a sizeable market share. Crudely put, if you are only 75% accurate or the customer experience is slightly suboptimal but if you are the first, you would make huge strides.

The fourth and final flavor to the context is the people at redBus. It is a small organization, and for every geography we have carved out a 'pod' made up of front and back end developers and QA. This structure gives me the liberty to develop features that i think are critical without worrying about getting enough tech bandwidth (which was often the case in Flipkart, my previous company). But India business being the primary focus of the company, the tech for other geographies do not often receive the love and attention they deserve, especially for senior tech managers when it comes to solutioning complicated features.  And this attentions is needed as the engineers working on newer geographies are usually just starting out, and not in a position to take critical solutioning decisions. Also, bandwidth from teams which work across geographies (like design) is difficult to get as the priority is often India specific features. This means that as a PM, along with trying to understand the user and writing specs for features to help them, i also need to spend significant time in soliciting help for tech solution and on understanding tech possibilities of what can be built next. It also means that the tech development has to very closely monitored (more so than what was required in Flipkart), ensuring there are no slippages and and no test cases missed. A final fallout of working in a small org is that communication is easier and faster- for ex, the PRDs can be short, crisp and to the point, instead of lengthy Flipkart PRDs which serve more to drive alignment and set context than communicate product requirement to tech. 

Given this broad context of Singapore and Malaysia market at redBus, an ideal PM for this geography would:

a) in absence of deep market research or customer feedback (we dont have people to undertake these), focus on data and market insights to draw product inspirations

b) detail the product to up to only 75% of the ideal, focus more on taking the product to market soon and iterate based on data and feedback

c) spend less time in writing specs (again going back to amount of detail) - going to the extend of writing just 3-4 page PRDs - but ensure to get the specs to tech and design sooner, so that the solutioning can be figured out in time

d) focus more on acquiring new customers and convert the acquired customers into app users and less on improving the booking experience - as being the first to reach offline bookers is more important than having the best product when you reach them