Everyone Needs to Know What We Do Here
I hear this expression used by marketers and sales people all the time. “Explain it to me like I was a five-year-old.” Ugh. How many pre-school-age children work in your company? Got many five-year-old kids sitting at desks? To say “Explain it to me like I was a five-year-old” is to say “I’m too ignorant to work here.”
The fastest way to lose credibility in a technology company is to say that you don’t understand technology. It’s okay to say that you don’t understand a new idea or a new implementation but to be effective in technology marketing and product management requires domain and technology expertise. People who tell you otherwise probably aren't very effective in working with technical products.
Marketers and product managers need to understand the technology of their business. Guess what? Developers and engineers need to understand the business of their technology.
Domain expertise helps product managers connect with buyers and users to truly understand what they need and not just what they want. Domain knowledge steers marketing communications to effective programs with a clear message for the buyer. Likewise developers and engineers. When a judgment call is necessary--and this is often--a developer who understands the customer profile is more likely to make the correct choice.
Outsourcing continues to be a hot topic in our product management classes. And frankly I’m opposed to outsourcing, not always a popular position. Some people have had good experiences; many have had terrible ones. The problem is that the fundamental idea of outsourcing implies that product development is factory work. And it isn’t. Well, I suppose localization or porting or assembly might indeed be factory work but creating new products that people will buy is a job for people who understand the domain. Gone are the days when we can have 'coders' who program to someone else's design.
I’m convinced that the iPod was created by designers and developers and engineers who love music—not by factory workers pounding out code. Look on the box that came with your iPod. It says, “Designed by Apple in California. Assembled in China.” Apple designed the iPods with artists in California and sent the designs to factories in China for assembly.
Firms sending good, complete designs offshore do achieve good results. Good designs = good results. Jobs not requiring knowledge of the market and products are ideal candidates for outsourcing. There are outsourcing firms in all aspects of technology including development programs and marketing campaigns. And for that matter, product sales can be outsourced too, can't it? If your sales people don’t need to know the product, outsource them too! If any job at any type of company can be done by someone without knowledge of that space, why do it internally?
Our developers, engineers, and product managers—and yes, even some sales people—embody a terrific collective of domain knowledge... or should. We can allow more freedom and creativity in the design and implementation if the team members understand the customer problem.
We can communicate in shorthand when both sides know the domain.
Employees cannot afford to be ignorant of their business. Product managers are learning to be more business-oriented. Marketers and developers need this too. Read your company's annual report. Make sure you understand your company's business strategy and challenges. Be able to participate in a strategy conversation. Otherwise, if you say, 'just tell me exactly what you want,' you're competing with outsourcing firms saying the same thing... at a fraction of your cost. Don't get so caught up in your technology that you lose sight of your business.
Steve Johnson, Pragmatic Institute
Update: As part of a BlogFest, several product management and marketing bloggers commented on this topic. Their opinions are published below, as well as links to their blogs where the discussion continues.
Understand your product’s domain
If you want to be a bad product manager, assume that domain knowledge is all you need to succeed. You know the company, the market, the competition and the customers because you’ve been involved in the industry forever. In fact, you used to be on “the other side” — as a customer, a vendor, or with a competitor. The knowledge that you’ve gathered over your years of service would be impossible for someone to gather quickly, and your domain knowledge is fundamental to your success in product management.
If you want to be a good product manager, make sure to have the right amount of knowledge about the domain in which you are working. Product managers need to understand their market, and to do so requires understanding of the domain. For example, if you are developing software that is sold to police stations to track cases but you have very little knowledge of the law enforcement and the criminal justice system, you will likely fail. How can you understand unmet needs of your customers if you do not even understand their most basic goals and tasks?
Domain knowledge provides product managers with the information to make the decisions that will be best for the customer, user, and market. Without some level of knowledge, product managers are flying blind. As Steve Johnson writes:
Domain expertise helps product managers connect with buyers and users to truly understand what they need and not just what they want. Domain knowledge steers marketing communications to effective programs with a clear message for the buyer. Likewise developers and engineers. When a judgment call is necessary–and this is often–a developer who understands the customer profile is more likely to make the correct choice.
Additionally, especially in a company where the employees are very experienced in the domain, lack of domain knowledge can impact a product manager’s ability to successfully lead. Speaking about technology companies, Steve writes:
The fastest way to lose credibility in a technology company is to say that you don’t understand technology. It’s okay to say that you don’t understand a new idea or a new implementation but to be effective in technology marketing and product management requires domain and technology expertise. People who tell you otherwise probably aren’t very effective in working with technical products.
However, domain knowledge alone will not make you a successful product manager. While domain knowledge is important, domain expertise is not essential. You do not need to be a lawyer to develop products for lawyers; you do not need to be a Help Desk analyst to develop products for Help Desks; you do not need to be a educators to develop software for educators.
Some experience may help, but too much experience may sometimes interfere with a product manager’s ability to objectively listen to the voice of the customer. Personal experiences and opinions may inadvertently trump customer feedback. You may find yourself ignoring suggestions from others because you consider your background more relevant. (Tip: If you find yourself saying, “When I was a [insert job title from previous experience]” more than a few times, you have probably fallen into this trap.)
Additionally, lack of experience in an area can be an asset if the product manager is curious, inquisitive, and a good listener (which all product managers should be). Maybe you have never worked as an investment banker, but if you can do a “deep dive” and understand their needs, you may actually develop insights about investment bankers that those who worked as one had never realized.
In my Ten Tips For New Product Managers webinar, one attendee asked if domain knowledge was essential when switching from one company to another company. This likely depends on several factors:
- Does the organization you are looking to join regularly hire those with little or no domain knowledge? If the company develops products for biotech researchers, and 80% of the employees have PhDs in chemistry or biology, the organization may be unlikely to even consider you despite your vast product management experience in other industries.
- Is the domain something that can be learned quickly? Some areas have a lower barrier to entry for domain expertise than others. Obtaining the background knowledge needed to manage a product used by grocery store cashiers to check out customers would probably take less time than getting an understanding of how propulsion engineers calculate thrust for rocket boosters in order to build software to support their work. No offense to grocery store cashiers, of course; it is simply a fact of life and business that some areas require more domain knowledge than others.
- How transferable are your product management skills? A product manager for computer peripherals like mice and drawing tablets might be able to transfer fairly well into a role overseeing development of medical devices used in surgery. Despite the very different domains, both roles rely heavily on ergonomics, product design, and manufacturing. Similarly, a product manager for a consumer web portal could likely transition to managing a corporate intranet with little disruption.
Good product managers should have a good solid understanding of the company’s business, the domain and industry, market dynamics, and user and customer behavior. Domain knowledge is helpful, but domain expertise or experience is not always required. A good product manager will be able to learn a new domain quickly and add insight that those working in the domain for some time might have missed.
Do Product Managers need Domain Knowledge?
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, analyze, 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.
Remember 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 Macintosh 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 we 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 fax modem 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.
Industry Experience: How Important Is It?
In the latest Pragmatic Market BlogFest, Steve Johnson wrote about the importance of domain expertise. Steve's two main points are:
- Developers need to understand the domain and not merely code to specs.
- Product managers need to understand technology
I can't disagree with Steve on these points. However, more interesting to me is:
How important is it that a product manager have prior knowledge and experience in the domain?
I have written on this topic in the past. In fact, it was one of the first entries in this blog. Below are some more thoughts.
Should a company hire a product manager with years of experience in, and knowledge of, the industry? How about a capable and experienced product manager with little or no prior domain knowledge?
The key to understanding the importance of domain knowledge lies in recognizing a product manager's most important skill: learning about the market.
Thoroughly understanding a market necessarily entails being intimately familiar with the user and buyer experience, and therefore requires grasping the domain in which they operate. So yes, domain knowledge is fundamentally important.
But 'learning' means acquiring knowledge, not having it already. A product manager who is knowledgeable about an industry solely as a result of lengthy prior experience is much less capable - and much less valuable - than a product manager who can quickly master a market and domain.
After all, markets change. New competitors enter the landscape, and user and buyer psychographics evolve. Don't you want a product manager who knows how to keep abreast of, or anticipate, these changes rather than relying on the way things used to be?
Thus we see that prior domain experience, while helpful, can be a crutch. An insistence on prior industry knowledge amounts to a concession that product managers are not capable of performing their primary learning function.
If you're an executive looking to hire a product manager, I recommend de-emphasizing domain experience and focusing on the skills that enable market mastery:
- Interviewing prospective and existing customers.
- Identifying and quantifying the problems that customers face.
- Analyzing the competition and their positioning.
- Framing survey questions and interpreting survey results.
- Observing customers in their native environments.
A product manager performs many other important duties, but the point is that domain knowledge is no substitute for these skills for achieving market mastery.
Bikram Gupta at Thoughts on Product Management
Is domain expertise critical for Product Management or Marketing success?
Thanks to the people at Pragmatic Institute for initiating such targeted discussion among the blogging community. This type of discussion is different than common blogging, because the consolidated writing serves as a much better reading than any single post, and even any tutorial.
My take on this topic is as follows; in the scope of complex, high-technology products.
- Domain expertise is necessary. Product management & marketing skills are indispensable.
- Domain expertise need not be required on day 1. It can be acquired in a few weeks or months. However, the product management & marketing skills may take years of time, reading, and introspection to acquire.
- Now a hitch- product management skills are invaluable to business, but cannot be measured effectively. Domain expertise is seen as a weakness any moment; after all you always discuss about the product!
- Domain expertise can prove detrimental, when acquired in pieces. There are decision makers (product managers) and there are decision enablers (technical & business experts). If the decision maker has a tendency to impose decisions without consulting the decision enablers, the situation can be fatal to the business.
- Product managers have to be solution thinkers (detailed view of user scenarios & impact of technology transformation in the relevant market), empathetic to their customers (end users, buyers, CFT) needs; and analytical proponents of low TCO (total cost-of-ownership). In high-technology marketplace, Customers are often unaware of the next trend and so strategy formulation skills invariably require cross-domain thinking.
Now, let's get into details.
As product managers, we interact with different groups: customers, sales, engineering etc. One can very efficiently handle outbound (sales, customers) interaction with a basic domain knowledge. But what if a large part of time goes in interaction with engineering; and particularly on debatable issues like bugs, fixes, patch releases, effort estimation, release schedule delay etc? Here a high level knowledge may not be good enough, you still need to understand a clear architectural view of the product. So one of the primary things is to note the role being performed by the product manager.
Can domain expertise of a product manager help build good products? Can domain expertise help understand the market better? I think a product manager needs a different level of skill, yet domain knowledge. Think of the following factors impacting your business.
Changes in computing paradigm - desktop, to laptop, to handheld, to ubiquitous computing. If your product is being used in a desktop environment, it may change the very environment over time. It will impact the domain; simply because the underlying platform, the operating system etc change. We can see that adaptability to different domains is a more important need than a specific domain skill.
Inorganic growth patterns - It is by far the most difficult issue. Integration success can take years to come by, during a merger or acquisition. Integrated product planning is a different skill than domain knowledge.
Outsourcing trends, buy-or-build decisions - These are crucial decisions that require sound business skills than any technical skill.
I want to emphasize that there's nothing called domain expertise in the high tech business. The fundamentals (CPU architecture, System architecture, OS design, Applications design, IP Networking fundamentals & protocols, Telecom protocols, Secure coding) skills can enable one to acquire any domain skill in weeks or a few months. The strategic thinking skill of a product manager is an invaluable asset, but unfortunately cannot be measured. If the business is doing good, just about anyone can be a high performing product manager.
Let's take a case of a product manager with sound domain expertise. What can go wrong? Tricky things can happen. For example, the low level details are far more difficult than high level picture. Anyone who has seen a few acquisitions can notice that the integration challenge seem to grow manifold as we get to know more in depth about both the products. In fact, it is not uncommon to see 2 similar products, yet with different architecture. Also think of a complex product where bugs, fixes etc take a lot of time of the product manager. In that situation, the PM with good domain expertise might tend to absorb himself more into such discussion, which is often not warranted.
We also need to note that customer centric thinking is different than domain expertise. In addition, even the user experience is different than domain expertise.
This brings us to the point. All skills being important, what extent of domain expertise serve enough for a product manager? I think the following types of skills will be good enough.
- Being able to explain how a small change on the engineering side impacts the overall solution?
- How the Customer is losing a lot more, for not having a small feature - being able to technically explain that to Engineering?
- Being able to explain to Sales on why a certain feature is not technically feasible on the product?
Put the user experience first
On page 5 of John Siracusa's Ars Technica review of Apple Mac OS X 10.5 'Leopard' is a too-brief observation on Apple's kernel design philosophy (my italics):
Apple's focus is on system-level performance, not micro-benchmarks. The kernel team's job is to make the software at the higher levels look good. If improving the performance of some tiny aspect of the kernel tenfold does not provide a measurable performance increase for some user-visible feature or task, it's not an effective use of development time, benchmark bragging rights be damned.
The fact that some of the best and brightest minds at Apple put the user experience first doesn't surprise me - just as the fact that bright minds elsewhere will pillory them for being inefficient and inelegant doesn't surprise me either. There is an endless tension between wanting to make each component of a larger system as great as it can be with the knowledge that good may be all that is needed.
We all know that great is the enemy of good - but institutionalizing that realization is difficult. How do you set the bar for excellence lower and not have individuals feel that they are compromising themselves? When can you say you've done enough to make it better, and that any additional effort is a truly wasted effort?
On two occasions I've heard Guy Kawasaki pronounce in a keynote speech 'don't worry, be crappy' - and on both occasions I've looked around when he's said that and noted wincing from both technical and marketing people. The fact that he follows up this exhortation with 'churn, baby, churn' fails to dull the sting that we should ever settle for a release that isn't the best it could be, by gum.
A popular anonymous product management blogger recently observed that the two ways to earn the respect of development are (in order) to stop being an asshole and become an expert in the current customer base. I would argue that if you are an expert in what the customer wants, sometimes you have to be an asshole to get the point across to people who may feel a proprietary interest in making whatever widget they are responsible for better than it needs to be. Assholery is a useful skill when applied infrequently and selectively.
And what better time to apply this useful skill than advocating for the user experience, especially when some 'you don't appreciate the power of my kung fu and I know better than you' developer decides to trump your requirements and spends a month on work that's the functional equivalent of painting the bottom of a chair.
Putting the user experience first is exactly what Barry Goldwater was thinking about in 1964 when he said, 'I would remind you that compromise in the defense of the user experience is no vice! And let me remind you also that over-engineering in the pursuit of excellence is no virtue!'
And so - if you want to be a good product manager, put the user experience first. A famous former IBM chief executive used to say that you should tattoo 'customer' on your forehead so that the customer would be the first and last thing you'd think about each day. It's fine advice, especially if you've been looking for a way to be more like Gully Foyle.
This is also my way of saying don't bother trying to become a great product manager. By the time you figure out how to be great, you'll have missed the opportunity to move on to a job in which your greatness is both more required and more richly rewarded.
Looking for the latest in product and data science? Get our articles, webinars and podcasts.