How To Train a Product Manager

December 23, 2015December 29, 2015

The Power of Ratios

Chapter 20 of On Financial Intelligence is all about the power and importance of ratios in financial analysis rather than totals. For instance, rather than looking at a company’s total earnings, it’s more telling to look at the ratio of earnings per share. Ratios are powerful because:

1. You can compare ratios to themselves over time. A ratio lends itself to self comparison because it’s unaffected by factors like company growth. If the numerator of a ratio grows, so too should the denominator. If the ratio changes over time, then you’re seeing a truly interesting trend in part of the finances becoming skewed.

2. You can compare ratios to what was projected. By setting goals and projections as ratios, it’s easier to make decisions. For instance, if you set a goals of keeping a product’s costs below $1 million, it’s hard to determine if you should make a $20,000 purchase without totaling your current costs and projections. However, if your goal is to keep margin for a product to a certain standard, you can look at the costs for an individual decision more discretely because the ratio (margin) goal can pertain just to a specific feature or decision.

3. You can compare ratios to industry averages. Public companies publish their key ratios quarterly and thus you can compare your ratios to theirs to determine if you’re on track, needing improvement, or have an advantage in the market.

These same arguments for why ratios are powerful in financial analysis also apply when setting KPIs for your product. When choosing a KPI around increased user activity for Facebook, for instance, it may be tempting to set a goals of 10 million posts in a quarter. Instead, if the KPI is to get to an average of 10 posts per user for the quarter, the goal gets the advantages of ratios as described above. You can compare this ratio over time and see if users are generally more active than the same quarter last year. You can use it in decision making by examining whether a feature is likely to make a user more likely to post and tracking posts per user in A/B tests. And you may be able to compare it to other social networks because, although they’re smaller than you and thus have less total posts a quarter, the ratio of posts per user is still comparable from one network to another.

So, when setting up the KPIs for your product, think about using ratios rather than fixed totals. Tracking totals is fun for milestone celebrations (like having the millionth user), but they’re far less actionable when making decisions.

December 18, 2015

All Night? All Right!

Sometimes you need to burn the midnight oil to get a project or release out the door. It’s part of life when creating exciting new products, but it doesn’t have to be painful. Here are some tips that I’ve collected to make late night work sessions effective. The list doesn’t even include caffeine or 80’s dance music.

Keep your eyes going strong

At night, your eyes can get tired quickly from your computer screen blasting white light at them. I either dim my monitor, or better yet use the High Contrast Chrome extension. This extension inverts the colors of you monitor, making your screen mostly black and thus easier to read. Instead of most websites or online tools showing black-on-white, they become white-on-black. For example, instead of reading a blog like this:

You can read it like this:

You can quickly toggle the color inversion off and on with the Chrome toolbar in case you need pictures in their normal colors. It’s a free extension, so give it a try. I even use it during the day if I’m going to be on the computer a lot.

Keep on target with Pomodoros

As I covered in a previous post, using the Pomodoro method can ensure you stay focused. You’ll work in 25 minute blocks, with 5 minute breaks, giving you a goal of focused work with a treat to take a break. I’m easily distracted late at night, so it’s even more vital to enact external systems to keep me on track. Plus you can set a goal of, say, 3 Pomodoros to feel accomplished before going to bed.

Save your typos for tomorrow

Working late at night also introduces common mistakes like typos due to your sleepy mind. If you’re working on emails, save them to the draft folder rather than sending immediately. In the morning, give them a quick proofread, and then press send. You’ll save yourself some embarrassing mistakes as well as wasted time explaining to co-workers what you really meant last night.

Block your temptations

Nighttime is also the time to be easily tempted, and for me it’s watching videos on YouTube with cookies and milk. There are many browser tools you can use to block access to websites that might distract you. Depending on your browser, you can make it a restricted site, or change your system proxy, to block the ability to get distracted.

If you have to pull an all-nighter, I hope you find these tips helpful, and you meet your goals.

December 11, 2015December 29, 2015

We Are All Human

Know your assumptions. That’s the first theme in a book I’ve begun reading: Financial Intelligence. Before diving into how to read and interpret financial statements, Karen and Joe (the authors) want to make it clear that all financial analyses are based on assumptions. Be it the depreciation schedule for a vehicle or what counts as cost of goods sold (COGS), there are judgement calls and assumptions that must be made to create a financial analysis. If you understand these assumptions, either by talking to your finance team or reading the footnotes for a financial statement, you can get the full context for the analysis and have conversations about whether those assumptions are accurate. Don’t just accept numbers. Instead, understand how they were chosen and question.

