On Product Management

Product Management Metrics (part 3)

Saeed — Thu, 26 Aug 2010 02:03:00 +0000

So here it is, looong overdue, the continuation of this series of articles. I published Part 1 and Part 2 late last year. I also had part 2a back in May, related to an audio seminar I participated in with Tom Grant of Forrester Research.

I’m not sure why it’s taken me so long to get to part 3, but here it is.

The story thus far

Unlike departments such as Sales or Marketing, measuring the value and contribution of a Product Management team or department is difficult.

Product Management doesn’t directly build, market or sell product, but clearly contributes significantly to the success in all those areas.

The focus of Product Management is product success, but that changes depending on the product strategy and the stage in the lifecycle of a given product.

Given the broad scope of the work, the dynamics of different products, and the cross-functional nature of the role, how can Product Management measure it’s success.

A different view of the Product Lifecycle

A traditional Product Lifecycle diagram (for a successful product!) looks something like this:

This is clearly a simplified diagram for illustrative purposes.

For any actual product, the stages such as Develop, Launch etc. would have different lengths of time, with the Maturity, and Decline stages being much longer than they are shown. The curve itself would also vary somewhat in shape and wouldn’t be a simple bell curve.

Each of these stages is fairly self explanatory, but if we look at the same diagram and replace the stage names with the main objective of each stage, the diagram becomes:

Described this way, it becomes much easier to identify the key Product Management goals and focus for each stage.

Build it

The focus is on developing the first version of a product or solution that addresses a market need for an identifiable set of target customers. This is typically an iterative process, starting with an initial hypothesis or seed of an idea and then working with a small set of early (pioneer) customers, learning from them as they are exposed to the product and incorporating that input back into the offering.

Nail it

Once the product is launched, Product Management focuses on gaining an even deeper understanding of use cases, product limitations, positioning and messaging issues, sales barriers, pricing issues and other blocking factors that would prevent rapid adoption of the product in the target market. Education is a factor here, both within the company as well as externally. Thus working with press, analysts, key partners and other influencers is very important.

Scale it

Once Product Management has “nailed it”, (maybe with version 1.2 of the product along with changes to the marketing, pricing etc. of the product), focus shifts to helping other parts of the company scale efforts and results. This can be tied into working with marketing, education, finance, sales channels etc. Additionally, changing market conditions, customer and partner feedback, and competitive issues will be used to drive the product development cycle.

Extend it

In my opinion, this is a very interesting phase of the product lifecycle, because there are many ways to extend a product beyond the original problem space and target market segment. But it takes a lot of discipline to properly decide how to proceed and many companies fail miserably at this stage. Some methods of extension include:

technology– e.g. adding new platform support such as a port from Windows to Mac or Linux
geography — e.g. international expansion or foreign language support
market segments — e.g. a small business edition or other vertical market specific offering
adjacent problems — e.g. like adding more blades to a Swiss Army knife
channels – e.g. working with resellers, VARs, distributors, OEMs or other parties

Milk it

At a certain point, either due to market or technology changes, the return on investment in extending the product is not justifyable. And assuming the market for the product has not commoditized — i.e. with free or very cheap equivalent alternatives — a product can enter a “cash cow” phase where the company can “milk” it, by collecting revenues but with minimal investments.

At this point Product Management’s focus is on maximizing the (declining) revenue stream, minimizing expenditures, and defending against low cost alternatives or other threats. Traditionally software products in this stage have benefited from a large customer base, strong recurring maintenance revenue and low demand for product changes or investment.

End it

At some point, based on declining revenue, increased maintenance costs, related technology obsolecence or complete lack of demand, a decision is made to end-of-life (EOL) a product. For any established product, this can take a period many quarters or years depending on the product and market segment.

There is not a lot for Product Management to do in this phase except perform the business analysis for EOLing a product and have it approved by management. Once that is done, assuming an EOL process is defined, a number of tactical activities, usually undertaken by other teams, are performed to ensure a smooth transition for customers.

What’s next?

In the next part — and I promise it is NOT months away — I’ll dig further into each of these stages and focus on specific activities and metrics for Product Management.

Saeed

Bookmark and Share:

Unexpected down time

Saeed — Mon, 23 Aug 2010 17:43:55 +0000

