Posted on

Your step by step guide to building impactful products!

Why do a lot products fail, and why do some of them succeed and do so well? What is it that kickass Product Managers do that makes them get such high output in less time, that average PMs would otherwise take large amount of time, and features to achieve?

The usual process for a product manager before building a feature is the identification of the problem the user is facing through various qualitative/quantitative means(the WHAT), moving on to find the possible solutions(HOWs), and then the execution of some of the features from the list of features that they think are higher priority features. But what they pay very little/no attention to is spending on predicting which solution shall work the best. The third step doesn’t have to be a subjective, but a very objective call to achieve high output.

Apart from design, analytics, UX, business and technical specifications, this strategizing of picking the right features is a very important skill for a Product Manager to know.

The next few steps going to serve as your kickass guide, which should help you predict the impact of features well before building them. Use this guide to build impactful features, in interviews, to impress people, whatever works best for you 😉

Know your funnel

To be able to get a good and broad understanding of the user journey in your product, it is important to know the various stages of your user and the number of users in each stage. A very basic user funnel in any product can look like:

Visitor -> Lead -> Activated -> Converted

For instance, on an ecommerce platform, a user funnel can look like the one below:

Knowing the number of users in each step of the funnel will let you know where your users are actually dropping off, do the analysis on why they’re dropping off and then build your tasks accordingly.

As you can see in the funnel above, one such prominent problem is that only 3% of the users complete a purchase even after adding the item to cart. It, hence becomes an important problem for the ecommerce company to solve.

Bucket features

Before you build a feature, try to bucket them on the following lines:

Necessary: Is there a feature that has high financial impact? Is there a usability issue for the user that I need to solve? Is there a feature that will significantly reduce the effort of my sales team? If there is a feature that solves any of the problems on these lines, they need to be picked on highest priority.

Experiments: There are features that you think can make it big, because of various reasons(because of data backing it, because you’ve spoken to the users who feel there is an issue with the product, it is a hunch based decision), but are not very sure of how well they shall perform.

For features like these, it is important you perform experiments to validate the impact.

For instance, say you think launching an offers section in your app will result in higher number of people making a purchase on your app. You think so because your competitor has had offers on their app for quite a while, and have in fact given them high visibility. But because you are not sure, an experiment can help you validate this hypothesis. Showing your app with the offers section to half of your users, and without the offers section to the remaining half will let you know what upside the offers section brings to your app, and whether you should have offers in your app or not.

(Experiments can be done through A/B testing, you can read about it further here)

Hygiene features: These are features that have to be present in the product, and will most probably not have impact metrics attached to them. For instance, my account page, terms and conditions, cancellation policy, uniform design guidelines in the product, research on a new analytics tool etc. in the product. Their impact doesn’t need to be quantified, but the validation can be simple on how many users actually use the feature.

A good mix of these features usually makes a good roadmap for building a product. I typically distribute necessary, hygiene and experiments as 60, 20 and 20%. Going extreme on any of the three verticals in a given timeline is usually not recommended. Why, you ask? Say for instance, you only pick 100% validated necessary financial tasks in a quarter, because you aren’t picking any experiments. In this case, your company isn’t doing any innovation and hence won’t have a USP in the long run. Also, because you haven’t picked the hygiene tasks, a lot of priority user problems will end up staying unsolved.

Similar argument can be given for other cases.

Quantify features

Before building any feature/product, try to come up with the following statement about the feature:

“This feature will improve the X Block by Y% in the next Z months”

For instance,

“This feature will improve the Visitor to lead % of the product by 0.5% in 2 months”

Remember, there is no feature in product that does nothing. If it actually does nothing, you shouldn’t really be picking it in the first place. Quantifying the impact of a feature gives you a good sense of whether you should really pick, and which ones you shouldn’t.

Looking at the impact of the features after you’ve built them will always have bias on what impact metrics you should be looking at. You’ll only end up looking at the metrics that have improved to self-justify yourself, and not at the blocks that actually matter. You don’t do this on purpose, you do it because it is human nature to really like what you’ve built and think what you’ve built is successful.

Once you’ve quantified the impact before building a feature, there’s no scope for you to do sales, even to yourself. Because you can now be very objective in the impact of the feature, and do its root cause analysis.

Most importantly, quantifying the impact helps you prioritize and pick the right features before building them.

Benchmark the impact of the features

But wait, the immediate next question that comes up is, how do I predict the impact of the features that haven’t been built? Yes, it’s a tough task, but it can be practiced and learned with experience and hard work. I use the following techniques to benchmark a feature:

