We’re running a business, not a technology company (part 2)

I want to continue with the this topic a bit. In the part 1, I made a few points:

• Product management must focus on optimizing for business success not simply technological leadership.
• This must be done by addressing market needs better than other competitors.
• A lot of what we deliver to customers may not be considered truly innovative, but is needed to address the way they need to use the product.
• Technology can change much faster than people’s ability to accept that change.

I want to spend a bit more time exploring this, as it does raise some points of discussion.

Last week when I was in California, I rented a Toyota Prius at the airport. It was my first time driving the Prius, and I will admit that, it took me a couple of minutes to figure out how to actually get the car in gear. First time I drove a car that had a power button in the dash.

Click image to enlarge

Once I figured that out, I drove the car for the duration of my trip and was amazed at how little gas it used. I’m pretty sure it averaged well over 50 mpg.

Now, the hybrid engine in the Prius is truly innovative. Toyota introduced the Prius 10 years ago (initially only in Japan). But the rest of the car is pretty standard: doors, windows, steering wheel, gas tank, mirrors, cup holders, radio etc. It’s not a perfect car, but it’s a pretty good 4 door sedan and it get excellent gas mileage. And given the price of gas these days (over $4 per gallon in California), it will likely have a great future.

Now compare the success of the Prius, with the the complete lack of success of a the Honda Insight. The Insight was actually the first hybrid car introduced in North America (1999). It preceded the Prius by about 6 months. It also had better gas mileage than the Prius, with an EPA rating of 70 mpg. But the Honda Insight sold only about 18,000 units total in the US. The Prius has sold over 1,000,000 units worldwide.

While there is no single reason for the lack of sales of the Insight, the styling of the Insight, the fact that it was only a 2 door hatchback (vs. a 4 door sedan for the Prius) are certainly a big factor. The Insight didn’t look like a “normal” car was something that was said of the vehicle.

The point here is that while one car, the Insight, was first to market and had what appeared to be technical superiority (much better gas mileage), the fact that it didn’t fit well with how people wanted to use the vehicle made it less successful than the Prius, which fit people’s vision of what they wanted in a car. It wasn’t simply the technological innovation of the hybrid engine (or high gas mileage) that was key, but all the other aspects of owning and driving a vehicle that they wanted.

Saeed

Agile/Scrum Software Development and Product Management

I think ours is the only Product Management blog in the entire blogosphere that has not yet had at least one post on Agile/Scrum software development. That is….until now.

I’m not so sure it was a conscious decision on any of our parts. There is so much other good and relevant stuff to write about, like iPhones and iPods for example.

But seriously, I don’t think we have written about Agile because, and I’ll speak for the 3 of us, it’s not that critical to product management. There I said it!

NOTE: where I use “Agile”, it implies a combination of Agile/Scrum

If you are not familiar with Agile or Scrum software development, you can read more in many locations on the web. A good starting point is, as expected, Wikipedia. Read up on both Agile and Scrum methodologies. While quite distinct in many ways, it’s important to understand both Agile and Scrum and how they are inter-related in practice. In fact, the first line of the Wikipedia entry on Scrum reads:

Scrum is an iterative incremental process of software development commonly used with Agile software development.

While not an absolute definition, and clearly some may argue, I view Agile as more of a culture or approach to software development, whereas Scrum is more truly a methodology, with specific roles, practices etc. that can be implemented. In many cases, when people say Agile, they imply Scrum as well.

As mentioned earlier, Scrum defines a set of roles. One of the key roles in Scrum is the Product Owner. That role is defined as:

The Product Owner represents the voice of the customer. They ensure that the Scrum Team works with the right things from a business perspective. The Product Owner writes User Stories, prioritizes them, then places them in the Product Backlog.

Now, this would most likely map to the Product Manager in most software companies. While true at a high level, another key element of Scrum is the daily scrum meeting where every member of the team, including the Product Owner attends.

Now, imagine if you as a Product Manager had to attend a development meeting every day. When would you get out of the office? When would you meet with customers, partners, prospects etc.?

One big mistake a lot of people make is assuming that the Product Owner has to be the Product Manager. While conceptually that may be true, the Product Manager cannot, and in my opinion, should not attend these daily scrum meetings. I’ve worked in PM role in two previous companies that used Agile/Scrum development methodologies, and I think I attended one Scrum meeting. We still had regular communication with the development teams and regular product reviews etc. but we weren’t embedded into the development process the way some people might think we should be.