Over the weekend, unexpectedly, the blog was not available for approximately 12 hours.

The reason was a problem in the blog database.

Thankfully it happened over the weekend and not during the week so the impact on readers was reduced.

The database issue has been addressed and the blog is up and running again.

If you have any other problems in the future accessing the blog, please let us know.

Our email is onproductmanagement (at) gmail (dot) com.

Thanks

Bookmark and Share:

Our Blog via Email

Guest Post: Improving Product Management the Agile Way

Saeed — Thu, 12 Aug 2010 16:51:45 +0000

NOTE: The following is a guest post from Ilya Bagrak. If you want to submit your own guest post, click here for more information.

- -

Boiling Down Agile

When I take a look at agile programming from far enough away, I am astounded by the powerful ideas it brings to software engineering. I am not going to regurgitate all the benefits and detractions of agile, but I will restate it in simpler terms or as I tend to understand it from my product management perch.

Agile takes a medium-term engineering goal, decomposes the delta between the current state of affairs and the objective into bite-size chunks, and then chews through one chunk at a time, learning as it goes along.
It increases the opportunity for self-correction by structuring the learning such that the team can apply the things that it learned in one iteration to the one that follows.
If self-correction happens often enough, we arrive either at an engineering success or at a well-supported argument why a goal cannot be reached.

Arguably, you can’t do much better at optimizing engineering resources regardless of whether you call it agile, waterfall or something else entirely. And this brings me to the original reason for raising the agile specter:

Can the above principles be applied to product management?

Agility in Product Management

I believe that some agile principles can be applied to product management, but we need to take note of a couple of terms listed above and how they are different for Product Management. These terms are “team” and “iteration”.

Team

Agile methods place a lot of focus on intra-team communications. It’s all about making sure that engineers get to bounce ideas off one another other, sanity-check their estimates with each other and work on the problems collaboratively as opposed to in complete isolation. Naturally, a lot of agile engineering deals with prescribing specific agile roles and the responsibilities that go along with them.

Contrast this with Product Management, which is often a “lone ranger” role. You do it all, with few team members, but usually in collaboration with various external stakeholders. For better or worse, these external stakeholders are all embedded in their own distinct workflows (sales, marketing, senior management), so they cannot be easily compelled to play by a uniform set of rules (as required in agile development).

To work with these stakeholders, it’s easier to think in terms of inputs you need from them and the outputs you must provide to them to move forward in the most efficient way possible. So in the end it’s all about communication as well (isn’t everything?).

How can this way of thinking be translated into action? It helps to sit down with different stakeholders and write down and agree with them about what they expect from you and what you expect from them. Trust me, I’ve done this exercise and it helps a lot in streamlining communications. You’ll also find that people are strongly motivated to sit down with you because there is clear value in this exercise for them as well.

Iterations

This is the other term to consider. Earlier I referred to iterations and the medium-term goals that engineering focuses on. To an especially cynical product manager it may seem natural to partition software development into sprints because all engineering activity is homogeneous, whereas product management activity is heterogeneous. The argument may be that it’s harder to march in lockstep since in product management you advance on many fronts at once.

But, there is nothing natural about splitting engineering work into bite-size chunks because work items often exceed the length of iteration and/or don’t start at the start of iteration. In my experience this is a tremendous source of agile headache. So in the end it’s not done because it’s a natural thing to do, it’s done because the benefits outweigh the downsides. The same holds true for product management.

If you have many concurrent and heterogeneous activities in various states of completion, nothing should be stopping you from checkpointing yourself every so often. To deflect the obvious criticism, let me say that I am not talking about scheduled reporting to your boss.

Instead I am talking about self-correction and squaring your progress against your own plans. The hope is that by increasing your opportunity for self-correction you also increase your chances of reaching your goals. The reason this is difficult for product managers is that it’s hard to pause just to have a conversation with yourself.

How long should agile product management iterations be? Think in terms of raw percentage of time spent planning and updating plans. This in my view should not exceed 10% of all work you do. If it takes you 1 day to plan for the next three weeks, that’s 1/15 or 6.7%, which looks just about right to me.

Putting Everything Together

If you’ve worked closely with engineering, you know that engineering gets a lot of flak for missing deadlines and providing inaccurate estimates of work to be done. And these are precisely the problem that agile programming practices try to address.

