Category Archives for "Secret Product Manager Manual"


Announcing The Secret Product Manager Handbook

I’m excited to announce The Secret Product Manager Handbook is available!

When I started in product management, there were no classes, books, or online resources for product managers. I always wanted the “secret handbook” – so I wrote it. The Secret Product Manager Handbook is all the things I wish someone had told me.

I wrote a book for people like me (and you?)

I provide a simple yet powerful framework for thinking about product management. The process of finding and validating market problems, creating solutions to those problems, and taking the solutions to market. (Readers of this blog have seen this before, of course.)

To make it even shorter, “We find market problems, create solutions to the problems, and take the solutions to market.”

This captures the meaning of, for example, “we’re the intersection of business, technology, and user experience.” But it’s simple and clear enough that your parents can understand it.

Market problems are the underlying organizing principle

The core idea of the book is the focus on “market problems.” If you’re oriented to the market problem, a lot of other things take care of themselves. Or at least they are easier, or you get better results.

In fact, I saw a Pragmatic Marketing poll the other day. Most product managers say “discovering and validating market problems is our most important job as product managers.” At the same time, they complain “we don’t spend enough time discovering and validating market problems.”  We understand we should be doing it more, but we aren’t.

Contents and structure

A mockup of a physical version of The Secret Product Mananager Handbook, with a spiffy cover design.

The Secret Product Manager Handbook

The book is organized around this framework. The first section introduces the framework. And other useful information about product management as a discipline and practice.

The next three sections each focus on one component of the framework.

  • Finding and validating market problems.
  • Creating solutions to the problems.
  • Taking the solutions to market.

Throughout I provide concrete steps you can take to put the ideas into practice. (If you’ve heard my podcast or read my blog you might recognize those “three things you can do today to put these ideas into practice.” I got that from the great Brian Tracy, a fantastic business and self-improvement guru. I’ve listened to his audio programs for decades.)

I provide checklists and scorecards for assessing how you’re doing. It’s valuable to know there are obstacles to success, so in each section I list out key obstacles. And I give you ways to get around those obstacles.

To learn more

To learn more about The Secret Product Manager Handbook, check out the book trailer (inserted above, as well). Download a sample chapter. Or simply go ahead and order your own copy.

2 Should You Be A Product Manager?

Have you built something? Have you led a team?

Have you built something? Have you led a team?

Product management is a hot, hot profession right now. It’s one of the most important roles in a product company, especially in high tech. But is it right for you?

If you’re wondering about this, or want to scope yourself against a basic set of guidelines for product managers, this post is for you.

What I’m looking for in a new product manager

There are definitely some skills you should have – technical, communication, decision-making. And you should have a flexible mind, love uncertainty, crave a fast pace, and enjoy working with people.

But what I look for most is that you’ve made something, that you worked with people to do it, and that it solved someone’s problem.

What have you done?

One way to check if you’re ready: reflect on what you’ve already done in your career, or in school, or perhaps as a volunteer or in a high school job.

  • Have you built things, or worked with others to build things, that addressed someone else’s problem?
  • Have you led these teams in some way (ideally without authority, just by influence)?

For example, I worked with a graduating college student once whose resume said this about his senior project:

  • Redesigned shipping packaging for Hardy Diagnostics for their petri dishes.
  • Shipping testing for new designed packing products.
  • Assembled, built, and utilized machines for packaging design and shipment testing.

We spent some time talking about what he did, and it turned out he was underselling a bit.

He’d led a team. He had to validate the problem he was asked to solve was significant and worth solving. He had to test that the solution he and his team designed and implemented actually solved the problem effectively. And he had to ensure that his design could be manufactured on the customer’s existing machines.

The point is that he had done a limited version of product management in this project. He’d led a team, to create a solution, for someone else, that had market value. It didn’t show up that way on his original resume, but it was there.

I felt comfortable recommending product management to him as a potential career path.

We Like People Who Build Things

