Today we see myriad distractions in meetings and working sessions. People on their phones; side conversations; surfing the web; updating Facebook.

If a meeting is important, then people should be engaged. Here are a few tips to keep your meeting on track.

Some meetings are boring. Particularly conference calls. To make them more fun, add Conference Call Bingo to your next conference call.

Do you want your team to be productive quickly? Fix your on-boarding process and you’ll achieve productivity in record time.

There are loads of good books on product management and product strategy. Here are some of the books we mention in our workshops and coaching sessions.

So many blogs and news sites to choose from. Here are some favorites.

Executives are extremely dissatisfied with their organization’s innovative performance but most firms seem to hate innovating. In 2016, McKinsey reported that 84% of executives see innovation as extremely important but only 6% are satisfied with their organization’s innovative performance. Understand why "different" is as important as "good."

When developing a competitive strategy, don’t try to compete directly against your competitor’s strengths. Instead, focus on—and build up—your strengths. It seems logical enough but we continue to see companies ignore this competitive reality.

In my discussions with executive teams, it’s clear that company leaders expect the product manager to be responsible for requirements. Communicating customer problems to development in some form, using artifacts known as stories, problems, features, or requirements. When pressed, execs often add some business aspects for the product: financial plan, roadmap, maybe a business case.

Rarely does a company leader advocate a product manager’s role in determining the company’s strategic direction or defining new products for the portfolio.

In college, a fraternity brother recommended I take a ROTC class—he promised me an “A” and I’d also get to fire a rifle. (And after struggling with Cost Accounting, I really needed the grade!) One thing I remember is, during WWII, each soldier was supported by 8 non-combat soldiers. For every soldier with a rifle, there were 8 with clipboards. Just look at M*A*S*H—in this support unit, there were half a dozen doctors plus many others necessary for its effective operation.

How many staff positions are required to support a person in the field?

User Personas can help product people really define who they're building their product for. Instead of thinking of your customer as a demographic, a user persona helps you visualize and define an actual *person*.

In this episode of the Build Launch Scale podcast, Steve Johnson explains how we can best create and leverage user personas when building products. 

Listen to the full podcast here.

The best sales people are what I call "brother-in-law sales reps." They understand both the client and the products well enough to explain which product can solve the client’s problem.

One of the key ceremonies in bringing new products to market is the product team briefing. Sometimes called a development brief, this meeting is oriented around the business and market conditions driving the product direction.

You’ve heard again and again that you should listen to customers. However, you will learn entirely different things depending on when you contact them. Consider the client’s confidence in your solution over time and align your interviews with their phases from buying to production.

Of all the techniques I’ve used, affinity mapping consistently delivers great results. By leveraging a team’s collective knowledge, you brainstorm a bunch of information to quickly find patterns and themes.

My favorite set of metrics help instrument the movement from interested to buyer? “Pirate Metrics” from Doug McClure.

At Under10, we make a big deal about personas and problems. We’re always asking, “What problem does this solve and for whom?” Here's short-form video from Under10 Playbook that explains the importance of problems. 

Do you really understand your buyer’s journey? The entire journey? From one department to the next? I've been thinking about the disconnect between marketing, sales, and service. Why doesn’t one department know what another department is doing? How many times must I provide the same information: name, email, phone number, address?

Most stories are boring. Do your stories actually tell a story? 

Steve Johnson was interviewed by Tom Cooper for his podcast. Tom & Steve tackled the issue of product management roles, titles, and responsibilities. 

Your costs and revenue plans are irrelevant to your customers but, of course, they’re quite relevant to your business case—if customer value is less than the revenue you can charge, you have a flaw in your business model, not a flaw in your pricing. Look at two examples of pricing driving behavior and vice versa.

I was interviewed by Chad McAllister, host of The Everyday Innovator podcast, the six types of expertise in product management. Listen in as we talk about expertise and the search for "purple squirrels." 

I set up a program in my marketing automation system and somehow set up a loop. The program called a page that called the program that called the page and so on. 

Never underestimate the power of observation.

The roadmap has become one of the most commonly requested—yet frequently misunderstood—documents in the product manager’s arsenal. However, for many product managers, the roadmap is an annoyance that must be changed constantly.

Did you know UPS trucks almost never make left-hand turns? Understanding the mechanics of how delivery vehicles work increased productivity for drivers and reduced fuel costs dramatically.

For any product, whether innovative or sustaining, the key is understanding personas and their real problems. Explore two techniques for innovation success: physical location and "jobs to be done." 

In a world with so many cheap or free options, and so many "good enough" solutions, customers seem willing to pay for better choices. Choices that are focused on their specific needs; that is, software that meets 100% of something rather than 80% of everything. A better webcam with a better app. A better software tool with better reporting and better tutorials.

As you develop your product personas, think about how they like to learn. Do they read and research? Or do they prefer to examine and discuss? Your sales team should be armed to handle both types of buyers. 

Observing customers in their work environment reveals common problems and irritations that no one would ever mention, resulting in clever features like the “PPI Function.”

It seems many teams confuse projects and products, and therefore have trouble delineating the roles of project managers and product managers.

A project has an end; a product doesn’t.

Assuming the sale of Yahoo to Verizon goes through, the remaining assets will become known as Altaba.

What kind of a name is that?

The level of precision in stories is an industry-wide problem. In general, product managers want to convey high-level epics or scenarios while many developers want specific tasks. This represents a huge divide of expectations.

Much of product management is prioritization. Which product to build; which feature to develop; which critical launch items to deliver. A prioritized list is critical—ideally sorted by some form of business value. Using an objective algorithm is the best approach. 

In a typical tiered pricing scenario, buying 101 seats in Tier 2 is cheaper than buying 100 seats in Tier 1. How do you deal with the edges on pricing tiers?

As a manager, you owe it to your employees to give them career counseling. But don’t do all the data gathering yourself. Use existing information or get your employees to pull the raw data together. Then use your management skills and career experience to analyze the data so you can provide specific recommendations. Your team will appreciate that you cared enough to prepare a meaningful assessment.

