Monthly Archives: August 2008

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.

Saeed

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

Saeed

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

Saeed

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

Agile/Scrum and Product Management (part 3)

Agile/Scrum and Product Management (part 3a)

Entrepreneurial Proverbs

I came across a really good post from a couple of years ago entitled Entrepreneurial Proverbs. Reminded me a bit of my own post on Product Management Axioms. (OK, enough of the gratuitous self-promotion).

Entrepreneurial Proverbs is a good selection of pithy sayings and brief explanations all related to startups and new businesses.

Here’s a few particularly good ones, but read the article for the descriptions and details.

  • Momentum builds upon itself
  • Pay attention to the idea that won’t leave you alone
  • Build what you know
  • Give people what they need, not what they say they need
  • Work only with people you like and believe in
  • Work only with people who like and believe in you, just naturally
  • Build the simplest thing possible
  • Test everything with real people
  • For investors, the product is nothing

There are actually about 30 of these in the article and it well worth a read.

Momentum builds upon itself is a good one. In physics, momentum is a vector, meaning that it has a magnitude AND a direction. This is true in business as well. Momentum can be good or bad depending on the direction you are heading and how fast you are heading there. And like big ship chugging through the water, it’s not always easy to change course to avoid problems. But, if you’re heading in the right direction, get to your destination as quickly and safely as possible.

Build what you know is another one I agree with. I’m a big proponent of having domain knowledge for whatever endeavour you embark on. Can you succeed with domain expertise? Certainly, but you’ll either have gained it along the way, or you’re really lucky.

For investors, the product is nothing is so true. Investors will invest in the people, not the product. For example, “friends and family” money is about people who trust you putting their dollars behind your idea. In most cases, they likely don’t understand the details of your endeavor, but they have faith in you. The same is true for VCs. Yes, they’ll look at the market and market opportunity, but a good opportunity with a bad management team is likely to get rejected. People invest in other people, and the more confidence they have in you, the more confidence they’ll have in your product, and in particular, your abilities to deal with the inevitable problems that appear along the way.

letter Here are a few more proverbs that I’d add to the list.

Failure is always an option — There cannot be success without failure, and there is nothing wrong with failing at something, IF you fail properly. Having a good idea, turning it from concept to product or service and executing well are necessary for success, but they are not sufficient. Sometimes external forces such as market conditions, general economic trends, competition, technical innovations or other factors your control can cause failure to happen. Don’t let your company catch Malcolm Crowe disease.

When in doubt, find out or leave it out — Software development is never a fully deterministic process. There are lots of unknowns to deal with, from technology to market needs to competitive threats. Usually, you’re learning as you’re building and the market landscape is constantly changing. There is a lot of pressure to add or include features “just in case”. But this can also be a death knell for small companies.

Adding functionality “just in case” is a sign that you don’t understand who you’re building for or what they will do with it. Granted, you never can know everything, but in this situation you have two options. Either get more information to validate the need, or if that is not possible, leave out the functionality. You can add it later (usually), and you can spend the resources on things that are definitely needed.

Good enough is not always good enough — This my sound contradictory to the “When in doubt…” proverb, but it’s not. There is a general rule that one should focus on making their product “good enough” for the objective it is meant to fulfill. And, in general, that general rule is true. :-) Make the thing work reasonably well, and people will use it.

But, in that “good enough” thinking lies a trap. What’s good enough today will not be good enough in the near future. What’s good enough for an industry giant is definitely not good enough for an upstart company. The playing field is not level and bar is not set at the same height for everyone. (Ouch….2 cliches in one sentence!) Don’t settle for “good enough”. Aim somewhat above that, and make your product memorable. Figure out how you can make your customers say “I gotta get me some of that!“, and you’ve set yourself ahead of most of your competitors.

Saeed

A Not so Cuil (Cool) Launch

Cuil logoTo a decent amount of fanfare, a search engine named Cuil (pronounced cool) was launched this week. Founded by ex-Googlers, Cuil was positioned as a direct competitor to Google.

Now, the web is full of articles describing the problems encountered by Cuil and it’s users in it’s first week.

While it claims to have indexed over 120 BILLION pages, it doesn’t seem to know what to do with them. Having previously worked in the search space, I know there are a few basic things that search engines need to be able to do:

1. Actually show results to common search queries

The following screenshot shows the actual results for the search terms “cuil search engine launch”

(click to enlarge)

Shockingly it came up with no results found, which makes no sense. This happened consistently, so it’s not simply a glitch due to heavy load.

2. Update your index more than once a week

Another example. Fully 5 days after the launch of Cuil, a search for the terms “cuil launch” gives only 24 hits that look like this:

(click to enlarge)

Note the complete lack of any hits related to the actual launch of the search engine itself. Not even the site itself Cuil.com shows up in the results. That tells me that while they may have indexed 120 Billion pages, they’ve indexed virtually nothing new in the past 5 days. Rather unimpressive, as relevancy and currency are both necessary for modern search engines. As a comparison, the following search engines have far more matches to the same query:

  • Google: 364,000 hits
  • Yahoo: 5,970,000 hits
  • Live: 248,000 hits
  • Altavista: 5,870,000 hits
  • Excite: 56 hits (not very exciting!)
  • Ask: 5460 hits

