DelrinaDifferentiationInnovationMarketingProduct ManagementProduct MarketingRequirementsResearchSaeedSalesSegmentationWorth Repeating

Worth Repeating: Do Product Managers need Domain Knowledge?

Here’s an oldie, but a real goody. Back in 2007, I posted this piece about the problems that occur when Product Managers (and thus companies) don’t have proper domain knowledge. It garnered a LOT of comments, especially from some former Delrina employees.

I’m reposting it as it is (still) a good relevant topic. I’m not trying to (re)ruffle any ex-Delrina feathers.

But I still want your comments. My own opinion on this topic has changed a bit since I wrote it. I won’t elucidate on that just yet, but if people do leave comments, I’m certainly open to a good discussion.

As part of the second Pragamatic Marketing blogfest, I’m responding to Steve Johnson’s post: “Everyone needs to know what we do here“.

In it, Steve writes about the need for domain knowledge for technology workers, particularly in regards to the business they are in and the needs of their market. Whether talking about engineers, marketers, sales people or product managers, everyone needs to understand the company’s strategic objectives as well as some aspect of market dynamics.

In this case, I can’t really argue too much with Steve. If key people in a company don’t have domain knowledge, then the question “Why not?” must be answered. Do your competitors have domain knowledge? Most likely, especially if they are leading you in the market. How can anyone run any kind of successful business without domain knowledge?

For technology companies, the questions to consider revolve around defining exactly what “domain knowledge” is, and how best to acquire and maintain it.

Domain knowledge, particularly in B2B technology companies, can be quite complex. Not only do Product Managers need to understand the overall market, but also market specifics that vary from geography to geography. They need to understand overall trends in the market, as well as technology and economic trends that could impact product performance. Then come the questions related to competitors — who are they, what are their strengths/weaknesses, and where are they heading? Finally, Product Managers need to understand their target customers in detail — what they do, what they find valuable, how they currently use your product (or one of your competitors), and why they would value yours.

All of these areas of knowledge constitute domain knowledge. The reality is, very few individuals can have a full understanding of all of this information. I believe there is a myth that the lone Product Manager can collect, analyse, understand and then react to all of this information. The reality is that technology companies should look at the Product Management function as opposed to the individual Product Manager, as the locus of this knowledge.

Clearly other teams in the company also have domain knowledge, but Product Management needs to collect it and put it all together to make a coherent picture out of it. To do that well, it can’t be the responsibility of a single individual. Companies should be thinking about Product Management teams for each of their products or product families.

Some companies seem to succeed in spite of themselves. You’ve all heard of (or maybe even worked for) at least one of these kinds of companies. They had an innovation that lead to a successful product, but couldn’t repeat that success. Why not? One of the principal reasons is lack of sufficient domain knowledge to make the leap to a second successful product.

Case Study

delrina-logo.jpgRemember Delrina Corp? The makers of WinFax? Back in the early 1990s, WinFax was the clear market leader for faxing on Windows operating systems. Everything in the company was focused on the Windows operating system.

I was a technical writer at the time, and was hired to join the “small but growing” Macintosh team at Delrina. The goal was, as I was told, to build out a whole product line of Macintosh products, with the first product being fax software. And who knew fax software better than Delrina, the people who invented it?

At the time, the core Macintosh development team consisted of three people: the lead (and sole) developer (Don), the QA engineer (Mike) and me (the tech writer).

During the development cycle of the first version of Delrina’s Macintosh fax software, a number of things happened that made me wonder if I’d made a good choice coming to Delrina.

Given that the three of us (Don, Mike and I) were virtually the only people in the entire company who had actually used a Macintosh, most people there only experienced the product through the documentation that I was writing (on a Windows PC using Ventura Publisher nonetheless — not my choice!).

On the Macintosh, the software worked by setting the fax-driver as the target for print jobs. This was done via the Chooser in the Macintosh environment.

At one cross-team meeting to review the development and documentation status, someone, I don’t recall who, asked:

“What are these Chooser and Finder things? Who named them that? Can we change them?”

I kid you not. I couldn’t make that up. Almost immediately Don looked at the person and stated, almost robotically:

“No we can’t change them or rename them. They are fundamental to the operation of the Macintosh.”

I gathered that this was not the first time he had uttered that line.