I believe this lesson can be extended farther to teams beyond finance. For new Product Managers, it’s likely the first time he or she will interact with teams like finance, legal, and security. These teams are often shrouded in mist as the common conception is that they speak their own language while making decisions that affect everyone. However, it’s important for a new Product Manager to understand that these teams are human. They must make assumptions and guesses to get their jobs done, and those assumptions are often wrong as assumptions often are. A new Product Manager should strive to form relationships with these groups to understand these assumptions as well as learn how to best inform them of their products impacts to their decisions. This relationship can be formed through informal 1:1s or lunches, or simply getting on the phone to talk to these teams rather than sending email. And even better is to read an intro book to those teams, like Financial Intelligence, to understand their lingo and the framework for their decisions.

So far Financial Intelligence is quite good, and I expect to have several posts about the parts of the book as I read through it.

November 17, 2015

Forming Habits, One Streak at a Time

Streaks logo from the Steaks Press Kit

It’s challenging to maintain healthy habits as a Product Manager. Not only can it be hard to find time to form work habits, like taking time for skill building, it can also be hard to create habits that promote a work/life balance. For a new Product Manager, it can be especially overwhelming as the excitement of a new position plus the never-ending list of things to be done can lead to burn out. It’s important to form sustainable habits as Product Management is a marathon.

Recently I’ve had a lot of success with a mobile app called Streaks. It’s a light-weight iOS app that helps you track how many days in a row you meet personal goals. For instance, you can set a goal to practice guitar on Monday and Thursday, or read a PM article every weekday. I’m using it for work-life balance, such as doing exercise every day, doing arts & crafts, and reading. It could also be used to help a new PM get set up with work habits, like “have lunch with a stakeholder” or “check up on competitors.” I’ve found it to be great encouragement to remember to do the important things that often get forgotten in favor of the urgent.

Even if you don’t buy the app, the idea is straightforward. The core to starting a habit is to have a trigger for the action, getting at least minimal reward for doing so, and making a cycle to come back to the trigger again. To set up your own system, give yourself extrinsic encouragement to start a habit until it’s met. It could be a friend or peer having regular checkins to keep you accountable, or giving yourself a reward for a job well done. There are even online programs like stickK where you can set a punishment if you don’t meet a goal. At the least, set up calendar reminders to make sure you do your goal everyday, and you’ll soon be on your way to a healthy habit.

August 18, 2015August 18, 2015

A PM’s Testing Advantages

I just finished a major release at work, so the last weeks have been crammed with helping the Team crunch out features rather than blogging. We don’t have QA analysts on our Team which means the PM and Devs must ensure a quality product is released. Testing can be intimidating to a new PM who has never been responsible for a release before, but there are key advantages a PM has when it comes to testing. Teaching these advantages to a new PM will help them feel confident and able to help make the product launch as success.

PMs aren’t responsible for the code – It’s very hard to test your own code. A developer doesn’t know what they don’t know. If they knew how there could be a bug in their code, they would have fixed it when they wrote it. Plus the sense of ownership for the code they wrote may make a Dev go soft on their testing so that their code doesn’t look bad.

A PM brings a fresh set of eyes to finding and exploiting soft spots in code, being able to ignore the effort that went into creating the code. Just because a new UI or process was hard to write, doesn’t mean a PM feels they need to go soft on testing it. I always enjoy this mental image of a Developer testing their beautiful product:

“Testing my own code” from DevOps Reactions on Tumblr

For a PM, it’s time to take a whack at the product and get that delicious candy inside.

PMs know what bugs are important – Rather than spend time on bug hunting for edge cases, such as clicking a button too many times too quickly, a PM can go for the stuff that’s really important. A PM knows what customers really value in the product, and they can thus ensure the critical features are working for launch. As an example in this last launch, I was sure to validate the main use cases of our API that a customer uses, rather than all the ways the API could be used, and found issues that would have definitely led to customer complaints. The Developers had tested the way they use the API internally, but didn’t know about common usage patterns for the API. By prioritizing testing on what’s important, a PM can make sure they give the most value to the Team with any testing time the PM can share.

PMs know the special customers – Every product has special customers, such as those with weird data or special integrations. The PM can make sure these cases are checked, simply by asking the Team “Did you think about X?” where X is a special customer. In this last release, I found bugs in customers who were special due to custom skins on their account and due to customizations they had to the product. A developer who isn’t used to the customer base wouldn’t know about these specials, so they wouldn’t think to test them.

