Category Archives: product management

2017: Year in Review

It’s the start of a new year, so once again, it’s time to reflect a bit on 2017 and look at what went well and identify my goals for 2018.

Reading: My target in 2017 was to read 12 books and to write about the ones that I found interesting. I had also wanted to get outside my comfort zone of self-improvement books and explore biographies, history, and non fiction. Sadly, I did not achieve this goad as only two books were outside the work related and self improvement categories. I managed to read a total of nine books (and write about six).

  • The Ascent of Money by Niall Ferguson
  • INSPIRED: How to Create Products Customers Love by Marty Cagan
  • Quiet: The Power of Introverts in a World That Can’t Stop Talking by Susan Cain
  • What Every Body is Saying by Joe Navarro
  • Emotional Design by Don Norman
  • The Everything Store by Brad Stone
  • The Goal by Eliyahu Goldratt
  • Product Leadership by Richard Banfield, Martin Eriksson, and Nate Walkingshaw
  • Radical Candor by Kim Scott

This year, I am going to try harder to move outside my comfort zone and explore other categories. I think the problem is that every year, there are at least 5-10 books in the core categories that I find interesting. Hence, in 2018, I plan to raise my target to 15 books and cover these categories.

Writing: I had set a target of 18 blog posts in 2017 and managed to do exactly half. The main issue was that I was unable to branch out from my main category of book summaries. I had a few ideas for a product management topics but kept procrastinating until I lost interest in the topics.

The blog received a total of 330+ visitors this year which was about a 35% drop from last year. Most visitors still visit the blog for the MBA related posts. I am not really worried about visitor numbers at this point as the main goal is to churn out good content.

In 2018, I am targeting 15 blog posts. I hope to get at least 5 posts that are not book summaries. In addition, I want to learn how to use an illustration tool to create simple drawings and graphs to make the content easier to read.

Career: 2017 was the year in which I became comfortable as a product manager. The added experience meant that I was largely unfazed even though the domain that I am working in (APIs, platform) is largely technical. Last year I noted that I had not yet decided if I wanted to be a technical PM but this year I realised that I am good at it and it is a niche skill and I quite enjoy it.

The company that I work for underwent an agile transformation and my team was one of the more successful adopters of the new process. We plan to continue being champion for the agile way and set an example for other teams. Having fixed the execution problem, in 2018 I want to move away from 6 month roadmaps and focus on goals/metrics based roadmaps.

In 2017, after two years on the job, I was promoted to senior product manager.  Therefore one area that I want to focus more this year on is my managerial/leadership skills. I have started reading a few books on this topic and have enrolled in management training that is being offered by my company.


Product Leadership by Richard Banfield, Martin Eriksson, and Nate Walkingshaw


Product Leadership is a book that distills the best practices of Product Management into one source. Mark Ericsson is the founder of Product Tank and Mind the Product and  has a wealth of experience in Product Management. The book covers topics such as leadership, vision, strategy, prioritising, user research, and many more.

I skimmed through this book very quickly since I found that it covered a lot of material that I was already familiar with and there was very little that was new. I’m probably going to skip reading Product Management books for a while. However, if you are a new  or aspiring PM, reading books such as this one or Inspired are a quick way to get up to speed.

Agile Transformation

Last year, Freshdesk underwent an Agile transformation. Some of the changes that we adopted were as follows:

  • Cross functional teams – A team must contain all skills required to take a feature from ideation to deployment. This avoids the need for handoffs to other teams and communication overhead.
  • Iterative development – Develop features in bite sized chunks and aim to deploy every sprint (A sprint is a timeframe between 1-4 weeks)
  • Transparency – Break silos by brainstorming ideas and planning for Sprints together as a squad
  • Limit WIP – Productivity improvement due to decreased multitasking and opportunity to spot improvements


Agile borrows heavily from the lean methodology in manufacturing and aims to avoid waste. Waste could be due to picking up features that not required, inefficient processes, communication overhead, quality issues etc. During the initial training, I recognised several similarities to concepts that I has learned during the Operations Management MBA course.

My squad (teams in Agile are called squads) has made several improvements over the last year which have increased our development velocity. While some of the changes (avoiding handoffs, iterative development) came part of the process, others (continous integration, test automation) were a a result of the squad embracing the need for continous improvement. Here’s how we went about it.

