An unfair world

It takes some living to realize how the world is unfair until you assert yourself. And.. asserting yourself is hard and does not come naturally to most. It does not come easily to me but comes very easily to my wife. I’m grateful for that. It balances things out. It prevents people from running over you and your ambitions just ’cause they can.

Always, the easier position for someone to take is to be “slightly” unfair to you rather than taking a stance against the majority to be fair to you and your interests.

For others to stand up for you, you need them to be able to empathise with you. Or, care for you. Why will they do that? They will do that only if they like you or if they know that you will fight back.

So.. assert yourself. Build this muscle. It helps a lot in life and in product management and in leadership.

Flavor of the month

Sometimes, I don’t get how large companies work. Management mostly spends time managing appearances or taking it too seriously. By that I mean, making sure that whatever is the hip, cool, shiny thing that upper management is discussing, their team should be able to show that:

  • Their team understands it
  • Their team practices it already
  • Their team excels at it and even evangelizes it to others.

Let me take an example to illustrate this. Lets say, upper management is discussing “Using analytics for decision making” this week. Managers see a sudden urge to demonstrate incredible competence in this area. So.. they:

  • Show that they understand the decisions should be driven by data
  • Their team collects vasts amounts of data for analytics
  • Their team has been asking other support teams for data for quite some time and have been encouraging the use of data in sub-organizations and scrum teams.

Now, if the manager wants to keep up appearances, he will not trouble the team and use existing knowledge to demonstrate these points. And to me, that makes a good manager.

The other extreme is a manager who will push all this down to his team and start asking for data and analytics on the smallest of item to demonstrate that they are acting on data. This causes a fair amount of upheaval and disruption to the team and costs productivity losses.

There is little focus on what problem organization really wants to solve by adopting data driven decision making. For example:

  • Were bad decisions made when data was available?
  • Is their a desire to use data to make decisions in a certain area?
  • Is there a desire to use data to drive out lethargy?

Unfortunately… there is a new flavor every couple of months in large organizations.. so its upto good management to ensure teams stay on track.


Analytics for Desktop and SaaS Software Products that want to be lean

I’ve been thinking a lot about what are important things to measure for a desktop software products and SaaS projects and here are my thoughts:

You can gather operational metrics and leading indicators that can impact your decisions as a product team. I think there is value in collecting both. Its important to think about what are the key metrics you want to focus on and if there are any key leading indicators that can predict changes in these metrics. For example: Reduce active use is a leading indicator for reduced revenue in the future. Lack of customer acquisition is a leading indicator of reduced trial downloads and eventually trial conversions, etc.

Generally it helps to have uninterrupted time  and a piece of paper to jot down what’s important to your business. For example: Is your goal to grow revenue? If yes, here are the hypothesis that you might want to test:

  • Marketing is not effective – not enough new customers coming in?
  • Customers are coming in but existing customers are leaving faster?

So, I’ve tried to categorise metrics that I try to gather for any software project I work on:

Customer acquisition Funnel
  • This is different for every channel through which you sell your product. The Direct Channel is simplest to understand and the metrics are listed below
  • Visits to the landing page – say “”
  • Landing page to trial download or “sign up” conversion
  • Trial to full product conversion
These to me are the most important metrics that  drive business goals and metrics. Everything else is making sure you provide sustained value to keep people once you’ve got them. Keeping existing customers is always easier than getting new ones. If these numbers are healthy and the business is tanking then you start focussing on customer retention.
Customer Retention Metrics
  • Active use: Usage by version (number of app launches by version per day)
  • Active use: Files saved in each app launch
  • Cohort analysis for subscribers
    • I’m looking for a simple spreadsheet which looks like this
    • | customerID (or GUID) | Subscription date | Subscription Type | Cancellation Date |
    • Such a spreadsheet can also answer my Customer acquisition requirements.

Customer Profile Metrics

  • Platform – Mac/Win/iOS
  • A Questionnaire during app install that can ask the user to share more about themselves

Feature usage metrics

    • Most used features – be careful about when this event is logged and how its logged 
    • Are new features being used, and how will you agree that a feature is being used a lot?
      • Look at new feature usage/session or /day post release
    • Is the addition of new features impacting customer retention or customer acquisition metrics?
      • This is really important – especially for established products. You may find that nothing you do impacts the business metrics. If you do then why develop features. Work on a new product, service or something else.

