Measuring Impact: Let's make it easy

My Documentation checklist says, "Why Business Success Depends on Being Thorough."

Being thorough - the easiest part. Think of more scenarios, corner cases, first-time experiences, peak experiences, and end experiences. 

Depends on - harder. Most people don't put enough effort in thinking this through and most of the time there are fewer critical dependencies, so you're saved. Still think about dependencies on upstream and downstream systems. 

Business - easier to define who is asking for it, or what this feature can help with. Subjectivity is easy. 

Why - Hard. Most people get the "What" right. They skip the "Why". E.g. User wants to filter the list based on a date range. Ok, but why? Why would they want to do that? Why would they want to see the filtered list? If you don't know - Ask! Don't imagine. If you imagine why a user would need something because you've already been told to build it - you're likely to imagine a problem that fits well with your version of the solution but doesn't really exist in the real world. 

 E.g. Bad reasons: The absence of a feature is not a great reason to build the feature. E.g. We need a search function because the user is unable to search for <xyz>. Doesn't explain why a user needs to search for <xyz>.   

 E.g. Bad reasons: It's a standard expectation. E.g. We need sorting on columns on the tabular view. Sorting is great, I like it. But, calling it as basic expectation is running away from thinking under what scenarios will a user want to sort the data. It makes you figure what all types of sorting will be needed. What should the default sort order? How does it go with pagination etc.  

What you need to identify and analyze is "Why" and then document it. And it doesn't end here. You should now quantify the problem. How many users have this problem? How frequently will a user need such a thing?

Success - Hardest. Here's when you define the success metric or measure of the impact of a feature. This is what most people find the hardest to determine. The fact is also highlighted by Rich Mironov. 

Two approaches:

1. Derive from Why? because they've mostly done a poor job of defining the why. If you've defined the "Why" really well. You'd know what success will look like. 

2. Quantify Usage: If the impact is tough to quantify, you can try quantifying usage. How many clients will adopt this? How many users in each client will use this?

Quantify using General Metrics 

Try to put your outcomes under one of the following categories - ACME

Acquisition - how many new clients, new users will this help in acquiring/adopting. 

Conversion - how many new clients, new users will convert due to this.  

Monetization - how much uptick in revenue can we expect due to this?

Engagement - how frequency of usage and/or quality of usage increase because of this feature?

Quantify using the Value System 