Later on, the issue of the product name came to light. At another cross-team meeting, it was announced that the naming committee had decided on a name for the product, and all software, documentation, marketing materials etc. should use the name. The name was….hold your breath: WinFax Mac.

Now, if you recall back to the early 1990s, it was the height of the Macintosh vs. Windows fight. Users in the Macintosh community were pretty vocal about their disdain for Windows.

Mike and I looked at each other and waited for Don to say something. Don made an attempt to hide his frustration and then tried to calmly explain why the prefix “Win” as in WinFax was not an acceptable name for a Macintosh product.

The Product Manager would have none of it. He explained the enormous brand equity “WinFax” had, and how strongly attached the name “WinFax” was to fax software and that the plan was to leverage it in this new foray in the Macintosh market. Mike also tried to explain the issues with using “Win” in the name of a Macintosh product and was also shut-down.

A couple of months later, at yet another cross-team meeting, the PM announced that feedback had been received from a large number of beta customers indicating their dislike of the product name, and thus a new name would be found without the prefix “Win” in it. Mike, Don and I looked at each other and rolled our eyes.

Once the project was complete, I decided to leave the company and find employment elsewhere. Even back then, early in my career, I could see the dark days ahead if I stayed at Delrina. I found work at a startup, but continued to track Delrina and their Macintosh product line. A few months later, I saw a review of the product in a computer magazine. The review was OK, but the documentation got a 4 out of 5! 🙂 I still have a copy of that manual.

As it turned out, the fax product was Delrina’s first and last Macintosh product. Aside from Delrina’s lack of knowledge about the Macintosh computer and user community, they also didn’t understand the dynamics of the Macintosh fax market. Delrina had succeeded in the Windows market by being first to market with an innovative product, and then controlling the channels by signing OEM deals with virtually every PC fax hardware manufacturer. In short, virtually every PC faxmodem that shipped at the time came bundled with a copy of WinFax Lite.

The same strategy had already been executed by other Macintosh fax software manufacturers. So when Delrina entered the Macintosh market, it not only was a late entrant, but the channels were all tied up by competitors. Their strategy, leveraging their Windows dominance to enter the Macintosh market was completely useless. And why? Quite simply because they had no real domain knowledge or true understanding of the market they were entering. Decisions made in a vacuum always look pretty good at the time.