However, I often see Product Management get less criticism than engineering for the same missteps. We are more easily forgiven for messing up the little stuff or steering off course temporarily as long as the overall direction and trend is acceptable. On the other extreme, when product managers fail, they fail spectacularly and with much more serious repercussions for the person at fault.

Why is this the case? I think the main issue is that our success as product managers is more amorphous and difficult to define than engineering success, and any agreement on how to evaluate product managers has proven elusive. It’s really a function of the multiple hats we wear, the lack of opportunity for repetitive course correction along the way, and the fact that complete and utter product failure just takes more time so it occurs less frequently, which in turn creates the perception of greater leniency.

In Conclusion

What I like about agile programming is the commitment to improving the metrics by which engineering is ultimately judged. As a consequence of inherent differences between product management and product engineering, not everything that is agile can be applied to product management. Still I do believe that a combination of:

more structured product management communications,
iterative planning and self-evaluation,
finer grain (as opposed to all or nothing) performance metrics

can all lead to better product managers and better products.

- -

Ilya Bagrak (@ibagrak) is a product manager and a budding internet entrepreneur who shares his time between Moscow, Russia and Silicon Valley, California. He also blogs about product management, entrepreneurship, and technology at codercofounder.wordpress.com.

Bookmark and Share:

Guest Post: How to Productize a Service for Enterprise Customers

Saeed — Wed, 11 Aug 2010 02:44:16 +0000

NOTE: The following is a guest post from Craig McQueen. If you want to submit your own guest post, click here for more information.

- -

If you have Enterprise customers you probably deliver services to them. It may be in support of a product you sell or you may strictly be a services firm.

Usually service engagements start off as custom pieces of work. Creating a statement of work defines what will be done and an estimate of the labour required is provided along with an hourly rate. After a few service engagements with customers you likely notice common activities in the work. When you see these, you have an opportunity to productize your service.

What does it mean to productize a service?

It means to define an offering with a set of repeatable activities and deliverables that address a common business problem of your customers.

Why would you productize your services?

It is easier to sell a defined offering that contains specific activities and deliverables rather than custom statements of work
Standardized delivery means it is easier to train your staff
Delivery is more efficient since the framework is already defined
Each time the offering is delivered it gets better through learnings
It strengthens the credibility of your organization as experts in your field

An Example

The company I work for has a specialty in implementing Microsoft Project Server. Virtually every client needs dashboards and reports that show project delivery and resource status. We have implemented many of these over the years and found that the key metrics for delivering projects are similar between companies. Based on our implementation experience and industry standards we have defined and now consistently deliver a standard, repeatable service to define and deliver Project Dashboards for organizations.

Other productization opportunities

Although this example is specific to a specific business function (Project Management), there are common themes of offerings that exist across business functions. Some common offering themes that you can consider for your company include:

Maturity assessment – Based on your understanding of your industry, investigate and compare your customer along different business functions.
Business case preparation – Uncover the inefficiencies in an organization that could be addressed with a solution.
Roadmap – Define a multi-year timeline with key benefits and milestones along a business line or functional area.

Remember these rules

Once you have a general idea of the service you want to productize, consider the following tips when working out the details:

Fix price the offering. When someone buys a product, they need to know the exact price up front. Even if you are intending to have the offering as a free value-add to a larger purchase – putting a price on it demonstrates the value the customer is getting.
Constrain the timeline. With a fixed price you want to constrain the timeline so your costs don’t blow up. Be crystal clear which activities occur during the engagement. Identify key milestones and deliverables.
Base it on previous experience. If you don’t yet have customer experience delivering the service you want to productize, do a trial run with your internal organization or a trusted partner.
Be clear about the benefits to the customer. Document the value proposition of the offering directed at helping customers understand the
Specify what you expect from the customer. Indicate who will participate in the offering, how much time is required from them and the types of activities.
Build supporting documentation. Items such as delivery guides and samples reports help the customer see that you have real intellectual property baked into the offering rather than using them as a guinea pig.

As you productize your service, keep your objective in mind. Will the service be a revenue generator or will it be tool to open doors with customers with the intention of a larger follow-on sale? Depending on the goal, you may market it differently.

Have a look at the types of services you are delivering to your customers today. Pick the most common one to start and apply these rules to productize it.

