Practical Rules for Product Management: Some rules just aren’t meant to be broken (Part I)

By Maureen Rogers August 01, 2009

The Pragmatic Institute Framework catalogs the activities and artifacts required for creating and delivering technology products to the market. You probably have a laminated version of it. Have you ever looked at the back? In addition to learning the Framework, people who attend the Pragmatic Institute seminar receive 20 rules for product management success.

Maureen Rogers applies her own interpretations and personal experiences to these 20 rules in her multiple-part series. In this article, she explores rules 1 through 5.

Wait half an hour after lunch before going in the water. Never end a sentence with a preposition. Don’t wear white after Labor Day and before Memorial Day.
Some rules really are meant to be broken.

But others aren’t. In the “other” category, there are 20 astute and practical rules that Pragmatic Institute has laid out for product management. I should know, because in my more than 25 years in B2B technology marketing, I’ve broken all of them. So with absolute conviction, I’ve reached the conclusion that, when it comes to rules, these all fall into the category of better to observe than to break.

After thinking about Pragmatic Institute’s rules, I’ve observed the following:


If product managers don’t do their jobs, the other departments will fill the void.

When I first worked as a product manager, I wasn’t all that sure what I was supposed to do. So I waited for everyone else—Engineering, QA, Tech Writing, Marketing, Sales Support, Customer Service—to stake their claims; then I ran around filling in the gaps. At the time, this struck me as a quite handy and pragmatic way to define my job. But it was a bad idea—and not just because I got stuck with all the stuff no one else wanted to do. As it turns out, products end up being better if someone truly owns the entire thing.

As so often happened during the course of my long career, I learned the hard way that good product managers aren’t just pragmatic, they’re proactive. They don’t just sit around waiting to see what everyone else does; they make it clear up front what their role is. And then they fill that role, rather than the gaps.

Here are just a few of the things that can happen when product managers don’t fill their roles:

If you don’t provide clear and supported input to the process, the engineers will develop what they please. It’s your responsibility to talk to your customers (and your prospects), check out the competition, listen to the analysts, learn about your industry, learn about your customers’ industries, find out what your sales engineers and customer support reps are encountering, look at those RFPs, and glean market intelligence. And it’s your responsibility to translate all this “stuff” into product requirements that you communicate to your engineers.

Yes, there will be things that your developers come up with on their own—and a lot of it will be great. But you need to be the driving force behind what goes into that product, or you could end up with a magnificently engineered product that nobody wants or needs.

If you don’t provide clear direction about your target customers, Sales will go wherever they please. Your products should be built with some particular use and customer in mind…shouldn’t they? Please let Sales know.

Even if your products are entirely horizontal—every company can use a database and a word processor—products need to be targeted to specific customers and/or buyers. You may also have a product that’s better suited for certain-sized companies or specific geographies. There may be good reasons to target industries as well. (If you’re selling to later adopters, for example, Get-a-Life Insurance is more apt to buy if One-Life-to-Live Insurance is on your customer list.)

The point is, you need to send Sales where they stand the best chance of winning. Even if you have the most generic product, you have to start somewhere. Pick that somewhere wisely, or Sales will pick it for you. And, in the short run, they’re not necessarily going to choose wisely (i.e., in support of your long-run strategy). Sure, they may make a sale or two, but it may not end up being a good thing for your product or your company.

While we’re on the subject of sales, if you don’t establish pricing, Sales will make it up. You absolutely need to listen to what Sales has to say on the matter. But it’s up to you to determine pricing that will work, that’s commensurate with the value provided, that’s not out-of-whack with the competition, and that is what the market can bear. If not, you’ll be in the wonderful world of having your sales team cannily figuring out what the prospects have in their wallets, and then establishing that as the price du jour—or just low-balling and overpromising to get the deal. (Just watch out when customers get together and compare notes.)

If you don’t provide clear direction about target customers and the right message for them, Marcom will go wherever they please and say whatever they want. Like Sales, if you’re not providing guidance to Marcom about target customers, they will come up with it on their own. Their programs may make spectacular sense; they may not. It’s best not to leave things to chance.

Similarly, if Marcom doesn’t know what the product is and does, they will come up with their own story. Again, their story may make spectacular sense; it may not. Again, it’s best not to leave things to chance. I worked for a company that was teetering, very publicly, on the brink of bankruptcy. One day, I saw a banner ad for one of our services. The ad touted our financial stability. I immediately called the ad person in Marcom and pointed out that this wasn’t exactly our strong suit. “But that’s what our buyers are most interested in,” she told me.

I could go on about how important this rule is, but by now you get it. And you were likely well ahead of me in getting it.