Other roles such as Product Designer need to be defined to take that day to day decision making role and act as the Product Owner, or at minimum, be the proxy for the Product Owner (if that is the PM) so that the PM doesn’t get bogged down by daily scrum meetings.

Keep in mind, Agile/Scrum is a DEVELOPMENT methodology. It is a great model for developers and engineers and other R&D team members to work and communicate more efficiently. There are very clear benefits to this model. It provides greater visibility into current work status, work remaining, can identify development hurdles earlier and can communicate them outward more easily.

But, in the end, it is still a development methodology. It should have minimal impact on Product Management’s job as a cross-functional leader marshalling the product from development through marketing, sales etc.

Here’s an analogy. Sales teams invariably follow some kind of sales methodology. It could be strategic selling, solution selling, or conceptual selling. It could be some other model, or even none at all. If the sales team decides to adopt or change their sales methodology, do other related teams like Marketing or Product Management have to change how they work?

The answer is NO. So, then why should those changes happen to Product Management if the development team adopts Agile/Scrum? Our job remains the same. Understand the market, customers, competitors, merge that in with business objectives etc. define what needs to be built and move that through all the stages of development/launch/post launch to enable product success.

If in a few years, some better development methodology comes along, and is adopted by the engineering teams, will that change what Product Management does?

NO.

Development methodologies should be a grey box for Product Management. We should have an understanding of them, but we don’t need to become an “embedded” part of their implementation. It’s all about loose coupling and clear lines of communication. We have our objectives, and Development has theirs, and when we need to interface, we do so in an efficient and mutually convenient manner.

Let me put it this way, and pardon the analogy if it is a bit inappropriate. Product Management and Development don’t need to be married to each other to be efficient. The relationship needs to be more like a “friends with benefits” arrangement. i.e. the two hook up on a regular or as needed basis.

Saeed

Little features and a lesson for Product Management

Today, while working on a different blog posting (to be posted soon), my browser, Firefox, froze. I use FireFox almost exclusively these days, mostly because it works well, and I really like the tabbed browser-window interface. I do a lot of multi-tasking via the web browser, and the tabbed interface makes it very easy to jump back and forth between contexts as I multi-task. Try that with the other dominant browser.

Yes, I know there is some toolbar or something for IE 6 that will do this and that IE 7 has it built-in, but FireFox has had tabs for a lonnnnng time, so I prefer it. And while the tabbing feature is great, that’s not the only little feature I want to discuss.

Firefox has another new feature, not sure when they added it, that will restore the full prior state of Firefox on the next launch, if it had shutdown unexpectedly.

(click to see the whole dialog)

How awesome is that? Well, let me tell you…earlier this evening I was working on a blog posting, typing right inside the WordPress editor, when, as I often do, I switched to another tab to look for some info. I clicked a link on that other page, and then the browser froze. And I mean froze. After waiting a minute and still not having a responsive browser, I had to kill the process in the Task Manager.

Somewhat annoyed at not having saved my brilliant blog posting, I reminded myself that I needed to regularly save my work.

But, when I relaunched Firefox and clicked the Restore Session button, to my amazement, there was the entire post in the WordPress editor, exactly as I had left it. It was not saved in WordPress, but Firefox had brought it back. Awesome. Saved me a bunch of time and yet another reason to continue using Firefox.

So, what’s the lesson for Product Managers?

Keep the user’s experience front and center!

I’m sure the tabbed interface and the Restore Session features were fairly easy to implement relative to other tasks such as accurate rendering of markup, script execution, addressing security issues, dealing with plug-ins etc. And while those are important things to work on, they are expected “buying features” for users. But the unexpected, particularly the ruthless efficiency of something like Restore Session, is what will clinch the deal with many users.

Yet, these kinds of features are often traded off when negotiating with development.

Do you want the security problems fixed or do you want the restore? We can’t do both.

Granted, an open source product like Firefox doesn’t necessarily have to make those trade offs, but for business software, that is not the case. Get your engineers to understand the value of having the product outperform expectations, and task them to help identify little gems of functionality that can be implemented to make users rave about your products.

Saeed — Raving Firefox fan, starting today.

Goodbye File menu, hello throbbing Orb

We recently upgraded from Microsoft Office 2003 to Microsoft Office 2007 at work. Clearly Microsoft has put a lot of effort into upgrading the UI in the various components of Office 2007. For those who have not seen Office 2007, this is a snippet from MS Word 2007.

So, gone are the various formatting, editing etc. toolbars that have been a mainstay in the UI for several releases. They have been replaced by “The Ribbon“, which in reality is just one big honkin’ set of toolbars accessed using the Home, Insert, Page Layout etc. menu titles.