MAKE WORK VISIBLE – When I began my first job, I was confused about how little I was saving. I was earning a decent amount and not making any large purchases, yet I was saving very little. I took the advice of a personal finance site and started using budgeting software to keep track of my spending. Once I did this, I was able to see exactly where my money was being spent and I was able to make the necessary changes and start saving.

Agile does something similar to drive improvements. It makes work visible by ensuring that large features are broken down into bite sized user stories and tracked using a too such as JIRA. The sprint ceremonies also a vital role in in improving transparency.

  1. Sprint planning – At the start of the sprint, the squad estimates which features will be deployed at the end of the sprint. This is entered into JIRA and it is visible to everyone throughout the sprint.
  2. Daily stand ups – Update the squad on what we are currently working on. We use the Kanban board to track the current status of user stories and be reminded of the sprint goals.
  3. Backlog grooming – Gain visibility into what is coming up in the next few sprints and collectively brainstorm.

INSPECT AND ADAPT – The agile principle “Inspect and Adapt calls for squads to come together at regular intervals to reflect on how to be more effective and adjust their behaviour accordingly. This is achieved through the sprint retrospective.

Sprint Retrospective – During the retrospective the squad identifies what prevented them from achieving the goals. This feedback is then prioritised and we figure out the best way to address it. It was feedback that led us to embrace continious integration, mock testing, and increased test automation.

One important point here is to keep the number of features taken up each sprint down to a minimum. Only features that you think will be shipped should be taken up. Why? First, it reduces multitasking which is a known productivity killer. Secondly, “Inventory is Evil”. Having buffer, prevents you from identifying bottlenecks in the process. In lean manufacturing, inventory is compared to a lake that hides sharp rocks underneath it.

Imagine that your code reviewer falls sick. If you maintain a buffer of code reviewed features, then the QA engineer would never waste time waiting for a new feature to test. This seems good in the short term, but may hurt you at a critical time. In Agile you face the delay and then introspect on how to prevent this. For example, you could set up a process to ensure that there are multiple engineers who can code review a feature.

The retrospective is critical as transparency by itself will not drive change just as keeping track of you expenses by itself will not make you save more. You need to act on the information and make changes i.e. Adapt.

INSPIRED: How to Create Products Customers Love


Marty Cagan is founding partner of the Silicon Valley Product Group, a consulting firm that helps companies with their product strategy. Prior to that he held product roles at EBay, Aol, Netscape among others. He is a well respected product thinker and several of the ideas in this book can also be gleaned from his insight blog on the SVPG website.

I had bought this book over a year ago as it was one of the highly recommended books for new PMs, but it sat in my Kindle until I finally got around to it recently. I concur with the advice about this book being an excellent read for new PMs, it covers an incredibly broad range of topics.

There are more than 40 (short) chapters in this book, so it’s impossible to talk about them all, but here are the parts that resonated the most with me.

Importance of product design – Even though the author was a platform product manager, much of the book is targeted towards products which have a UI and therefore there is a lot of advice on the importance of designers. He recommends doing away with PRDs in favour of high fidelity prototypes that can be tested on actual users.

Startup vs Large companies – Startups that are still trying to find product market fit are places where the emphasis is on getting things out of the door. They learn by shipping and mistakes are accepted. By contrast, large companies have a lot to lose by shipping an ill thought out feature and are much more risk averse and detail oriented.

Leadership by objective and roadmaps – This management style advocates giving people a goal and letting them figure out how to achieve it. Marty advocates a similar approach to road mapping. Leadership comes with a central theme and then rather than features, gives individual teams a set of goals and lets them decide what features to ship in pursuit of that goal.

Role of emotion in purchasing decisions – In the enterprise the dominant emotions are greed (If I buy this, I can save money or time) and fear (If I don’t buy this, I will lose to my competitors). In the consumer space, the emotions are more personal – pride, greed, love, lust etc.

Platform product management – There are three user personas a platform PM has to consider 1) Developers 2) Business head of the developers, and 3) End users. A common error is to think that since developers are the most important as they use the platform to create apps for end users. However, the reality is that the end user and the business head are much more important.

This resonated with me as it was a mistake that I made. It can be hard when your passionate development team comes up with lots of ideas on how to improve the development experience. You give in only to realise later that they didn’t really make a difference to the key objective of the product.