Most relevant in B2B: The Value Matrix, main categories of customer benefits. Based on the work by James Andersson et al in the book “Value Merchant”. [Have read the book, this is roughly what it is. But it is not called out in the book, don't sweat looking for it.]

Increase revenue

Reduce cost

Improve brand (virality, user delight)

Minimize risk (future costs/losses)

Setting up the Metrics (copied from internal memo)

Get Goals right! -- most critical to get this right. Be honest about why you are doing this. At this point, typically, we are mostly doing stuff to unblock sales, implementation, and retention (by building what was promised). First list that out. If you think the feature has the potential to do more, add another goal about how it can be upsold, convert other clients or engage clients more frequently.

Good Goals v/s Bad Goals 

• Whatever gives one-time value is a Bad Goal from the product's pov. 
• If the goal doesn't lead to a multifold ROI, it is not a good goal.  

Get the Success Indicator right! -- this should answer the question "What would indicate the Goal is getting achieved?" If your goal is improving experience the success Indicator will either be something like improvement in NPS or more frequent usage. In most cases, you'd have to make it quantitative. Don't put hypothetical metrics that you'd never be able to calculate. Like if you aren't already measuring NPS regularly, what's the likeliness of you measuring it for this feature specifically. 

Get Current Values right! -- Current value is the baseline. If you say Faster Implementation, you should state how much time it takes to implement right now. If you say increase Retention you should state what is the Retention right now. If you get the baseline wrong you won't be able to measure the change later on. If something doesn't exist, look for potential usage. E.g. there is no favorite in Team Calendar. A good proxy can be that Adding favs should increase views on the Team Calendar. Of course, the best metric would be how many users actually mark any favorites.

Get the Milestone right! -- Milestone is the estimate of impact. If you don't get this right, you haven't really understood the impact of the feature, which means you might have got the priority wrong as well. So, how much revenue will be unblocked? How much NPS or feedback rating do you expect to improve? How fast would the implementation become? It should have an exact date when you want to measure and exact targets that you'd measure against.

PMs, Problem Discovery is where you are losing out

Product Management gets a lot of flak for not gathering the requirements correctly. The prime reason is that problem discovery is Hard, and PMs take it lightly.

This is what makes it hard: 
1. Customers are confused about what they need versus what they want versus what they are asking for
2. Customers aren't able to articulate clearly - often not their core skill 
3. Most customers describe solutions they want you to build instead of the problem they want you to solve
4. Product guys are biased by their limited product and domain knowledge. They look at new things with the old lens. 

Understand the problem-solution continuum 

If your vision and roadmap are not clear for the product. All your work, including client communication, requirement gathering, and problem discovery, will be very sacrificial. You need to have a very clear understanding of: 

• What are the general problems in the domain
• What are the general problems of your customers and of your users? 
• What specific problems is your product solving 
• What specific adjacent problems is your product not solving
• What are the alternatives being used today (direct competition (Coke v/s Pepsi) and indirect competition (SaaS v/s Excel), and alternatives (Netflix v/s Uber v/s Wakefit))

When you understand the problems and solutions in the domain, you’d be able to understand whether to push back on a request or add it to the roadmap? It will help you know if you should dive deeper in to it and start requirement gathering or request the clients to gather their thoughts and schedule a meeting when they are more mature.

Get answers to “Why” without asking Why. 

• 5 Why’s are super helpful in lab conditions. However, like our brain, in our conversations as well, we need to prioritise emotion before logic. Asking Why and getting a useful answer is super hard. Asking “why" forces people to think things they haven’t thought through earlier. Thinking creates friction. It may also make them feel stupid, or they may feel challenged. It causes cognitive dissonance as their initial reasons may not justify the original ask. Some clients feel you should not even ask “Why", it is your duty to do it, since they asked for it. This is mainly because that’s what they may be doing in their role. They may not have a clear answer to your “Why”.

• 
  

Alternatives to asking a direct WHY question

• How would this help you? 
• What will you achieve with this?
• What is the problem you are trying to solve with this?
• What kind of decisions would you take if this was available?  
• Let’s assume we have this today. How will you use it, and what will you do next?

Listen to understand, not to respond. 

• Clients may have very wrong assumptions about your product. It’s ok. Listen completely and take notes.
• They might ask for a feature that you already have, but they have never used. It’s ok. Blame the discoverability of your feature.
• When they complain (or rant), try to understand why YOU are not able to feel the same pain. 
• Error Messages: When they don’t read the message and take corrective action, think about how you can make the error more understandable, instead of just more readable. Can you suggest an alternative action?

Solve Problems.

 Your product is an enabler, not a constraint. Clients look up to you as a problem solver. 

• Don’t explain your limitations and constraints. They may be important, but they don’t sound interesting and do not encourage the client to convey more.
• Ignore your mental screams that “this is not possible”, “this is not what you created the product for”, “you never asked for it earlier”. All of it may be true, but it hardly matters.
• If you cannot immediately think of a solution on how you can enable them to solve this, just listen and take notes. Tell them you’d work on it and come back to them later. Helps you give a better response and avoid conflict.

Design for sales not users

Focus on the User may not always help. It reduces your scope of thinking. Focus on selling might help. It's almost Amazon's "work backward" model applied to "designing". 

Creating designs for sales vs creating them for Users. 

I am saying DON'T BE USER CENTRIC ... (Don't shoot me yet)...for a little while. 

We are NOT talking about implementing a design that isn't user-centric. We are just keeping our protagonist on the side for a little while and working on the promo poster of the film. 

Thinking about users brings in a lot of clutter. 

There are typically a bunch of different things you need to think about:

1. What's the persona: who exactly is using this feature and why? 

2. What are they hiring this product/module/feature/screen for? 

3. The main flow, additional flows, error flows

4. Some navigation constraints like where are they coming from, and where can they go from here. 

5. A few product constraints around what information we traditionally have or do not have

6. A few constraints based on timelines, and scope 

7. Finally maybe some constraints based on the technical capabilities

So as a first step, we don't design for the user. We imagine our product already exists and users are using it. We need to simplify and show something that is clearly much simpler and can be used in a print ad or a TV commercial. With 4 out of 5 sponsors of all large tournaments in India being mobile app companies, it's easy to find inspiration for how people simplify their complex user interfaces for showcasing the use case in TVCs.

Example:

PayTM actual screen v/s the Screen on Ad 

 v/s

When you design for sales, you just want it to have the following:

1. It clearly states the value achieved by the user. 

2. It is aesthetically pleasing. 

