Product Management is everything!

In 1991, Regis McKenna wrote a seminal article entitled Marketing is Everything that was published in the Harvard Business Review. The article paints a picture of technology as an agent of change in the market place. He wrote near the beginning of the article:

Technology is transforming choice, and choice is transforming the marketplace. As a result, we are witnessing the emergence of a new marketing paradigm– not a “do more” marketing that simply turns up the volume on the sales spiels of the past, but a knowledge- and experience-based marketing that represents the once-and-for-all death of the salesman.

These are bold words, particularly for the early 1990s. I’d say that those words are more true today than they were back then. While it is true that the need for salespeople still exists in many cases, it is also very true that there are MANY transactions that take place today without any sales intermediary that could not have been done without one 20 or so years ago.

Many years ago, someone once asked me, if I’d every bought something I’d never seen. I said, not that I could think of, except for maybe something mundane like ordering a pizza.

He then asked if I’d ever bought a computer online. The answer was yes. He then asked if I’d bought a specific model or a custom configuration. I said a custom configuration from a website. He then said, that was an example of buying something I’d never seen. True. I saw pictures of it on the website, configured the options I wanted and paid by credit card. And I did it without talking to a single person.

That transaction is an example of what McKenna was writing about in the early 1990s, except then, the Web was certainly not mainstream. The browser itself was a few years from being invented. But McKenna was right on the mark.

McKenna continues later in the article:

…successful companies are becoming market driven, adapting their products to fit their customers’ strategies. These companies will practice “let’s figure out together whether and how color matters to your larger goal” marketing. It is marketing that is oriented towards creating rather than controlling a market; it is based on developmental education, incremental improvement, and ongoing process rather than simple market share tactics, raw sales, and one time events. Most important, it draws on the base knowledge and experience that exists in the organization.

Hmmm…does that sound like marketing or more like some other discipline we are all familiar with? Well there’s more, as McKenna describes what he calls “knowledge-based and experience-based marketing.”

Knowledge-based marketing requires a company to master a scale of knowledge; of the technology in which it competes; of its competition; of its customers; of new sources of technology that can alter its competitive environment; and of its own organization, capabilities, plans and way of doing business.

I’m hoping this is sounding familiar. He continues:

Armed with this mastery, companies can put knowledge-based marketing to work in three essentials ways:

integrating the customer into the design process to guarantee a product that is tailored on only to the customers’ needs and desires but also to the customers’ strategies

generating niche thinking to use the company’s knowledge of channels and markets to identify segments of the market the company can own

and developing the infrastructure of suppliers, vendors, partners, and users whose relationships will help sustain and support the company’s reputation and technological edge.

So in short, work closely with customers, identify market segments (not entire markets) that can be dominated, and create an ecosystem of customers/partners etc. that can help the company push forward and continue to lead. All sounds pretty standard nowadays, but back then, this was new stuff. And it was less than 20 years ago.

McKenna continues:

The other half of this new marketing paradigm is experience-based marketing which emphasizes interactivity, connectivity and creativity. With this approach, companies spend time with their customers, constantly monitor their competitors, and develop a feedback-analysis system that turns this information about the market and the competition into important new product intelligence. At the same time, these companies must both evaluate their own technology to assess its currency and cooperate with other companies to create mutually advantageous systems and solutions. These close encounters–with customers, competitors, and internal and external technologies–give companies the first hand experience they need to invest in market development and to take intelligent, calculated risks.

Now before you think I’m just going to replay the entire article to you, let me say that there’s a point to this, but it needs the proper context. McKenna was stating, almost 20 years ago, that change was taking place in the Marketing profession, and that the old monolithic ways of marketing to customers were no longer valid. Embracing customers, instead of evangelizing to them was becoming critical.

But, McKenna didn’t have a good catch-phrase for this new discipline. He talked about knowledge-based and experience-based marketing. He also wrote:

In a time of exploding choice and unpredictable change, marketing–the new marketing–is the answer.

…The marketer must be an integrator, both internally–synthesizing technological capability with market needs–and externally–bringing the customer into the company as a participant in the development and adaptation of goods and services.

…Playing the integrator requires the marketer to command credibility. In
a marketplace characterized by rapid change and potentially paralyzing choice, credibility becomes the company’s sustaining value.

I’ll stop there. It should be clear where McKenna was heading with this. This new type of Marketing–that understands technology, the market, customer needs, and the competition; that works with partners, suppliers, vendors as well as customers; that integrates the customers into the development process to produce superior products and services–is what we today call Product Management.

Whether he intended it to be so or not, what Regis McKenna, one of the luminaries of high-tech marketing was saying, was that the critical function that companies must adopt to thrive in the market is Product Management.

