How to identify and track the right metric?

“To know how to measure the success, is to know how to achieve it”

A few days ago while discussing complexities of managing a product portfolio, Uday asked me a simple question: what is the most important metric one should use to measure product performance? I suddenly felt dumbfounded because I didn’t have a clear answer. Though I could have used my heuristics to throw suggestions such as ARPU (average revenue per user), engagement, and churn rate, I knew that the thought process was more important than the metric itself. A good metric allows taking action, a bad one only provides some data. So Uday and I decided to jointly answer this question by creating a framework, which Uday will illustrate with examples from his experience. So here are the four steps:

1) Define what the big success looks like

This is the most difficult step and perhaps half the work. This requires you to see the big picture and yet relate to all the parts. But you can perhaps do it much easily, if you start thinking of success in pure binary terms. So everything succeeds, if this one or two things happen right, else everything fails.

Uday: At my previous startup, I was looking at the dashboard which tracked conversion funnel. I knew that just looking at growth in number of visits, free users, and paid users would only paint a rosy picture, and not necessarily the most accurate one. Clearly, the single most important goal for my company to succeed at this stage was ‘growth in paid user’ and ‘longevity of paid users’.

2) Break down and prioritize on the basis of need and controllability

Now that you have one or two big metric from the first step, you need to start breaking them down. Once you break it down in different parts, start prioritizing on the basis of what answers your most pressing needs and what you can control. It’s okay to combine multiple variables to create a super metric.

Uday: I decided to steer away from vanity metrics like number of page views, which were simply non-actionable for me. I focused on 1)  (CLV), which captured engagement (longevity) and reflected whether we were on track to become a sustainable business (revenue/growth); I used cohort analysis for this. 2) Net subscribers (new paid subscribers – cancellations on a given day), which helped us capture change in two important things in one attempt – number of free users converting to paid users and cancellation (super metric).

3) Locate the right data and evaluate cost

Now you know what you want to track, you need to find information to do that. Remember, available information can be cheap, but retrieving it in desired format, not always. If some information is easily available and helps you answer ~85% of what you want to track, make adjustments in your metrics and go ahead.

Uday: Although all data was readily available, I had to make additional efforts for conducting cohort analysis with CLV (the cost!). Later on I got a dashboard developed to do the same, without having to resort to excel every time.

4) Develop, present, and revise

This is more like a hypothetical step, before you actually present the final metrics. Imagine that you’re presenting your metrics to someone important. Think the questions they would typically ask. If you are able to justify your choice of metrics and explain why you didn’t include a lot of other metrics, you’ve done a good job. Else, revise.

Uday: I made all the reports / dashboards simple, comprehensible, and differentiable. I was ready to answer questions like how I was already baking in conversion rate, active users, and paid subscribers in my choice of metrics. Sometimes I would separately include information for my marketing team which would typically ask for these baked-in metrics. Lastly, since cohort analysis was the basis of my analysis, I’d put a foot-note for those who didn’t understand it well.

Remember

  1. Understand the difference between absolute and relative terms. Often, we need a combination of both to create an accurate picture.
  2. See the forest for the trees. Your selection of information or metric should try to capture major trends, opportunities, or challenges.
  3. Don’t go online right away as you start brainstorming. You have to understand what answers your business questions, not someone else’s.
  4. Go online once you know what questions you’re trying to answer. Taking ideas from how others did it efficiently is good once you understand your problems better.
  5. Keep it simple. Does it require any explanation? 🙂

A well-thought metric allows us to deal better with uncertainty of decision making, with a precision of action. And the next time someone asks me to include another metric in my analysis, I don’t want to respond by saying ‘sure, I will include that next time’. Because everything which is necessary, would already be there!

(Co-author: Abhyuday “Uday” Chakravarthi, image credit: Dennis van Zuijlekom)

HackerEarth: an online technical sourcing and assessment solution – Sachin Gupta, Co-founder. #PNHangout.

HackerEarth is a Bangalore based start-up which helps companies hire programmers. It was started in 2012 by Sachin Gupta and Vivek Prakash, both of whom are alumni of IIT Roorkee. HackerEarth provides solutions for the technical recruitment space – one is an online assessment tool which is used by organizations to assess both internal and external candidates. Another solution acts as an engagement platform for companies when sourcing employees. With respect to internal candidates, companies typically use HackerEarth to conduct online challenges to assess their employees’ abilities. On the other hand, when we consider recruitment, there are primarily three stages during recruitment – sourcing where you source candidates, assessment which involves psychometric assessment, technical assessments, etc. and selection which is obviously where the candidate is selected. Our focus is primarily on stage one and two and our approach to these two stages differs from that of a typical recruitment agency. Our approach is to conduct an online hiring challenge. It is like an open test that we conduct on our community of developers. People come and participate in these challenges and based on their performance, we shortlist candidates. Since we began we have conducted numerous challenges, so we now have a large user base whose skill sets we’re aware of.