Much of the language of software creation is based on the manufacturing metaphor. We “plan” software. We “engineer” software. We “assemble” software. The implication is that creating software is rote work that can be done by factory workers on an assembly line. Creating isn't the same as assembling.

I'm pleased to be named as one of the "19 Product Managers You Must Follow" by Mark Silver at Spectechular. 

It seems that many sales people are hired for reasons other than their industry expertise. We typically attempt to hire “closers” and “elephant hunters.” But without industry expertise, these sales folks will need lots of technical support. What is the product manager’s role in supporting sales teams?

Despite the adoption of agile philosophies, many product executives request detailed time estimates and costing at the feature level. As someone who has worked with product teams for decades, I can tell you time and cost estimates of features just aren’t reliable. What to do?

If you're not mobile already, you're overdue for declaring a mobile strategy for your product.

Allan Neil of Ready Product Radio recorded a session with Steve Johnson of Under10 Playbook. Steve's topic: When the product is YOU! 

Nowadays, many product managers and marketers focus on a series of increasingly broad launches, not on packaging releases.

It’s helpful to understand that product release is the end of development; product launch is the beginning of availability. Developers work forward to a release date; other internal teams work backward from a launch date.

For the business of product management, one area that typically gets short shrift is the creation, measurement and review of product metrics.

Your product is in the market but no one knows it. Or perhaps you’ve done the “product roll-out”—you’ve rolled the product out the door and then slammed the door shut. Some companies prefer the “development launch”—when the code compiles with no errors, it’s released to clients. Launch complete.

Congratulations. You’ve perfected the stealth launch!

The questions to consider in creating your personas are these: What information is relevant to your marketing and development decisions? Do you need demographic attributes or situational ones? Or both?

 Fundamentally, we need to know how to find and market to our buyers and how to develop to our users. What do you need to know to succeed?

Back in my days with Pragmatic Marketing, I traveled almost every week delivering both public and private seminars to groups from 12 to 120 people. In fact, I stayed in the same hotel every month for a decade. We did lots of public seminars in hotel conference areas; some were good, others not so much. Only once was I asked for recommendations on how the hotel conference facilities could be improved.

Many in ed-tech prefer to hire teachers for their domain expertise but what do teachers know about the business of education? Health organizations like to hire nurses and practitioners but what do they know about the business side? Most product management and marketing job descriptions mandate heavy domain expertise but is this really necessary? After all, practitioners only experience a minute part of the overall business of their domain.

I'm not in the sales or marketing department but I'd like to help the sales teams. What can I do to help the company succeed?

Strategic vision links the present to the future, showing how you intend to move the organization to its next level of performance. Much has been written about strategic vision and alignment. Context vs core. Must-have products vs nice-to-have. The question here is whether any new idea is a key component of your long-term strategic vision. That, without it, your company’s long-term viability is in jeopardy.

During the growth phase, product leaders turn their attention to promotion and sales enablement. Presumably we have a workable product solution. Now the fundamental question is: How can we sell faster? Or if you prefer, how do we improve customer adoption? We want to expand the share of market (ie., more new clients) and expand the share of wallet (ie., more sales to existing clients).

Most product managers, marketers, and developers have an infinite queue of things to be done. The challenge for many (including me) is to stay focused on the things that really matter. You can easily get distracted by the “noise” and miss the ideas that are vital.

When considering how to communicate your value proposition, many firms try to reveal how they’re better (slightly better) than the competitor—sometimes in really subtle but irrelevant ways.

Instead of trying to show how you’re better, show how you are the exact opposite from your competitor. They are that, we are NOT that.

Perhaps the book that most influenced me recently was Moneyball, by Michael Lewis, first published in 2004. As I read it, I couldn’t help but find parallels between the folklore of baseball and that of marketing.

If your product is deficient in capabilities that your competitors have already delivered, you expend the majority of your development resource just catching up. After all, there are must-have features in every product—the ones you need just to be considered viable. But to jump ahead, you need to address these basic competitive features and also allocate resources to do work beyond the basics. 

To “leapfrog the competition,” you need to out-spend them. But more than that, you need to out-learn them.

So many product managers focus on the BUILD aspects of product but often forget about empowering the launch and its promotion. 

There are two types of sales people: order-takers and rainmakers. Which do you need?

Here's a thought: If your product was on Gilligan's Island, which character would it be?

Amazon Echo, the speaker with Siri functionality, was released in a series of phases using the soft launch approach. 

The “big launch” approach often fails because you haven’t perfected the go-to-market materials. Consider a soft launch with limited availability so you can nail your message, materials, and approaches before going to scale.

I fear how many product managers and product marketing managers treat their days. A meeting here, a phone call there. Dealing with some emergency or “just one quick question.” Before you know it, your day is done…and you haven’t actually accomplished anything.

Great results come from more than great development. You need a simple approach to optimize your product delivery every step of the way, from business planning to product creation to sales enablement.

For product managers and product marketers, the term ‘persona’ is used for profiles of buyers and users. Personas are a key element of a product manager’s playbook. They define the behaviors, attitudes, and goals of the kinds of people we encounter with our products. (Frankly, I’ve always had a little difficulty referring to our customers as 'users.' After all, only software developers and drug dealers refer to their customers this way.)

Some of the common attributes for personas include job titles, industries, a typical day, and products commonly used. For consumer products, we often see demographics like age, education, and buying power.

Some companies use titles for their personas. Titles like “decision maker” or “head of IT” or “HR rep.” One company used “managers” and “doers.” WTH? (I guess managers don’t do stuff.)

But… should your personas have names?

I've seen a bunch of variations on the Venn diagram for product management. Is it the intersection of tech and UX and requirements? Or is it finance and customer and something else?

What's the right metaphor for product management?

A guy fell into a hole. A friend heard his cries for help and promptly jumped down into the hole too. The guy says, “What are you doing? Now we’re both stuck down here!” And the friend says, “Yes, but I’ve been down here before and I know the way out.”

