Clicky

MANAGING THE BUSINESS OF SOFTWARE

Empowering judgment with context

White board 593349 1920

 

It is better to train ten people than to do the work of ten people. But it is harder.—Dwight Lyman Moody

The typical product manager's inbox is a mess. Maybe yours is too. But when you're working from your inbox, you're working on someone else's priorities, not your own. The same is true for your calendar. Before you know it, your calendar is filled with appointments that seem really urgent—but are they really important? And are they furthering your agenda or someone else's? Others are determining your priorities, as you go from one urgent meeting to another.

Attending meetings, responding to emails, helping individuals one at a time can't be maintained, at least not for long. We need to find a better way to empower others.

Instead of answering questions, explain the vision. Instead of providing detail, provide context. Tell stories about personas and their problems so development and marketing teams can use their judgment.

After all, what is the goal of product management? We want developers to build the right product and we want sales people to know how to sell it.

We want to build the product right and also build the right product.

In a small company, the executive team manages the product and defines product direction, perhaps with ideas from developers and sales people. But as the company grows larger and the product set more complex, the company leaders are too busy managing the day-to-day of the company to focus on a single product. That's when you need product managers and product marketing managers.

Ideally, product management is making decisions that the leadership would make if only they had the time to do so.

Product management professionals serve as the leadership's eyes and ears, at the product level. Looking at the business aspects of the individual products and spending time in the market to help make product decisions with the right priorities.

Share market information with the company

Every development methodology calls for someone to represent the market to the product team. Developers need to understand the people who use the product and the problems they need to solve. There are two ways to help this effort: either work side-by-side with the product team and answer questions as they arise, or help the team understand the context of the problem so they can answer their own questions using their judgment.

That's the power of product management artifacts: personas, stories about problems, and descriptions of workflows. These help the team understand what they're trying to solve.

patton General George Patton said, "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." Yet many leadership teams and many product management teams insist on telling the developers both what to do and how to do it. And after a while, the developers learn not to use their judgment and insights and innovations. They say, "Just tell me exactly what you want and I'll do it." But that increases the amount of work dramatically.

Think of the remote control for your television. For some people, choosing inputs and channels is all rather like magic. One solution is to document everything: "to watch a movie, switch to HDMI-1 by pressing the INPUT button up to three times until you see 'DVD' in the upper-right corner of the screen" and so on. Instead, you'll have better luck if you can explain how the input button toggles between the different input sources—cable, internet, Blu-ray player, game device, and so on. Once your family understands what devices are connected where, they can use their common sense to operate the remote control.

The same is true for developers. This is the essence of agile.

And sales people. You could give them a long list of answers to memorize and a Q&A document to reference, or you can help them understand who buys the product, what issues they're facing, and the philosophy of how you solve it.

Help them understand the why, not the what.

Help them help themselves

Telling stories about the work your customers do, explaining personas and their problems—these help the development, marketing, and sales teams learn to help themselves.

Think of a legal document, like a will or an employment contract or an employee handbook. These documents attempt to describe in laborious detail every aspect of the problem to be solved. How much easier would it be if these documents explained the ideas rather than the details?

Nordstrom Rules: Rule #1. Use your good judgment in all situations. There will be no additional rules.

That's it. The Nordstrom Employee Handbook. On a single index card.

This sort of "use your judgment" idea affects the kind of people you hire. And is impacted by the people you have already hired. If you've hired mindless drones, if you think product creation is like factory work, you can't expect them to use their judgment. If you hire people who know nothing about your industry and domain, you'll likely be disappointed if you expect them to answer their own questions. So you need to either hire for expertise or supplement the people you have hired with expertise.

I believe that people can learn. I believe that people want to know more about their products and their customers and their companies. You can help your colleagues learn to use their judgment by sharing your product vision, the kinds of customers who need your products, the problems that those customers are trying to solve, and the tools you're using to connect with those customers.

What's next?

Look for ways to explain and teach and empower those who need product and market information. Instead of responding to each request one at a time, ensure the information is available online or in ready-to-use tools.

I have a personal rule: if one person asks, then most people don't know. So whenever I get a request from a colleague or a customer, I write a comprehensive answer and then publish it. That's the reason for an internal wiki or external blog; you can respond to inquiries, in detail, and never answer the question again. Before you know it, you have a collection of documents and articles and posts that answer almost every question.

Use the artifacts of product management—personas, stories, roadmaps, and plans—to give people the information they need when they need it. Show them where it is so they can answer their own questions and use their own judgment.