Gone too is what has been probably the single most consistent interface element of GUIs, traceable back to the original Macintosh:

Original Macintosh interface

and the Apple Lisa:

Apple Lisa interface

So what was that interface element? It was the File/Edit menu structure. You can see it’s origins in the Lisa interface. Pretty much every general purpose GUI application since the advent of the Macintosh, and certainly from the time that Windows 1.0 came out, had that. That was over 20 years of UI consistency.

Windows 1.0 screenshot

In Office 2007, Microsoft decided to remove it. I have no issue with changing something like the File/Edit menu structure, IF they found a better paradigm or mechanism to replace it with. But the reality is that they’ve simply replaced the File Menu with the “Throbbing Orb”, or should I say the “Microsoft Office Button“.

I refer to it as throbbing, or perhaps pulsating may be a more appropriate adjective, because when I first launched Word 2007, that button was pulsating. I actually ignored it for several minutes, looking for the “File” menu. I wanted to open a document. How difficult should that be? I clicked on all the headers of the Ribbon — Home, Insert, Page Layout etc. — but couldn’t find the thing I needed most — File->Open.

Now I’ve been using software for a very long time. The first Word Processor I ever used was on a Wang 2200 computer. I’ve used WordStar (on CP/M and DOS), Multimate (I’m embarrassed to admit), Wordperfect on DOS (and unfortunately also on Windows — what a horrible product that was), as well as many versions of Word. So, when I sat there dumbfounded unable to find the equivalent of File->Open, I asked one of my coworkers for help. He came over and said, “Click that thing”, pointing at the Office button in the top left of the screen. This is what happens in Word when you click that button:

I immediately thought “What the *&@#?” Why would they do that?

It actually makes no sense to me to design something like this. Why not simply create a File title as part of the Ribbon and put the icons for all these things there? I have to guess there was some internal push by the marketing team to create the Office button for some sort of branding purposes, or perhaps there is some particular IP issue being addressed.

I don’t know, but I really wonder who made such a design decision and why? It’s completely inconsistent with the rest of the interface, confusing for new users, and yet so deliberate in it’s implementation that I’m sure there must have been heavy debates in the Office UI team when deciding to implement it.

There is evidence in the Word (and other Office tools) GUI that the toolbar/no toolbar debate happened within the UI team. After using the Office button, I noticed the little toolbar right at the top of Window with several of the “old” icons such as Save, Undo, Redo etc. Seems like a clear “hack” to appease the more traditionalist camp that insisted on toolbars, or perhaps a clear realization that users needed an easy way to perform basic tasks. I think the folks at Microsoft should remember one of the key axioms of Product Management:

Change is a process, not an event.

Anyone have any insights into the Office 2007 design process at Microsoft ? If so, please share.

Saeed

P.S. Apparently there is enough of a market opportunity for the “old” Office interface, that a 3rd party company has created a product to give that to users.

What’s the deal with Personas?

The CrankyPM recently posted a good little rant on personas. It’s drawn some interesting comments from both sides of the persona camp (PCamp? ). BTW, I’m totally jealous as she snagged a great title — Persona non grata — for her post.

I’ve been incubating the following persona related post for a while, and thought now a good time as ever to finish and post it.

There’s been a fair bit of writing related to personas as a tool for better understanding users and their requirements. Adele Revella has The Buyer Persona blog, and Bonnie Rind has her Product Personas blog. And of course, the accredited father of the persona concept for product design is Alan Cooper. Cooper’s firm has a number of persona related articles on their site. Perfecting your Personas by Kim Goodwin provides a good overview for those who are interested in understanding the basics.

She starts:

A persona is a user archetype you can use to help guide decisions about product features, navigation, interactions, and even visual design. By designing for the archetype—whose goals and behavior patterns are well understood—you can satisfy the broader group of people represented by that archetype.

This makes complete sense and whether one is explicitly familiar with personas or not, it’s what most Product Managers tend to do, some better than others.

Later Kim writes:

There is seldom a one-to-one correlation between personas and job descriptions. In some cases there will be multiple personas with the same job description; in others, a single persona can represent people with a wide range of jobs.

Thus for a single job — say an administrator — there could be personas representing new administrators who need lots of prompting, and experienced administrators who prefer command lines and know exactly what they need to do. Again, not much to debate here.

Later on Kim writes:

You can also add life to the persona by using environmental details to reinforce important characteristics. For example, if someone tends to be incredibly busy at work, don’t just say he’s incredibly busy; instead, say there’s a sandwich on his desk that he’s been trying to find time to eat for three hours.

