2 People Don’t Buy Capabilities, They Buy Knowledge

A visual of a head with gears where the brain goes, and knowledge spilling out of it.

This guy might have too much knowledge.

Knowledge is power

Most of our tools and applications deliver capabilities, but users and buyers are always hoping that what they’re buying is knowledge. Knowledge of how to do the job. How to do the job faster, or with fewer errors, or with better outcomes. If we don’t put the knowledge in, the our users have to figure it all out themselves. They have to become experts in our tools when they really just want to be experts in their job.

Even if it’s basic knowledge that everyone knows, putting it in your product will make your product more valuable. And of course, the more knowledge you can embed, the better.

There are a ton of good examples:

  • Instagram (filters)
  • LinkedIn (“The most successful profiles have…”)
  • SAP (the Reference Model)
  • iPhone (visual voicemail)
  • Slack (Slackbot, do this then that)
  • IFTTT (example recipes, that are then augmented by shared customer recipes)
  • Any product that has a setup wizard or onboarding process
  • And it doesn’t have to be built in – can be an email-based onboarding process
  • NetIQ (Knowledge Scripts)

It’s not an accident that all of these examples are market-leading or paradigm changing. Compare what they delivered in their product versus what their competitors delivered. With rare exceptions, the competitors were offering the same capabilities but not in the form of defaults or a pre-made experience.


  • Instagram: If you’re delivering a photo app, it’s obvious to include the capabilities of editing and adjusting the images. And most photo apps have that capability. But Instagram one-upped its competitors by putting well-designed default filters front and center. Users no longer had to learn how to adjust a photo to increase the drama or appeal. An expert had already figured that out, and Instagram put that expert in your hand. (This is one of the ideas in my bonus content for this post.)
  • iPhone Visual Voicemail: I’ve said before that the iPhone’s Visual Voicemail feature is one of my favorite examples of killer product management. Today it seems kind of boring, until you are faced with a Cisco Internet phone on your desk, for example. All of us can do regular old voicemail (like the stupid Cisco system). We just hate it! Visual Voicemail takes all that stuff that we used to have to do manually and hides it all behind a “knowledge-full” experience. The iPhone was the first cell phone with this feature built in according to Wikipedia.

Low hanging fruit

The good news for all of us product managers is that the bar is extremely low in this area. Most of our competitors are not putting knowledge in their applications. Chances are you’re not either. So a little bit of embedded knowledge can create a lot of differentiation.

The other piece of good news is that defaults and knowledge provide differentiation in two ways. First, they provide the knowledge. But almost as importantly, they make the customer feel like you care about them, because you gave them knowledge. How many Instagram photos use a different filters than the default? It’s a very small percentage. But the idea that those other filters are there is extremely comforting.

Put this idea to use

Here are three things you can start doing today to put more knowledge into your application so you’re not just selling capabilities. (Or get the freebie for these and an additional bonus idea!)

  1. Find out how experts configure or interact with your product. Then create templates based on what the experts do. For example, if your product is a project management system, how do experts configure their projects? Create a project template based on their configuration. If your product is a collaboration tool, how do experts set up their groups and notifications? Give your users the option to have their system set up with groups and notifications based on that model.
  2. Look for situations in your application where most users take the same steps in the same order, most of the time. Make this set of steps the default, and make it achievable in a single action. You might want to leave the other options available, but if most people are doing the same thing most of the time, make it very, very easy to do that thing. (This is an example of the knowledge of the crowd, not of an expert, but it’s still knowledge.)
  3. You can also use your own insights into how the product should be used to get the most value. This is especially valuable if your customers are not currently getting as much value as they could. Sometimes this is because the steps to achieve the value are complex, easy to forget, or error-prone. Sometimes it’s because you expect the user to do some work outside the application to achieve the benefit. A great example is retrospectives. All us tool builders know that our customers will be more successful over time if they do retrospectives. And there’s actually very strong research data that says how much more successful they’ll be. However, no (or very few) project management/collaboration/development tools actually support retrospectives directly. Even if you can’t do it perfectly, if you put that capability into your product and our competitors don’t have it, at minimum you have a good differentiator. Ideally your customers will actually get the value of the capability (retrospectives in this example), and that will enable them to beat their competitors.

Over to you

I’d love to hear your stories of how you’re putting knowledge into your application. Please leave a comment or drop me an email.

And if you have other good examples of applications that include knowledge, I’d love to keep building my list.

This New Template Helps You Write Better Product Requirements

A watercolor illustration showing two profile heads with a jumble of "wires" connecting them.

“Communication” by Joan M. Mas. See below for image credit.

Effective Communication is Challenging

Product managers tell me – and the people managing product managers tell me – that one of their biggest challenges is communicating with the development team. People complain about:

  • Developers being poorly motivated, or having a bad attitude about what you want them to build
  • Getting the “wrong thing” from the developers – the feature they deliver is not what you had in mind
  • And other forms of miscommunication between PM and dev

Product management has all the responsibility, and none of the authority. If communication problems are happening, it’s at least partly product management’s fault. At a minimum, you’re contributing to these problems. And no matter whose fault it is, product management has to fix the problems.