I am not saying these can't be done in a user-centric approach as well. Just that it usually gets lost in the clutter, and what you get is a dull and boring design that functions really well. It's almost like you stack the cans, arrange the snacks, order the food and then forget to party. 

Starting by creating for sales helps you create some really great UI, that impresses. In fact, the first version of the product may look completely different from the UI you've created for sales. Well, it's not for the sales team to actually use it (while we do sometimes end up showing it during high-profile deals). It is for the product and design teams to use it for internal selling. We can call it a North Star UI. 

How to do it?

What is the final outcome/value achieved by the user?

What will the screen look like, at its glorious best?

What is the most relatable information/term/output on the screen?

What is NOT immediately screaming value?

This has helped. 

Try it, and let me know

if you don't find it helpful. :-) 

List of some speaking engagements I've had

Someone asked for links to any past speaking engagements and I was hoping to find a couple. To my surprise, there were a bunch available online. :-)

Most offline events are either not recorded or the recordings are never published online but here are some online and offline ones that were captured over the years and are available. 

Short Workshop on Idea Validation: https://www.youtube.com/watch?v=LHfCWY-eAIw,

Moderating a panel during Product Week (ADPList) - https://www.youtube.com/watch?v=lPSt6stl0wE

Snippets from Funnel Analysis Masterclass - https://www.youtube.com/watch?v=G8UFpYvEqZA

Live session on Product Management 101 - https://www.facebook.com/watch/live/?ref=watch_permalink&v=1084671915223183

Podcast on Product Thinking - https://pm-powerconsulting.com/blog/product-thinking-trifecta-with-ujjwal-trivedi/

Short Workshop: How to create MVP - https://www.facebook.com/watch/live/?ref=watch_permalink&v=884902488909378

Moderating a Panel for Headstart- https://www.youtube.com/watch?v=RxQi1Qd1vIQ 

Just keeping it here for my own quick reference. If you recently found this blog, you can skip these and go read some stuff here and on medium - would probably be more useful.  

Product Management Learning Track @MoveInSync

Once upon a time, I thought I should start a product management course too. There are hundreds of cohort-based courses out there now, but I am talking about a time a little before PM courses were being sold on Fiverr. When they still seemed rare and valuable. 

I recorded the first PM-related intro video in 2015 for an ed-tech platform that doesn't even exist now. Over 2k people loved it and rated it 4.9/5 stars. If 2k looks too small a number to you, let me tell you that it would have been about 10% of the market share then. I was also consulting some big brands for setting up the curriculum for their upcoming product management courses. I also taught classes at some of those "very academic" courses - mostly delivered by folks who come from large corporates. I was invited for giving "practical" insights. So, it shouldn't come as a surprise if I had a feeling that I could do a few notches better than them. 

So, I planned the entire thing, but then, something wasn't adding up. I figured people buy what they want, not necessarily what they need. I strongly wanted to give them only what they need. Unpopular things like ignoring "RICE" and "MoSCoW" frameworks early on, and prioritizing by deeply understanding ROI. 

The guys who wanted to sell my course wanted me to do stuff that would sell. But, I figured I don't want to teach that kinda stuff. I actually did not want to sell at all, I just wanted to teach. I also know that anything done for free gets taken for granted. So, I could not do a free course either. 

Where could I get a sincere audience who would take stuff seriously without paying for it? 

EVIL PLANS

I once got a call from one of my reportees at MoveInSync. She was ranting about how she has been spending week after week firefighting. And I asked her if all this fire wasn't there, what was her plan of action. She had none. While she was puzzled, I was smiling - the smile you have when you get an evil idea. I had 10 reportees at that point and I could see all of them struggle with one thing or the other. Here was my audience. And a great opportunity, because we wanted to build a kickass SaaS product, that can have a "Global" appeal. 

One beautiful thing about MoveInSync culture is that it is very open. Thanks to my reporting manager Videh, at that point, for encouraging me to begin experimenting with a learning series for all young PMs. After a few experiments around a classroom-style model once a month, I figured it's extremely hard to maintain consistency by teaching a common topic to a diverse crowd. I wanted to do something that helps people subscribe to the learning, and not force people into it. 

So here are the details of what eventually worked (and is still WIP). 

12 SKILLS, 12 MONTHS

Some numbers just fit. I found this popular blog from Ravi Mehta. 

It talks about 12 skills that a PM should possess and practice and how the expertise required in each skill changes as you ride up the career path in product management. As you'd have guessed 12 skills in 12 months looks like a perfect fit. 