Tweet this: Do Product Managers need Domain Knowledge?  http://wp.me/pXBON-2Db #prodmgmt #prodmktg #innovation

  1. Geoffrey Anderson

    Great post and worthy of a reprise.

    When I saw the title, I will admit that I jumped to the conclusion that it was a post on why you needed to hire people with domain knowledge, but was pleasantly surprised that it wasn’t, and was more along the lines that your people must have (extensive) domain knowledge.

    I always wonder when I see a job posting that has such deep requirements in the domain knowledge that either a) they need to bring someone in to teach them the domain, or b) are targeting someone at a specific competitor, and all others need not apply. I guess there is c) Really don’t know what you are looking for, akin to the posting looking for rockstar product managers.

    A good product manager will come in, hit the ground running and quickly absorb existing domain knowledge, AND then extend it is ways that were probably not visible before. We are sponges, we are curious, and we have extensive networks to help us learn the market and product. Otherwise, we would have washed out years ago.

    Thanks for sharing, and glad to see the reprise.

    WinFax Mac indeed. As a Mac person, that makes my nose wrinkle.

    1. Saeed


      Thanks for the comment. Domain knowledge is a tricky subject and the need for it in a particular individual varies on the role, focus, company and domain. 🙂

      Companies need domain knowledge without question. Individuals need domain knowledge to the extent that it enables them to be proficient in their roles. Not everyone though needs the same knowledge and I think this is where companies get it wrong by requiring (or thinking they require) someone with both broad domain and PM skills. I’ll hire that person if I can find them, but in may cases it’s not possible. Instead I’ll look for good strong PM skills and domain experience from a related area. But in the end, it’s the team, and not the individual that will succeed or fail.

      In the Delrina example, it was a company full of very smart people without question. They knew how to write fax software and the Mac product was a good technical product. But the fact that “WinFax Mac” (as an example) was seriously considered as the product name, showed an overall lack of Macintosh market knowledge. And while they fixed that problem, it was a symptom of a much larger problem at the company.

      Success doesn’t always breed success. And this is one clear example of that.

  2. Jeff Lash

    I agree with Geoffrey — the question isn’t, “Do Product Managers need domain knowledge?” because the answer is a resounding YES. The REAL question is: Do Product Managers need domain knowledge in order to be HIRED into a company?

    In your example, a good product manager wouldn’t have necessarily needed to have much/any experience with Mac to be hired into the position of managing the new Mac product, but should have spent a bunch of time up front getting to know the market, potential customers, user/buyer personas, etc. Any decent product manager worth their paycheck would get out of the office, meet with customers/prospects, and understand the lay of the land.

    Yes, a certain level of domain knowledge is required. Example: If you’re designing a product for elementary school teachers, you should know a bit about elementary school education, educational regulations, different approaches to learning, how school districts are run, and things like that. Having that knowledge coming in to a job could be helpful, though lots of smart people can learn stuff like that very quickly. Do you need a PhD in elementary education or 20 years as a teacher? Probably not.

    Obviously, for some more specialized products — highly technical or scientific, perhaps — the level of domain knowledge necessary to perform the job may be higher, though I think in general we overestimate the value of domain knowledge and underestimate the value of just plain ol’ good product management / development practices and knowledge.

    1. Saeed

      Jeff & theprodmgr

      Thanks for the comments. In general I agree with you and in particular with the line from theprodmgr that “as long as the Product Management TEAM has the domain knowledge” things will work.

      I cited the Delrina “WinFax Mac” “What is this Chooser” examples as they were such egregious and extreme cases of lack of domain knowledge. The company was so successful in the Windows markets that it had blinders on top to bottom about the Mac market — with the exception of a few people like Don and Mike.

      Could you imagine if the situation were reversed? i.e. a successful Mac product coming to Windows? Would anyone have thought “MacFax for Windows” or something like that would be acceptable?

      Domain knowledge should not be viewed as the responsibility of a single individual or the few. It is also not static. But companies with blinders on, make these kinds of mistakes regularly.


  3. theprodmgr

    I have to agree with Geoffrey and Jeff….

    You don’t necessarily need to have extensive domain knowledge coming into the job, however you need to have the skills to be able to go out and get it. An understanding of how / what a Product Manager is supposed to do can be applied to any domain.

    A company will be successful as long as the Product Management TEAM has the domain knowledge and that can translate to successful products (measured as in ones that can be sold profitability).

    In my past two jobs, I was brought in due to my expertise as a Product Manager NOT as an expert in their domain. In both cases, I was able to leverage domain experts within the Product Management team to gain the domain knowledge I needed to be successful.

  4. Einar Gustafsson

    Being able to get out there and get the basic domain knowledge is one thing. But having true valuable insights in the domain and a passion for the product is what sets good PM’s and their products apart from great.

  5. Katelyn Friedson

    The best way for a product manager to acquire domain knowledge is to create/manage a product in a specific domain- so how can one gain these valuable insights without trying out different domains?

    I can’t say how advantageous it is to know several domains very well, because a lot problem-solving can be transferred and re-used from one domain to another.

    Additionally, isn’t a PM’s role to study the market, understand its customers- and marry market needs with business objectives? New domains/industries are popping up so frequently now, that if you don’t have the process or skill set to adapt to different domains (or different demographics or market segments within the same domain), then you’ll fall behind.

    And my opinion on passion is if you never experience what a certain domain is like, it’s tough to say it’s the one you’re most passionate about. IMO, PM’s are typically passionate about product development in general- regardless of the domain. I only speak of my own experiences, where most of my product management skills have been transferrable in my career and while one domain is a particular passion of mine, I realized it was the product itself that I grew attached to, but the actual building and process and strategy of product creation is what I’m really passionate about.

    And on the contrary- Lacking prior domain knowledge could put a product manager at an advantage as well. Coming in with fresh ideas and a diverse background is what a lot of companies often seek.

    My opinion- absolutely no domain experience required- unless a company doesn’t have time to give the PM a learning curve and chance to understand the market- which at that point, the company is already in the sh*ts.

    1. Saeed


      Thanks for the comment. Your last line sums it up well. But I do have to add that even if individuals have domain knowledge – which some did at Delrina WRT the Mac market — if the management won’t listen or is set in their ways, that’s a problem. All people in the decision making process have to be open to having their assumptions challenged based on market evidience — even CEOs.


Leave a Reply

Your email address will not be published. Required fields are marked *