In this post I give you a powerful tool for doing that – fixing the problem. And be sure to check out the infographic that goes along with this post.

Our Requirements Are Letting The Developers Down

Our primary mechanism for communicating with development – aside from having conversations with them, which you’re doing, right? – is via some variety of “product requirements document” – the written-down “Why?” and “What?” of a new feature or new capability in your product. This might be a document, or a wiki page, or even a post-it note.

I’ll use the term “requirement” in this article for this concept. But you might call these “features” or “feature specifications.” Or “Epics” or “User Stories.” (All these terms have problems, but that’s a topic for a different article.) Let’s just call them requirements or “product requirements” for now. I hope we can all basically agree on what that means, and nod our heads.

Product requirements are our “stock in trade” as product managers. But chances are we are not doing as good a job of writing and communicating these as we should. Or as we think we are. Resulting in the problems I mentioned above.

Let’s think about developers as people for a minute. Like all people, developers are motivated by what Dan Pink, in his awesome book Drive, calls the components of Motivation 3.0 – mastery, autonomy, and purpose. (The handy acronym MAP will help you remember these.) Of course, we PMs are driven by the same things.

Requirements and Mastery, autonomy, and purpose

What do mastery, autonomy, and purpose mean for software developers?

  • Mastery should be clear – it means that they are in control of their tools, and expert at using them. These tools are programming languages, of course, but also the engineering disciplines of technical design, architecture, problem-solving, and so on.
  • Autonomy is a little less clear. What does it mean for a developer – part of an engineering team, amongst other engineering teams, in a big company – to be autonomous? It means that they get to apply their mastery to solve problems in their own way, using their own expert skills. This explains why engineers are often so frustrated when product managers go beyond the “Why?” and “What?” in their requirements and start specifying designs.
  • Purpose is often the big problem for developers. We product managers have a good sense of our purpose. We want to help our customers have better, more successful lives and to achieve their business and personal goals. But if we’re not careful, it’s easy to lose the connection to this ultimate goal by the time a requirement gets to an engineer. Often the engineer is given a document that describes something the PM wants, but with no connection to the way it makes the customer’s life better. This significantly dilutes any sense of purpose that the engineer has, and consequently reduces their motivation to do it.

Summing up, engineers, being humans, are motivated by solving important problems – using their mastery of problem solving, architecture, design, and programming – in new creative ways – using their autonomy – so that they can improve customers’ lives – achieving a meaningful purpose.

If your requirements are not meeting the standard that helps them do that, they will be less motivated.

What can we do?

Part of the answer is use a good template. Templates are cognitive aids. They make sure we address all the necessary topics.

I’ve written in the past about the value of templates for our cognitive resource management. You might remember the “Impact Areas” template for product requirements or product feature specifications I described in the past.

There are a handful of common templates for writing requirements and related things. The best known one is INVEST – which is an acronym for:

  • Independent
  • Negotiable
  • Valuable
  • Estimatable
  • Small
  • Testable

But I’ve never felt that the INVEST acronym spoke to me as a person who is trying to solve problems for customers with my products. INVEST loses focus on the market problem, and instead takes too many implementation considerations into account.

I want to make sure my requirements addressed these issues head on. For example, the customer’s problem, the thing we’re trying to solve, needs to have pride of place. We must make sure that the development organization and product management are on the same page – that’s a meta-requirement. And the requirement is a lot more valuable if it includes acceptance tests. Developers, QA, and product management can quickly understand if the feature really solves the problem.

To capture all these insights, and a few more, I created a new “requirements” template. This template will enable you to communicate more effectively with the development team. And it has a great acronym!

The VALUABLE template

The VALUABLE Template InfographicMy VALUABLE template – yes, “VALUABLE” is the name of the template! – is focused on helping developers understand the value they are creating with their solution. Developers are humans and are motivated by solving real problems for real customers, so the VALUABLE template makes this explicit.

With VALUABLE, the market problem and the focus on the customer drive everything. And the implementation decisions are left to the developers and designers.

The “VALUABLE” acronym stands for:

  • V is for Valuable (yes, it’s a recursive acronym)
  • A is for Aligned
    • The feature is Aligned with company strategy and priorities
  • L is for Loved
    • The feature will be Loved by customers because it will do what they need and not cause them more problems
  • U is for Understood
    • The requirement is Understood the same way by engineering and product management
  • A is for Acceptance tests
    • The requirement has clear acceptance criteria so it’s easy to tell if the implementation delivers the desired value.
  • B is for Bounded
    • The development team and the product management organization both agree that this feature is “realistically achievable” by the current team. Note this doesn’t mean that we know exactly how long it will take or when it will be delivered. Just that we are confident we can deliver it soon enough for it to make a difference.
  • L is for Leverages
    • The feature Leverages our competencies and unique abilities, both technical and business
  • And the final E is for Expected usage
    • The requirement includes explicit and testable usage Expectations. These can be used to instrument the feature, and to monitor its usage by customers once deployed

Contrast with INVEST

The VALUABLE template addresses the goals of writing requirements from a vastly different place than INVEST.