Without getting into the debate of the accuracy of this, I'd tell you how it became immediately useful. It was a good way for everyone to do self-evaluation and identify what skills would they want to work on. 

And so, we planned a monthly one-to-one check-in with me - where everyone will review themselves on all 12 params. I'd discuss my evaluation of their skills and gaps. Then we mutually decide what they'd like to focus on learning in the next 1 month. 

Monthly plan

• Learners should decide and announce what skill they'd focus on learning. 
• Learners should then study the topic and eventually apply it in their daily work. I'd help get them started with a list of books, podcasts, blog posts, and internet resources that I have saved for my own reference. These are usually things that I have re-read multiple times and have personally found very beneficial. Here's the index. Every time we decide on a topic I send them links from here. And of course, this is just a start. The curious folks, keep double-clicking on the right things and find their own treasures. 
• They should take notes, take snapshots of "before" and "after" for things they seem to have clearly improved upon, and register it in the workbook (mostly a shared spreadsheet) so that we can discuss it during the next check-in. 
• Learners should also plan to discuss the topic all through the month with peers and managers to internalize it and apply it effectively.  
• At the end of the month, we looked at the notes, discuss progress in self-evaluation and decide what should be picked up next. 

This has been really helpful in improving the baseline of product management know-how for everyone in the team. It also gives people enough time and motivation to keep learning new stuff and to keep applying it. And probably I'd skip the part where I tell you how effective it has been for creating an amazing product culture at the organization. I am sure you can imagine it. 

NUANCES

This looks like a perfect plan, but, it isn't. 

• Not everyone finds this 100% useful. So, it is OK if they would like to take up a different skill like Tech/Digital-Marketing - it can quickly be structured in a similar way. The understanding is that you are upskilling yourself and making defined, structured progress.  
• Not everyone learns at the same pace. So one can be flexible. Remember there are no annual term exams at the end of the 12-month period. So, it can pretty much be self-paced. People can also take a sabbatical from this and join back the track at any time because everyone is working on their own set of skills. 
• Not every skill is immediately applicable. There are some skills like documentation that you get to use every day, there are others like road-mapping which may not even apply to a team member (based on their designation).
• Learning some of these skills (most of the last six) is subject to opportunities. Learning about team leadership is one thing, but actually leading a team of smart folks is another. You only get the experience, when you get an opportunity to do it. It may happen within the course of a year, and it may not. I strongly believe that success is when "opportunity" meets "preparedness". So while one may not get immediate opportunities, one should prepare for them long before one actually gets them. That's what I continue to do for my own learning as well. I read stuff and learn things that may not be immediately useful, but could be useful someday. Also, as a manager, I try to get my folks that opportunity in some form.  

I just thought I'd open source this initiative so that more curious PM leads in different organizations can build more useful, impactful stuff on top of this. 

I'd love to know if you do that, and/or if I can contribute further to your cause. 

--------

PS: Leaving a comment/question helps the author get the motivation to write more. SO DO IT!

After the ProductHunt Launch

What to do after launching on product hunt? 

This is what I looked for and figured that I was too late. And if you have launched the product without a lot of good preparation, you've missed the bus too. 

However, all is not lost and this post will still help you salvage the situation to some extent. Also, if you haven't yet - you're lucky. This is going to be a very powerful set of actions you can take immediately. 

CONTEXT

So our marketing team had a real good run with the listing sites like G2, Gartner, and the likes. And they thought they now know how things work. And hence one day I got to know that one of the noobs from the marketing team has hunted our product on ProductHunt. Facepalm! 

Despite our best efforts, we missed getting any meaningful ROI. However, every failure is learning. So, I picked up all the gyaan I could gather on the topic from successful Hunters and wrote a memo to my Marketing Team about what happened and what to expect now. I feel many other noobs could find this useful so I am reproducing it here. 

Here's the Memo: 