Hopefully you find these tips helpful in inspiring your next bug hunt, or helping a new PM get into the right mindset for helping to test their first launch.

July 24, 2015

Tools and Tips for Mac Presentations

There’s nothing worse than having the message of your presentation or demo obscured by technical issues. Over time, I’ve collected some key tools and tips for presenting on a Mac to ensure computer gremlins are kept at bay. Hopefully you find them useful too. If you already knew them, tell a new Product Manager about them so they don’t learn the hard way how presentations and demos can quickly go bad.

These tips and tools are all compatible with Mac OS X Yosemite (10.10) and later versions. I hope they keep working in future versions too.

First, stop what you’re doing: Before using your laptop to present, stop what you’re currently doing to ensure none of your background programs get in the way. You’ll want to check for applications that can be quit as well as browser tabs like Google Calendar that can give pop-ups (such as when your next meeting is about to start.) When in doubt, I quit the program, and it may even be worth quitting and reopening web browsers to clear out any open tabs that may start playing ad music.

If your demo requires a first-time-user experience, you can use private browsing modes in Chrome and/or Firefox to ignore your saved cache and cookies.

There’s also a very handy built-in tool in the Mac Notification Center to mark yourself as Do Not Disturb. I always turn this on to avoid notifications from my applications. It stays on for 24 hours, but you can also turn it off after your presentation. You can access the Notification Center in the upper right under the icon of three lines. Here’s a screenshot of the setting, and you may need to scroll up in the Notification Center to see it:

While you’re on, don’t let your computer go off: During your presentation while you’re taking Q&A, your computer will want to go to sleep to save power. Don’t let it do so, leaving you with a black screen and a password prompt, by using a small app called Caffeine. Caffeine installs an icon in your menu bar that, when active, keeps your computer from falling asleep. I use this for much more than presenting, such as making sure my computer stays awake while it’s crunching data.

Make sure your audience can see: You can ensure the whole audience can see your demo with a couple quick steps. First, make your browser or application full screen by clicking the green circle in the upper left. This will remove any distraction for the audience from your dock or other open applications. You can then increase the font of most applications by using command+shift+’+’ to make it easier to read. If you need to shift quickly between applications, consider using command+tab and command+shift+tab to cycle through your open applications.

Sometimes a monitor or setup will be at a poor resolution, causing scrollbars or visual issues in your demo. Chrome has a nice add-on Window Resizer to quickly set the resolution for your browser. This can get you to your minimum resolution for your product or ensure you’re using the window size that works best for you. As a bonus it’s also great for testing responsive products such as mobile websites from your desktop by setting your browser to a mobile device resolution.

Hopefully you find these tips useful, and if you have any of your own tools and tips for great presentations, please let me know in the comments.

July 7, 2015July 7, 2015

What’s the Worst That Could Happen?

It’s the start of a new quarter, and thus it’s time to make plans, share them, and decide how to best execute them. One of my favorite activities during this time is a reflection on plan risks with the development team, for a couple reasons. First, it serves as a venue to share the upcoming plan if it hasn’t already been shared. Second, it lets team members get pessimistic and vent their fears about the future in a safe space. Third, if the reflection is focused on actionable risk mitigations, it leads to a plan that is much more likely to succeed.

Talking about risks and risk mitigation can be tricky for a new product manager as the topic can appear much more complex than it needs to be. Often someone new to risk management will jump to having to calculate revenue exposure, probability of risk materialization, and other numbers that can feel like wild guesses. However, if tbey focus on the goal of risk discovery as identifying actionable mitigation strategies to make a plan successful, rather than calculating the financial impact of risks, these numbers are not important. What the risk management needs to do is identify the top risks and focus on what the Team can do to mitigate the risk materialization.

To identify the top risks, I have Teams first think widely about everything that could go wrong. To then prioritize the top risks, I have the Team rate each risk on two metrics: probability of materilization and impact if it does materialize. Rather than getting numeric values, I have them rate the risks relative to each other via a low/medium/high rating for each. Typically one or two risks will get a high/high rating for probability and impact of materialization, and these are the risks we discuss. Not only can this simplified framework help a new product manager discuss risks with a Team, it can help them think about risks and experiments for their products. By keeping risk management simple, they’ll be much more likely to incorporate it into planning and critical thinking about products and plans.

If you’d like to read more about risk mitigation, I suggest DeMarco’s Waltzing with Bears as an enjoyable and accessible way to understand risk management and be successful talking about risks in product development.

June 16, 2015

Service Design – Is your Service Ethical?