When I’m talking to someone who wants to get into product management – like when I coach young people on their resumes during their job search – I always explore these stories. How they built something, or worked with others to build something. How they made sure the thing they were building was worth building. How they got people to work with them. How they took the solution to market, perhaps. And how they validated the solution worked – that it solved the problem.

If a person doesn’t have some stories like this, I am suspicious they want to get into product management for the wrong reasons.

I Make Things, That’s My Job

And after you’ve been a product manager for a while we assume you have proven to yourself and others that you should be a product manager, that it’s the appropriate job for you. And at that point I start asking a whole different set of questions, of course!

How To Say “No” To A Feature Request

No (picture credit at the bottom)

Sometimes No Is The Right Answer

Can you talk to me about a time when you had to say no to a customer? Why did you have to say no? How did you handle it?

Customers often make feature requests that seem obvious on the surface, but which in fact are misguided or a bad idea. My goal is to be able to tell them that we won’t implement that feature, and have them thank me for that answer. I do that by leading them to make the decision themselves. This is a matter of asking the right questions in the right way.

Oh, That’s A Terrible Idea!

For example, let’s say your product is a project management tool. And one of your big features is being able to staff a project by role. For example, you can specify that the project will take two DBAs, three Developers, a Project Manager, and a Business Analyst. And you can say how long you need each of these, and even define when on the calendar they are needed.

That’s a very powerful capability. But one of the first things you think of when you look at it is, “Wouldn’t it be cool if I could use skills in addition to roles?” For example, some Developers know Java, and some know .Net. Our customers often asked for the ability to use skills, not just roles, to help them staff projects.

This feature request turns out to be a bad idea, and very difficult to implement in a usable way. So I used the following approach when I’d get that request.

Leading The Customer Along A Path

First, I’d acknowledge that this seems like a good idea, and that other customers have asked for this capability.

Then I say “I want to understand more about what you’re looking for.” It’s always a good idea to ask the customer this question, and the follow-on questions, whether or not the request is valuable.

The resulting conversation can head in several directions. One is that we actually can do what they need (which is often not what they ask for). This happens all the time: customers ask for features that already exist, or they are trying to solve a problem that’s already solved a different way.

You Can’t Handle The Truth

However, if they truly are looking for something new, as in this case, the next step is to drill down into how they expect that might work. For example, I always ask about how they expect to manage the association between skills and resources. Who maintains this information? How do you keep that relationship trustworthy? How will it be vetted? Does it capture enough information that it will be useful in allocating resources, etc.?

Usually by this point in the conversation the customer starts to hem and haw. It turns out that they don’t have a way to ensure the information is accurate over time. And as a result they also start to understand how supporting skills could actually be counterproductive if the data isn’t kept accurate.

Closing The Conversation

I’ll usually say at this point that we have considered this enhancement, but we also haven’t come up with a solution to make usable in real life. And that other customers agree as well that the cost of maintaining any model that was used for resourcing based on skills would likely break immediately. (In fact, for many of our customers just maintaining the role mapping for resources can be difficult to maintain.)

By the end of the conversation the customer typically admits that they don’t have a good use case for making this work. And we move on. Of course, I’m always gracious throughout this whole process. I’ll associate the customer with the enhancement request. And I’ll say that if we crack this nut, if we figure out how to make it work and make it valuable, it’s a common request and we’ll prioritize it along with all our other work.

What’s amazing is that the customer usually feels better about the product, and about me, at the end of this process. I just saved them a lot of headache (if we’d actually done their feature). And I made sure that my resources could continue to be focused on more valuable capabilities that they’d benefit from.

Leading The Customer To Say “No” Themselves

The steps are:

  1. Find out what the customer is really asking for – what’s the desired outcome behind the feature request?
  2. If you already solve it, then fantastic – you don’t have to say “No.”
  3. Otherwise, help the customer understand the implications of the enhancement – in the case of using skills for staffing, the implication is a huge overhead in maintaining data integrity, for which there is no good solution.
  4. Lead the customer to say “No” themselves.
  5. Make sure to capture the enhancement anyway, and promise to reconsider if a good solution presents itself.