1.      Identify what are the metrics you’ll impact: For instance, if you change the color of your chat head to give it more visibility in your app, it’ll result in more number of message sends which might eventually result in more number of conversions. The former is called lead metric, and the latter are called lag metrics.

2.       Predict how well your features will perform: You can use any of the following techniques to be able to do so:

a.      Previously launched features: If you have the learnings of the impact of a similar feature that was launched previously, or the same feature launched on a different platform, you can use them to predict how your feature shall perform.

For instance, you can use the learnings of how well the offers section performed in your android app, to better place the feature on your desktop/mobile site/iOS app.

b.     Competitor analysis: If you want to introduce an offers section in your product, the placement of this feature can well be decided where your competitors have placed this feature, and why.

c.      Experiment: If an impact of the feature is not known, try and experiment your product with and without the feature. I’ve explained experimentation before, but the success/failure of the experiment shall help you gauge on how the feature shall perform if it is fully rolled out.

d.     Guesstimate: Do a plain guesstimate of how well your feature shall perform, if it’s an absolutely new feature, or space that you have no idea of. Remember the questions they used to ask us in interviews? Estimate the number of cabs in India? Similarly, try and do a rough estimate of how many users, which user segment shall use your product and why.

Make sure, keep in mind variable factors like seasonality, varying tax policies etc. that aren’t in your control, but affect the impact your feature shall bring while you do your predictions.

A snapshot of how a roadmap can look like basis the techniques above is given below:

Validate

Needless to say, once you’re done launching a feature, spend time validating the impact of the feature/product you’ve built.

Once you’re done validating, you should have an answer as to why your feature achieved what it was intended to achieve, or why did it underachieve/overachieve.

Use these learnings in the next feature/product you build. Repeat!

Phew, long read, wasn’t it? But I really hope you learnt an important aspect of strategizing and prioritizing in building impactful products. 🙂

Posted on

Aye Product Manager ki honda hai?

At a usual evening at a Punjabi wedding, where random aunties are scouting for their next eligible damaad or bahu – I was spotted and probably liked by a Punjabi aunty from a distance; she stared at me for long enough till the time I took notice of her, came to me with a smile so bright as if she just brushed her teeth and wanted to show off, asked me “Puttar tusi kya karde ho?”(What do you do, son?). I politely replied, “Aunty I’m a product manager”. Aunty hadn’t ever heard of this term before, as the only profession she’d probably of was an engineer. Perplexed, she asks me “Puttar aye Bank manager taan suniya si, Aye product manager ki honda hai?” (Dude, heard of a bank manager before, dafuq is a product manager, really?!). I died laughing the moment I heard her say that. Though I did try to explain what we do, she seemed quite dissatisfied while I explained. Since none of her neighbors knew what a product manager was, I was immediately struck off from her prospect daamad list.

But when I came back home, I did realize that most of the people in some of the best engineering colleges, and working professionals don’t quite have a clue on what a product manager really does! Sadly enough, one of the major reasons is the lack of literature around, and the difference in the definition of Product management in every article you read, or every product manager you speak to; since the definition of this profile varies quite a bit in different product companies, and the kind of the product you own. So what does a product manager do, really? Ai Product manager ki hunda hai?

A simple Google search ‘What does a product manager do’ would very likely land you on an image like this:

A broad highlight of what a Product Manager does
Definition of a Product Manager

But hey wait, there’s LOADS more to it! A product manager works with Engineers, designers, business and marketing people, the customers, legal and finance folks, and the analytics teams to build a feature, or a product. Wait, what?! How does one PM be in touch with so many teams? There’s a reason why this is a super hero role, needs so much experience to be good at and why a PM is called the CEO of a product!

How does the work of a PM feel like on an average day?

Any Product Manager, consciously or subconsciously tries to figure out the what, why, how and when of the feature/product (s)he is building.

What: A PM tries to understand what is the problem to be solved, and by what means. It could be by speaking to the customers and doing a user study, by doing an elaborate analytics of the current feature to see what and where the flow of a feature is broken, by doing a competitive analysis, and by speaking to the stakeholders within the company who shall be impacted through the feature. Basis this, he decides on what is the feature that needs to be built.

Why: While a PM decides on the what, he tries to focus on the why of the feature being built, in the process of his research. Why this feature? What metric will it solve? Will this increase the retention of the product, or will it lead to more people paying on the product? How many people would adopt to the feature? What is the target audience of the feature like? There are some of various questions that are catered to in the process.