While INVEST does have a V for valuable, it’s mixed in with other terms like Independent and Small and Testable. These are much more implementation-focused, and less appropriate for product requirements, per se.

VALUABLE is much more explicitly about customer value, about strategic alignment, and about coming to a common understanding with development. My template leaves out Independent and Negotiable, which are not necessary, and Small, which most interesting things are NOT. And it covers some things INVEST doesn’t – such as the “Expected use,” “Alignment with strategy,” and “Leveraging our competencies.”

What’s missing from VALUABLE?

No one template can contain everything, and some things are missing from this one. For example, it doesn’t explicitly mention that the market problem mentioned under V has been validated (although it is implied). And it doesn’t include my Impact Areas template – the I just didn’t fit in the acronym!

By design the template doesn’t mention anything related to a technical specification. I’ve explained why that can be demotivating for developers. If you think about the purpose of a requirement, to capture the Why? and What? of a feature, and not the How?, it makes sense. But there’s nothing limiting you from putting technical guidance into the requirement.

Using the template

How would I use this in practice? There are a few ways to use it.

  • You can use the template as the table of contents for your requirements.
  • You can check your requirements against the template as an acceptance test. For example, the Understood component reminds you that product management and development need to be on the same page. When both parties are communicating clearly, it reduces issues with the handoff of requirements.


I’d like to hear your feedback on this approach to writing better requirements that result in better deliveries from your development team. Download the infographic that’s perfect for hanging on the wall of your cube. Let me know via the comments if you think this can help you and your organization to be more effective.

Image Credit: “Communication” by Joan M. Mas. Copyright (c) 2007 Joan M. Mas, Attribution-NonCommercial 2.0 Generic (CC BY-NC 2.0) 

5 The Secret Product Management Framework

One of the most challenging questions about product management has been – in my experience – “What is Product Management?”

In this post, I share a simple model or framework to answer this question. I talk about this model with lots of people, but I’ve never explicitly written it down in a post. I’ve found the model to be very powerful in my career, and I hope it’s helpful to you.

(And if you read all the way to the bottom, you’ll find a nice bonus!)

We’re called “product” managers

We’ll start with a box labeled “Product.” (It’s in our name, right?) This is the part of the job that’s most obvious. I suspect most of what you’ve learned about product management thus far has revolved around “the product.” By the end of this post you’ll have a much better context for thinking about “the product.”

The first box in the Secret Product Management Framework

“Product” involves things like:

  • Requirements or user stories or features
  • Design, both visual and technical
  • Backlog
  • Agile development methodologies
  • Product manager =? Product Owner
  • Releases
  • And even roadmaps

And indeed, as a product manager “product” is where you spend a lot of your time, typically. But it’s not 80%. Maybe it’s 40%-50%, ideally. What do we do – or what should we do – with the rest of our time?

Our products solve problems for users

Here’s where things get interesting. The most fundamental thing to remember is that successful products solve problems for customers. I’m using the term “problem.” Business applications and products literally solve problems. Products for consumers can solve a problem, or they can address a desire or need. A consumer product like the Swiffer solves a problem – dirty floors. A consumer product like the iPod addresses the deep human desire for music. 1,000s of different product categories have addressed this deep human desire over the millennia.

I’ll use the term “problem” in this post, but you can think “need and desire” if you’re working on a consumer product.

A big part of our job is finding these market problems, customer needs and desires.

Since what our product does is solve a problem I’m going to rename the “product” box. Let’s call it a “solution.”

Products solve problems. So we have to find and validate problems to solve.

Market research

There are lots of ways to find market problems or customer desires, and I have several earlier posts that cover some of these techniques. A few useful approaches are:

  • Interviewing customers
  • Anthropology/ aka watching what they do
  • The Jobs To Be Done framework has a whole methodology for finding unmet needs of market segments

And note that this process needs to happen whether you’re talking about the product or an individual feature of a product. They all should solve problems.

Validation and feasibility

The other half of the “Problem” box is that we need to validate that the problems we found are worth solving. Will enough people pay for a solution that it’s worth our time to solve it? Indeed, can we solve it?

Finding and validating market problems is not a one-time thing. You need a continuous funnel of potential problems to solve with your product, or with a new product.

So you will constantly be out talking to “the market” to find and validate new problems. How much should you do this? Some product management experts say that product managers should talk to every one of their customers over the course of a year. And this is outside the context of a sales call!

Once you have this funnel of market problems coming in through this research, there’s a process of deciding which problems to attack. Which ones should you create solutions for. There are a lot of ways to prioritize, as I’ve described in previous posts.

The story so far

Summarizing, we find market problems that need solving, then we create solutions to the best of those problems.

But there’s one other very important product management function.

  • We need to find and acquire customers
  • We need to get people to buy our solutions.

Now we need to take our solution to market.

“Go to market” is the part of the product management process where we:

  • Define who is a good prospect, so that Marketing can go out and find those people
  • Make sure the sales people know what to say to those people when they find them

Go to Market Challenges

The challenges you’re addressing in the go to market phase are:

  • How do our prospects find out we have a solution to their problem?
  • Who are the right customer/prospects to target?
  • How do we find them?
  • What do we say to them when we find them?
  • What’s the best way to communicate with them?
  • Why should they buy our product instead of something else?