- -

Craig McQueen leads the Business Intelligence practice for Agora Consulting Partners. He is involved with all aspects of the practice including sales, marketing and delivery. Through his consulting career, he has worked with enterprise customers including TD Bank, Royal Bank, BMO, Rogers Communications and Bell Canada. You can reach Craig at the following email – cmcqueen (at) agorainc dot com.

Bookmark and Share:

Product Management and Thought Leadership

Saeed — Wed, 04 Aug 2010 23:49:54 +0000

Last year, as I was creating content for my Devil’s Dictionary for High Tech – I tweeted the following:

You can see the original Tweet here.

Now this was clearly a satirical definition, but it is based on my experience with the topic of thought leadership. I’ve been in more than a few meetings where someone stated that one of the marketing goals was to be seen as a thought leader in our space in the coming year.

No one, myself included, asked what it actually meant to be a thought leader, or how we’d know that we’d achieved our goal, or even what the benefits were if we did become one. The goal of being seen as a “thought leader” was in itself a phrase whose meaning seemed self-evident.

But, clearly that isn’t the case. As mentioned in a previous post, Tom Grant at Forrester is conducting research on thought leadership and is looking for community input.

Having said that, I thought I’d get some direct input from you folks about this topic. And while Tom is focusing on thought leadership in the enterprise software and services space — using Salesforce.com and Wipro as case studies — I see this topic having direct relevance to Product Management.

What is a thought leader?

Before going further, let me try to put a box around the phrase “thought leader”. I say “try”, because I think the phrase will mean different things to different people and there is no single definition that can cover all viewpoints. Here’s one view:

A thought leader is someone who consistently communicates credible and unbiased information and insight in a particular domain AND whose insights are used by others to take action or make decisions about issues in that domain.

OK, so that won’t fit into a single tweet, and it probably could use improvement (your thoughts are welcome), but it does contain several important points.

1. Thought leaders are people.

Yes, sometimes an organization can be viewed as a thought leader, but it’s the people who make up the organization, and in particular those who speak for it, and represent it that can be viewed as thought leaders.

2. Thought leadership is an active task.

People must communicate in an ongoing manner. A brilliant person who cannot communicate his/her insights to a wide audience cannot be a leader. Communication is one of the 4 Cs of Leadership.

3. Credibility and trust are a must

Virtually anyone can speak on any topic, and with web technologies, they have a virtual megaphone to get their message across. But that fact alone doesn’t make someone a leader. Thought leadership, like any type of leadership requires the trust of those who follow. The leader must be believable and not be seen as a self-promoter or a shill for some organization.

4. Other people/parties must find the leaders insight relevant and actionable

Leadership must be tied into action or progress for those who follow, and not simply the number of those who will listen.

For example, Kanye West joined Twitter on July 28/2010. He had about 200,000 followers the next day and currently has almost 500,000 (roughly 1 week later). Does that make him a thought leader? Not in my opinion, at least not on Twitter. Between musings on life, or Twitpics of things he wants to buy, it’s hard to see how any of this minutae about his life can be considered useful insight. In fact, Kanye seems like a perfect example of the Devil’s Dictionary definition I gave at the beginning of this post.

Product Managers are thought leaders

Looking at the 4 points above, they can clearly be applied to the role of Product Management. Product Managers must lead through influence, must convince others of their perspectives and views, must have credibility and trust, and must communicate information in ways that others find useful and relevant. This applies to both internal teams and with external audiences.

Product managers may not see themselves explicitly as thought leaders, but they often are viewed that way by others. Keep this in mind as you work through your next research project or product release.

How would you define thought leadership?

Do you see yourself as a thought leader in your company?

Saeed

Bookmark and Share:

Please help Tom Grant with his research on Thought Leadership

Saeed — Mon, 02 Aug 2010 18:53:25 +0000

Forrester analyst Tom Grant is conducting research on the topic of Thought Leadership. But for this research, he’s taking a much more open, collaborative, and as Tom indicates, an agile approach to the research.

In short, Tom is trying to validate the hypothesis:

While thought leadership depends on a variety of factors, the one irreplaceable element is a portfolio of success stories. This experience not only adds credibility, but also builds a network of influence that the thought leader needs for every aspect of commercialization.

He wants community input in helping focus on the key questions that should be addressed by the research.

