Author Archives: Vivek Vijayan

About Vivek Vijayan

A Technology Product Manager - I derive satisfaction when my product intelligently makes life easier for users.

Three question for Product Manager Teresa Torres

We start the Q & A series of 2015 with Teresa Torres of ProductTalk fame. As usual – just three Teresa-Torresquestions and unedited answers!

Product Mantra: Gut feeling and data-driven approach – when do you prefer one over the other?

Teresa: I don’t prefer one over the other. Both are important and need to play a role in decision-making. Gut feelings or intuition is usually the result of pattern matching based on our prior experience. We notice something in a current situation that reminds us of past experience and we generate a solution based on what worked in our past. Whether or not this is a good solution depends on whether the current situation is similar to our past experience in relevant ways.

The challenge is our past experience might be similar in superficial ways and different in significant ways, meaning that a solution that worked in a past experience may be irrelevant to our current situation. We aren’t very good at recognizing when this occurs. Our intuition finds a solution quickly and we aren’t very good at slowing down and asking in which ways is this situation similar and different.

This is where a data-driven approach can help. We should listen to our intuition, but we shouldn’t trust it blindly. Instead, we should design experiments to test whether or not our proposed solution works in the current situation.

The optimal form of decision making is to listen to our intuition to generate insights and then to use a data-driven approach to test those insights.

Product Mantra: Intuition is very important for a good Product Manager. How do you develop intuition?

Teresa: Intuition comes from experience and reflection. Both are critical. We all know people who have years of experience who stopped improving long ago. And similarly, we all know people who seem experienced beyond their years. The difference is often reflection.

It’s not enough to log 10,000 hours of practice. In fact, the research that suggests it takes 10,000 hours of practice to develop expertise probably doesn’t apply to fields like product management. With the type of complex business problems that we tend to face, it’s hard to get expert coaching and it’s even harder to get real-time feedback, both of which are necessary for the deliberate practice required by the so-called “10,000 hour rule.”

You can’t just log experience. You have to take the time to reflect on your experience. This means you need to grow your awareness around how you make decisions and when you tend to be wrong. For product managers, I recommend doing the following for each new product idea:

  • Write down what impact you expect the product change to have.
  • Estimate an exact amount with a rationale for why.
  • Design an experiment to test your thinking.
  • Track your results.
  • Compare the actual outcomes to your estimated outcomes.
  • Do the work to understand the gap between the actual outcomes and your expected outcomes.

If you do this over and over gain, your intuition will improve. But remember, a finely tuned intuition doesn’t mean you can ever stop experimenting (as you won’t know when you are wrong), it just means your cycles will get shorter – you’ll know what to test sooner, your tests will get better, and you’ll start to move more quickly.

We need to let go of the idea that as product managers we can be right more often than not. Instead, we need to assume we’ll be wrong and adjust our methods to account for this.

I suspect the real question behind this question is how to we get better at product management. Product management is a broad function and it’s impossible to build expertise in every aspect of it. I recommend getting good at the basic fundamentals which I define as empathy, active listening, curiosity, intellectual honesty, statistical competence, root-cause analysis, visual communication, and abductive reasoning; cultivating the right mindsets such as being human-centered, experimental, collaborative, and metacognitive; and picking one or two areas of depth to develop deep expertise. You can read more about my philosophy on developing product expertise here.

ProductMantra: What was your New Year resolution for 2014 as a Product Manager? Based on that how do you frame one for 2015.

Teresa: I don’t set New Year resolutions. Too much research suggests that they don’t work. Instead, I set learning goals.

In 2013, I wanted to learn about content marketing and get better at cohort analytics. That year I worked at AfterCollege  I built out a content marketing team that is building awareness and growing the student audience and I implemented cohort analytics that accelerated our rate of learning and allowed us to get traction with a new product much faster than we otherwise would have been able to do.

In 2014, I worked as a full-time consultant coaching product teams on how to integrate user research, experimentation, and meaningful metrics into the product development process to help them make better product decisions. My goal for the year was to invest 100% of my effort into making this a viable business and this led to a variety of learning goals around how to support a growing consulting business. I also invested heavily in growing my statistical knowledge so that I was better equipped to coach my clients on understanding their experiment results.

Heading into 2015, my consulting business is strong and I’m less concerned about growing my business and I’m shifting my focus to my bigger goal of how do we invest in product management as a function – how do we get better at building products. As a consultant, I get access to the way different companies build products. I can see what’s working and what’s not across several companies. This year I plan to focus my energy into translating those insights into more writing and more teaching.