(Have removed some parts that don't make sense for a wider audience)  

Unlike listing and product review sites - PH is a LAUNCH platform. We chase a #1 Product of the day tag - and it's a 24-hour game. That's about it. If we get that badge we can use it for a long time. If we don't, we're done.  

We ended up being 12th on the day. The rating depends a lot on who's hunted the app and who is commenting on it. Upvotes also help - we did decent with the numbers, but we need more genuine upvotes, more meaningful conversation happening on the page, and finally more demo signups from the page. 

Next steps. 

This launch is done. Nothing more to do.

Next, we can launch new versions (after a few months), lateral products, and peripheral Products like (<some side product ideas, including case studies converted to ebooks etc> and all of them lead to the same landing page, etc. 

Here's what works better: 

1. Animated logo - gathers more attention. H/T @naz_09

2. Get hunted by one of the Top 10 hunters 

3. Prepare for launch - have a PH landing page that incentivizes upvotes (like a 30% off) for 3 months. 

4. Prepare for launch - have PH Launch e-mailer ready to be shared with existing and prospective clients so they can leave comments and hopefully upvote. 

5. Prepare for launch - Prepare employees to sign up on PH, and use it like they would use the platform. Instead of most people being new signups - only to gather upvotes. 

6. Prepare for launch - Keep social media and personal posts ready where we talk about PH launch on our social handles. 

7. Prepare for launch - identify top people in the category and reach out to them to check out the product and upvote/comment. 

8. We have to time the launch in a way that provides good overlap for both employees and clients. (6am EST is a good time) Also, doing it over the all-hands meet could be a good idea. We get 200+ live audiences on that.

9. And we have to ensure most people are not using office IP address, otherwise the traffic is probably discounted (no one outside PH knows what happens for real). 

More elaborate ideas on how to fill the form - https://medium.com/swlh/product-hunt-101-426511f03501 

HTH!

-------------------------

If you found this helpful, do leave a comment for the Author. Otherwise, you'd never make it to the #1 spot. 

Building Empathy as a product manager

Source: Oliver Clink

Empathy is the ability to conceive the right product for the right people at the right time while keeping the team super excited. Execution and delivery need much more than empathy - but that's for another day. 

How does one build empathy?

I've followed a lot of contemporary product guys and discussed with them what differentiates great PMs from others who also write documents, analyse data, coordinate with stakeholders and get things done? And the answers lead to their skill/ability to empathise with the user/ stakeholder/ reader/ audience/ team. I firmly believe, and it won't be hard to realise for you too, that how you do one thing is how you do everything. So you can't possibly be doing a great PM job for your users, if you aren't also empathetic towards your team and other stakeholders. 

While your job involves a lot of pushback and "Saying No", that's certainly far from meaning that you stop listening. You don't exist to pick battles and win them, you exist to create a balance in feasibility, viability and usability. The negotiation hat comes in only after you've been super receptive to what people need and want - not only from the product, but also from you (you are also a product). 

When you are being empathetic, it shows up in your communication, in the documents you create, in the designs you make and in the metrics your measure. 

Conscious effort to be empathetic is all it takes. Ask "why" and "who for" more often. You need to put it in daily practice. Here's a few things that can help you get better.  

Get deliberate exposure

Get out of the building

Get into the calls, meetings, visits where you can see, meet and talk to your users and understand them better. Make it a process. If you aren't going out of the building you'd never reach their heart. If it's not part of the process it won't happen regularly. 

Make it a process, put it on your calendar. 

Listen to feel

You are responsible for the emotion. You have to feel what they feel. If you don't feel pain, regret, guilt in a support call of a useful product, you aren't listening hard enough. If you aren't getting a lot of product ideas while thinking about the conversation, you aren't listening hard enough. Listen to what they say and also what they don't put in words. Look for patterns, if more than 2 unrelated users say the same thing - one should get alerted about a possible insight.  

Articulate user responses

Empathy Map

When thinking of your user's journey through a task - check at every step what the user Says, Thinks, Feels, Does. That's a great framework to understand the user and also to convey your understanding to the wise folks around you. 

Eat that dogfood

Source: Reddit

If you aren't using the product "like a user", you can't get it right. If you are creating something for a delivery boy, use the phone they use, get out in the sun/rain, drive with them. Unless you do that, your requirement gathering is incomplete. 

Forget your product

Forgetting is a superpower

This is powerful. How easily can you forget you have a product and articulate the exact problem your user is having. Don't try to tweak it in terms of the solution you have. We generally practice filtered listening, we note only what is relevant to our product, our beliefs, and our roadmap. A good indicator that you are able to forget the product when listening to a user is that you'd learn about 2-3 non-relevant problems of the user as well.  

Appreciate Art

A great way to be more empathetic is to improve your emotional vocabulary. Humans have 34000 emotions, how many you name? Refer to this amazing guide of Emotions. If you are able to observe your emotion and decide whether you are irritable or angry or disappointed, you help yourself win the emotion as well as get more empathetic. A good exercise is also to try understanding art - not just enjoying it. It could be music, painting, movies, poetry - or anything that you deem creative. 

--

Show the author some empathy, drop a line.