And finally, not simply to paraphrase him, but to update what he was saying with our context, almost 20 years later:

Product Management is everything!

Now, before my marketing friends get upset and claim I’m deriding their work, I’m not. Marketing has an important role in the product lifecycle, but the role of Product Management is distinct and key. Each can deliver real benefit to a company, but only when the two work together efficiently and collaboratively, can the true benefit of what McKenna writes about be seen.


And the ComputerWeekly IT Blog winner is….

Computer Weekly IT blog awards logo

A few weeks back, we asked our loyal readers to vote for us in the ComputerWeekly IT Blog awards. We were nominated in the IT Project Management category.

Now, aside from the fact that this is a PRODUCT Management blog and not a PROJECT Management blog, we were happy to be nominated and noted that a couple of other Product Management blogs were also in the running, including Cranky PM and All About Product Management.

So, we asked you for your votes, and some of you responded. Well the results are now in and I’m here to say, that after all the effort . . . . . drumroll please . . . . . we did not win.

Heck, we didn’t even come in second. That second place honour went to the Cranky PM. First place went to some crazy, off-topic UK based blog called A Girls Guide to Managing Projects. 🙂

So, I can see how the winner may have won the category…a blog actually on PROJECT Management, with good content and with the writer residing in the UK. Yes, the contest was specifically for the best UK IT blogs.

But, how did Cranky get second place? While well written and humourous, it’s a PRODUCT management blog, and it’s certainly not based in the UK! I think I know where Karl Rove’s electioneering machine has been spending it’s time recently, warming up for this fall’s US election.

So, congrats to the winners. But this experience has sparked an idea. It’s time to reward ourselves, and not rely on some derivative discipline to honour (yes spelled with a U) ourselves and the best we have to offer. If we don’t pat ourselves on the back, who will?

Stay tuned.

Saeed, Ethan, Alan

Daddy, what do you do at work?

My kids always ask what I do at work.

When I work at home they see me shift between talking on the phone, sending emails, working on the computer and taking breaks for snacks or other necessities. That’s actually pretty much what I do at work, except at work, I’m spending more time in meetings. And of course, there is the traveling I do to tradeshows, customers, partners, conferences etc.

But as a Product Manager, what do I actually do?

My son recently asked if I made things at work? No, not really.

He then asked me if I sold things? Not really.

“Do you boss people around?” he then asked. No, not really, though that would be nice sometimes!

“Do you fire people?” Again, no, but again, would be nice sometimes.

So I started thinking, what do I actually do?

Of course I could have said something like;

“My job is to understand what customers will want to buy from us and then work with other groups in the company to ensure that we build and deliver those products to them.”

Or something like that. But that was not really an appropriate answer for him.

So, after thinking about it, I said to him, “I make decisions. I make decisions for our company that help us make better products that we can sell to people.”

“Uh, OK.” he said, and walked away.

I wasn’t sure if he was satisfied or simply found my answer rather boring. But for me, the “I make decisions” line was a good one because at the very core of what Product Managers do is make decisions, informed decisions based on data, insight and knowledge that have significant business impact. That’s why I like the job (most days!).


(click to enlarge)

On Taking Advice

Michael Phelps

A short thought on taking advice:

Business school case studies almost always go into details about some successful company or individual. Rarely, if ever, do they try to dissect a failure. I have heard a story that when a Harvard MBA student asked why this was the case, the answer was that there are a million ways to fail but very few paths to success. The objective of case studies was to present a cross-section of successful businesses and have students try to find the common threads. Seems sensible enough.

On the other hand, we have this article from today’s Globe and Mail wherein a reporter tries to eat the same diet as Michael Phelps in the hopes of improving his Olympic prospects. I won’t repeat the article, but Phelps eats 12,000 calories a day which is roughly equivalent to five days worth of food for a normal adult male. I suspect that if you studied a lot of Olympians you’d find that many of them eat around this much food while they’re training.

Putting these two ancedotes together, if I was a Harvard MBA students I might come to the conclusion that the key to athletic success is eating several thousand calories a day. As the reporter discovers, doing this and this alone merely makes one short of breath.

My point – and I do have one – is that when you’re studying how other Product Managers operate don’t fixate too much on any one specific element of their success. Make sure you separate causes from effects. Look closely at what people are doing because often the roots of success are fundamentally tedious and all the glamorous stuff (perhaps only I consider eating twelve thousand calories a day glamorous) is just a side-effect.

Agile/Scrum Software Development and Product Management part 2

Agile 2008There have been a number of good comments on my original post on this subject and I thought, given that the Agile 2008 conference is happening here in Toronto this week, some additional focus was appropo.