The Secret Product Management Framework

And that’s the Secret Product Manager Framework:

  • We find market problems, create solutions, and get customers to buy our solutions

Why is it “secret?” I’ve never seen product management described like this, so if anyone has done it, it was secret to me. Many people do talk about these components separately, but not tied together in this way.

How to talk to your parents about what you do

One of the big strengths of this model is that you can use it to talk to non-technical people about what you do.

(Don’t say you’re the “CEO of the product” – they won’t know what you mean, and they’ll think you’re full of yourself)

Try this instead:

“I find market problems, create solutions to those problems, and take the solutions to market.”

Everyone understand problems, and solutions, and customers, whatever their background.

Three takeaways

How can you start using this information right away?

  1. It should be your mantra. “I find market problems, guide the creation of solutions to those problems, and take the solutions to market.”
  2. It’s a good way to describe what you do. It will differentiate you from a lot of product managers who cannot give you a concise description of what they do. And it will help your thinking and help you change your mindset.
  3. Use it to help guide your activities. For example, the problem you’re solving imbues everything. Your work, at bottom, is not about the product, it’s about the customer and what the product does for them, how it solves their problem. Whether you’re talking to customers, prospects, or engineers try to put the feature or feature request in the context of a customer problem. One simple change is to say “you” instead of “we” when talking to customers about your product. I.e., “Our product has feature X” is wrong. Say “Your problem Y is addressed by our feature X.”

Bonus Video

For a longer explanation of the Secret Product Manager Framework check out the “What Is Product Management?” video, from my (still in production) Secret Product Manager Handbook series.

Keep in touch

Let me know in the comments what you think about the Secret Product Manager Handbook.

And don’t forget to sign up for my email list!

Writing For Product Managers: Readability Is More Persuasive

In my Writing Tips for Product Managers post I suggested making your writing more readable. I mentioned a tool I use called Hemingway. It has both a Mac app and an online version.

In this post I’m going to show how I use Hemingway. (In my upcoming writing course I’ll give a video demonstration of Hemingway.)

Starting from terrible

I’ll start with a paragraph from a blog post I wrote in 2013. It’s not a bad post! But it was before I discovered the importance of readability. In 2015 started using sites like readability-score.com to help me improve my writing’s readability. And then I got Hemingway, which is much more convenient.

The original paragraph reads:

Of course, we have a lot of best practices. We know that requirements are a best practice, but we also know that a lot of successful products have been delivered without much in the way of requirements. We know that prototyping is a great way to converge on a product design, but there are lots of products that don’t have much design that do OK, and lots of beautiful products that sink like cannonballs. We know that having a well-articulated value proposition is a great best practice, but we know lots of companies that manage to do without them, at least initially.

Loading it into Hemingway, I get this:

The image is a screenshot of the Hemingway editor, which has highlighted three sentences as being very hard to read.

The original paragraph. Hemingway says three of four sentences are “very hard to read.”

Hemingway says this paragraph is Grade 12. And its remark is “OK. Aim for 9.” Its assessment of the writing is on the right. I did avoid passive voice and adverbs in the original. But Hemingway deems three sentences “very hard to read.” What makes a sentence hard to read? Length is one criterion. Shorter is better. Length of the words in the sentence also contributes.

You can see that I love to make long sentences. I often put a thought into a sentence, and then expand on the thought. And this can lead to very long sentences. It’s a habit I’m trying to break. Hemingway is helping me.

Making it all better

The first thing I do is to shorten some of my sentences a little bit. A natural place to shorten a sentence is at a comma. For example, in the original we had this very long sentence. It has 28 words!

“We know that requirements are a best practice, but we also know that a lot of successful products have been delivered without much in the way of requirements.”

I shorten it by putting a period in at the first comma. I take off the “We know that…” fragment. It doesn’t add much. Then I rewrite the second clause a bit. As two sentences, the meaning is the same – perhaps even enhanced. And the grade level has dropped to 9.

The image is a screenshot of Hemingway, showing that simply fixing the first very hard to read sentence has improved the paragraph's overall readability.

After fixing the first “very hard to read” sentence.

After I make the same transformation on all the long sentences, I end up with this. Reading level 6. Two-thirds as many words. No passive voice. No adverbs.

The final image shows the paragraph after all three very long sentences have been edited. The paragraph now has a reading Grade level of 6, and it's much shorter as well.

The final version.

Here are the original and the updated paragraphs side by side. The new paragraph now has a grade level of 5.

Before: 102 words, Grade 12After: 73 words, Grade 5
Of course, we have a lot of best practices. We know that requirements are a best practice, but we also know that a lot of successful products have been delivered without much in the way of requirements. We know that prototyping is a great way to converge on a product design, but there are lots of products that don't have much design that do OK, and lots of beautiful products that sink like cannonballs. We know that having a well-articulated value proposition is a great best practice, but we know lots of companies that manage to do without them, at least initially.Of course, we have a lot of best practices. Requirements are a best practice. But many successful products have never had much in the way of requirements. Prototyping is a great way to converge on a product design. But many products that don't have much design do OK. (And lots of beautiful products sink like cannonballs.) A well-articulated value proposition is a great best practice. But many companies manage to do without them.