Of all of the Pragmatic Institute rules, I find this the most important. And that’s not because those who will be filling whatever void you leave are evil and must be stopped. (Hey, you may even want, need, appreciate their suggestions and advice.) But, if engineers are figuring out what’s in the product all on their lonesome…if Sales is pulling prices out of their ear on the way to a call…if Marketing is claiming that your product solves world peace when it’s really designed for warmongers—they’re all trying to do something that is neither their expertise nor their responsibility. That responsibility is yours. Take it and use it.


An outside-in approach increases the likelihood of product success.

However brilliantly, presciently, and uniquely imagined a product is; however a product idea seemingly springs full-blown from some Medusa’s head, there is no substitute for solving a real problem experienced by real people in a way that will work for them.

How do you get real?

I’ve found the key is in five simple words: See how your customer works.
That means looking at the current processes they have in place, at the inputs, the outputs, the end results. Who does what to whom? How do they do it? Where do they hit roadblocks? Little snags? Where does the ball drop? What happens when that happens?

There are a number of ways you can do this.

One is to actually go in and watch. Some of my most valuable hours in the field have been spent observing how my customers get their jobs done—with or without my product.

In days of yore, as the product manager for a mainframe financial reporting system, I spent the night at AT&T while they closed their books, just to see how they used our product.

Boy, was I exhausted after 20 hours. And, boy, did I see some areas where our product could be improved.

I’ve done this a few times since. And, to me, it’s the most effective way to figure out where your product needs to go. Knowing what people go through trumps your imagination, common sense, and intuition—no matter how wonderful they all are.

Another good technique is open-ended interviews that get your customers and prospects to talk about “things”: business, processes, behaviors, wish lists, druthers, etc. When I’ve used this method, I’ve taken notes and, where possible, made recordings.

A third technique I’ve used is creating “A Day in the Life” scenarios, where you lay out the hour-by-hour activities your customer goes through and figure out where your product can be inserted to relieve some of the pain that invariably occurs in even the happiest work day. Obviously, it helps if you’ve observed and/or spoken with customers to ensure you have the right idea about how they spend their days.

The bottom line: Your product has to “fit” the customers’ needs and desires, solving a true problem. You never want your customers to be stuck exchanging an existing problem for a new one—using your product. This won’t happen if you build a product outside-in.


Time spent on the strategic reduces time wasted on the tactical.