There’s a huge disparity in the numbers, but the exception of Excite — does anyone use Excite any more? — it’s pretty clear that there are hundreds of thousands, if not millions of pages on the web that match the search “cuil launch”. Even Excite’s paltry 56 hits is more than double that of Cuil.

3. Show results in a meaningful way

Cuil shows search results in a 3 column magazine style format. This is different the the standard ranked list of search results that virtually every other search engine provides. I’m not sure why Cuil’s makers decided to list their results this way. Do I assume that relevance is by column or by row? A search for “Ethan Alan Saeed” — I’ve got to assume that those three names don’t appear together that often outside of our blog — gave the following:

(click to enlarge)

So which are more or less relevant? Is Cuil saying it doesn’t matter? And why is Pop Matters listed first? Yes, that page has all three names on it, but other than that, nothing.

Google, Live and Yahoo all list our blog first.

4. Images should be relevant to the search

Most search engines show images in some of the general web hits. Cuil is no different. But what I can’t figure out is what is the relationship between hits and the associated images. Take the following search — “saeed khan product management” and this set of search results:

(click to enlarge)

Each of the hits above seems to relate to me or our blog, but careful inspection shows that not to be the case. For example, the third hit on the top links to this page on Jeff Lash’s GoodProductManager.com site.

But the actual page, from January 2007 doesn’t contain either my first name or my last name. Odd.

The other odd thing about the page is that the images associated with each link are not from those pages themselves, or even from those domains. For example, the Contact and About Us link — second row first column — has a prominent picture of someone. First of all, that image is not on that page, check for yourself here, and secondly, that picture is not a picture of me, and it is certainly not Ethan or Alan.

In fact, it is a picture of an Australian politician named Saeed Khan. No relation to me or our blog at all. As I look across the results on that page, it is clear to me that not a single one of the images has any relation to the link it is associated with.

My final thoughts

It’s hard to believe that Cuil was launched with such fanfare, yet so prematurely. One has to wonder why? Did someone or something force their hand to launch earlier than planned or was this simply an example of a really bad launch. The name is odd, and misspelling it — ciul.com or culi.com — takes you either to a parked domain or a domain that focuses on (ahem) “parking“.

But aside from that, the various problems with the site could have been alleviated by using a simple 4-letter word: BETA.

While product success certainly depends on the product, it depends even more on setting expectations and ensuring that users and customers know what to expect when they use it. There’s no good reason why Cuil couldn’t have slapped the word BETA on their site, as Google is won’t to do for new services — and thus set expectations accordingly.

Another thing they should have done is not position themselves as a direct competitor to Google. Taking on an established and dominant competitor out of the gate, like conducting a land war in Asia, is a bad strategy.

They should have followed the axiom Nail it, then Scale it.

Let’s see how they recover from this.

Saeed

Can't we all just get along?

Having just finished a post recently defending Microsoft PM Scott Buchanan from the overwhelming force of the Cranky PM’s vituperative volley, I came across another scathing salvo from Tom Grant at Forrester.

I have to give Tom credit for two things though:

  1. He does clarify that the role of Product Manager at Microsoft is more like a Marketing Manager with outbound focus.
  2. The title of his post “Crankiness vs. Perkiness–FIGHT!” is one of the better titles I’ve seen in a while on a PM blog

But, Tom does get on Scott’s case for not being technical, pumping his fist when reading email, and having a Zune. You can read Scott’s original Business Week profile here.

In the Business Week article, written by Scott himself, he writes:

On my first day at Microsoft it took me 30 minutes just to find the latch to open my laptop…

Her Crankiness also fixated on this point, using it as evidence that Scott was somehow unfit for any job that had either of the words “Product” or “Manager”, let alone both, in the job title. Chill out a bit folks. That line is obviously a bit of self-deprecating humour.

Tom is critical of Scott’s youth stating:

He’s a bit too young and naive to blame him for doing anything but what his new employer asks him to do.

Tom also focuses on Scott’s line that his job is about “unlocking value” in Microsoft Office. Tom writes:

Use Scott’s own description of his job, “unlocking value,” you need a deep understanding of both the tool and the problem to help people understand how to use one to fix the other. If Scott lacks the technical skill to understand the tool, and he’s not devoting a lot of time to understanding the use case, then how exactly is he going to help people “unlock value?”

Give the guy a break. It’s a bit of a leap to jump from a self-deprecating line about technical aptitude, to the conclusion that he lacks the skills to understand Microsoft Office. This is Microsoft Office, not SQLServer or IIS that we’re talking about here.

I have nothing against Tom or Cranky, or Scott for that matter, but I’m really surprised at how quickly the PM community openly attacked Scott. Is that how we should be treating each other? Is that going to better our profession?

Sorry for being on a high horse, but let’s work towards a common good vs. tearing each other down.

Saeed