Readability increases readership!

Improving the readability of your writing is definitely worthwhile! I have found visitors are much more likely to read my blog posts when they are easy to read. Even if your readers are highly educated, they prefer easier-to-read writing.

3 10 Writing Tips For Product Managers

An open fountain pen lying across some notebooks with writing.

Tips for writing. (CC BY-SA 2.0 by jvleis)

I’ve started working on an online course on “writing for product managers.” It will come out in the next few months. In the process, useful tips about writing keep popping up.

These tips will help you make your product management writing more persuasive, easier to read, more engaging, and more effective overall.

Some of the tips reflect topics I’ve covered before. Others I will cover in the future. And some are just obvious! But they are all things I watch out for or use in my own writing.

You can think of this post as a teaser for the writing course itself. Subscribe to my mailing list to be sure to find out when the course becomes live.

And if you have an interest in the course, leave a comment. Let me know what would help you most in your product management writing.

Ten Writing Tips

If there’s an existing post related to the tip, I link to it (or them). The first five tips apply to any writing you do, for any audience:

  1. It’s about them – that is, the target audience for your writing – not you. Use their language, not your language.
  2. Don’t use jargon unless the reader will understand it. And if you do choose to use jargon, make sure you use it correctly!
  3. Write in a conversational style, no matter who your audience is. Conversational style (versus academic style) is far more persuasive.
  4. Use a tool to check the readability score of your writing, and edit until the score is Grade 8 or lower. I use the Hemingway editor to help me with this. It works on Macs and has an online version as well. There are comparable tools for Windows. Or you can just use an online site like readability-score.com or readable.io.
  5. Use pictures if possible, especially for complex things. This is often the case in business or enterprise software

For writing targeted toward the customer or prospect:

  1. Use the value proposition format, or at least make sure you cover the key points of the value proposition: what your product does, the ideal customer (so the prospect can see him or herself as someone who needs this), what benefits the prospect gets, and why your solution is better than the other alternatives.
  2. Use personal goals achieved for social proof, not business goals. Prospects don’t only have a business problem, the business problem is causing personal problems as well.
  3. Use testimonials from existing customers, and use personal goals achieved if available. (And if not available, go do some more interviews and get those quotes.)

For writing that’s targeted toward developers and designers:

  1. When writing a spec, make sure the focus is on the problem the customer is experiencing. This will help the developers and designers create better solutions.
  2. Include the criteria for determining if the spec is satisfied, or the feature is “done” – i.e., acceptance tests.

Share Your Writing Tips

Do you have writing tips that you use or recommend, especially in the context of product management? Let me know in the comments.

And, if you have an interest in the course, leave a comment. Help me understand what would help you most in your product management writing.

7 The Value Inequality – The Real Meaning Of “Customer Value”

Cost Plus Pricing = No Good

You must balance value versus (multiple) costs to determine price. (By Hans Splinter, Attribution-NoDerivs 2.0 Generic (CC BY-ND 2.0))

People sometimes ask me “how should I price my product?” so I Googled it. I found a LOT of blog posts about pricing. A surprising number recommend “cost plus” pricing. How much does it cost to make your product? How much do you have to sell it for to make money? They say “Sell it for more than that.”

It’s well known that “cost plus” pricing doesn’t work for enterprise software. In fact, it doesn’t work for most high value products of any type.

The alternative to “cost plus” pricing is “value-based” pricing. A few people recommend this. And then they don’t say much about what that means.

Let’s explore this idea a bit more, and see what we can learn.

The customer’s perspective

Of course, the customer cares zero, not one iota, NOTHING, about your problems with making money. OK, they might care a tiny little bit if they want you to be around to support them. But they don’t care very much. It is not their problem if you make money or not based on choosing the wrong pricing.

But customers do care about something. In so many words, the customer has a problem. The problem is costing the customer some amount of money or time or business friction. They are looking for a solution to that problem. Your product may provide a solution to that problem. That’s what the customer cares about – solving a problem.

The first rule of pricing is:

Your product must cost less than the problem costs the customer. No customer will pay more to solve a problem than the problem is costing them.

Corollary: If your product doesn’t solve a problem the customer needs to solve, it cannot be successful.

But the customer has other concerns, not just about the price of your product:

  • Your product represents a big risk to them. Does your solution solve their problem? It looks like it does, but until they put it into production, they won’t know for sure. That risk makes your product worth less, until they are confident it solves their problem.
  • Your product represents a big change management cost. Their current solution or lack of solution to the business problem is costly. Your product may completely solve that business problem. But the cost of moving from their legacy solution to your solution will be significant. In some cases the cost of putting a new solution in place can outweigh the benefits of the new solution, irrespective of its price.
  • Your product represents an opportunity cost. The business problem you solve is not their only business problem. By buying your solution they won’t be able to buy a solution to some other business problem.

The Value Inequality

If you put all these customer concerns together into kind of some math, you get the following inequality:

V > P + R + M + C

The customer will only buy your solution if:

The value (V) the customer gets from your solution is greater than the price (P) of the solution plus the risk factor (R) that the solution will or will not work plus the cost of migrating (M) to your solution plus the opportunity cost (C) of not using that money to solve some other problem.

I call this the “Value Inequality.”

To buy your solution, the value the customer gets (solving the business problem) must be greater than all these costs combined.

And to make your sales easier, strive to ensure the value the customer gets from your solution is MUCH greater than the price of the solution. (In math terms:

V >> P + R + M + C

As product managers we have some control over all the terms in that inequality. In the next installment I’ll give you concrete ways to get this inequality working in your favor.

Three Things You Can Do Today

In the meantime, here are three things you can do today to start using these ideas.

  1. Put yourself in your customer’s shoes. What are the risks, change management costs, and opportunity costs they perceive with your product? Be specific. You should be able to come up with ten or more items.
  2. Start from the risks you found in step one. Find three ideas for reducing the customer’s risk of implementing your product. For example, do you have successful customers already? Can you use the story of their success to reduce the fear of a new customer?
  3. Find three ideas for increasing the customer’s perception of your product’s value. Again, you might be able to use the experience of existing customers. Get a good story from an existing customer about the value they experienced when they implemented your product. Or maybe your product has features whose value is not described well in your sales and marketing.

I’d love to hear your feedback on this idea. Have you used a model like this for pricing?

4 What Will Product Management Be Like In 5 Years?

The future is hard to tease out, but here's what will happen in product management's future. (CC 2.0 by PunkToad)

The future is hard to tease out, but here’s what will happen in product management’s future. (CC 2.0 by PunkToad)

Earlier this year Janna Bastow of ProdPad put out a call for opinions on the future of product management. I quickly responded then. And realized later it would also make a good blog post.

To understand the future of product management I started from the “present” of product management. Where are we now in the product management discipline?

The “Present” of Product Management

Product management today has these characteristics:

Where (I hope) product management will be in five years

  1. Product management will be understood to be more about finding market problems and solving them than about “product” per se.
  2. Businesses will understand that the activities and effectiveness of product management are the primary leverage the business has on revenue and profits. Small improvements in PM effectiveness have outsize effects on the top and bottom lines.
  3. The business value of PM – i.e., revenue per PM – will be well known and (somewhat) managed to.
  4. Product managers take strong control of their part of go-to-market.
  5. We will have escaped from the fetters of the old inherited IT lexicon.

Three things you can do

  1. Make sure you’re spending enough time on the most valuable product management activity – finding and validating market problems.
  2. Understand where you and your company are in terms of finance-related product management ratios.
  3. Think about the literal and connotative meanings of the words you use – requirements, features, roadmaps, applications, agile. Make sure you understand not only what you mean by them, but what others hear when you say them. And if those aren’t aligned, change what you say.

Product Management And Fear – Three More Powerful Creative Blockbusters

Several years ago I had an article about three powerful tips for getting through a creative block. Although focused toward product managers, the tips were general purpose ways to increase your creative output.

  1. Morning pages
  2. Crappy first drafts
  3. “Use Your Obvious”

You can summarize the three tips pretty easily, despite their variety – “Just Write!”

At right around the same time I drafted this post with more tips that are especially applicable to product managers. But I just found out I never posted it! So here it is, a little late, but still pretty useful, I’d say. (Well, I still use these techniques anyway!)

Use multiple modalities

More than most other creative domains, product management is a multidisciplinary activity. All of our work has a technical aspect, a creative aspect, such as the UI, a marketing aspect, the sales aspect. And this gives you powerful tools to unblock your creativity. If you’re blocked with writing a requirement, you can design a UI, and so on. I call this approach to your creative problems “multimodal.”

If you get stuck on one mode, you can often get started on another mode and continue to make progress. And because all the modes are interdependent, making progress in one area often frees your mind up to make progress in other areas.

Suppose you are working on a new feature, but you’re not quite sure how to articulate the user story for the developers. Instead, you might attack it from a different perspective. You could start by describing how the user would experience the feature, how it would help his or her day-to-day life. Or you could start by writing down some technical constraints on the feature. What technology would be used, or how it would interact with other existing features to make sure no value is lost? Or, in a very traditional approach, you could start by writing the datasheet for the new feature. And of course you could start by sketching out a user interface.

(And remember to apply all the rules from the previous article, especially “crappy first drafts.” Your first drafts are often not going to be usable. But they’ll give you insights to use for your second and final drafts. )

Conceptualization tools

So far, I’ve described techniques that help you create the actual content of your requirement or marketing piece and all related components.

But, as my friend Scott Gilbert (with the awesome Twitter handle @AgileProducMgr) mentioned in a comment on LinkedIn, you can also use tools that help you conceptualize the problem. A novelist might use a story board, a timeline, and a cast of characters to conceptualize his or her novel. These all help develop the story, and prep for, but do not precisely achieve, getting words on paper.

We can use those techniques as well, in exact analogs to the novelist’s story board, timeline, and cast of characters. We can explore the timeline of the feature and how it fits into the process flow in the application. We can list the users of this new feature (or as they’re often called, the personas).


 As I determine if my design supports different aspects of politeness, I move the aspect to the Yes branch, with an annotation saying how it's polite in that way.

As I determine if my design supports different aspects of politeness, I move the aspect to the Yes branch, with an annotation saying how it’s polite in that way.

Another tool that works very well for conceptualizing a new feature is a mind map. I use a free mind mapping tool called Freemind. Scott uses MindJet, a commercial product. We both got a lot of value from creating mind maps. They help us understand not only the problem we’re trying to solve, but also how the solution might come together. They are great for addressing the -ilities like usability and scalability.

I created a mind map template to help me with user experience and interaction design aspects of my features. My template outlines the key aspects of user experience as described by Alan Cooper in The Inmates Are Running the Asylum (including the 17 aspects of politeness). I use the mindmap to make sure I have good answers to every aspect as I’m designing the feature.

Next Up – PM-specific Tools, Not Just Techniques

In this article I focused on techniques that are well-suited to product management’s multiple modalities. A later post in the series will be about tools that are specifically designed for PMs and how they can help overcome creative blocks. (Unfortunately, as you’ll see, some of those tools so far only exist in conceptual form – that is, in my mind.)

4 Mental Models for Product Managers – Part 2

Brain Wiring

Brain Wiring (by Wellcome Images, CC licensed)

In part 1 I introduced mental models and some reasons they are important. And I provided a few “general purpose” examples. In this part we dive into what you really came here for – product management-specific mental models.

Why are product management-related mental models different?

The mental models I’m going to talk about share two key characteristics:

  • They are about about products
  • They are not used enough

We have some great mental models in product management. But we have not been doing a great job of using them to help us make better products. While I think a lot of us have intuitive ideas about “how to think about” product management, my observation is that these mental models are not as widely used as they should be.

I wouldn’t be surprised if you haven’t even heard of these mental models. And if you’ve heard of them, you may not know how to use them.

The value proposition

For example, one of the powerful mental models is “the value proposition.” I’m sure you’ve heard this term. It’s very easy to say, and rolls off the tongue. Yet in my experience many product managers don’t know that a value proposition has a specific structure. A properly constructed value proposition is extremely compelling to prospects. But a “value proposition” that doesn’t have the four specific components of this structure is significantly less powerful.

What are the four components?

  • Who the product is for (the market)
  • What the product is (the category)
  • What the product does (its key features)
  • Why my product is a better choice for you (the differentiators)

This is the classic framework from Geoffrey Moore’s Crossing the Chasm. I’ve written about value propositions at greater length in A Weak Value Proposition Is A Symptom, Not A Disease.

Mental Model Categories

The value proposition is a mental model in the form of a template. It gives you a structure for your thinking and research. I like using good templates. Of course they are used throughout our domain – a user story is a very simple template, a Jira issue is created using a template. And most product management tools are essentially a database of items created by filling in templates.

But there are other types of mental models. While categorization itself is a type of mental model – the idea that different topics or pieces of information fall into different buckets – it’s not a product management-specific concept. But let’s use the categorization mental model to help organize some more product management-specific ideas.

One possible grouping is:

  • Templates
  • Categorization tools
  • Heuristics and algorithms
  • Cognitive laws

I’ll give a few examples of each in this post, and follow up with deeper dives in future posts.


  • The Value Proposition as discussed above
  • The Three Laws of Marketing Physics: For the best chance of success, your product should have 1) an Overt Benefit, 2) a Dramatic Difference, 3) a Real Reason To Believe. For more, check out my article on Doug Hall’s Three Laws of Marketing Physics, or his excellent book Jumpstart Your Business Brain!
  • My V.A.L.U.A.B.L.E. rubric for product requirements. I have a podcast episode and a downloadable graphic about this approach to requirements.

