How to define the indefinable? What is a Product Manager? — Part 3

Portuguese version

We are finally at the last article about the skills of a Product Manager. Read the first or the second article.

In the first article, I explained what is a product and the interpersonal skills of a Product Manager. In the second, the approach was based in Strategic skills. In this third article, I will talk about the Analytical skills.

3.1 Analysis: Prioritization

An almost universal (context free) skill for Product Managers is Prioritization. A PM must prioritize everything related to his work: activities, meetings, the most important features, the best markets, etc.

To make an excellent work, a PM can’t rely on his memory. We need to empty our minds. Tools like Trello or Evernote can help to reduce the overhead of information that we need to deal. It is key to empty our inbox — e-mails, tasks, subjects, invites. If you write everything that matters in a tool it is easier to create different stacks:

• Urgent and Important: Do it now!
• Urgent and not Important: Someone can do this for you?
• Not Urgent and Important: These are the real valuable tasks
• Not Urgent and Not Important: Don’t do it — but let people know that you will not do it.

Remember to review your tasks and, even more important: execute them.

“Focusing is about saying NO!” — Steve Jobs

When we are prioritizing product-related features, there are a ton of different techniques. I will talk about a few of them:

Kano Model

Source: Wikipedia

A prioritization model created in the 80s by professor Noriaki Kano. It classifies features in five categories:

• Delighters: These are high satisfaction related features, but they don’t hurt satisfaction when not present. These are things customers don’t expect in the product, and exceed their expectations;
• Performance: These increase the customer’s satisfaction according to its quantity. For example: Memory capacity in a Smartphone;
• Basic: Customers expect those items. They don’t increase satisfaction, but cause huge dissatisfaction when not present. Like toilet paper in a hotel room, right?
• Indifferent: They don’t generate satisfaction neither dissatisfaction. It doesn’t matter;
• Reverse: Those items create dissatisfaction. Just don’t!

Attention: As time passes, delighters become performance items, and then performance become basic items. That’s why we need to keep creating delighters and performance items. Some time ago, there wasn’t biometric security in smartphones. In 2011 Motorola Atrix was the first Smartphone with this feature (Toshiba G500 was the first mobile phone in 2007), and it was a delighter. Other products copied this feature, and it stop being a delighter, but a performance attribute (first fingerprint security, then voice or face recognition). Soon enough, all smartphones will have these features. So it will become a basic need. It will not create satisfaction, but a phone without it will generate dissatisfaction.

MoSCoW

We understand that every feature will have some importance, but some of them more than the others. This technique was created by Dai Clegg, and the features are divided in four stacks:

• Must have: Critical items for the product;
• Should have: Important items but not critical — the product might exist only with must have, and the should have can be on a second version;
• Could have: Those are desirable items, but they are not necessary. Usually they can improve the experience or user satisfaction with low effort. They can be included in the product if time and resources are available;
• Won’t have: Those are the less important items, with least ROI. They can be left out of the product without impact.

GUT

It is a type of BSC (Balanced ScoreCard). Every feature is assigned with a value of: Gravity, Urgency and Tendency, and the items are classified from 1 to 5. Gravity (how serious is the problem/pain) and Urgency (how urgent the problem must be solved) are self explanatory. The purpose of tendency is to define if the problem will get quickly worse if nothing is done (5), it will worsen with time (3) or will not get worse (1).

RUT

It is based on GUT, but it considers relevancy instead of gravity. The reason is, depending of the context, we can’t estimate a gravity. Imagine that you are creating a social network such as Facebook. We can’t define the gravity of timeline for instance. But, since lots of social networks had timelines, we can assume that is extremely relevant (5).

Other Techniques

Daniel Zacarias did an amazing job of getting 20 prioritization techniques together, and he classified them according with its use. It will be a nice reading.

Story Mapping

When we have access to our market, it is incredibly interesting to have a Story Mapping session. This activity was created by Jeff Paton in 2005 and it is a worth reading. There are a ton of articles teaching this technique (https://www.thoughtworks.com/pt/insights/blog/story-mapping-visual-way-building-product-backlog) so I will only explain a simple activity to improve understanding. Consider this:

• You just woke up and you have 30 minutes to leave the house to arrive in time for an important meeting. In some post-its, write the activities that you would do before leaving the house. Then put them in order of execution;
• Now, consider the same situation, but you woke up later and you only have 15 minutes. Select the activities that you would do within this time;
• Now, you are even more late. You only have 5 minutes. Select the activities again.
• Now, look at your “map”: The activities you’ve selected in the third round are the most important activities in your workflow. If we are creating a product for this problem, we would include only those activities in the first release. The second release would be the activities left in the second round, and the third release would be the activities left in the first round. Of course it is not a realistic example, but this activity show how easy it is to visualize workflows with story mapping.

3.2 Analysis: Data-driven

Too much is being said about data-driven organizations and how PMs need to be focused on data for decision making. But indeed, what is data-driven about?

To illustrate what is a data-driven decision, imagine this situation: You are an airplane pilot and you are accelerating your aircraft to takeoff. Suddenly, one turbine catches fire. What do you do? You keep accelerating? Or you try to hit the brakes?

When we took decisions without looking at data, we’re playing with destiny, without really know which one is the best option. If you’re like me, the best approach for the airplane pilot is to stay in the ground. If this is also your opinion, it may be the worst choice. In aviation, there is something called “V1”. It is the maximum speed of an aircraft when the pilot still can make a decision of taking off or staying in the ground. In that case, if our airplane is above V1, we must take off anyway, and rest assured that this is the right decision.

To have a data-driven culture, a company must know the data and it is helpful if data is organized and in a unique source. PMs must have access to the data, and it is important that the meaning of each data is understood by the people who have access to them.

This way, we make sure that we have a data-driven culture.

3.3 Analysis: Technology

“We are stuck with technology when what we really want is just stuff that works” — Douglas Adams

There is an interesting discussion here: A Product Manager must know about technology? I think that the answer is quite simple: as much as your product needs. Your product is an API? Well, it means that at least you must understand what is an API and how it works. Your product is a simple e-commerce? Maybe you just need to know how to navigate in the internet, but a deep understanding of e-commerce.

It is important to understand that to be a PM one don’t need to code or to design. PMs must have the necessary skills to create value for their teams and customer — Emily Tate rocked in her tweet: https://twitter.com/thedailyem/status/990636330949505024.

But, since we are already stuck with technology (thanks, Douglas Adams), we should enjoy what tech offers. Lots of tools can make our work easier:

Research:

• Typeform;
• Google Forms;
• Survey Mokey;

Prototyping:

• Balsamiq Mockups;
• UXpin;
• Sketch;

Metrics:

• Mixpanel;
• Google Analytics;
• Segment;

There are a ton of other tools to make our work easier. Since our time is rare, many activities can be automated through technology. Every activity that you do with frequency is a candidate for automation. Be critic when evaluating your own processes, and automate what you can.

3.4 Analysis: UX

I won’t get into the details of UX because it is a whole discipline. But we, as PMs, must understand part of it (or all of it if this is your focus), because this helps to do our jobs. User Experience is focused in the experience of the user (really?) and that means that the user must be the focus of your product. It means that the user must use the product, in an effective and efficient way. We must think of experience before, during and after using the product.

To offer the best experience, we must understand the real needs of our users and, from that, create as many solutions as we can. One of the most interesting books of UX is Don’t Make me Think — Steve Krug. Also, a frequent subject of study is the Nielsen’s Heuristics:

• Visibility of system status: Continuously inform what the user is doing;
• Match between system and the real world;
• User controls and freedom: The user controls the system, not the opposite;
• Consistency and standards;
• Error prevention;
• Recognition rather than recall;
• Flexibility and efficiency of use;
• Aesthetic and minimalist designs;
• Help users recognize, diagnose and recover from errors; 10 — Help and documentation: it is better if it is not needed, but if it does, it should be accessible.

3.5 Analysis: Validation

I wrote about Lean Startup in my last article as one of the important skills for PMs, but I decided to include Validation as a separate skill, with its own importance — even though it is a natural process of Lean Startup.

“Progress in manufacturing is measured by the production of high quality goods. The unit of progress for Lean Startups is validated learning” — Eric Ries

Even if your product is not startup related, idea validation is still primordial.

Many products died because a lack of continuous validation (you thought you only needed continuous delivery? Think again!).

All hypothesis must be validated, so it is important to understand what is a hypothesis: “A supposition or proposed explanation made on the basis of limited evidence as a starting point for further investigation”. Source: Google Dictionary

Every not validated idea or supposition is an hypothesis, and must be treated as such — to be validated, as soon as possible.

3.6 Analysis: Action

This is the last skill of our series. I left it at the end (it doesn’t actually fit in analysis) to emphasize that, even if you are great at all the other skills, you can fail to generate results without a bias to action. The previous skills can guarantee that you know the right thing to do, but only you can make sure that the right thing is actually being done.

“Getting stuff done is easy, getting the right stuff done is what is hard”.

This is how we end this series of the skills of Product Managers. Do you think that we haven’t covered any skills? Want to better understand any skill? Get in touch!