The test, or the challenge, as we call it, gives us a good understanding of a candidate’s programming proficiency. If they have performed well in the challenge, we know the candidate is good. We then aggregate their coding activities from online sources like StackOverflow, GitHub, etc, combine all this data to understand their core skills/strengths and we match it to a company’s requirements.

When we began HackerEarth, we were keen on working with early stage start-ups but we quickly realized that even if we give them good candidates, the number of hires wouldn’t be very high. So we decided instead to focus only on series A, series B funded companies. At that time InMobi, was a marquee client for us. Later on, Practo, FreshDesk, came onboard and we were able to fulfill their hiring needs too. We found great success in working with growth stage startups. Once we’d established some presence in the market we realized that the SaaS assessment tool could be sold to larger corporations too. Companies like Symantec and Citrix became our customers because our tool because of the time it saved them in assessments. Also, the product was much more stable and much more mature by then.

On the non-hiring front, we conduct exciting programming challenges which engages the developer community. We have a big following now. In addition, all the users on our platform are high on quality, high on skill sets and this in turn made sourcing from HackerEarth very effective.

Obstacles overcome:

The three main challenges that we have faced since we started-up are:

  1. Selection/Identification: As our company has expanded over the last 20 months, the most recurrent challenge that we have encountered is identifying our focus and priorities at different stages. If you can do this, you can actually build a very good company. When it was just the two of us, our challenge was to identify a MVP. We had interacted with a lot of people but there has to be a point where you need to sit down and start working on a product and in spite of this you will always feel that you don’t have enough information. You need to rely on your gut instinct and know why you entered that market or why you are building your product. Combine this with the initial user survey that you did to come up with an MVP and then proceed.
  2. Sales: Another big challenge for us was sales as both of us co-founders have a technical background and we had very little connection to the industry and even lesser knowledge of how to sell. In addition to the MVP we also needed to identify who are our target customers were because in many instances, potential customers expressed interest when we discussed our idea with them but their responses when we spoke to them after having built our product was very different. In our case especially, since we are a B2B solution in some sense, it was very important for us to identify our customer set as we were going after the entire technical hiring gamut. So we had to be extremely choosy. Now that HackerEarth has grown, we have a strong client base, revenue has been coming in and people are becoming more aware of HackerEarth. Building a good sales team was very important for us.
  3. Scaling: After a few successes, we realized that we needed to expand our customer base and accelerate in that direction. User acquisition is one of the most pressing things for us because we are essentially a marketplace as we have developers on one front and recruiters on the other side. It is similar to a chicken and egg problem. If you don’t have developers, you don’t have recruiters and if you don’t have recruiters you don’t have developers, so we have decided to focus more on getting developers to our platform and this is currently a challenge that my team and I are tackling.

Metrics is a must

Being a tech intensive company, the first thing that I would absolutely look for in a Product Manager is how driven the person is with metrics – you should be able to define what numbers you should be tracking, what are the time lines, you should be able to understand the sales figures, etc. By using tools like google analytics, he or she should be able to use a CRM to track sales, they should be able to use analytics to see how users are performing, they should be able to work with mix-panel and other tools to understand how users are interacting with the product and then be on top of these numbers because personally I believe product management is about tracking these numbers and making actionable decisions based on them.

HackerearthSecond is someone with actual previous hands-on experience with technology. If they still work with technology that is even better because sometimes, say you want to build a hack for marketing or you want to implement a small feature that your customer requested which typically would take say half an hour of work and you don’t want to disturb your team, you can go ahead and implement it yourself. So this is hands on technical skills, if not current, then at least experience with working with technology in the past.

Third is having domain knowledge. So somebody who has worked with programmers, somebody who can understand what programmers want and also understands recruiting because at the end of the day, the problem that we are solving is recruiting. We are helping companies hire programmers better. So if I can’t understand the pain point of a recruiter then I would not be able to build a product for them.

In addition, I believe that some sensitivity towards design is required. HackerEarth is a very design sensitive company. So the product manager also should understand what good design is. I don’t really expect them to create good designs but they should be able to understand what is good, what is bad and then work with the designer. One of the challenges of being a PM is actually working with the designer because designers tend to form a certain view point about certain things, so they are very passionate about what they see and sometimes what they see or what they feel or what they think or believe in may not actually translate to what the users want or what the business wants.

At the end of the day, being a product manager doesn’t mean you know everything. You could be wrong but to be a good product manager you need to be someone who is really passionate about solving a particular problem.

#PNHANGOUT is an ongoing series where we talk to Product Managers from various companies to understand what drives them, the products they work on and the role they play in defining the products success.

If you have any feedback or questions that you would like answered in this series feel free to email me at appy(dot)sg@gmail(dot)com.