I also want to get better at the skills that underlie both of those. I’m approaching writing as a craft and investing in my skills by reading and writing more. With teaching, I’m investing in teaching opportunities that extend beyond what I do in my blog or a one hour talk. I’m doing more workshops and I’m experimenting with new course formats. I want to help more people get better at building products, so this year I’m experimenting with how to reach more people in ways that allow them to practice the craft of product management.

ProductMantra: Thanks a lot Teresa.

Teresa is a product coach helping teams adopt user-focused, hypothesis driven product development practices. You can read her views here and follow her tweets here.

Three questions to the Product Manager Shardul Mehta

Product Mantra is starting a new monthly Q & A series with Product Managers worldwide. We have decided to keep the format simple – just three questions. We start the series with the well known Product Manager Shardul Mehta of Product Canvas fame.

3572f74

Product Mantra: What do you think is the right personality for a Product Manager?
Shardul Mehta: Curiosity. Thirst for learning. Always wanting to know why. Great customer empathy. Technologist with customer experience chops and business sense. Always thinking about the future, but acts in the now. Get-things-done attitude. One of the best communicators in the organization. Leadership.

Product Mantra: When does Product Management get stressful? 
Shardul Mehta: Every job can be stressful when a lot is happening all at once. This is not unique to Product Management.

Product Mantra: Do you see the role of a Product Manager undergoing an evolutionary change in the next 10 years? If not why and if so how.
Shardul Mehta: Yes. It has to. PM missed the boat on Agile, Design Thinking, and Lean Startup. Product Managers spend too much time focusing on features, triaging engineering tasks, and managing releases. Instead, need to focus on the innovation process, customer development, and go-to-market strategies. That’s how it can add real, sustainable and measurable value to the business (and customers).

Thanks a lot Shardul – that was insightful – particularly on your opinion that PM missed the boat on Agile and Lean Startup. We will catchup – as a Product walks with the foot of the Product Manager and so we better catchup.

Shardul has a very useful blog here and a Twitter handle worth following here.

Do you monitor the dashboard daily? And react daily?

2869095880_b57de3336a_zIf you ask any Product Manager on what consists his/her daily routine at work, you will in a majority of the cases hear monitoring the dashboard as one of the starting items on any given day. As Product Managers we must be on the top of the dashboard. A recent incident makes me think, if we really should on a day-to-day basis “worry” about the change in metrics.

A few weeks back, I was palpitating looking a key metric which which was showing a downward trend since the last 3 days for no apparent reason. I drew a series of hypothesis and started chasing every hypothesis – some were a wild goose chase – with none of the hypothesis turning turning true. I looked at the external environment – nothing sudden was happening in the market. I looked at the data of the previous year – nothing really was co-relating with the present one. I was advised by my senior to wait and watch as there seems to be no apparent reason – sometimes there are short waves that come and go for no apparent reason and breaking your head over something of that sort might be a waste of time. I patiently waited. The metric came back to normal. Did I have to really deep dive and waste my time? Alternatively, if it was an upward trend, would I have created some hypothesis from thin air co-relating it with some changes we had made much earlier? We must look at the dashboard, not for blips, but as a whole over a well defined period of time. Well, if you had just launched a AB test you might be tempted, but even in that case until you get a statistically relevant number – do you really want to react?

Next time, when you ask a Product Manager what their daily tasks are and if you get a response saying “monitoring the dashboard and ensuring if things were OK”, ask them what happens if “things do not seem OK”. That will give you an insight into how an organisation works – impulsive and reactive  or well planned and organised.

Photo credit: Scania Group

“If all team members meet users, what will a Product Manager do?”

3319280560_8bde079e96_qDuring my brief stint at Intuit, I liked this practice of meeting users of the product; Intuit refers to this practice as Follow-Me-Home (FMH). Nothing unusual in that. However what was unusual was that the whole team meets the end users of the product – the developer, the quality assurance person, the technical support person – everyone. Many people outside Intuit asked me if everyone met customers, were Product Managers needed? This is the same question that Product Managers of Intuit asked back in 2009 when lean was introduced (see The Lean Startup Eric Ries p248-50).  Do we really need to go to the extent of asking if Product Managers are needed?

If the only work of the Product Managers is to meet customers and prescribe solutions based on the finding then it is over simplifying the job totally. A customer meeting provides qualitative feedback with sometimes a lot of noise. The noise needs to be filtered out by analysis of vast amount of quantitative data that one has accumulated. Combine this with what is happening in the business environment and goals of the product to decide what to do next. Not to forget the acumen needed to project manage the execution with cross-functional teams. The customer meeting, although important is one among other important things for a Product Manager.  So next time there is a proposal for the developer to join a customer meet, heartily welcome it. It keeps you as a Product Manager on the toes and prevents you from prescribing solutions purely based on symptoms alone.

Photo credit: Victor

User Stories: Beware of “yes, but…” more than a “No”

4564003386_b21410efa2_zNot so long ago, when I was the Product Manager of a mobile application, my mandate was to make the on-boarding of users of the app seamlessly easy. This app was an enterprise solution and needed an alpha-numeric code to unlock and start using (for various valid reasons). For the end user, obtaining this secret code from their company’s IT folks was complicated and made several users  install the app and never use this app. It would strike almost anyone as to why a normal (corporate) email authentication cannot be used for the purpose. To make end-users’ life easier by replacing the alphanumeric secret code with an email address, the work involved in the back-end was simply enormous. When I took the story to the Engineering Head, who was already inundated with too many things, the answer was not an expected “no”. I had every weapon in my armory to deflect a “no”. But I seem to have been outsmarted by a “Yes, but…”. I was told that there is an impending “fear” of the alphanumeric codes being shared and hence we must distribute two numbers instead – which will reduce the probability of a misuse. I was aghast at how this can solve anything I was trying to solve. I am not finishing the story and leave it to the imagination of the readers.

This is an instance of a user-story twisted to take a new avatar altogether – not achieving what it  proposed to. User stories which are enormous in effort must be split. Changing the direction to reduce development time is not a solution. Split user stories – never change direction.

Beware of a “Yes, but…” more than a “No”.

Photo Credit: Calleaghn

Product Managers are neither Astrologers nor Gamblers

Product Managers early into their career might get a bit frustrated when their product 300946273_d0b6f28186_mfeatures do not sometimes make an impact in the market with the users. Usually, they get questioned on why an investment was made in a feature which has made little or no impact. Does it mean good Product Managers have to be good astrologers? Not at all. If only Product Managers knew what the future is – so perfectly – they could have chosen a profession which is a lot more lucrative – professing the future for world leaders and business conglomerates – who struggle to make the right decisions. Product Managers work on features or products – small and big – some make big impact in the market – some don’t. Does it mean Product Managers are gamblers and work on something at random. Not at all.

Product Managers should have their ears on the ground. They should know the pulse of their users. Essentially a product walks with the foot of the Product Manager. Based on hours of interaction with users, analysis of vast data and knowledge of the market – a Product Manager comes up with what would be the next thing that would solve a (burning) 6155148915_7199307653_zuser/customer problem or improve user engagement. It might appear to others as mere intuition – but it is not; Product Management is not Astrology. However, such carefully acquired intuitions can go wrong and make a Product Manager appear more as a Gambler. Again – where the Product Manager’s skill comes into effect is to define what one will measure when the new feature is rolled out and what would be the minimal viable product to extract maximum learning. Essentially – “fail fast” – determine that something is not working and warrants no further investment or needs a pivot based on the learning. There is no gambling involved here.

A corollary of this argument would be when products/features are successful; the same Product Managers are termed visionaries.

Photo credits: Gil and William Cho

Moving from Free to Paid: 3 things that you cannot afford to mess

Often consumer online products need a critical mass of users to even know if the product is indeed 6280507539_f32a72be10_qworking and adds value to the users. Most products start by offering the product/service free to attain critical mass and also get actively engaged users. No sooner does it gather enough engaged users, the juggernaut of “monetization” is on its way and the only model that might be feasible is the user-paid model. Most products usually have a well-thought road-map on how long the free model must continue and how to start some positive cash flow. When you move to a paid model, you could mess up totally by doing these:

Convolute the user experience: This strategy only spells doom for the product. Alternatively, look at features you can carve out for paid users; the user experience of the product as a whole should be left in-tact. Sometimes it so happens that the whole set of existing features forms the perfect user experience and removal of any feature cripples the product so much so that it becomes useless. In such cases, the challenge would be to create new feature set – which are enticing enough for a segment of users to pay or create a limited time period for usage of the free product.

– Delay moving away from free: The conversion percentage from paid to free is usually a small fraction; running free version for a long period increases the cost of acquisition of paid users.

– Asking for “long-term” commitment: Users moving from free to paid should have a smooth “on-boarding” experience. Mandatory long period sign-ups (even if there is opt-out facility) causes high drop-out rates among users.

You build your user base with a lot of effort – let it not wither away when you need them the most.

 

Photo credit: https://www.flickr.com/people/68751915@N05/