2016: Year in Review

It’s the start of a new year, so it’s time to reflect a bit on 2016 and look at what went well and identify where I can improve.


My target in 2016 was to read 12 books and to write about the ones that I found interesting. Writing about what you have learned improves your ability to retain information. I also get outside my comfort zone of self-improvement books and explore biographies and history. In 2016, I managed to read a total of seven books (and write about three).

  • Seven Habits of Highly Effective People by Stephen Covey
  • Deep Work by Cal Newport
  • The Elephant Complex
  • The Startup of You by Reid Hoffman
  • The Hard Thing about Hard Things by Ben Horowitz
  • Steve Jobs by Walter Isaacson
  • Don’t Make Me Think by Steve Krug

For 2017, I am planning to retain my target of 12 books. More than the number of books, I want to use the knowledge in them to become better. This is a hard goal to measure but important nevertheless. Another target is to read more about emerging trends and understand them – for 2017, I plan to read about Artificial Intelligence.


I had neglected this blog from mid 2015 to mid 2016 at which point I had resolved to start again and get to 12 blog posts for 2016. I managed half that number and stopped just three months after I began. The blog received a total of 500+ visitors this year which was about a 50% drop from last year.

The main factor that limited my blogging  was that I wanted to get serious about investing and the scene in India is very different than in the USA. Hence, I spent a considerable amount of time reading and researching the topic. It took nearly three months before I settled on a strategy and I should have more time going forward.

In 2017, I am targeting 18 blog posts. In addition to the PM posts, and the book summaries, I plan to start adding in a few posts about my travels. I visited Sikkim, Udaipur, Agra, Bali, and Sri Lanka this year and plan to visit many more in 2017 so that should add to the number of blog posts.


2016 marked my first year as a Product Manager and was fairly eventful. My team launched our first big feature (We started development in 2015, but did not ship until early 2016), expanded in size, and began an agile transformation. I plan to write more on my learnings as a PM this year.

When I started my role, I fancied myself as a PM who would take on a design and business specialisation. This was primarily due to my interest in UI design and human psychology. However, my role was in the API and Developer platform team and this has led to me enhancing my technical skills. Technical PMs are definitely underrepresented among PMs and there is a growing demand for them, but I have not decided if that’s the path that I want to take.

In 2017, one area that I want to focus more on is my managerial/leadership skills. This is an area I had not given much thought to in the past, but as the team has grown and I move into a more senior role, it will become more important.

My average PM workday at Freshdesk

PMmemeA question that one can always expect from a prospective Product Manager is – so what’s an average day like?  This post is my attempt at answering this question.

7:00 AM: The alarm goes off and I get out of bed half an hour later.

8:00 AM – 9:00 AM: Hit the gym to workout. I try to workout three times a week. If I’m not working out, I go out for a walk and get some physical activity before it gets really hot.