I’m surprised when companies outsource their strategy work such as customer discovery, persona development, and product positioning. Can you really understand the output without understanding the underlying inputs?

When it comes down to your product, you just want it to work - not just in the sense of all of its features operating properly, but you also want it to resonate well with your intended audience. You want them to love what you've created. They should feel like it has enhanced their lives. Whatever it is you've made, make sure that your creation avoids a few mistakes product designers inadvertently make during the process, so everything works as well as it possibly can.

The new bride is making her first big holiday dinner and tries her hand at her mother's brisket recipe, cutting off the ends of the roast the way her mother always did.

Hubby thinks the meat is delicious, but says, "Why do you cut off the ends?—that's the best part!"

She answers, "That's the way my mother always made it."

On Ready Product Radio, Steve Johnson and Allan Neil talk about the 4 Types of Expertise required for success in Product Management as well as whether Agile is making Product Management too tactical. 

I was facilitating a session on product positioning. The team was really nailing it, with a strong focus on customer problems. Then the session came to a crashing halt when the VP of Marketing said, “We need to incorporate the word ‘power.’ Didn’t you notice how the president’s eyes really lit up every time you said ‘power’ yesterday?”

I could feel the energy leave the room. And a few people glanced at me to see how I would handle it.

In a recent discussion I was shocked by a claim made by a product marketing manager: "Product marketing in B2B is harder than B2C because we can’t use the product."

Yes, I agree it is hard to market products that you don’t understand. But why don’t you? You simply can’t do product marketing without knowing the product.

Domain experience is critical to selling. It's why we keep going to hardware stores instead of buying from the big box stores. We go for advice, not just products. We go for product expertise—the clerk who knows why this product is better than that one for your project.

How about your clients? How much are they asking for advice rather than price?

The plans you make must be guided by your results from previous plans. After all, the best lens on the future is the past.

You made your plans with a set of assumptions: the size and skills of your product team, an expected rate of customer acquisition and retention, a level of funding for marketing and sales programs. Re-examine those assumptions and revise them based on your results. Look at what worked and what didn’t. Consider whether new methods can be applied to your products and services.

Make time for a retrospective.

I use the term "product" all the time to mean a combination of products and services but many of my clients equate "product" with "software" and rarely consider services as part of their products.

Great ideas—which turn into great products—seek to fill a void that the target market has—and may not be not aware they have. Ideally, your idea will revolutionize their life, from changing the way they communicate to how they conduct their business. Consider these five steps from idea to launch for your new product initiatives.

Have you ever had a sales person set up a client visit at your corporate headquarters?

The agenda usually involves the company president, the head of technology, one or more product managers, the head of support and services. And of course, the sales rep needs each of these people to attend the full day session just in case. The product managers certainly need to be there to make sure nobody makes any claims that must be supported elsewhere—such as the demo or on the ever-changing product roadmap; you need to make sure nobody is making any promises the products can’t keep.

Sometimes the sales team organizes this type of agenda at the client’s location so you can add in travel costs too.

For many organizations, every major deal involves this type of client visit. The cost of such a program is staggering. Just add up the daily salaries of these people plus the cost of travel—not to mention the opportunity cost—and you’re talking about a very expensive cost of sale, so you better win it!

No one can ever say product development is an easy task. There are unbelievably tight deadlines to keep, limited resources, and bosses or clients who want your deliverables now to appease. Naturally, this means product development managers have to find places to cut costs, find ways to speed the process, and try to follow a regular production schedule. That may be a good model for a factory, but the process of product development is something altogether different.

I’ve found that many companies understaff customer support and rely on product managers to support the support team. That means the product managers are not doing their jobs because they’re busy doing other departments' work.

How many departments are hiding their headcount in product management?

You know the worst thing that can happen with a new product? You get some customers. Not none. Not a lot. Just a few. And now you have a bad idea that must be supported and maintained and explained.

A product retrospective looks at the product capability, the best (and worst) customers, and the sales successes. What should we stop doing? What should we do more often? Let results drive your decisions for refining your product, your promotion, and your sales efforts.

What if you could develop faster than you sell? What if you could have a product release (or two) during the sales cycle?

A buyer wants a feature that’s planned for later in the roadmap. Since it’s crucial to a deal, we can put it into the queue for the next iteration and have the feature online in two weeks, long before the contract closes.

Your competitor announces a new feature. If you have a top-performing product team—and if it makes sense for your roadmap—you could develop and deliver the feature while your competitor is still showing prototypes.

You’ll want to avoid the appearance of being a custom developer but the promise of agile teams is they can react to changing requirements quickly. Use the "development pull" technique to align changing market conditions with consistent product team deliverables.

In my first sit-down with a marketing agency, they peppered me with questions about the product and the market. They wanted to know about clients, their problems, our solution, and why our product was better than alternatives. After a few minutes it finally hit me: “Do you want my product positioning?” And I pulled a product brief document out of my case with all their questions already answered.

Over the years I’ve learned to empower teams with the information they need about the product as well as the context of the product: the personas and their problems, the product vision, the roadmap, and the product status.

Most product managers recognize the value of user testing. But sadly, we don’t often allocate the time to do it properly on new feature/product ideas. We are all under intense time pressures. So it is often hard to fit in testing and design iteration before the sprint deadline.

Steven Cohn, the Founder of Validately and a user testing expert, gives some practical advice on how to balance the time pressures of product management and conducting proper user testing.

A fellow had just been hired as the new product manager at a technology corporation. Taking the desk of the former product manager, he opened the desk-drawer to find three envelopes marked "Open in case of emergency."

The best source for product leaders is someone already doing the job elsewhere. But you have to ask yourself, why would someone leave one job for another unless there’s more money or more responsibility.

When stating your product strategy or your key functionality, you want to ensure that your message resonates instead of sounding just like everyone else. One technique for evaluating strategic messages is to see if the reverse is a sound strategy.

Rating defects is often a nightmare. Bad sales people tell their customers to rate everything a Sev1 to ensure the feature gets delivered. Bad QA leads use bug ratings to prove a political point. Bad developers rate critical bugs as Sev4 so they don’t have to work on it.