Just because you have a template it doesn’t mean your job is done. Filling in the templates is often extremely difficult. For example, articulating a meaningful Dramatic Difference or “differentiator” portion of the value proposition is usually difficult. (This is especially true if your product is really “a solution looking for a problem.”)

Categorization tools

Categorization is not a product-specific concept, but there are some categorization tools that are specifically about product. Here are a few of my favorites:

  • Stack ranking. It rests on another critical mental model, which also underlies “agile” – this is the idea that focusing on the most important thing first is the best use of your time.

Stacking ranking is a “one-dimensional” structure. The next set of examples live in two dimensions:

The BCG - or Share Growth - Matrix shows a set of products laid out based on their market share and the growth of the market.

This prioritization matrix from Accept360 lays out features based on their value (vertical access) and their cost (horizontal access, starting from zero at the right)

The Gartner Magic Quadrant chart lays out products or offerings based on their "vision" and their "ability to execute" - companies with an interesting vision and high ability to execute are considered Leaders.

The "Eisenhower Matrix" helps you with prioritization - tasks in the Important but Not Urgent quadrant are where you should aim to spend most of your time.

Categorization tools are helpful for making decisions and prioritizing features or portfolios.

Heuristics and algorithms

Technically, heuristics and algorithms give you steps to follow in specific situations. But often the steps involve reconceptualizing the situations, which puts them squarely in the province of mental model.