10:00 AM: Leave for work. I don’t have a car, so I call for an Uber or Ola (Ola is the Indian competitor to Uber. It isn’t as cheap as Uber, but the sedan class of cars have wifi, which allows me to check emails while I ride to work. I live around 5km (3 miles) and it usually takes me about 20 minutes to get to work.

10:30 AM – 12:00 AM: I reach work and grab a cup of tea and check my emails, Twitter, and check my to do list for the day. This is not the most productive time of the day for me, so I try to keep it for light/shallow work such as reviewing the roadmap, collecting metrics, making notes etc.

12:00 AM – 2:00 PM: At 12, my team has our daily standup where we talk about what we did yesterday and what we plan to do today. Along with the PMs and engineers, we also have the PMM and QA attend this meeting. The QA at Freshdesk is organised as a functional unit i.e there is one QA team across the company and involving them in the standup is a great way to ensure that there are no communication gaps. Post standup is usually a productive time for me and I try to avoid meetings and distractions.

2:00 PM – 3:00 PM: I have a late lunch. Most days, I will head over to our cafeteria for the (free) lunch, but there is a food court downstairs with additional options that I will head to once a week. After lunch,  a fellow PM and I go for a quick walk. On my return, I usually spend a few minutes reading the day’s newspaper.

3:00 PM – 5:00PM: I try to keep most meetings in this time period as most people in the office are usually present at this time. Most days I usually spend 1-2 hours in meetings.

5:00 PM – 7:00 PM: This is another productive block of time for me, so I will use it for work that requires my full attention such as research, PRDs etc. Right now, I’m helping write the technical documentation for the APIs and the app framework.

7:30 PM: I spend the last few minutes of the day tying up loose ends and then I leave work at around 7:30 or so and I reach home by 8.

8:00 – 11:00 PM: At home, I cook dinner and relax. I will watch TV, play games, or do read interesting articles online. Occasionally (1 time a week), I will have a few small things from work to take care of, but most days are free.

11:00 PM: I turn off all screens at this time. I had pretty bad insomnia that improved after I  started limiting my caffeine and screen time, so I try to be disciplined about this. I will usually read a book until I feel sleepy. Right now I am reading “The hard thing about hard things” by Ben Horowitz and I will post my thoughts soon. I usually turn the lights off before 12.

Summary: I used to be really bad at answering the average day question when I first began working. This was because there was no average day – I was overloaded and did whatever came up. This resulted in me focussing a lot on what Cal Newport calls “shallow work” such as answering emails or solving support tickets. However, the deep work (research, PRDs) did not get enough attention. Recently, I have gotten better at recognising my productive times during the day and reserving them for work that adds the highest value.

Latest Updates

It’s been a really long time since I last posted but I promise to post more regularly (at least once a month) from now. I began the Oxford Comma once I began my MBA at the Said School of Business, Oxford. My main motivation was to provide the information that I had found missing when I was an applicant and I also wanted to improve my writing. However, once I left, there wasn’t anything I could add to the blog and more than a year has passed since I last posted.

After I graduated, I was looking for Product Management roles and I started a new blog to catalogue my experiences learning about the role. However, once I got a job, that blog started to be neglected as well. I intend to make more PM and career themes posts but I didn’t really want to maintain two separate blogs. In addition, I also wanted a blog to share my travel experiences and other musings.

Long story short, I plan to convert The Oxford Comma into my personal blog and make posts from all the aforementioned categories here. I have already merged all the posts from my PM blog into this blog. I plan to rename the blog name and domain accordingly.

Thoughts on Uber’s Surge Pricing

A few weeks ago, the following tweet popped up in my timeline.

By now, everyone is probably familiar with the mechanics of Uber’s ‘surge pricing’. When the demand for taxis increases, the price of a taxi ride spikes. The company claims that higher prices encourage more drivers to get on the road. It also rations taxi usage by ensuring that only those who really need the taxi immediately and are thus willing to pay higher prices, continue to use it while others wait for the demand and supply to balance each other out.

The economic principles behind surge pricing are widely accepted by economists, which begs the following question – why don’t more companies adopt this pricing model to boost revenue? The answer as Megan Mcardle points out is that raising prices during periods of high demand is usually very unpopular with consumers who feel like they are being exploited. This is reflected in the sentiment behind the tweet at the top of this post. This negatively impacts the reputation of the brand and thus companies will usually forgo the short term boost in revenue in order to prevent the long term loss of reputation. Uber itself has faced tremendous criticism when it has (automatically) raised prices during natural disasters or emergencies.

So why does Uber unabashedly continue to persist with its aggressive surge pricing algorithm? I believe that one of the reasons is that its business model enables it to use it as a competitive advantage. Uber is a platform business, with taxi drivers on one side of the platform and taxi riders on the other. Most businesses fight over customers, but platform businesses have to fight over the suppliers (taxi drivers) as well. As Ben Thompson points out in this brilliant article, the fight over drivers is much more consequential than the one over riders, as having more drivers will enable Uber to lower the average wait time for a rider, which will attract riders to the service. The wait time is of course directly related to the number of available taxis on the road, which explains the mad rush to sign up drivers.

So how do you get drivers to sign up, especially when they have a choice between competing services? Like most other humans, drivers too will choose the company that they think will enable them to earn the most. Now read the tweet at the top of this post one last time, but this time, put yourself in a taxi driver’s shoes. Would you prefer to work for a company that paid you a base rate that remained constant at all times or one that gets raised aggressively during periods of high demand? The choice should be apparent, which explains why Ola was forced to abandon its initial stable pricing model and introduce peak pricing earlier this year.