Market segmentation, or lack of it at Facebook

I came across a new blog, a la 360, which just started a couple of months ago. The author recently posted a couple of articles related to Facebook. One blog asks “Which problem is Facebook solving?“. Another discusses market segmentation WRT Facebook.

I like both articles as they ask straight forward and fundamental questions that we all should be asking ourselves (if we aren’t already) when looking to create a new product or service. Now one could argue that without clearly identifying a target set of problems or clearly segmenting the market, Facebook is more successful than 99% of internet applications, so why bother?

The issue is not about Facebook, but simply about reminding ourselves to do our homework to help improve the chances of success of our products. For every Facebook that succeeds, there are hundreds that fail.

Saeed

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, 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

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 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.

Saeed

iPhone vs. iPod Touch

A few months ago, to much fanfare and (possibly well deserved) hype, Apple released the iPhone.

People oohed and ahhed.

And a small number (1, 2, 3) OK…lots of people bought them.

Then Apple did something really interesting. Within a few months of the iPhone release, they dropped the price of the iPhone, by 33% (from $599 -> $399), and almost simultaneously released the iPod Touch.

The price drop really annoyed existing iPhone owners, and the new iPod Touch once again made people ooh and ahh.

The iPod Touch, is essentially an iPhone, without the phone, camera and a number of other features. The Touch is only 15 grams (1/2 ounce) lighter and 3 mm thinner than an iPhone. They have the same sized screen and function almost identically.

Why is this at all interesting?

First, people paid a premium price for the iPhone even though it was clearly quite expensive, AND it had a poor cell phone carrier plan. With the price drop, a customer revolt ensued, but Apple seems to have handled it well with a $100 Apple credit for any of the original iPhone purchasers.

Second, that the difference in price between an 8GB iPhone and an 8GB iPod Touch is only $100. $399 for the phone. $299 for the Touch. Makes you wonder. Is the phone portion such a commodity or are Apple’s margins really good on the Touch?

Third, and most important IMHO, Apple now has two different products that fundamentally share the same technology. And while this can be viewed as line extension (iPod, iPod nano, iPod shuffle etc.), in many ways this is really a big step forward for the iPod. It now becomes a mobile, wireless device, and not simply a portable music/video player. And the rumours are that the multi-touch pointing technology is next headed for the laptop.

So from a Product Management perspective, what can be learned?

1. Always keep innovating.The iPhone may be as great as all the hype, maybe not, but it truly is different in many ways when compared to other high end mobile phones. But note that in all the hype about the iPhone, was there any mention that this was Apple’s second kick at the telecom can? Anyone remember the ROKR? OK, it was a Motorola phone, but Apple was certainly involved in it’s development. Can anyone say boooring?
2. Communicate those innovations in intelligent and articulate ways to your market/customers in advance of the launch. By giving people 3 months notice of the launch of the iPhone, Apple ensured that word would spread and demand would grow. Many software companies wait until the ship date to communicate to the market and customers. This is a guaranteed way to delay revenue.
3. Leverage your technology investments and deliver multiple solutions to different market segments.It’s always great to create a completely new product with new technology and new functionality. But, what’s even better is to get multiple returns on a single technology investment by being able to repackage, reposition, and resell different slices of the same technology to address problems for different users and use cases. If you are in the BUSINESS of technology, and not simply the technology business, this is something you really need to focus on.

Saeed

Product Manager vs. Product Management (part 1)

I recently finished a series of articles on being a Great Product Manager. I want to switch gears a bit and spend some time talking about the function of Product Management in software companies. As we know, product managers and product management are not isolated to software companies, but the role of product management in software companies is different from the role of product (or brand) management in other domains, such as the financial sector or Consumer Packaged Goods (CPG) firms.

For example:

• How many new “features” does a “release” of a new shampoo have?
• How much time does the brand manager spend with the chemists working on that new shampoo formulation during the “release cycle”?
• How much discussion is needed on how the consumer will actually use the shampoo?
• Are whitepapers and product demos that important for shampoo?

This is not to belittle brand management in CPG, but simply to give a few examples of how issues in CPG product management may be different than those in software product management.

One nice thing about CPG Product Management is that it is fairly well defined. For CPG, Product Management is, without question, a marketing function. CPG Product Managers need to be business focussed and have a keen understanding of media and web marketing, demographics, finance and analytics. They need to be able to grasp the differences in various global markets, and be able to market global brands locally, as well as create local brands and products as needed in specific markets.

The 4 P’s (product, place, price, promotion) are fundamental to them. And, with the web growing ever omnipresent in our lives, and the emergence of new technologies allowing customers and companies to communicate more intimately with each other, terms like interaction, interruption and mass-customization are heard quite frequently.

Now compare this to Product Management in most software companies. Honestly, how many software product managers could list the 4 P’s, let alone talk confidently about the dynamics of international markets and how they impact their software products?

Full disclosure: I always list “Position” as one of the P’s (product, position, price, promotion), even though it is not. I really think it should be! Also, while I have been the PM of products that have had world-wide distribution including full localization into languages such as Japanese, French and Korean, I really had little insight into the dynamics of those markets. For the most part, beyond the specific localization, those markets received exactly the same functionality as every other geography, and it was up to local partners and distributors to market the product in the ways they saw fit.

The reality is that software product management is still an immature function. Most software companies define and staff product management in a reactionary manner. Typically a product manager is hired once the founder or CTO or chief architect or other corporate thought leader reaches the limit of their abilities in defining the product, or things become so messed up in the company with a product or technology strategy, a member of the Board of Directors tells the CEO to get a Product Manager.