While any experienced developer can instrument your app so that you can log usage data on your servers its important to get the user to opt into usage tracking. Here are some companies that make it easy to instrument app usage and help startups get a better understanding of their customer

  • Omniture from
  • Google Analytics since its free
  • You can also try to implement a custom logging solution built by your engineering team


More when I get time.

The power of pushing back and delaying decisions

Every now and then engineering is going to come back to you and say that something’s not possible for will take too much time to implement. Its generally good to hold your ground and try to motivate the team to push the envelope or look at the problem differently. And – to always ask for alternatives.

I’ve noticed that, at times, when I push back, splendid things happen. The engineering team gets a chance to shine and prove themselves wrong. Trust me. Development teams enjoy solving problems and outdoing themselves. This is what makes it really fun to work with a really talented and motivated teams. Its easy to agree to a cut down feature set or to say yes to an “ok” experience but it never challenges the teams to out think themselves.

So.. when there is no time pressure, I ask the teams to think about the problem some more and come back with alternatives. Push back and state why the solving the problem a certain way is beneficial to the user. State the importance of the “right” solution in terms of the user experience rather than your opinion. Smart people can always distinguish between facts and opinions.


Great day as a Product Manager

As a product manager based in India, its great when your product gets centre stage at a worldwide conference in the US. This happened to me last week and it made all the struggles over the last 8 months worth it. But the real heroes are the engineers on the product team. They put in the real work to realise, shape and rationalise management’s vision. It was gratifying to send pictures and emails to the team letting them know that their work mattered and is being showcased at the highest level.

It’s only after shipping that the real analytical work begins as we try to answer the following questions:

  1. Are people using the new features?
  2. If yes, how much are they using it?
  3. What amount of use makes an investment in a feature worthwhile?
  4. Are these features bringing new users to the product? – If this was a goal for the release.
  5. Are the new features usable?

I try to get question #5 answered via prerelease testing but all the other questions are truly answered only after the product reaches the customers hands. I know that #4 was not a goal for this release.

Q3 is always tricky. Sometimes you invest way more resources into a feature that you anticipated at the beginning of the cycle. This is just the engineering truth. You discover usability issues late or the engineering team discovers workflow issues that we did not think of before hand.

Sometimes you find a single bug or a performance issue that prevents you from shipping a feature that you worked on for 4-8 weeks. This is still not bad considering that only a few releases ago we would have wasted many more months of work since we were were following a waterfall approach. Every time I run into such situations I feel proud that we develop software incrementally and send it out to a set of users for testing every month. This validates our assumptions earlier and allows us to discover issues earlier. And, that is worth the pain the process changes bring with them.

Typical travel

Travel is a key part of a product managers job. Especially if you have worldwide responsibility for your product.

So why do we travel so much:

The biggest bucket is to meet with customers to

  • Understand how they use the product, which is normally different from how you envisioned it 🙂
  • Bounce of new product and feature ideas
  • Idea discovery

The other bucket is office visits for

  • Discussing and presenting product roadmaps
  • Politicking or gathering support for your ideas
  • Building relationships with folks with influence in the office

Final bucket is outward facing product management function that require you to travel to:

  • Train sales team
  • Ensure marketing messaging is consistent with product features
  • Meet with press, bloggers and influencers


As much as I enjoy traveling, here’s how travel can get taxing. I spent almost 16/52 weeks outside India last year. I’ve already traveled almost once a month in the first quarter of 2013. Here is my travel calendar for the last 15 months and the coming 3

Date Country Duration
Jan-12 US & UK & Ireland 2 weeks
Mar-12 NZ 2 weeks
Apr-12 US & Malaysia 3 week
May-12 UK & Germany 1 week
Jun-12 France & US 2 weeks
Aug-12 US 1 week
Sep-12 US & Netherlands 2 weeks
Dec-12 US 1 week
Jan-13 Japan 1 week
Mar-13 Thailand & Maldives 10 days
Apr-13 US 1 week
May-13 US 1 week
Jun-13 US 1 week