The best way to click this link, Thought Leadership development document, log in and add your comments to the page.

A few people have already done so and some interesting discussion is now developing.

I’m working on a blog post to provide my comments on the topic and will publish that soon.

Saeed

Bookmark and Share:

Check out LiteMind for a free eBook

Alan Armstrong — Fri, 30 Jul 2010 14:51:29 +0000

I recently started reading LiteMind, and have been enjoying it very much. The focus of the site is personal development, productivity, freedom, and creativity … all topics that product managers can benefit from.

They have an offer today that you should check out: A free eBook just for making a comment on a post. I think it’s a draw, so it’s not a sure thing, but the list of books is worth perusing.

Check it out here: http://litemind.com/personal-development-giveaway/

- Alan

Bookmark and Share:

5 steps to building a great Product Management organization

Saeed — Tue, 27 Jul 2010 04:29:05 +0000

There’s a lot of general discussion about traits and activities to help individual Product Managers excel, but not a lot is written about Product Management teams and departments. I wrote a pair of blog posts on this topic a couple of years ago, but not much since, so I thought it was time to revisit the topic.

A reality of Product Management teams is that they are usually relatively small, particularly when compared to larger departments such as Engineering, Marketing or Sales. And perhaps it is because these teams are small, that not much thought is given to how to best structure them. But in fact, given the critical cross-functional role Product Management plays, having a well structured, scalable and properly staffed team can make a huge impact on the top-line of a company’s balance sheet.

Here are the 5 steps to building a great organization.

1. Understand the full value of Product Management

Too often technology Product Management is viewed as the requirements collector, or keeper of the product roadmap, or an adjunct to Engineering. But all of these sell short the value and impact Product Management can have on a business.

What is the ultimate goal of Product Management?

To optimize the business at the product, product line or product portfolio level over the lifecycle of the products.

Or as Don Vendetti defined it in his guest post:

To deliver measurable business results through product solutions that meet both market needs and company goals.

Either way, the focus is on the business success.

And if you look back at the origins of Product Management it’s clear that’s how it was envisioned by James McElroy at Procter and Gamble almost 80 years ago.

2. Put formal Product Management in place very early in a company’s life

Understanding what should be built and for whom is a core task of Product Management. But even in very early stage companies, there are many other questions that Product Management must answer:

Questions such as:

What high value problems does the product solve?
Who faces these problems today?
How much pain do these problems pose for these people?
Who will be the main buyers of the product? (Note: buyers and users are not necessarily the same).
Will the buyers pay to address the user pain (i.e. is the pain a high enough priority for the buyer to spend money to address it?)
What are the current alternatives to using the product?
What obstacles need to be overcome for people to adopt this product?
What skillsets will the target users have?
Do the skillsets of those users match with the required skillsets needed to use the product?
How should the product be priced and licensed?
How should the product be initially delivered into the market?
What channels or partnerships are required to enter the market?

These are all fundamental questions that should be asked and answered in the earliest stages of a business, as they not only impact how a product is built, but also the activities and people needed to bring the product successfully to market.

For any startup, company success is tied directly to product success. Or as Bill Campbell said, “Great companies start with great products”. It is something a lot of companies seem to forget, as they release complex or unfocused products that require significant marketing and sales efforts to generate customer adoption. Put skilled Product Management in place early to accelerate market adoption, revenue and profits.

3. Product Management must be part of the Executive team

An experienced Product Management executive should be the first formal Product Management hire as she/he can not only help with overall product strategy and market alignment, but can set the stage for building a great team as the company expands. In short, Product Management needs a seat at the management table.

Many companies that hire early, make the mistake of hiring a less experienced person — a “hands on” individual contributor — to be “the Product Manager” for the fledgling product. This person typically reports into Engineering or Marketing and thus isn’t part of the Sr. Management team. While a good individual contributor can certainly help a company avoid common mistakes, an experienced executive can help drive the company forward and accelerate success.

4. Don’t starve Product Management as the company grows

Far too many companies have significant budgets to hire additional engineers, sales and marketing staff as growth occurs. But as they grow, they typically don’t increase the Product Management team to keep pace. This is a pattern repeated in many companies.