It really shocks me that VC’s don’t make it a funding requirement, at minimum in the series B and above rounds, that a startup must have an experienced Product Management executive on board. Think about it? These folks are in the business of investing in technology companies. Their objective is to maximize the likelihood of success for their investments. As such, why would they not view Product Management as a critical role, on the same level as Sales, Marketing and Engineering?

I recently asked a couple of VCs this question. The answers really surprised me.

One said, quite candidly, that he really didn’t understand the role of product management very well, but that he had recently learned a lot more about it via interaction with one of his portfolio companies. OK, thanks for the honest answer, but not very reassuring from my perspective.

Another said his expectation was that the founders would fill in for the PM function until such a time as it made sense to bring dedicated product management into the company. I asked the latter VC why he didn’t view product management as a critical role to fill right at the start? He said that when he makes investments, it’s fundamentally the management team, and particularly the founders that he’s investing in. Pulling in a PM who isn’t a close associate of the founders in the early stages can be disruptive to the management team.

OK, certainly a better answer, but it says a lot about software product management when those who make their living investing in software companies cannot see enough benefit in the function to have it outweigh any concerns they have about personalities and fit in the management team.

In the next post, I’ll dig deeper into the software product management function and discuss some ways to improve both the status and discipline of the role.

Saeed

Related Articles
Product Manager vs. Product Management (part 2)
Product Manager vs. Product Management (part 3)
Product Manager vs. Product Management (part 4)
Product Manager vs. Product Management (part 5)
Product Manager vs. Product Management (part 6)

How does a PM gain insight?

In a comment on one of Alan’s posts, a reader, Michael, asks, how product managers can gain insight into market and customer needs.

He then lists a number of ways of doing this. I summarize them a bit for brevity.

1. You could talk directly to customers.
2. You could talk to a sample of customers (via focus groups or user group meetings or similar).
3. You could rely on voluntary feedback (like those ghastly product registration cards so many things seem to come with).
4. You could trawl the web looking for blog entries about your product.
5. You could solicit feedback from your own sales team.
6. You could ask your support staff what problems customers keep coming up against
7. You could talk to industry pundits, who will guess what customers think of your product.
8. You could ignore the customers and assume that they want what you want.

In another comment, Michael continues:

To pick an example, say you were involved with something like a consumer-grade digital camera (lots on units, lots of customers, scope for plenty of product differentiation). Given the volumes, you can’t talk to all the customers. Given the sales channel, you might not even know who most of the customers are. What can you do for something like this?

For the example above: a consumer-grade digital camera, let’s take a step back and talk about market segmentation. When the camera was being conceived there was an audience in mind for the camera. Today the digital camera market has matured enough that there are clear market segments at which cameras are aimed. For example, a simple segmentation could be:

• toy cameras, intended for use by children
• compact point and shoot, for the casual photographer,
• prosumer cameras for the more serious photographers
• digital single lens reflex (DSLR) for very serious and professional photographers

Now each of these segments defines different types of people, with different budgets, photography experience and photographic intent. When looking to design a camera, you would need to get a clear definition of the segment you’re aiming for, understand the dynamics of that segment (competitors, trends, subsegments etc.) and then start developing the product.

As for gaining insight, once you know the segment and the characteristics of that segment, you know the type of people to talk to: which end users, retailers, distributors etc. Those 8 questions listed earlier (OK, #8 — ignore the customers is probably not a good tactic) are all ways to gain insight, both before, during and after the product is released. Of course, there are many others.

Shifting to software, one of the most well known and oft-cited examples of gaining customer insight was Intuit’s “follow-me -home” program. This program had Intuit staff visit the homes of Quicken users and observe them using the product in their home settings. This program yielded valuable insights into what people did with the product in their home environment and led to several product enhancements such as an electronic paper tape feature in the Quicken calculator.

BTW, if you want to read a great book on Intuit’s history and struggles, I recommend Inside Intuit. It covers, what we can now call, the early years, and if I recall [I read the book a long time ago] has a section covering the follow-me-home program.

The follow-me-home program was an example of ethnographic research. Essentially it is fieldwork; getting out into the real world and truly understanding the environment and frames of reference of those who will be using, recommending, selling or distributing your product.

One thing to keep in mind is that when doing fieldwork, it is best to include several people from your organization from teams other than product management. The reason? Because, regardless of how much primary research you do, you will always interpret what you observe and learn through your own personal frame of reference. The patterns you see when conducting the research will likely be somewhat different than the patterns others see. And the conclusions you draw may be different than the conclusions others draw.

Include members of engineering, market and even sales if possible and feasible in your research. Also take other product managers along. At minimum, you’ll have a control element in your sample of interpreters of the data you collect.

I honestly believe it takes a very skilled person to do ethnographic research well. You have to be able to put your personal biases and views aside, and not only listen to what others are saying and doing, but also ask the right questions (open ended, neutral questions) to solicit the input that is needed.

I’ll probably write about this more in future post, but one thing I see lacking in virtually all product management training is any coverage of the skills needed to do good field research. It is such a critical part of the product manager’s job, but I’ve yet to see that topic covered with any level of substance in any training courses aimed at product managers.

The question: “How does a PM gain insight?” is a good one. The answer, quite simply, is that there is no simple answer. Like most things, it takes ongoing effort, communication, thought and dedication.

Saeed