Bhuwan, Ivan, Consultiq and Stacy all agreed with my position that the Product Manager shouldn’t be the Product Owner (Scrum role) if the meant that the Product Manager had to attend daily stand-up meetings with Development. This would force the Product Manager to be a daily tactical decision maker and would make it even more difficult to get out of the office, meet with customers, partners and prospects and do the fundamental research that is needed to ensure that the future success of the product is addressed.

Stacy wrote:

Many companies have assumed that Product Owner is equal to Product Manager. That’s a recipe for disaster — Product Managers can’t be in the daily stand-up, or the team will reach a point where they don’t know what to do next. … Product Management has to be that bridge between the market and development…and we can’t do that if we’re in the building, involved in the daily workings of Development.

I personally don’t like the name “Product Owner” for the role as it is defined in Scrum. At one company I worked at, we called it “Project Owner”, explicitly to remove the assumption that the Product Owner and Product Manager were one and the same.

In fact, on any sizable product release, there will be multiple scrum teams working on different aspects of the product, and thus in the Scrum terminology, there would be multiple “product owners” which doesn’t make sense. Now, the term “Project Owner” is not perfect either as there can then be confusion between the Project Owner and the Project Manager, but I think there is less potential confusion there than using the term “Product Owner”.

Steve wrote the following:

So, where does it say that if you move to an Agile/Scrum methodology that Development can make decisions on functionality without first consulting with the Product Manager/Product Owner?

Nowhere as far as I know. But this is not a problem with Scrum or Agile, but it exists in companies regardless of which Development methodology they use. Read my response below WRT Walter’s comment on how to address this issue IF the PM is not explicitly the “Product Owner”.

Walter left a thoughtful comment covering a number of topics. He suggested that the PM attend a Scrum of Scrums meeting to get away from the daily standup, but to still be involved. I have not worked in a company where they implemented a formal Scrum of Scrums type meeting so I can’t speak from experience, but I’m somewhat skeptical of the benefit, simply because the focus of Scrum of Scrums will be inter-team issues and not necessarily product/functionality issues that requires a PM’s attention. As stated in the Scrum of Scrums link above:

These meetings allow clusters of teams to discuss their work, focusing especially on areas of overlap and integration.

Walter also suggests using a person with a role something like “Requirements Architect” who can attend the daily scrum instead of the PM. I agree with this. In fact, I wrote in the original post:

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.

They key here is level of focus and ability to execute. It is very difficult for any one person to work at a very detailed tactical level — which is where the Product Owner needs to be — and still think, act and plan for the future at a strategic level which is where the Product Manager should focus. Having a Product Designer or a Requirements Architecture fulfill that tactical role but also know how and when to escalate decisions up to the Product Manager minimizes the impact on Development, but also allows for a scalable model that works for both PM and Development.

Walter continues:

Probably more important (and more time consuming) than the daily scrum is your participation in iteration planning, demos and retrospectives.

There will be other affects on the product manager when switching from waterfall to agile. You’ll want to approach your requirements differently. Instead of a list of things the software should / shouldn’t do, you should break it down into stories where each can be implemented independently, will add customer value and the team will be able to accomplish within an iteration.

Instead of saying “must”, “should”, or “frill”, you should rank them and update that ranking every iteration based on what was learned. Agile is all about attacking the most important things and changing based on what you’ve learned.

2 person meetingThis is where the Product Designer or Requirements Architect can also play a significant role, by working with the Product Manager to take the requirements that have been collected and defined for the release, and translate them into effective and accurate user stories that can be readily consumed during sprints. Priorities can also be defined for the stories, so that as implementation proceeds, decisions can be made quickly to drop or reprioritize specific stories if lack of time/resources force the case.

By working with the PM in this way, the Product Designer (or equivalent role) gains a clear understanding of the requirements, their context and importance and can then work efficiently with the Development team to see them through implementation.

The Product Manager can (and should) regularly communicate with the Product Designer and Development Management, at minimum, at key milestones such as feature/functionality reviews, retrospectives etc. to ensure the development work continues to stay aligned with the original intent of the requirements. This also frees the PM to work with other teams such as Product Marketing, Marketing, Sales, Finance, as well as customers, partners and prospects and focus on overall product success.

In the end, the key is to ensure there is clear understanding of who has what authority and responsibilities, and people communicate effectively with one another to define, build and release the best product possible. No one role can succeed without the others, and in the end, all teams must either succeed together or fail together.


Agile/Scrum Software Development and Product Management (part 1)

Agile/Scrum and Product Management (part 3)

Agile/Scrum and Product Management (part 3a)