Now this is where things get interesting, and this is the issue that Cranky fixates on in her post. And to be honest, it’s really hard to disagree with Cranky. Imagine the look on a bunch of developers faces as you start laying out the persona, describe their environment, their goals, their workflow, and the fact that a sandwich has been sitting on their desk for 3 hours.

Might as well stamp the words — Marketing dweeb — across your forehead and then tell them you’re going to get a soy latte at the brasserie. First of all, I’ve yet to meet a development team that cares about these kinds of details. They don’t want to know that Albert, the community college grad who provides DB2 database administration support likes to watch Ren and Stimpy videos while he waits for nightly database backups to run.

They also don’t want to know that Sachiko, the business analyst, has an MBA from a second-tier Midwestern university, is planning the details of her upcoming marriage, and thus doesn’t have time to conduct proper and formal analyses for the new CRM system that is needed.

These are all completely unnecessary details in the B2B context. For consumer software or products, these details may be very important.

A while back, I worked on a new Administration Console for an enterprise middleware product. The product itself was in widespread use, but there was a real push to make it “enterprise ready”, which meant that things like security and role based permissions were important.

The developers spoke about the target user — “the administrator” — in very vague terms. There was also confusion around the fact that some users of the product could act as both administrators and operators depending on the circumstances.

We needed clarity on this and a way to distinguish who did what, when and why with the product, and who the target would be for the new Administration Console. So, we decided to talk to customers to get some raw data. After a number of customer visits and calls, we determined the following:

• There were four major “administrator” roles within our customer base
  • Network Administrators
  • Infrastructure Administrators
  • Application Administrators
  • Operations Administrator

• These four roles were generally consistent across customers, though responsibilities crossed over between roles in different customers
• Administration teams were structured very differently across organizations
  • Some customers had administration teams with global responsibilities
  • Others had teams with specific geographic focus (e.g. Americas, APAC, EMEA)
  • Others had teams responsible for specific applications

From these and other findings, we came up with specific definitions of the roles. Here’s the definition of the Infrastructure Administrator which we decided was the target user for our Administration Console.

An infrastructure administrator is concerned with a specific set of hardware and software running on that hardware. This set of hardware/software is usually domain specific. I.e. it is assocated with a particular enterprise application, such as Siebel, PeopleSoft, an external web application or some other system.

The infrastructure administrator’s job is to ensure that the particular hardware and services, particularly the services, they are responsible for are operating efficiently and that any general maintenance, such as application data backups, server shutdowns etc. are managed in an efficient way.

In the context of our product, an infrastructure administrator is responsible for starting/stopping repositories, configuring servers, performing repository backups etc. In most cases, but particularly with small to medium installations, the infrastructure administrator also handles inter-repository migration of metadata. i.e. they do the deployment from development to test, and test to production.The infrastructure administrator is the primary user of the Administration Console, though from our discussions it is clear that they do not need to use it everyday.

The developers really understood this description. We had similar ones for the other three types of administrators, and throughout the development of the Administration Console, we regularly referred to these roles, their descriptions and other findings from our research when questions arose as to what should or shouldn’t be part of the console. Notice there is no mention of personalities, habits, level of disorganization on someone’s desk or anything that detracts from the role and it’s focus.

So, what’s deal with Personas? Technically nothing, unless you insist on using them with engineers or other people who just couldn’t give a damn about all that extraneous “marketing fluff”. A big part of Product Management is communication, and speaking in the language of others. If engineers don’t “grok” personas, don’t force them down their throats.

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

Some Product Management reading

Over the last few years I’ve written several articles that have been published by the folks at ProductMarketing.com.

I discussed one such article, Product Management Axioms, in another blog post.

The remaining articles cover different topics related to product management, from beta programs to prioritizing customer feedback to a discussion on how many product managers are really enough in an organization.

I’d love to hear your feedback on any of them.

Building a Better Beta
Detailed description of the key elements of beta programs and ways to make them effective across teams in a software company

A Model for Metrics Driven Feature Prioritization
Describes a method for including large numbers of customers in a closed-loop dialog on product direction

You Can Never Have Too Many Product Managers
Defining the value of Product Management in a software company is difficult but critical. Companies must ensure the Product Management role does not bottleneck other parts of the company.

A House with no Front Door
Creating great software products requires diligence and forethought. Efforts that put development efficiencies ahead of user needs simply increase complexity and cost for the vendor over time.

Saeed

How to be a GREAT Product Manager (part 6)

Own the product from conception to completion and beyond

In my early product management jobs, I focused a lot on the process of product management. A CEO of a startup I worked for told me that my approach to product management was “very academic” in nature. He viewed himself as a “get it done by any means necessary” entrepreneur, while I viewed myself as a”get it done right” product manager.

The startup was a very sales/deal driven company, as many startups tend to be. Putting product management in place in such an organization is not easy. But having a process focus is very important for a product manager. Every other function, from sales to marketing to development to finance to HR implement processes.

But because product managers work across these functional units, people don’t realize or understand that even in small companies there must be a repeatable and scalable process to conceive, research, define, develop, test, launch, promote, sell, support and sustain winning products!

And while product managers have a direct responsibility in some of these 10 areas and indirect responsibility in others, PMs absolutely have a core responsibility to oversee and align the activities of other teams across this entire process. I’m not talking about managing those people directly or telling them what they should do. I’m assuming people know how to do their respective jobs. What I am saying is that if you want to be a great Product Manager, take ownership (not necessarily full control) over the process and lead the teams in alignment through it.

Get alignment from the very beginning
From the start, as you (and/or your PM team) are doing your research, clearly define the context and vocabulary necessary to effectively convey the research results to the intended audiences. This vocabulary, whether related to personae/roles, business functions, consumer needs, product architecture or functionality or something else, will become key to bringing everyone into the same frame of reference. This is important because it helps to minimize misinterpretations and miscommunication during the product development and launch process. If people aren’t aligned early on in the process, you are likely to see confusion or conflict later on as requirements are implemented incorrectly or with unacceptable constraints.

As an example, before becoming a product manager, I worked at a company that was developing a fairly sophisticated reporting and visualization framework for business and financial data. One of the engineers was tasked with the requirement to create a flexible means to allow users to format and display numeric and character text (including time, date and multiple international currency values) dynamically for display in pop-up boxes when on-screen entities were moused-over. Are you with me?

He went off, did some research and without a lot of internal discussion, implemented functionality to address the requirement. I was responsible for documenting the functionality. When I saw what he had developed, I was stunned. He had created a flexible — but incredibly complicated — formatting subsystem. Yes, it could do everything and more relative to the requirement, but I’m certain only the engineer and a few other technical people could actually use it. The documentation for this functionality took 60 pages (out of a 600 page reference manual). When people in the company saw how complex it was, the functionality was removed from the product.

What went wrong? A number of things including lack of internal communication, lack of oversight, and lack of involvement from the product manager. Where was he during all this? I don’t recall exactly, but I think he was out, working with sales and trying to close some deals. Helping sales is good. Don’t get me wrong. But not when it comes at the expense of the product being built.

Get your hands good and dirty
During the development cycle, work to keep other teams such as marketing, product marketing, sales, sales consulting, support, channels, alliances and professional services informed and educated on the development status and product functionality. For smaller consumer products or websites, this may not be a difficult task, but for larger enterprise or data center software, this can be a daunting task.

For a major release of a large product, a development cycle will last 12 months or more. There are many decisions that are made during this cycle that need to be conveyed to downstream teams to ensure they can plan ahead for the impact of the new release.

Don’t stop until adoption is clear
Once the product is released, you need to stay focused on the product. You can’t let up and simply go start gathering requirements for the next release. Stay engaged with early customers, partners and the customer facing teams such as sales and professional services. If early customers are upgrading to the new release from a previous version, track those upgrades and follow up with the customers to see how the upgrade went and what comments they have about the new release.

Join members of the sales team on customer and prospect calls and listen to how they are describing and selling the new release, and what the reaction is from the audiences.

• Are the salespeople on message?
• Are the sales consultants adequately trained?
• Do the demos hit on target?
• Is the market need that you researched and identified oh so long ago, still as relevant and critical as it was back then?

These questions (as well as others) should be the focus of product managers (and product marketers) after product launch.

All too often, I’ve seen people work on a release, have it launch, and then essentially forget about it as they start focusing on the next release. Big mistake. If sales is struggling to sell the product, as the Product Manager, you need to take the challenge on and work to identify and remove the barriers.

Don’t look at it as someone else’s job because it isn’t. Would a CEO let a struggling VP of Sales flounder for a quarter or two? Absolutely not. As a PM, take your cues from the CEO and within reason, do what a CEO would do. Don’t wait for others to tell you what needs to be done. Take charge of your product, make sure it is built right and then ensure it trounces the competition.

Saeed

Part 5 - Be an integrator, translator and communicator

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