As product managers, we’re responsible not just for performing customer research and writing user stories, but also for the performance and the behavior of our product. Ensuring our product behaves correctly becomes harder yet more important as we gain more users.

Therefore, as part of writing a successful product spec, you should include information on how you expect the product to behave once you’ve implemented your new functionality.

One of the best ways to ensure that you understand the expected behavior of your product is to write up test cases. After all, if you understand how your product should behave under a multitude of scenarios, your product will be more robust.

So, how should we think through test cases as we create our product specs? Continue Reading

In our previous article, we talked about the costs of context switching, and how to generally prevent context switching.

However, product managers don’t usually have the luxury of working with uninterrupted time, specifically because we have so many responsibilities and fill up the white space.

So, I’d like to talk you through how to context switch better, since so much of our time and output is consumed by context switching.

How to Context Switch Effectively

Nearly every product manager struggles with context switching during working hours. Therefore, some product managers have resorted to working early mornings, late nights, or weekends to try to get uninterrupted time for focused work.

While that tactic can work in the short run, it’s unsustainable in the long run. Continue Reading

Since product managers fill the white space between departments and have so many tasks to juggle, we’re constantly switching between different contexts.

For example, one moment we’ll be writing up a meeting agenda, and the next minute we’ll be dropped into an urgent bug resolution war room.

Context switching usually causes major losses. I’ll present some research below that demonstrates the high negative impact of context switching.

Yet, at the same time, product managers don’t usually have the luxury of working with uninterrupted time, specifically because we have so many responsibilities and fill up the white space.

Therefore, we’ll explore context switching in two articles.

In this first article, I’ll walk through the costs of context switching, and I’ll share conventional advice on how to prevent context switching. Continue Reading

Product managers are multiplicative, not additive. In other words, we set the direction for others to take – and if we take them in the wrong direction, then we put the company at risk. Therefore, it’s imperative for hiring managers to minimize their risk when hiring product managers.

What kinds of risks do hiring managers consider when they hire product managers? They seek to minimize skills risk and people risk.

A candidate presents skills risk if her resume and cover letter do not demonstrate that she has relevant skills or experiences in product management.

Hiring managers need to know that the candidate will be able to carry out the responsibilities of the role. Because product managers must successfully execute a wide variety of tasks, it’s nearly impossible to quickly train a non-product manager into a product manager. Continue Reading

Throughout this series of articles, we’ve provided frameworks for how to work effectively with your sales team: how to shadow sales calls, how to partner on sales calls, and how to drive sales calls.

But while I’ve sung the praises of working alongside your sales team, I haven’t yet discussed how to determine when it’s appropriate to join the sales team.

After all, product managers have limited time, and have many other responsibilities.

So, in this final article of our series, I’ll provide a framework that addresses how often you should be joining the sales team to maximize impact for you, your team, and your organization.

Frequency

You should join your sales team at a minimum of once per quarter, and no more frequently than once per month. Continue Reading