What If It’s Not A Terrible Idea?

Of course, this is the case where it’s an enhancement request that you don’t want to do and that isn’t a good idea anyway. It’s a different process if the enhancement is a good idea, but you are just unable to prioritize it highly enough to replace something else on the roadmap. I’ll do another article on that soon.

(Image “No” copyright (c) 2014 Henry Burrows, Attribution-ShareAlike 2.0 Generic – CC BY-SA 2.0


What Does A Product Manager Do?

When someone asks you in the future “What does a product manager do?,” instead of saying “he or she is the CEO of the product,” you can say they:

  • Find a market problem (and validate it)
  • Create a solution to the problem
  • Take it to market

Wait a sec! That seems simple, almost like something my mother might understand.

Product Management Is All About The Money, Baby!

Most of you have the ambition to get big. How do you do that? The only way to get big as a product company is for people to buy your product. Preferably a lot of people, for significant amounts of money at a time. Duh!

But why would people buy your product? We know there are products that people don’t buy. We don’t want to have one of those – because you can’t get big, or even grow at all. If you look at the revenue line for a product that no one buys – it’s nasty! We don’t like that line at all!

Why Do We Get Revenue?

Compare it to our desired revenue line – up and to the right – and accelerating as it goes up. If our product sells like that, it means it’s solving an important problem for some people. Important enough that people will pay for the solution.

You may have a beautiful product, beautifully engineered and architected, and rocking in usability. But if it doesn’t solve a big market problem… Flat line.

A product can have some warts, not quite work as the user expects all the time, have some typos, use a 1998 style UI – but if it solves a big problem better than anything else… Up and to the right.

Problem Should Be At The Center

This is called, in Lean, “product/market fit,” or “finding a repeatable business model,” or other things. These terms suggest the product is at the center. But in truth the market problem should be at the center. That’s what drives your revenue up and to the right – a good market problem that only you solve, or that you solve better than anyone else.

Also Known As … Product Management

There’s a person in your company, perhaps multiple people, who are responsible for finding these problems and figuring out how to solve them. If you’re a small startup, this is going to be one of your founders. In a larger company, that person is usually called a “product manager.” (Perhaps this role should be called “problem manager?”)

The Rest Of The Story

Apart from finding (and validating) the problem, there are two other important things product managers do as well – less important in some sense (doing a better job of building a zero-revenue product still leaves you with zero) – but still necessary for success.

One of these is to guide the creation of the solution. This happens differently at different companies – sometimes the PM creates a full spec, sometimes a tweet is good enough to guide the engineering team. But it’s the responsibility of the PM to make sure that what comes out solves the market problem.

The third critical piece is to get the product to market. This is often called, surprise, “go to market.”

  • Making sure Marketing knows who to target with programs, and knows the right messages to put out
  • Giving the sales force tools for reaching those people and selling the solution effectively. (Remember, those people are anxious for a solution and willing to pay for it.)
  • Providing competitive analysis and other materials so your product prevails in sales engagements

Taking Action

Here are three things you can do today to use these ideas

  1. Start thinking of yourself as a “problem finder” – and start to learn how to find problems (hint: Here are some posts on this blog to help you get started: Finding and Validating A Market Problem, How Badass Are You At Finding And Validating Market Problems?)
  2. Make sure you can articulate the problem your product solves for your market segment. (Here are some guidelines on how to do that effectively: A Weak Value Proposition Is A Symptom, Not A Disease, Do You Want To Be A Badass Product Manager?)
  3. Make sure your marketing and sales people understand who you’re selling to and why they should buy your product and not spend their money elsewhere. (What Is Marketing, To Product Managers?)


Product management consists of three main activities:

  1. Finding and validating market problems
  2. Creating solutions to those problems that are better than other alternatives
  3. Taking those solutions to market

While #2 is the most natural, for a lot of us, #1 is far more important. No matter how good your product is, if it doesn’t solve an important customer problem, it won’t sell. And if the market doesn’t hear about it, or hears the wrong thing (#3) then they won’t buy it either.