Return to Blog

Empowering judgment with context

 

It is better to train ten people than to do the work of ten people. But it is harder.—Dwight Lyman Moody

The typical product manager's inbox is a mess. Maybe yours is too. But when you're working from your inbox, you're working on someone else's priorities, not your own. The same is true for your calendar. Before you know it, your calendar is filled with appointments that seem really urgent—but are they really important? And are they furthering your agenda or someone else's? Others are determining your priorities, as you go from one urgent meeting to another.

Attending meetings, responding to emails, helping individuals one at a time can't be maintained, at least not for long. We need to find a better way to empower others.

Instead of answering questions, explain the vision. Instead of providing detail, provide context. Tell stories about personas and their problems so development and marketing teams can use their judgment.

After all, what is the goal of product management? We want developers to build the right product and we want sales people to know how to sell it.

We want to build the product right and also build the right product.

In a small company, the executive team manages the product and defines product direction, perhaps with ideas from developers and sales people. But as the company grows larger and the product set more complex, the company leaders are too busy managing the day-to-day of the company to focus on a single product. That's when you need product managers and product marketing managers.

Ideally, product management is making decisions that the leadership would make if only they had the time to do so.

Product management professionals serve as the leadership's eyes and ears, at the product level. Looking at the business aspects of the individual products and spending time in the market to help make product decisions with the right priorities.

Share market information with the company

Every development methodology calls for someone to represent the market to the product team. Developers need to understand the people who use the product and the problems they need to solve. There are two ways to help this effort: either work side-by-side with the product team and answer questions as they arise, or help the team understand the context of the problem so they can answer their own questions using their judgment.

That's the power of product management artifacts: personas, stories about problems, and descriptions of workflows. These help the team understand what they're trying to solve.

patton General George Patton said, "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity." Yet many leadership teams and many product management teams insist on telling the developers both what to do and how to do it. And after a while, the developers learn not to use their judgment and insights and innovations. They say, "Just tell me exactly what you want and I'll do it." But that increases the amount of work dramatically.

Think of the remote control for your television. For some people, choosing inputs and channels is all rather like magic. One solution is to document everything: "to watch a movie, switch to HDMI-1 by pressing the INPUT button up to three times until you see 'DVD' in the upper-right corner of the screen" and so on. Instead, you'll have better luck if you can explain how the input button toggles between the different input sources—cable, internet, Blu-ray player, game device, and so on. Once your family understands what devices are connected where, they can use their common sense to operate the remote control.

The same is true for developers. This is the essence of agile.

And sales people. You could give them a long list of answers to memorize and a Q&A document to reference, or you can help them understand who buys the product, what issues they're facing, and the philosophy of how you solve it.

Help them understand the why, not the what.

Help them help themselves

Telling stories about the work your customers do, explaining personas and their problems—these help the development, marketing, and sales teams learn to help themselves.

Think of a legal document, like a will or an employment contract or an employee handbook. These documents attempt to describe in laborious detail every aspect of the problem to be solved. How much easier would it be if these documents explained the ideas rather than the details?

Nordstrom Rules: Rule #1. Use your good judgment in all situations. There will be no additional rules.

That's it. The Nordstrom Employee Handbook. On a single index card.

This sort of "use your judgment" idea affects the kind of people you hire. And is impacted by the people you have already hired. If you've hired mindless drones, if you think product creation is like factory work, you can't expect them to use their judgment. If you hire people who know nothing about your industry and domain, you'll likely be disappointed if you expect them to answer their own questions. So you need to either hire for expertise or supplement the people you have hired with expertise.

I believe that people can learn. I believe that people want to know more about their products and their customers and their companies. You can help your colleagues learn to use their judgment by sharing your product vision, the kinds of customers who need your products, the problems that those customers are trying to solve, and the tools you're using to connect with those customers.

What's next?

Look for ways to explain and teach and empower those who need product and market information. Instead of responding to each request one at a time, ensure the information is available online or in ready-to-use tools.

I have a personal rule: if one person asks, then most people don't know. So whenever I get a request from a colleague or a customer, I write a comprehensive answer and then publish it. That's the reason for an internal wiki or external blog; you can respond to inquiries, in detail, and never answer the question again. Before you know it, you have a collection of documents and articles and posts that answer almost every question.

Use the artifacts of product management—personas, stories, roadmaps, and plans—to give people the information they need when they need it. Show them where it is so they can answer their own questions and use their own judgment.