For example, there are some great heuristics in Chip and Dan Heath’s book Decisive that can help us make better decisions. The book is a great and entertaining read. And Teresa Torres has written a number of great articles putting a product management spin on them.

I’m going to touch on two of their mental models about decision making:

  • It’s never an either/or decision – you can always find more options than Yes/No, Go/NoGo
  • The 10/10/10 rule – think about how you’re going to feel about this decision in 10 days, in ten months, and in ten years. This rule helps you get out of the rut of taking hasty action now that you might regret later. Getting caught up in the urgency of something that might not actually be important in the long run. I illustrated the use of this rule in my article 5 tips for when your release is running late? You can push to get it out on time, even if there might be quality problems. That’s going to make you and your execs happy for a few days or weeks, but it’s going to haunt you next year when your customers stop renewing because of “your history of low quality releases.” On the other hand, if you delay the release until the quality is better – that’s a big downer today and for a few weeks, but in six months no one will remember, and in six years your company will be twice as big because all your customers renewed, citing “very high quality releases every time.”

“Rules of thumb” are another set of good heuristics that represent useful mental models. in my Rules of Thumb series I wrote about a few I use.

Cognitive laws

These mental models are rooted in the way people really think and make decisions (as opposed to how they think they do).

  • Customers don’t know what they want – this is an agglomeration of the results of a lot of different cognitive biases our customers have. Steve Jobs had a great quote, “A lot of times people don’t know what they want until you show it to them.” This doesn’t mean you shouldn’t talk to your customers. But you need to talk to them about their problems, not about “what they want.”
  • Personal goals – this is another one that’s easy to say, and powerful, but hard to do in reality. It turns out that customers and users don’t care that much about the business benefits that our products provide. What they actually care about is achieving personal goals. I wrote about this idea in greater detail in The Best Way To Engage Your Audience Is To Help Them Kick Ass.


I’ve only begun to touch on mental models for product managers – most of these I’ve described with a few sentences.

I haven’t even talked about some of the valuable larger frameworks of mental models (although I do have blog posts about some – like Kathy Sierra’s “badass” approach).

And I haven’t mentioned anti-models – mental models that are actively dangerous for product managers (despite their ubiquity).

So, there will be more coming in future blog posts. But, in the meantime, I want to make sure you have some actionable, concrete advice for making use of these ideas.

Three things you can do today

You can start putting these mental models to use, and work on your own library of mental models, with these three actions:

  1. If you don’t have a value proposition articulated using the four part framework – category, customer, benefits, differentiators – then do it. You’ll learn a lot. This is hard, by the way. And you might find yourself struggling. That’s a good sign. If you’re struggling, imagine how your market is struggling to understand why they should buy your thing.
  2. If you can’t do the 10x thing for your product, get to work on that. It’s also a hard thing. Luckily, in most cases you can do the 10x against business as usual, and not against your competitors. Although if you can do it against your competitors, that’s amazingly powerful. “Not only will you have 1/10 the downtime, but you’ll implement 10x faster than with our competitors.”
  3. Study up on mental models. This really means studying up on ideas – ideas from different domains that focus on understanding how things work, and how things can be improved. A good list of mental models to start from is Mental Models I Find Repeatedly Useful by Gabriel Weinberg.

1 A Toolset For Getting Unstuck When Your Creativity Is Blocked

Penrose Triangle - A Very Creative Block

A Very Creative Block – Penrose Triangle by Wes Peck, CC 2.0 license

We product managers are inventing stuff most of the time. Whether it’s new features, or designs, or go to market materials, or just making decisions. And that means we are going to have creative blocks. A lot. That is, except for those times when we can steal stuff from others. Unfortunately, we can’t steal as much as I’d like!

A Toolset for Overcoming Creative Blocks

So, I’ve honed a set of “thinking tools” over the years to help me make progress in this invention process. Especially when I’m stuck (which happens all the time), I find I can often get unstuck using one or more of these techniques. This list includes:

  • Mindmaps – I have several product management-specific mindmap templates
  • My product management rules of thumb
  • The V.A.L.U.A.B.L.E. rubric for requirements
  • The Cynefin framework, especially the Complex quadrant
  • Asking good questions (open-ended, “5 Whys”)
  • Talking to other people, even people who don’t know anything about the topic and aren’t that interested – it turns out I “think by talking”
  • Creating a Powerpoint about the topic, and then presenting it (out loud, but only to myself)
  • Crappy first drafts and “Just get started” and “The simplest thing that could possibly work
  • Write the Amazon review first
  • Anthropology – getting back to the people whose problem I’m solving to make sure I really understand it. (Problems are much easier to solve when you understand them correctly!)
  • Sketching and mockups, even though I’m a terrible artist and designer. Simply putting something down on paper or in Balsamiq or Powerpoint often breaks down obstacles.
  • Appropriation – seeing how others have solved this problem, or finding out how similar problems are solved in a different domain. (“Good artists copy, great artists steal.”)

Especially if I’m stuck, I do some of these things and I find myself, against all odds, making progress.

Some of these I’ve discussed before (links provided above). But much of this post is only a tease. I plan to make follow on posts about my mindmaps. But let me know if you want me to drill down one of more of these ideas.