Simply defined, strategic is where you want to go; tactical is how to get there. It’s pretty easy to see that you’d better have the strategic figured out first.
While there are many different areas in which the “strategy vs. tactics” debate can occur, I’ll frame it here in terms of trying to market a product absent a strategy. (Which also translates into trying to market a product for which the product manager hasn’t followed Rule #1, and the product has just sort of happened—generally at the hands of the engineers, I’m afraid.)

My personal favorite is the “if we build it, they will come” approach, in which a product is built, then tossed over the transom into Marketing, who are presumably waiting with open arms and closed mouths for the product toss.
No, no, a thousand times no!

You need to have a product strategy in mind that spells out positioning basics (who’s going to use the product and why), establishes the pricing rationale, provides at least a rudimentary guidepost for where the product is going, etc., etc., etc.

Another thing we’ve all faced as marketers is the situation in which we’ve been goaded (forced?) to just do something, do anything. “Something” must be done! This usually comes down on the head of Marcom and usually means helping fill the big, gaping maw at the beginning of the sales pipeline.
Do something. Do anything. Let’s get going.

Banner ads…webinars…email blasts…spiffs…promotional deals…guys with sandwich boards trolling the streets.

Thus, the campaign to nowhere begins.

You may get somewhere, but even that somewhere is going to feel like nowhere, absent a strategy. Never confuse activity with action.

There’s a corollary to this rule: In the absence of a strategy, people will go ahead and do what they think is best.

So the marketers will look at the product they’ve been given and hazard a guess on where they can market it. They may do a bang-up job of it. (Great! Two hundred tuna fishermen attended our webinar. Too bad our product doesn’t really do anything for them. Not to mention that we really should be selling to tuba players. Tuna? Tuba? Close enough.)

Strategy’s hard. It means really thinking through things. It means taking a risk by declaring where it is you want to go. It means having the discipline and strength to give it time enough to succeed.

Tactics absent strategy? You might think you’re getting somewhere, but you’re really on the night train to nowhere.


In the absence of market facts, he who owns the compiler wins.

I’ve lived through this nightmare more than once, and all I can say is, even in the presence of market facts, it’s plenty easy for the guy with the compiler to win. But when you’re working with the engineers, it is always best to have the following:

  • Win-loss analysis. If 19 out of 20 times, you hear that a key factor in a loss was ease of use, your developers may respond that “the customers don’t know what they’re talking about,” “we’re selling to the wrong people,” and “our sales folks don’t know how to sell.” But you will have market facts to support your argument that the UI needs work.

  • Competitive information. The last thing you want to find yourself doing is playing competitive catch-up. It is always useful to know what you’re up against. And, if you can anticipate moves that your competition is going to make—by watching what they’re saying publicly, whom they’re partnering with, where they’re selling, etc.—so much the better.

  • Market trends. What’s going on in your industry or the industry into which you sell? What’s being said about technology trends? No, you don’t have to listen to every pronouncement from on high, but it helps not to operate in a complete vacuum. So dig up whatever data you can find on SOA, SaaS, MDM, or whatever acronym your product needs to accommodate. (Years ago, I worked for a software company that was wedded to OS/2. I came to a development meeting with a copy of InfoWeek magazine sporting a cover showing OS/2 in a coffin with a lily on it. That display definitely helped us move along on our decision to convert to NT.)

  • Customer input. The customer is not always right, and sometimes, they will ask for stupid or irrelevant things. But your trusted customers—not your developers—are the ones actually using your product, so their ideas matter.

  • Sales engineering and customer service input. Better than anyone else, your sales engineers tend to know the technical obstacles to selling and implementing your product. You need a forum for capturing their ideas. Better than anyone else, your customer service folks tend to know the technical obstacles to ongoing, day-to-day success with your products. You need a forum for capturing their ideas, as well.

When you, as a product manager, start talking product with the engineers, you need to be armed with the richest set of market facts you can find. The preceding suggestions are useful sources of those facts. It’s then up to you to put the market facts into a digestible, sensible format for presentation to engineering.

There is still no guarantee that a really stubborn guy with a compiler won’t balk at product ideas that aren’t invented in his brain. But, if you’ve got the facts, ma’am, it’s far more likely that resistance will fade away.


Product Management determines the go-to-market strategy; Marcom executes the strategy.

First off, much of my career has been spent in smaller companies where Product Management/Product Marketing and Marcom were housed under one very small group. Heck, I’ve been in places where they were me, myself, and I.

But I did spend several years in a large company where we had separate Product Management, Product Marketing, and Marcom groups. And herein lies a cautionary tale of what happens when it’s not clear who’s setting the strategic agenda.

At this company, Product Management and Product Marketing resided in the same group, and we were clear about the roles each group played. But Marcom was completely and utterly separate from us, connecting on the org chart only to the president’s box.

This would have worked out fine if someone in the president’s box or in the EVP boxes just below actually agreed that Product Marketing—which set the go-to-market strategy—and Marcom were separate functions, with different roles, responsibilities, and expertise. And then declared that the two groups were going to get along.

Well, that never happened. And, although the reasons had little to do with marketing, is it any wonder that the company folded?

Although I had many good friends and colleagues in Marcom, relationships between us (Product Marketing) and them were generally non-productive and rancorous.

Marcom was under Sales, and much of what they did was what Sales wanted them to do. Suffice it to say that Sales wanted the short-term hit, not the long-term build. It never seemed to matter what the overall corporate strategy was; if Sales didn’t think they could easily sell it tomorrow, it didn’t get marketed today.

Marcom also owned the entire budget, so Product Marketing was always in the position of begging to get any attention for our products.

Sometimes, the budget stuff played out in ridiculous ways. At one annual (internal) sales conference, we had an exhibit hall for the products. Product Marketing had draped tables, out-of-pocket signs printed at Kinko’s, photocopied sell sheets, no lights, and lame-o promotional gimmicks to attract the sales guys’ interest.

Marcom shipped in tradeshow booths—complete with beautiful lighting and nice signage—at which they showcased their new corporate brochures, ad campaigns, website, and corporate giveaways.

We had the content; they had the stuff.

Shouldn’t we have come together on this? But, no. The enmity between the two camps was just too great. The rap on Product Marketing: no sense of the real-world pressure from Sales. The rap on Marcom: no content, big spenders.

I spent half my life at this company just trying to define organizational roles, smooth ruffled feathers, make peace, and make some sense out of things. Believe me, if I couldn’t get things to work out between us, no one could.

What a waste!

So, I’ll add to Pragmatic’s rule: Ensure that the roles are clear, and insist on an environment of mutual trust and respect. Strategy and execution are both important. But if the executors aren’t bothering with the strategy, whatever happens will not be pretty.

Maureen Rogers

Maureen Rogers

Maureen Rogers is a senior consultant with Communigration, specializing in strategic product marketing (market identification, product positioning, and product messaging) for B2B technology and services companies. A resident of Boston, Maureen is a graduate of MIT’s Sloan School of Management and has over 25 years experience as a product manager and product marketer. With her friend and colleague John Whiteside, she blogs on marketing at Opinionated Marketers and, on her own, writes about business, the workplace, and culture at Pink Slip. Maureen can be reached at

Looking for the latest in product and data science? Get our articles, webinars and podcasts.