Over time, Product Management becomes a bottleneck for other groups in the company. This not only reduces the effectiveness of Product Management, but also impacts all the downstream teams and activities that depend on information and decisions coming from Product Management. This creates a drag on the company’s ability to execute effectively and to bring new successful products to market.

5. Create Product Management teams with differentiated roles

An often heard lament of companies looking for Product Managers is that it’s difficult to find really good Product Management candidates. I’m sure that’s true, but it’s also true when it comes to finding really great candidates for sales, marketing, software development, QA etc.

In general, good talent is hard to find. But what exacerbates the Product Management search even further is how companies define the job of individual Product Managers.

Product Management is a very broad function with a mix of technical and business responsibilities. Product Management needs to stay abreast of changing market conditions, competitors, and new technologies. Product Management also must create product and business plans to address market opportunities. Additionally Product Management must work across multiple groups and departments in a company to help ensure they are aligned.

A lot of companies make the mistake of rolling all of these responsibilities into a single role – the Product Manager – and then looking for the ideal candidate with all of the the technical and business experience, domain knowledge and leadership skills to fill that role.

And then when they need to scale – for example when looking to create a second product – the same companies look for yet another candidate with the same broad skill set. This process gets repeated over and over again across many companies. Of course, not only does this make it hard to find suitable candidates, but it makes it very difficult for those people, once hired, to be truly effective and successful.

Would any company hire software developers and ask them to design and write software, test it and also write the documentation for it? Or how about trying to hire a salesperson who can do their own lead generation and act as their own sales consultant. Not very likely.

Few if any companies would think that these are ways to build scalable and effective software development or sales teams. It should be evident then, that it is also no way to build a scalable and effective Product Management team.

Roles in Product Management should differentiate between technical and business focus; between short term tactical focus and longer term strategic focus; between internal (inbound) and external (outbound) responsibilities. These roles should be organized as small teams focused on specific products or product lines, with defined metrics to measure progress and success.

This is what is done with virtually every other department in a company. Why should it be different for Product Management?

Saeed

NOTE: Shortlink for this article is: http://wp.me/pXBON-1Fv

Bookmark and Share:

Open Question – One thing you wish you had known when you became a PM

Saeed — Fri, 23 Jul 2010 14:58:34 +0000

Simple question :

What’s one thing you know now that you wish you had known when you became a Product Manager?

Think of it as advice you’d like to pass down to those new to or thinking about entering the field.

I’ll start.

I wish I had really understood the value of ruthless prioritization. By that I mean prioritizing all the things that were (seemingly) expected of me, and being able to clearly define what was most important and focus on those.

I remember being completely overwhelmed in my first Product Management position by trying to do what I thought was expected of me by all the other teams.

It was a huge learning curve, and this was in a company that in hindsight, probably had one of the best grasps of Product Management of any company I’ve worked in.

OK, over to you. Please leave your answers in the comments section below.

Saeed

NOTE: Shortlink for this article is: http://wp.me/pXBON-1Fl

Bookmark and Share:

Lessons from 2 very different social media events

Saeed — Tue, 20 Jul 2010 00:00:02 +0000

NOTE: Shortlink for this article is: http://wp.me/pXBON-178

Boy, you can’t throw a stick these days without hitting someone who’s got some kind of social media activity going on. And it’s not just the technology or CPG marketers who are getting into the action.

Perhaps taking a lesson from the success of Barack Obama’s use of social media in his election campaign, Canadian politicians have started their own efforts in this area.

A few months ago, the leaders of the two largest political parties in Canada – Prime Minister Stephen Harper of the Conservative Party of Canada, and Michael Ignatieff, leader of the Liberal Party of Canada — held events that heavily relied on social media.

Comparing the two is very interesting and there are some clear lessons to be learned.

NOTE: I’m in no way endorsing either of these two parties or their leaders, and I have no political agenda here. I’m not a member of either political party. But these two events do lend themselves to analysis and learning. That’s my objective.

Event 1 – Prime Minister Stephen Harper takes questions on YouTube

YouTube and Google Moderator were used to allow people to propose and rank questions that would be asked of the Prime Minister. Over 1800 questions were submitted and voted on. A recorded interview with Google’s Chief Financial Officer, Patrick Pichette asking the Prime Minister questions was posted on YouTube under the TalkCanada channel. I’ve embedded the interview below.