How: Once the ‘what’ is decided, the Product manager will work with the designers, engineers to move on to detailing of the feature/product. This shall involving wireframing of the feature, deciding on the flow of the feature, think of hacks that need to be applied to launch fast and understand the constraints of building the feature from the engineers and designers, if any. He then writes the elaborate specifications to the feature which are consequently picked up and built for execution. You’ll also need to setup the analytics that is required to validate the success/failure of the feature, and at times understand the financial and legal aspects of building the product.

When: Basis the how, the product manager decided on the versioning of the feature, and what shall be the timelines like for building the feature.

Phew! That’s a lot, isn’t it? But what are some of the traits that you’ll see in all good PMs?

Collaboration: No, a Product Manager’s role isn’t a leadership role. It’s a collaborative one. You’re going to speak to various stakeholders in the company, and will try and align them to your line of thought. But you have to take into account the impact that it shall have on them, and what their perception is of the product being built. Though your stakeholders don’t have a direct call in the product, their say in the product cannot be ignored.

Decisiveness: You’re going to be taking decisions everyday. There are going to be a few Yeses and a lot of Nos. There are going to be truckloads of opinions that you’re going to get everyday, and though you have to, and should listen to them, it’s going to be your call to give direction to the product. There are going to be good decisions, and there are going to be bad ones. If you take the bad ones, you need to accept them fast and iterate faster.

Prioritization: There’s going to be loads on your plate everyday, and you have to learn the art of prioritizing what you do in a day, one task at a time. There are a gazillion improvements that you can think of on your product, but you need to prioritize the ones that’ll bring the maximum impact.

Numbers/Analytics: This is something that most Product Managers need to be good with. Whether it’s making a top down story of how a feature is going to perform, or validating a feature, or speaking to any of the stakeholders, you have to know your numbers and metrics really well. Without the numbers, your talk is just going to be loose talk.

If you’ve come this far, I hope you’ve been able to get a broad sense of what a product manager does, but it is one dope role to work in 🙂

Posted on

If you think you don’t need analytics, you do need analytics!

I’ve lately spoken to a large number of early stage startups to see, and understand on how they build their ideas to execution, and product. Every conversation has been a learning experience and has only given me better perspective on technology, business and life.

A few common traits that I observed on all of the founders was the great emphasis on the pace of execution, the zeal and passion in how they talked, a detailed understanding of their customer, and depth of why they’re trying to solve the problem that they’re solving; traits that excite me to bits!

But there was another common trait that I noticed when I went a little deeper in the conversations was that the emphasis on analytics in most of the startups was minimal; which was alarming, but not surprising for me. Most of the founders, though broadly know that they need the analytics in place in their product, but don’t put it to execution. But wait, why is that so?

  1. Because we don’t exactly understand how getting the product analytics in place is going to impact the business, and hence the ROI doesn’t seem worth it. It isn’t the founders to blame either; before working in Product, it didn’t intuitively occur to me either that just improving the positioning of a call to action would actually improve business.
  2. Because viewing the numbers, learning the analytics tools is a job of patience. Because getting those events in place, and trying to drive conclusions can at times take time and practice.
  3. Because getting traffic/building traction is subconsciously more important to us than engaging, and converting the ones that have landed on our product.

But why should one spend time on doing the analytics?

It’s the cheapest means to building better business right from the start

Let me give you an example here. Let’s say you’re an e-commerce company that sells products in various parts of India. You probably know that the maximum traffic comes to you from Kerala, you know this data.

But your drop down which asks for the user city/state shows Kerala in the 7th – 8th position. You’ve just added extra friction for that Kerala user before he could even move to see your product; just by hard coding the top 3-4 traffic/searched cities, your business could have increased significantly.

Now say user finally does the search successfully, but the load time of the page is so slow that the user doesn’t actually reach your product page, which is your actual offering. There can be a gazillion examples like these, but we don’t spend time recognizing them.

It’s objective

We all have our biases in who, and how are customer is and we build our product basis that. Doing so in the first attempt, but iterating on your product just by this understanding isn’t the right approach, which is what I observed a lot of startups do.

Taking the previous example, the founder had a bias that users from North India, primarily Delhi are more likely to make a purchase from his e-commerce product, which later turned out that Kerala visitors used the product more.

Disassociating your association with the bias is what data helps you do.

It’s time saving!

Though it’s absolutely important to understand your costumer, speaking to them on a regular basis, analytics is probably the quickest means to understand how your user is interacting with the product! It helps you take product and business decisions quicker, saves you time and hence saves you money. Your time is expensive afterall 🙂

So as founders, the number of users going deeper in your product funnel should be just as important as tracking those GMV/install numbers. Spend time reading, and understanding them!