For the final meeting of the Service Design book club, we covered Chapter 9 and did an overall debrief of the book. This chapter was the least liked by the group. We could tell that it was written by a different author, making it feel disjointed from the rest of the book. The subject was also about assessing whether a service is ethical, which did not pertain much to our services.

However, the chapter got more relevance recently for me at the Mind The Product SF conference when Marty Cagan promoted adding “Ethical” as a new fourth dimension to a Product Manager’s values of Viable, Feasible, and Usable. He talked about how too often he’s seen Product Managers ignore the ethical nature of their products to pursue the latest fad in technology or profits. I agree that it’s a value to consider when designing a service or product, and when training a new Product Manager it’s an important discussion as often a new Product Manager has not been in a position to make decisions that could have wide-ranging ethical impacts. Rather than telling the new Product Manager if something is ethical or not, teach them how to talk about ethical attributes of their product with teams like Legal and Security to determine it for themselves. Since ethics can be subjective, it’s crucial for them to get feedback from others on tough decisions rather than assuming that they know best.

If you’d like discussion questions for Chapter 9 and an overall debrief for your own book club, here are some that I used:

Did the triple-bottom line of economic, societal, and environmental impact resonate with you? How do you feel we perform in regards to these three measures?
Which practices from this book would you like to try out?
What’s your one take-away from this book?

And as this was the last session of the Service Design book club, here are links to the prior posts. If you decide to run your own, it’d be awesome to hear how it went for you and what types of conversations you had.

June 14, 2015

What Is Code?

Paul Ford has posted an awesome read at Bloomberg on code and the culture that surrounds it: What Is Code? For a new Product Manager, it’s a fantastic way to get a foundation about what code and computers really are. Product Managers use computers all the time, but we rarely take the moment to think about what’s actually happening between our fingers touching the keyboard and pixels sending light to our eyes. Paul breaks it down bit by bit such that any non-developer can understand. And if you think you know computers and code, I’m sure you’ll learn at least something.

Paul’s take on computing culture is also well done, and gives a new Product Manager a good look at programmer culture as a whole. Articles like this deliver the wider industry context for new Product Managers, helping them understand their role and software projects. A new Product Manager has probably worked for one or two companies, and thus may not have the experience of working on a poorly run Agile project as their developer team members have. Industry articles such as this give them this perspective to better relate to their team.

The article is also great as an example of incorporating style and interactivity into what would traditionally be a long, dry read. [Spoiler Alert] You even get a certificate of completion at the end! [End Spoiler]

So get a snack, a drink, and give it a read; it’s worth the time – What Is Code?

June 9, 2015June 9, 2015

Service Design – Expectation Setting

For the fourth session of the Service Design we looked at Chapter 7 and 8 which covered Service prototyping and measuring services.

One of the themes of this section was in setting expectations. Services are experienced through the lens of expectations, so it’s important to know what expectations your customers have before they use your service and what expectations the rest of your service has set. You can then design experiences that both meet these expectations and set appropriate expectations for other experiences in your service offering.

For Product Managers, the adage for expectation setting is “under promise, over deliver.” Whether it’s talking about future roadmap items or responding to support issues, be sure to set expectations that you can over-fulfill. I’ve found this adage is an especially good one to teach to new Product Managers as likely they’ve had an experience of over-promising that they never want to repeat. This saying is an easy one to remember for tough situations and serves as a quick safety check before saying anything close to a promise that may be misinterpreted by marketing, sales, customers, or other groups that are eager to hear commitments they can act on.

These chapters also had a good overview of prototyping practices for service experimentation, which can be a good resource for Product Managers. Here are also the discussion questions I used for this session if you’re interested in digging deeper into the chapters:

Do you have an example where a solution had issues because it was not designed with the whole in mind? From the book “The entire purpose of service design blueprinting is to ensure that all the different elements across all touchpoints are not designed in isolation.”
Do you feel we have any places with particularly good or bad expectation setting? Or have you been the recipient of particularly good or bad expectation seeing? From the book “As customers, we have expectations of a service in terms of quality and value that overarch the day-to-day tasks we undertake. These expectations are set by the brand and our experience of other services, and are closely tied to the amount we are paying.”
Do you feel we have any touchpoints that are too high in quality? From the book “Sometimes, you may need to consider reducing the quality of a certain touchpoint to enhance the overall experience of quality in the service. When you set consistent expectations in each interaction and fulfill them in the next, people will feel quality.”
What do you think are some great service measurements that we could be tracking? How could we set a baseline? From the book “However, it is important to define some measurement criteria before a new design is launched and to track these parameters to prove value and improve the service.”