Tuesday, May 30, 2017

Revisiting the PsychUp Checklist

Based on my previous studies I created this psych up checklist. It is for product managers to be able to quickly evaluate what their products are missing in terms of how well the products appeal to the Right brain of their customers/users. At a recent workshop I took, a lot of participants used it and I was able to find checklist items that people slipped on most frequently.

A lot of it may be due to not being able to understand it or not being able to apply it. I'd work to gather more examples and add more actionable steps so that every one can use it.

However, till that time here's the list of most frequently missed biases, and some of my commentaries.

Salience Bias - If there are multiple things seeking user's attention, the one that is most easy to understand or looks familiar is the one user is going to go for first. Hence, making the most useful feature prominent and most simple to use is very important. Your UI needs to drive the users to do what you *want* them to do.

Stereotype - Making it "look" like a winner. This is very common. Making UI look beautiful is considered one of the last things that people want to do for their products. It's ok. But, if you want to scale and you want users to perceive your product as more valuable, it is important to make it look rich.

Risk Aversion Bias - Making users feel more in control. It's again very important to make your users feel in complete control by talking to their fears and concerns. It's like people want autonomous cars, but I am sure they'd pay extra to buy the one which allows manual driving. Nothing in your product should scare your users, or even make them think or be concerned. Make sure they can reset to default settings easily.

Anchoring - Setting the expectations right. This one is difficult to understand and implement. It does require some diffused thinking and making iterative changes. It is specific to consumption and pricing.

Bandwagon effect - Providing social proof (this was a surprise!). I am surprised that people forget putting testimonials or social proof of who their current users are and what they think. It works like a charm if done correctly. Obviously, you'd have to keep it real and make it look as real as possible and it needs to "connect" with your TG.

Decoy effect - Introducing Decoy pricing plans to make the target plan look more profitable. This one is again a less used magical formula. When you add two price plans, add another no brainer high price low value option comparable to your target plan. When it looks more profitable than something, users end to think it is the most profitable. Higher conversions!

If you have had success stories or trouble using any of these do comment and I'd see how I can help you further. And if you haven't taken the Psych Test yet, now is a good time.




If you have reached this far you should totally leave a comment about how you liked it and share this post with others.  

Wednesday, May 3, 2017

How to create a data driven Product Roadmap?


A product roadmap is NOT a product backlog. So essentially it's not a prioritised list of tasks that you'd want to do. A Product Roadmap is Product Strategy. It entails, what is it that you are building, who for, and little insight about how? Are you going to cater to a wider audience in future or provide more value to similar set of customers that you are targeting now. I've tried to cover most of how one should be looking at the products (Problem-Solution Framework) in this video.

I've tried multiple ways of creating a Product Roadmap and have come to define a good way for creating a comprehensive one from which one can derive s.m.a.r.t goals. You know Goals need to be SMART (specific, measurable, attainable, reasonable, time-bound). And there is so much talk of being data-driven - just that not everyone has a clue of how to become data-driven. Most articles that I read about creating roadmap are about coming up with a laundry list of things and prioritizing them. You definitely need to do that but you might always miss out certain aspects when you go by that method. So, I came up with a framework to create a Product Roadmap that is both comprehensive and data driven.

Things I've tried earlier:

1. Doing a competition analysis and identifying list of features that need to be built. Prioritising it.

2. Collecting all ideas from every one, get every one to vote on them and then prioritise them based on Votes and Impact versus Effort analysis by tech team. E.g. Pandora does it really well.

2. Setting Goals based on the vision, deriving high level tasks and then create discuss, debate and decide priorities. This is actually much better than first one but it is not comprehensive. Your current set of goals may be too narrow or too wide.

You may still need to do some of it but these things have been very random.

Finally, to come up with a Roadmap that is both data driven and covers all aspects of growth I decided to draw it through the standard Metrics of Acquisition, Conversion, Money, Engagement (ACME). You'd still need to debate, discuss and document your vision, short term, medium term and long term goals. But, putting it in these broad categories gives you a good coverage.

Step - 1
Define your vision and tentative goals or themes in next few months typically next 1 month, 3 months and 6 months. This can be very high level -
E.g. 1 want to improve revenue
E.g. 2 want to optimise new user acquisition/conversion
E.g. 3 want to improve user retention

Bucket your goals in to ACME. You should have Acquisition Goals, Conversion Goals, Monetisation or Revenue Goals, Engagement Goals. In fact, if the vision is clearly defined you can just start noting your ACME goals. Start with high level as given in example and then break things down to smaller items.

Step - 2
This is good place to have lot of dependencies and conflicts. E.g. You might notice that you can't achieve target revenue without improving both acquisition and conversion. And hence priority of each goal would need to be analysed again. Similarly you may have kept engagement as short term goal but the tasks required to achieve it may not be complete in short term so that again needs you to shuffle your itinerary.

After this exercise you should have a list of of things sorted in a more feasible order. You'd again need to prioritise this list. One way of prioritising is to gather all stakeholders in a room and explain every one the task and get developer and QA guys to rate the effort - low, medium, high. I would define low as less than a day, medium as 3 days and high as 5 days or more. Similarly, product and business guys should rate the impact of that task as low, medium, high. Obviously, low effort high impact tasks would get priority.  

Step - 3 
Define how you will measure the success for each task. Define it to the metric and formula you'd use to measure the impact of that task. This can be complex and one may not be able to do that in a meeting like setup. However, assigning two stakeholders for each task and both of them working in pairs to come up with this works great. This is very important step.

Many times when you try defining the measurement metric for tasks you may realise how easy/tough or trivial it can be. In quite a few case it unveils what we are not measuring and we should. It also makes a case for better instrumentation of your product.

Step - 4
Go ahead and publish this to all stakeholders. Let every one be inspired by what's coming and what they are going to build for the world.

Thoughts? Questions? Please leave your comments.

PM is a Double Agent

Most Popular on this blog