The people in development and support should be clear on your rating system.

Some people ask me about the difference between a proDUCT manager and a proJECT manager. I find the easiest approach is to consider the two roles against the product life cycle. A project manager typically has authority to plan, manage, and execute a given scheme--usually a single iteration of a product release while a product manager focuses on managing a product throughout its lifecycle across multiple releases.

A product manager is a marketer, a negotiator, a demographer, a liaison, a researcher, an innovator — it can entail so many jobs that two job descriptions reading “product manager” may read quite differently depending upon the product and the company. Given such a diverse range of duties, what exactly qualifies someone to be a good product manager? In short, it requires a firm grounding in the present and a creative eye toward the future.

Marketing campaigns must be measured. If you can’t prove the value, then you shouldn’t be doing it. Examining marketing campaigns is a key part of a market retrospective, part of your product playbook.

 For many product managers, the main channel to customers is through the sales team. Sales teams know which features sales are won on and which they’re lost on. Sales knows what features prospects are asking for and can place a direct monetary value on implementing such a feature request. But sales people listen to sell; they don’t always listen to learn.

I read an article that claims Agile Development has now reached the “trough of disillusionment.” It seems that executives and product leaders have started to pine for the good old days of waterfall.

You remember waterfall. We had lots of big documents and checklists and wonderful GANTT charts and status boards. And we were always sure what features would be delivered on certain dates.

Wait. What?

Did we ever hit our dates? The big lie of waterfall was that you could anticipate all requirements in advance. And that requirements didn’t change. And you’d hit your dates. And you could still somehow add features without delaying the project or increasing the headcount.

Would you be surprised to learn roughly 50% of sales people's time is spent working on things that do not generate revenue? In short, half the time, sales people aren't working toward their objectives but are providing market expertise to the rest of the organization.

I had the pleasure of being interviewed by Ravi Kumar, founder/curator of ProductCamp Singapore, product owner at Autodesk, and host of yoursproductly.com. We scheduled 45 minutes and ran over an hour. So much to say, so little time. 

Where do you find ideas for new products? After all, it seems like everything's already been solved. Yet ideas are everywhere. What problems are you dealing with today that requires a solution?

Have you looked at your address book lately?

I have numbers and names I've moved from one computer to another and from one address book program to another; I've been using smart phones for years. I have contacts spread across three accounts.

A reader asks: How does one deal with one-off feature requests from sales people that are supposedly deal breakers?

No product is ever finished. There's always another feature needed. That's why it seems many product managers are continually saying "no" to sales requests. Yet, to the sales person, these one-off requests for a single customer seem perfectly reasonable.

Look at it from a sales perspective: You don't have this key feature; you don't support this key technology. And the competitors do. Remember, the only time sales people hear something good about your product is at the annual kickoff meeting but they hear bad stuff all the time.

When we're talking about positioning and messaging, I always reflect on the falseness of many messages: customers come first; we're here to help you; we're scalable.

Just saying it doesn't make it so.

Here's my favorite:

For your convenience. 

Just think about the number of times you see that phrase. How often do you think, "Wow! This is really convenient!" (For me, it's never).

My definition of innovation is solving a customer problem in a new way. The key to innovation is an intense focus on one specific type of customer and problem. To build an innovation team, you want to pull together people who have experience solving this type of problem.

Roles and responsibilities for product managers and product marketing managers vary from industry to industry and even from company to company within an industry. In general, we see product managers in mobile products more focused on technology skills while product managers for enterprise products tend to be more focused on sales and marketing. Hardware and semiconductor industries rely heavily on operational skills for product managers. When considering a product leadership role in any company, get specifics on the types of activities that are expected in the job.

Product management is about empowering others. In each stage of the life cycle—before, during, and after product development—the product manager brings clarity to the team.

I hear many reasons organizations adopt agile development so it's good to see the facts. The number one reason teams adopt agile is to accelerate product delivery. But in close second is enhance ability to manage changing priorities. (Notice also that reduce project cost isn't in the top 10. Agile is so much more than "cheaper development.")

It seems too often that goals are in conflict. One department has not staffed appropriately so they rely on another group to fill the gaps. Sales people are focused on deals, Marketing is focused on awareness, Development is focused on delivering on time. What’s needed is a team of peers working together for a common goal; a team with mutual respect for each other’s skills.

From a design standpoint, your teams should plan for mistakes and confusion. Not every process is step-by-step, first A then B. More often, you do half a process and then get interrupted and return later.

Products should allow us to cancel or undo or revert. They should guide the novice persona step-by-step through a process. And they should resume where you left off.

They should be… forgiving.

How does a pack of wolves take down a bear? They attack from all sides. While the bear is dealing with a frontal attack, another wolf is attacking from behind. Ultimately, the bear gets exhausted from turning and turning and turning to address each attack.

To survive attacks from too many internal ideas and too many external threats, you need a nimble planning process ;to move (quickly) from idea to execution. You need to evaluate a new idea, test your hypotheses, and come up with a plan—before your competitors do.

The key to value-based pricing is to align the price to the pain. (Call it pain-based pricing if you prefer.) What is the value of removing the pain? 

As you reflect on which of these seem “fair” to you and which make you feel ripped off, you realize the connection between price and frequency of the pain. That is, how often the pain occurs tell us whether to use a one-time fee or recurring fees.

Have you heard the saying that you can’t get promoted until you have someone ready to replace you? If you can't be replaced, you can't be promoted. Yet there will come a time when someone has to take over for you. When managing a product, or raising a child, caring for your parents, or taking sick leave. Are you ready?

A product manager took a job recently and asked about her predecessor’s files. She was told, “Well, there’s a lot of stuff on sharepoint. You should look there.”

What we need is a binder—a playbook—of the active projects and all the associated paperwork.

Here, from a list by Seth Godin, are some attributes that make your personas more like real people.

My laptop keyboard broke. I called the manufacturer who was quite helpful. She quickly gave me a return authorization and even sent me a prepaid label for shipping. But… I was without my laptop while it was being fixed. Through a series of misadventures, it ultimately took six weeks (that is, six weeks without the computer) to get it repaired. I had to buy a new computer so I could continue working. So, a mostly good vendor experience with very friendly and helpful people. But not a good customer outcome.

My former VP of Marketing said something that has been a guiding principle for me throughout my career. “Marketing people move all customers forward in their buying cycle; sales people move one customer forward.”

Today I help teams clearly define their roles and responsibilities. What accountabilities to assign to which titles. This “one customer vs market full of customers” rule provides a lot of guidance and we always identify a number of activities that should be done by others.

Product managers often have the challenge to speak the truth, particularly to those in power—to execs and developers and sales people. “No, we cannot deliver that capability with today’s technology.” “No, we cannot add this idea to the top of the backlog; it has to be prioritized.” “No, we are focused on the market, not the requirements of a single customer.”

In most organizations, development teams have dramatically less capacity than the appetites of the business units and sales teams. That’s why I continue to hear things like “how can we get the developers to work harder?” or “why aren’t they giving me what I need?”

The big thing is this: you only get the development your organization has chosen to afford.

Many cannot understand why this feature or that one can’t simply be added to the list. Here’s why: adding a feature means moving or deleting another feature; satisfying one customer (and their sales person) usually means disappointing another customer (and their sales person).

Product marketing or market owners should focus on a market full of customers, and generate a prioritized list of what is needed by their markets; portfolio owners should direct those market stories to the appropriate product. And company leadership prioritizes these with the budget.

You’ve planned a new release, pulling together ideas from the market and from the company. You think you’ve got a really strong plan but as soon as it’s announced, the complaining begins. “Where’s my pet project?” “When are we going to fix security?” “But I promised this feature to a prospect!” “Waa waa waa!”

Never forget, a product release is always political. To be successful, every release needs something to appease each of your internal stakeholders.

User experience (UX) is an area that befuddles many product managers. Ideally, product managers should be focused on the customer problem while development designs the company's solution. A strong dev team will propose one or more solutions to the articulated problem, allowing the product manager to accept the best option by leveraging his or her business, technical, marketing, and domain knowledge. A UX designer is a critical element of a successful product team.

There seems to be confusion about "minimum viable product" (aka MVP). It doesn't mean a poorly implemented product; MVP is the smallest amount of coding that can be used to test your product hypothesis.  Before you worry about go-to-market, get a concept in front of some customers. Test your product idea.

I often chat with company leaders who ask me how to do customer discovery but I always find it a confusing conversation. They don’t seem to understand my questions. “Who did you build it for?” “What problems are you solving and for whom?”

Before you can re-imagine a workflow, you have to understand what customers do and why.

This ad was mentioned in  Made to Stick: Why some ideas survive and others die by Dan and Chip Heath.

Good stories have the element of surprise. "Unexpectedness" (if that's a word).

Do your marketing messages sound like a typical car commercial?

The best messages resonate because they articulate what you've already been trying to say.— Steve Johnson, Under 10 Consulting.

Have you ever been in a customer advisory board? How much did you talk and how much did you listen? After all, the idea of a customer advisory board is for customers to advise you. Yet in so many cases, vendors deliver one presentation after another. Talk talk talk.

You can learn a lot just by listening.

Marketing and sales people rely on product management for technical expertise; developers rely on product management for market expertise. Now those departments could increase their expertise through hiring or training. I mean, shouldn't the marketing and sales teams know how the product solves customer problems? Or they should hire product marketing managers and sales engineers who do. And perhaps the development group needs to hire business or product analysts to provide expertise to their teams. And if those skills are not available in the departments, product management needs to be expanded to support each department's expertise needs.

Have you had this experience in a presentation? You’re in the back of the room and someone close to the front asks a question. All you hear “Is it true that mumble mumble mumble mumble?” And the instructor replies, “Yes, that’s absolutely critical.”

Many of us need to do presentations at company or customer events. Here’s the best technique to deal with questions from the audience.

There are many times when employees need to use their own judgment. There's no rule that seems to cover everything and no historical reference to guide their thinking. Unless you get everyone to agree to Rule #1: do what's best for the customer.

Branding is a verb; brand is a noun. Branding is the exercise of telling your story to get people to buy your product. Your brand results from years of delivering great products and creating satisfied customers.

A reader asks: When are branded names preferred over descriptive names?

For your naming strategy, you should attempt to brand only one thing. Which will it be? The company, the portfolio, or the product? Or said differently, which are people buying?

I love deadlines. I like the whooshing sound they make as they fly by.—Douglas Adams, author, The Hitchhiker's Guide to the Galaxy

Changing a project code name to a marketing brand name is nontrivial. That's why I always recommend that project names be offensive or embarrassing in some way so that developers don't fall in love with the project name. Had you called the project "Spaghetti" they probably wouldn't fight the change so hard.

Lately, I've been recommending some new titles for product managers. A "product owner" (sometimes called a technical product manager) should be near their development or engineering team; a "market owner" (sometimes called a product marketing manager) should be near the markets they serve. Most of all, a "business owner" (aka strategic product manager) should be near the executives.

Sales teams often need access to deep product knowledge. That’s why many product managers get involved with roadmap discussions, technical demos, and answering RFP/RFIs. In fact, 46% of product management time is spent in firefighting.

One VP claimed that product managers should be the source of all product knowledge for the entire company—the “Wikipedia of the product.” And published the home and cell numbers of the product managers. Right idea maybe but wrong implementation.

It’s not that product managers don’t want to support sales people; it’s just that there aren’t enough product managers and too many sales people. We need to support the sales teams more efficiently. Here are a few techniques that consistently get good results.

Whenever I perform a RACI analysis I find the team confused about the terms “responsible” versus “accountable.” I often encounter confusion about the difference between a product and a project, and between a technique and a tool.

Having clarity on the exact meanings of words is important. It’s difficult to have a conversation when different team members have different interpretations of the terms. In the RACI model, the ambiguity of the terms “responsible” and “accountable” confuse many people, which is why I use “responsible” and “approval” instead.

When I started a new job as a product manager, my company president said, “You need to find out why development is broken. Our developers are terrible—they can’t seem to ship anything.”

So I sat down with my developers and said, “The word is that you’re terrible and never ship anything.”

The lead developer said, “I’m sure that’s how it looks from the executive corner but, actually, we’re practicing what we call ‘requirements aging.’ We don’t work on anything for a month because some executive usually changes the requirements before we can begin.”

And sure enough, a few minutes later, the VP of Engineering came in and said, “Guys, stop what you’re doing. I’m getting new requirements.”

I’m a big believer in brevity. One-page documents, cork boards of index cards, simple spreadsheets of prioritized items. I have come to believe that most organizations need a small number of living documents—fewer than 10—to manage their products and services. I believe in minimal process, brief artifacts, and simple templates and worksheets.

Except for one. I think a product manager’s journal often makes sense.

If you’ve been working in the same field for a decade, you’re probably following a passion as well as a profession. Domain expertise brings loads of context such as understanding the implementation aspects of HIPAA or the best way to mount a video camera on the outside of a building. Domain experts know how things really operate and are really installed—not just the way they’re supposed to be according to the documentation.

Write down everything you need to do.
Put the list in order of importance.
Work from the top down—from most important to least important.
Stop when you run out of time or money.
That’s it.

That’s a backlog.

There are many ways to write feature requests including traditional requirements, user stories, and job stories.

The traditional requirement took the form of “The product shall <have some capability>.” And this approach can work. Many teams still use this format, particularly for what are called non-functional requirements—that is, requirements that focus on capabilities and constraints, like performance, usability, security and similar items that are not feature-based.

The challenge many teams face with traditional requirements is they tend to articulate an already-designed feature. The problem with this approach is the focus is on the product rather than the person using the product.

A difficulty for many agile teams is the granular nature of user stories. Some are written about the problem to be solved and some are written about the feature to be built and some are actually individual tasks for the developers.

Does your organization have a way to move ideas into production?

The three horizons model is a great tool for thinking about product maintenance versus new features development versus new product innovation.

Measurement is important. Knowing the results of a marketing program or of a technology test is critical. But the key is knowing which metrics matter and then adjusting your plans as a result.

One of the corporate competencies that no one seems to discuss is passion. We talk about systems and expertise and different departments but passion and purpose rarely make the list.

Yet it is passion that makes people go the extra mile. It’s what makes them stay late and come in on the weekend.

Feature prioritization is a mystery to most of the people in your organization. How things get into the product is unclear. For executives, it seems their favorite features get in only if they complain loudly. For sales people, it seems that none of their critical features even get considered unless they commit the team with a customer contract.

What few seem to realize is you have many, many more requests than you have resources. You must constantly weigh the merits of one feature over another. Plus take into account defects and infrastructure.

Show them how you choose.

Marketing, like every other department, has to prioritize. We have to choose. And that usually means choosing not to do things. Invariably some don’t get their pet programs funded. After all, there are always more ways to spend money than the budget allows.

Marketing needs to focus on business prioritization—just like agile development teams.We can learn a lot from Kanban. Just like your home budget, you allocate funds by category, prioritize the list, start from the top and work your way through the list until you run out of time or money. We need to focus on business prioritization—just like agile development teams.

In my early days as a product manager, I really enjoyed doing product training for the sales people. I was good at presenting. I enjoyed it. And I wanted them to see the presentation and demo done correctly at least once. Yet all the sales people said, “Man! That kid is good. I’m going to take him on all my sales calls.”

In a similar story, the VP of sales distributed the home and mobile phone numbers of all product managers to the sales channel (including international). Within a week, all of the product managers had gotten new, unlisted phone numbers.

These scenarios—with all the best intentions—resulted in sales people perceiving product management as the go-to resource for all things product.

Is that what you want your product managers to do?

In small companies—and in some not-so-small companies—the development lead often serves as the product leader or product manager. Is this a good idea?

In your team, who is responsible for persona or market definition, requirements, acceptance testing, and feature prioritization?

The standard rejection letter claims “We’ll keep your resume on file.” But do you really?

You should and here's why.

Lately everybody seems to be saying you should learn to program. But unless you have a reason—an application—you’re unlikely to stick with it. Same for a web site, or a blog, or whatever.

A friend hasn’t used Excel in years but thinks she should know it. But no matter how she tries, she just can’t get into it. The problem is, she doesn’t need it. She doesn’t have an application. And I’ve found that can’t really learn something until you have an application for it—a real need.

If you had to identify, in one word, the reason why the human race has not achieved, and never will achieve, its full potential, that word would be meetings.—Dave Barry

What would you do differently if meetings could only be 5 minutes, 20 minutes, 90 minutes, or all day? No hour-long meetings!

It’s unfortunate that our calendar programs insist on booking one-hour blocks. Some meetings only need to be 20 minutes; others need to be two or three hours. Here are some thought on having better meetings.

I’ve long been uncomfortable with the term “marketing.” For many of us, marketing is a philosophy. Marketing is looking at the business from the buyer’s point of view. It’s looking at the whole product, not just the software. Marketing includes packaging and pricing, and even how we answer the phone. But for others, “marketing” is a department, often associated primarily with advertising and branding.

Consider this: in marketing we use "greeking" to help people evaluate a design without getting distracted by (or obsessed with) the text. Product marketing owns the text; marketing owns the design.

I didn't necessarily plan for a career in product management. I spent time in development. I spent time in sales, sales engineering, and customer training and implementation. These and my college courses somewhat, perhaps accidentally, prepared me for the job.

I’ve seen many product demonstrations. Some good. Some not. In some cases, it’s clear that the person doing the demo hasn’t prepared and is just following a canned script. In others, you can tell that they put a lot of time into tailoring the demo specifically for the client, but even then, the demo can often miss the target.

How do you create a great demo? Show buyers what they need to know. But not necessarily what they think they need to know.

In a workshop, we were discussing customer interviews and someone wondered why we bother. “After all,” he said, “people only seem to listen to data. They want to know how many and what percentage.” He suggested that we stop doing interviews and focus our energies on surveys instead.

Except… you don’t know what you don’t know.

In my experience, people have either breadth or depth. Some people have a little information about almost every topic. After all, most people only have so much room in their heads. Some people have a lot of information about one topic. Do they have breadth on multiple topics or depth on a single topic?

The phrase "what you have to understand" rarely refers to something I have to understand.— Steve Johnson.

Some companies’ paranoia is laughable. They worry about piracy when they should worry about obscurity. They worry more about protecting an idea than they do about making sure it’s an idea the market will embrace.

One of the reasons that agile methods are so effective is they focus on getting stuff done. Do a little work, show your results, and then move to the next step. Avoid analysis paralysis.

I’ve known sales people who hate selling but that’s what they were trained to do. I’ve talked with product managers and product owners who didn’t like working with engineers and developers. I have friends who’ve been doing the same job for 20 years and can’t stand it.

Everyone has talent and many of us need help identifying that talent.

That’s what parents and teachers and managers were supposed to do.

You have spent a great deal of money and effort to build great products. But have they been installed and implemented correctly? Who verifies the acceptance criteria of your services.

Is that a job for product management?

“Strategy.”

What a word.

If I say “these activities are tactical,” people responsible for those activities get upset. If I say, “this is strategic,” people relax and feel better about themselves.

There’s a sense that strategic is somehow better than tactical.

A caesura is a long pause. The term is mostly used in music and poetry but I first learned about it as a “technique” in sales methodology training. The idea is that extroverts are so uncomfortable with silence that they rush to speak before the other party has finished thinking.

Sales people and other extroverts need to get comfortable with silence. They need to slow down and let the client process information.

Product managers do too.

It’s vastly easier to sell products when you understand them deeply.  Everyone needs to know what we do here. And in my experience, the best sales people are ones with domain knowledge… but it’s their ability to apply that knowledge to customer scenarios that creates success. The best sales people are trusted advisors to their clients. And that’s the way it should be. What do your sales people really need to know about your products and technology?

The rules of product management and marketing have changed; so have the rules of development and sales. Are you (and your people) keeping up?

Do you have ideas that are crazy? Are they visionary ideas or are they just crazy? It’s hard to tell sometimes. After all, crazy ideas don’t seem so crazy after the fact. Who would have thought that Apple could re-invent the mobile phone? Sure, it seems obvious now but it wasn’t when they began. And the idea of pursuing consumers instead of their core business buyers probably seemed quite logical to the folks at Blackberry. Oops.

A key element of many agile methods is the retrospective. After each iteration, the team comes together to discuss what worked and what didn’t, and to brainstorm ways to improve the process. After all, the people who participate in a process are the ones most likely to see ways to improve it.

But let’s take it further. Don’t limit your thinking to just the product creation process. After each product release, let’s examine every process: the development methods, the product launch, the sales enablement, the roll-out to professional services and support.

Have you ever helped your parents with their computers? It becomes shockingly obvious that there are too many options and too many ways to do too many things. I often find myself shaking my head, wondering, “How did you even find this?” Things that ought to be clear aren’t, and danger lies in only a couple of mouse clicks.

Perhaps it’s because we don’t really understand our customers. It’s not that those who have responsibility for technology products think more options is better; it’s that we don’t know which to include and which to omit.

People talk about being market-driven and performing customer development. Every marketing person will tell you that customer interviews provide deep insights on the product, its promotion, your sales team effectiveness, and your company strategy.

Do you need to be convinced that listening to the market is a good thing?

MRD, PRD, FRS, BRD. How many of these documents do you have? Each one was initiated with the best intentions. Some confusion in the process, a missing role, a book somebody read. Before you know it, you're not building a product; you're building a bunch of documents. But there's something even more systemic. We're trying to do too much. We have too many documents, too many priorities, too many meetings, and too many people in those meetings.

We say “yes” to too many things.

Steve Jobs said, “It's only by saying 'no' that you can concentrate on the things that are really important.”

There are plenty of good ideas—you have to choose those that are critical to your product. You have to say “no” to the many, many things that are compelling but not vital.

If you want time, you must make it.

The great thing about product management is you work across all parts of the organization—development, marketing, sales, services, support, finance, and the executive team.

The secret to success is to know the potential customers for your product better than anyone else.

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.

Imagine you're a new product manager. What company-specific knowledge do you need? Is there a standard template for positioning or for a business case? Where is it? Once you fill it out, how do you share it and store it? And with whom?

What you need is a product management playbook, a collection of the templates and tools tailored for your organization.

I hear it from developers, product managers, product marketers, executives. When writing anything from a press release to a programming module, most folks write for their parents. Or their friends. Or themselves.

That's the value of personas. They remind you that you are not the target customer, nor are your colleagues, your leaders, or your families.

The reality of today's workplace is that almost everyone needs strong speaking skills. There are loads of resources for doing better presentations. Here are a few of my favorite tips.

Why don't you go to the carwash more often?

When it's a beautiful sunny day, many drivers think, "Hey, how about getting the ol' car washed?" Then they check the weather forecast on their phone and say, "why bother to get the car washed if it's just gonna rain tomorrow?"

So the people who run car washing services see ups and downs in their revenue, entirely dependent on the weather forecast.

Is there another way?

A recent survey reveals product managers and product marketing managers spend 46% of their time in firefighting. With so much time focused on operational issues and emergencies, when are you going to work on the critical core documents that drive your product strategically?

I've seen many product managers attempt to write business plans and development documents and sales tools accounting for every possible contingency. ("Suppose a tree fell down!") And yet, some things you anticipated never occur, and the ones you didn't anticipate frequently do. ("Supposing it didn't," said Pooh.)

Who defines product positioning? Product Management or Marketing Communications?

Product managers are responsible for the features of the product and its positioning in the marketplace. The Marketing Communications (marcom or marcomms) organization is chartered with delivering the product message to the market. Product Management defines the positioning and Marcom delivers the positioning.

Here's a crazy idea. What if we thought of marcom as a development organization!

A lot of product management is mitigating risk. We estimate revenues and costs, prioritize features and stories, and try to articulate a message that resonates with buyers—all in the hope of making the best choices for our organization.

We do what we can to prevent failure. And that's good. 

Every marketing resource—books, seminars, college courses—tells you to visit customers. You certainly don't learn anything about the market while sitting at your desk or in conference rooms. Yet even when we do visit customers, we often have a short-term agenda. "Do you like our user interface?" "Will you buy this if we make it?" "Can I have a sales guy call on you?"

However, small improvements—often quite easy to create—can have huge ramifications.

I’ve become a real fan of win loss analysis. That’s where to begin as you look at problems in your revenue generation. Win loss analysis answers the questions: "Why do we lose deals?” and “Why do we win deals?” It’s likely you’ll find from your analysis some simple things to fix in sales training and coaching, sales enablement, and leadgen, but you’ll also find some areas of the product and operations that could use your attention.

I was running a positioning exercise with a team of product managers and VPs. We were really getting into it when the VP of Marketing interrupted the process to say, “We need to use the word ‘power’ in our messaging. The president loves that word.”

Maybe that’s why so much of the positioning I see is industry gobbledygook; Marketers are trying to impress the leadership instead of the customer.

I’m an agile advocate. I’ve worked with teams who can deliver better results sooner. I love the emphasis on conversations over documents, and the ability to adapt to changing requirements. But that doesn’t mean I think everyone in the company needs to know the mechanics of agile methods.

Half the money I spend on advertising is wasted, and the trouble is, I don't know which half.—John Wanamaker

Many HR professionals would apply Wanamaker's statement to skills training: “Half the money I spend on training is wasted.” In fact, it’s the number one issue I hear when folks try to bring change to their organization.

Market research is easy. Visit customers, with or without sales people.

Go on sales calls. Go to user group meetings. Go to conferences. Call a few customers on the phone and ask to how they are using your product, where they find deficiencies, and what direction they are taking their own businesses.

You don’t have to hire an agency; you don’t need to spend a lot of money. A quick phone call or skype meeting is often all that’s necessary to get in sync with your customers.

You just have to learn to listen.

There's doing it right, and there's doing it perfectly. You want to focus on the former and not the latter.

Marketing dragged me into a meeting with a new agency. There, I was asked to talk about the people who buy the product, some of its best capabilities, and some of my customer stories. This went on for a bit as I tried to figure out their agenda. Finally it hit me:

“Are you trying to figure out my positioning?”

“Yes,” they said. “Our plan is to interview you and all the members of the leadership team. Then we’ll take what we’ve learned to craft your product positioning.”

Instead, I opened my laptop and shared my already-approved positioning document with the agency team. They were shocked. They rarely, if ever, work with a company that has figured this out already.

For agile teams, the biggest area of friction for agile teams is agreement on what constitutes a story. Product managers and product owners try to write market requirements in the form of a story when many developers really want product specifications.

It seems so simple. Product managers and product owner write user stories; developers break them into tasks and develop the feature. But the difficulty facing many agile teams today is what, exactly, is a user story?

Agile developers want user stories; product managers want to bring back stories from the market about users. What we REALLY need is to understand user goals. Is there a difference? 

Tactical tools stored in a desk are worthless; they must be published internally to be effective. “Publish or perish” is as true for product leaders as it is for academics: if the company does not know what you do, then what you do is not important to the company.

Have you heard this one?

A machine breaks, the assembly line is idle, and nobody can fix it. Finally they call the old guy who retired and he agrees to come fix it. When he arrived, he listened to the machine for a moment, and then hit the machine with a mallet. Machine fixed; assembly line working again.

(Do you know the punch line?)

While not directly the responsibility of product management, processes in other areas of the company that affect the customer—and they all do—should be reviewed by the product manager. How is the customer (and potential customer) greeted when he calls? How easy or hard is it to obtain information? Is the web site updated? Are the sales teams informed?

When organizing teams, you want to align the different areas of expertise with the needs of your business. Rather than organizing teams around products, I recommend a product management team organized around a portfolio of products, ideally with staffing in four areas of expertise.

A product or portfolio roadmap is a key tool in planning, looking beyond your current product deliverables to months and years ahead. But a roadmap can also be a helpful tool with sales people, prospects, and customers.

But many companies, particularly startups, find sharing the roadmap is a great way to promote and validate their innovation plans. Obviously you cannot do everything at once so a roadmap shows your market that you’re thinking beyond the current development iterations.

Estimating is perhaps the biggest issue facing product managers regarding product and portfolio roadmaps. Obviously you want to get an estimate before anyone spends too much time designing a solution but you can’t really get a valid estimate without some level of design.

Here’s the big trick: guess. 

Each year, I re-read  Blue Ocean Strategy by W. Chan Kim and Renee Mauborgne. As I’m reading it again, I wonder if it’s possible to predict a successful strategy. It’s certainly easier to work backward from success and use value innovation as a tool to explain the success. As a predictive tool, the authors argue that you can identify which de facto standards for the industry are out of sync with the buyer’s value. Is the authors' “value curve” idea a predictive tool or an evaluation tool?

Executives, sales people, and marketing leaders are often frustrated with the short-term focus in product management, particularly those using agile development methods. Leaders have no idea what is planned—if anything—beyond the next two-week sprint. And that’s why they ask for a roadmap.

In my product leadership roles I always have a (small) collection of documents that reflect the current state of my product(s). Sometimes I have a standard price list; sometimes a financial model. Sometimes it’s a set of positioning documents by persona, or perhaps a roadmap of the next few releases. These living documents are the ones that I reference often. Once I kept them on paper in a notebook; now I keep them in a shared folder to access from my computer or tablet.

What are the templates? Here's a list of fewer than 10.