Event 2 – Canada at 150 Conference lead by Liberal Party Michael Ignatieff

A 3-day conference entitled “Canada at 150: Rising to the Challenge” was held in Montreal from March 26-28.

The conference had invited speakers who discussed topics on a number of themes, and also answered live questions from across Canada submitted via email, Skype and Twitter.

There was a live audience of paid attendees at the conference who also asked questions of the various panelists.

Mr. Ignatieff spoke at the beginning and end of the conference but sat in the audience otherwise.

The whole event was streamed live over the Web via their website — http://www.can150.ca — and there were many local meetings held across Canada over the weekend where people could watch the panels and speakers in Montreal, submit questions and discuss issues.

And obviously recordings were posted on YouTube after the event.

Comparing the two events

It’s important to note that these were two very different events, held by very different political parties and for very different reasons. BUT, there are valid comparisons that can be made from the social media perspective and what it means to use and benefit from social media.

Prime Minister Harper on YouTube

The Stephen Harper YouTube event was recorded and not live. It was no different than an interview or “fireside chat” that could have been delivered via television or radio for that matter. The Globe and Mail newspaper had an interesting take on event.

Lesson: Putting videos on YouTube does not mean you are “leveraging social media”.

If you listen to the interview and know a bit about Canadian politics, the responses, such as why does Canada not have an elected Senate, on legalizing marijuana, or the Prime Minister’s views on another separation referendum in Quebec were very simple in nature, given little additional information and insight into the topics.

Lesson: Social media can help reach new audiences, but you need to be authentic and open. Save stock, scripted answers for mainstream media sound bites.

One question on the Canadian military’s role in the potential mistreatment of Afghan detainees (a hot topic in Canada at the time) was met basically with a repudiation of the question and a somewhat rambling answer that avoided the intent of the question.

Lesson: Social media are most valuable for authentic bi-directional communication, not for simply broadcasting controlled messages

Overall response to the event was not very positive. Even the usually supportive newspaper, the National Post, ended a “review” of the performance with this line:

And so, YouTube Interview with Prime Minister Harper ends not with a bang, but with a whimper. As with many government performances of late, a disappointing finish to an otherwise well-meaning effort.

Canada @ 150 Conference

Hailed by Mr. Ignatieff himself as an example of 21st century democracy (I personally don’t agree with that claim), and a starting point for conversations about future of Canada, the conference was in many ways the polar opposite of the Stephen Harper event.

Instead of a single speaker with pre-screened questions and a recording of the answers, there were many speakers, live streamed over the Web and live questions via email, Twitter and Skype.

Lesson: Social media are tools for communication. Providing multiple means for people to communicate helps foster a true sense of openness and dialogue.

As mentioned earlier, there were over 50 sites across the country where people could go and discuss issue with local members of the Liberal party as well as other individual people. At each of those sites the live stream from Montreal was projected onto screens so all could listen.

A moderator at each site took questions from the audience and conveyed them to the conference in Montreal, but of course people could email, tweet directly on their own.

Lesson: Social media tools should support live human conversations whenever possible, not act simply as a replacement for them.

The Twitter hash tag #can150 was very active during the conference and for several days afterwards with lively responses to the conference, as well as debate on whether the conference was successful or not. Sadly, there is little happening on Twitter a few months later WRT that that event.

This is one place where I believe the Canada @150 conference failed with it’s social media activities. The event hailed as the start of conversations about Canada’s future provided no real means to continue the conversations once the conference ended.

Lesson: Social media provide the means to create ongoing connections with people. For any ongoing project, use them to create and build communities of people who can help move your project forward.

And finally…

It’s been several months since these events, and neither Mr. Harper nor Mr. Ignatieff has followed up with any additional social media activities beyond Twitter and Facebook.

Prime Minister Harper: @pmharper, http://www.facebook.com/pmharper

Michael Ignatieff: @M_Igniatieff, http://www.facebook.com/MichaelIgnatieff

It’s interesting to note that Michael Ignatieff is currently on an old style cross-country summer bus tour to meet people across Canada. Nothing like actually meeting people face to face in their own local environments. You can follow it on Twitter under #liberalexpress.

Even if you aren’t familiar with Canadian politics, are there other lessons people should be aware of when using social media?

Saeed

Bookmark and Share: