Month: July 2015

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.

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.