Category Archives: Roadmaps

ProductCamp Toronto – Oct 4, 2009

In just about 3 weeks, we’ll be hosting the 2nd ProductCamp in Toronto. Last year, at the first event, over 100 people came out to participate in a day of very engaging discussions and talks about topics on product development, product management, marketing, innovation and more. Some of the presentations and notes can be found here.

Pre-register today!

There are already about 150 pre-registrations for the this year’s event!

If  you want to attend, click here to add your name to the list.

It’s free to attend, and lunch is included(!),  so come out and spend a day of engaging thought and discussion with others like you.

Suggest a Session (or Vote for your Favourites)

In the spirit of BarCamp, the day’s sessions will be voted on at the start of the ProductCamp on Oct 4. But if you want to suggest a session, or want to present one yourself, you can do so in advance.

Click here to see the sessions and vote on them, or to suggest new ones of your own.

Become a Sponsor!

A number of companies have already agreed to sponsor the event, including:

  • The Ted Rogers School of Management (providing the venue)
  • Pragmatic Marketing
  • SevenL Networks
  • Greenscroll
  • MI6 Agency

Also, our own Alan Armstrong and his jazz band will play live at the end of day reception.

Thank you to all of these organizations. But we’re looking for more sponsors. Sponsorships are used to pay for lunch and t-shirts for all the participants, as well as materials, signage and other expenses that are incurred.

Your organization’s name and logo will be prominently displayed on the ProductCamp website, on the day’s materials, on the t-shirts, and significant mention will be made of the sponsor’s during the day.

If you’d like to become a sponsor and gain visibility with innovators in the Toronto area, contact us:

  • productcamptoronto at gmail dot com


We’re looking for volunteers to help with some of the logistics during the day. If you’re interested in volunteering,  you can indicate that when you register and someone will contact you.

Twitter – #pct2

Finally, look for the #pct2 hash tag on Twitter. We’ll post announcements via Twitter ahead of the Camp and hope to have some live updates on Oct 4.

Looking forward to seeing you there.


Guest Post: To Kill a Product: Why, When and How, Part 2/3

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Note: This is the 2nd of a 3 part series of articles by guest blogger Chris Brown. If you feel inspired to write a guest post of your own, click here to find out how to submit it to us.

Part 2: When to kill a productlicense_to_kill_ver1

No one wants to manage a dying product. No one wants to sell, support or, certainly, buy a dying product, either. The role of the product manager includes performing the kill analysis – thoughtful, thorough and completely unbiased – and making a recommendation that is best for the business.

Knowing When It’s Time

When do you know it’s time to kill a product? To make the case, the product manager should demonstrate the product’s performance over its lifetime and build an impartial view of the situation, and then make a recommendation. With the data points listed below presented and analyzed fairly, the decision to kill or not should be obvious, and the recommendation will carry sufficient weight to sway senior managers. (In some instances, a product may be unfairly on the chopping block, in the doghouse, for one reason or another, of senior management or a CEO. Performing this analysis could just as easily demonstrate why a product should be salvaged and invested in, rather than killed or left to slowly die.)

Here are some telltale signs your product is on life support:

Steady decline or flat sales volume or market share. Downward or flat sales volume over a long period of time indicates apathy on the part of the market, the sales team or both, neither of which are good. Apathy for one product can have a negative halo effect on others, which is discussed in more detail later.

Decreasing or flat revenues and/or margins. Lower/flat sales volume shouldn’t be the lone factor in a kill decision. Perhaps your product’s audience, to quote “Spinal Tap,” has become “more selective.” No problem: If a product is specialized and valuable enough to that audience, revenues can continue to climb based on price increases. But if the market is unwilling to accept a price increase and volume is in decline, then you’ve got a kill situation. This is why margins should also be analyzed. Products become more profitable as they reach economies of scale (products typically have lower margins in the launch and growth stages, and higher margins as the product reaches maturity, assuming steady volume growth). Tight margins, especially well after launch, indicate that the product may never reach the scale it needs to be truly profitable in the long term.

Lack of investment. Products that are on their deathbed often get ignored during budget cycles. This is not by accident, and can be a self-fulfilling prophecy, but is often a telltale sign that the organization has lost interest.

Over-investment. The converse of products that consistently get no budgetary love are the money pits, the ones that suck resources but see no return on investment. Again, the decision to kill these products tends to be a little easier, yet expensive-yet-poor-performing products can inexplicably live on. If high direct costs are the problem, you’ll see this in your margin analysis. But other costs, like ongoing technical, marketing and customer support, may take more effort to ferret out.

KPIs are in the dumper. This is important. Every product has a set of key performance indicators (KPIs) or metrics, other than sales or revenue, that measure success. These can be customer satisfaction scores, usage statistics, conversion rates, etc. Sometimes a product can have very strong KPIs, but slow sales. This could mean you have a marketing or sales channel issue. Ambiguous or conflicting KPIs may indicate a positioning – or even tracking – problem. In either case, the product may just need some tweaking or new messaging. But if KPIs are and have been in a steady state of malaise, then consider it a bad sign.

Strategic misalignment. Strategies can shift from year to year, and a product that was aligned with a strategy when it launched may not be in line with current strategy. Or, it becomes clear that the product was never able to deliver against the strategic direction, even if that direction has not changed. Either way, if your product is not delivering key strategic objectives, then it only becomes a distraction. (This will be obvious in your KPIs, which should be aligned with strategic objectives.)

None of these in isolation should serve as a reason to shut down a product. Even together they should be utilized as a basis for discussion of whether or not to go down the path of sun-setting. A product’s KPIs could be in the dumper, for instance, because the product is lacking key functionality, which it can’t have without investment, but no one wants to invest  because sales are down, which perpetuates the above mentioned self-fulfilling prophecy. You’re better off applying these criteria to a grid, like the one below, and using this as the basis for a deeper analysis.

The table will serve as a guide, but each of these areas should be fleshed out with data and analysis by the product manager.

In addition to these data points, present information that (hopefully) already exists, primarily a market analysis (who makes up the market for this product and how has it shifted, and what are competitors doing?) and an updated roadmap (features and enhancements necessary for product growth, and the level of investment needed to build these features). Combined this information and view it through a clear lens, and the right direction should be obvious.

–  Chris Brown

Chris is vice president of product management at, a division of Classified Ventures, LLC. Email him at or follow him @Brown784

Coming up:

Part 3: How to kill a product.
How do you kill a product? You’ve made the decision to pull the plug, now follow these steps to ensure a smooth sun-setting process.


Part 1: Why you should kill a product.
If it’s generating some revenue, even a little, why kill an underperforming product? Because ineffective products divert focus and resources from core and growth products, and ultimately dilute the overall value proposition of the business.

5 benefits in thinking about revenue models right from the start

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

moneymanThere are a number of Web sites and applications — two of the most well known examples being Twitter and Facebook — that offer very good, free services. And over time, as they grow larger, the quest begins to find a revenue model or models to turn the service into something that actually resembles a sustainable business.

The problem is that after the fact, trying to find and attach a revenue model onto something that people know and expect to be free is difficult. There may or may not be technical difficulties in doing this, but there will almost certainly be business and cultural difficulties in adding revenue models after the fact.

A lot of people like to cite Google as the model for a company that started out without any revenue models and then figured out an incredibly successful one later on. There’s nothing wrong with wanting to be the next Google, but the story of Google’s revenue model success is not one that can be recreated simply by positive thinking and hard work. Ask the folks at Cuil about that one.

The conditions and circumstances, market opportunities and market needs may be totally different. There’s so much we don’t know about the market that leaving revenue generation to an afterthought is hardly good business strategy.

It’s great to tout 1,000,000 or 5,000,000 or even 100,000,000 “users” or “visitors”, but when they cost you money everyday instead of helping generate positive cash flow, more is not better. And this, after the fact thought process of figuring out revenue models, is problematic to say the least.

Instead, why don’t these companies consider revenue models right from the outset or very early into their startup process? Whether the revenue comes from users themselves, advertising, premium services, data collection and licensing or some other means, it’s very important to think this through upfront and act accordingly to understand and implement those models that make the most sense.

There are a number of benefits in thinking and working this way:

  1. It requires you to actually segment your buyers and your users
  2. It helps you understand who you are truly competing against
  3. It reinforces the value proposition to your existing and potential users or buyers
  4. It sets up a revenue-centric culture within your company
  5. It’s the right thing to do

Let’s look at each one of these in more detail.

1. It requires you to segment your buyers and users

Who is the target customer? Now that’s a common question that gets asked all the time for virtually every product or service. Unfortunately, too many times the answer comes back as “everyone”, or “consumers”, or “anyone who needs our product”, or something equally vague and not very helpful.

It’s not always easy to know everyone who will find value in an offering, but it really helps to start with at least one or two target groups. Understanding who they are, what they need, and the value your offering delivers are key to defining a sustainable revenue model.

A lot of times people don’t do this for fear of missing or eliminating key groups of people, but if you can’t identify the kinds of people who might pay for your product or service, how can you decide how much value it is to them and how much to charge?

Keep in mind that users and buyers are not always one in the same. Taking Google’s search engine as an example, the users are the people conducting searches through the site. That service is free to them. The buyers are those organizations that buy pay-per-click (typically Adwords) advertising that is displayed in the search results.

The system of connecting searchers with ad buyers (i.e. targeted ad placement when people are searching for information), creates an incredibly efficient and scalable engine for revenue, and it must be noted, one that few companies have been able to emulate with as much success.

2. It helps you understand who you are truly competing against

There is competition for virtually every product or service. For some it’s very obvious, and direct competitors can be listed without thinking. For others it’s not so obvious, but incredibly important to identify. Why? Because the word “competitor” must be thought of as “other options for your target buyer to achieve the same or similar result”.

If you are going to charge for something, you need to know how your target buyer spends their money today (if they do at all) for similar results. Too often focus is simply put on very similar offerings in the market, and using those offerings as a basis for thinking about revenue models.

But if you truly put yourself in the context of your buyer, understand their options, and what final results or outcomes they want, your perspective can change significantly.

Southwest Airlines sees their competitors not only as other airlines, but also cars and intercity buses. Why? Because these are the most likely alternatives that their target customers (budget minded travelers) would look to in order to travel between cities. Keep in mind that a lot of SouthWest flights are short-haul routes.

Similarly, when Intuit introduced Quicken, they viewed their competition as not only other home accounting software packages (of which there were many), but also the pencil and paper, because that was also a common option for people who wanted to perform home finance calculations.  The outcome — balancing a checkbook or simple budgeting — can be achieved by computer as well as by hand.

In both cases, clearly understanding their target users’ desired outcomes and their likely options helped the companies understand the value they could deliver and in Intuit’s case, a benchmark for the price they could charge.

3. It sets up a revenue-centric culture within your company

What do you call a business that doesn’t care about revenue? Answer: A hobby.

Employees in a business need to think and act for the benefit of the business. People are hired, culture is developed, processes are defined, decisions are made and systems are built that align with the objectives of the business. If the goals of the business (at least initially) do not involve revenue (in some form), the culture, decisions, processes, systems and people within the company will adapt to that.

And when at some point revenue becomes a priority, then changes, possibly significant ones, will have to be made to accommodate for that. Decisions, which were likely technology or user driven will need to start incorporating revenue and business considerations. Does your service or product have a licensing mechanism? Is it flexible enough to accommodate the business? What changes in the Engineering, Marketing or Finance teams are needed? Do you need to create a Sales team?

It sounds trivial, but it isn’t. Consider what happens when something as simple as a pricing change is required in an existing business. There are many existing internal AND external parties and processes that need to adapt to that change.

Now imagine the impact if that pricing change goes from “no pricing at all” to some form of pricing. New people would have to be hired, for example, in finance. New systems would have to be created to collect revenue and process it. New processes are needed to handle refunds, discounts, create financial reports etc. Decision making criteria need to change to focus on what can generate and sustain revenue. These are just some of the changes that would need to occur to create a culture in the company that is revenue centric.

Why not set up the company early on to manage and deal with these kinds of issues and possibly accelerate the process of generating revenue.

4. It reinforces the value proposition to your potential users or buyers

There is absolutely nothing wrong with providing a free service. If  the objective is to only have a free service and it can be funded then go ahead.

But most services are not created to be completely free forever. Even open source software, which originally was viewed as “free” has developed business and revenue models that leverage the value their customers derive from it. Redhat, Suse, MySQL and JBoss are all examples of very successful businesses founded on this so called “free” software model.

For any aspiring profitable business, there is a very clear need to identify upfront what is truly free (e.g downloading and using open source software) and what requires payment (e.g technical support for open source software). Not only does this delineate the difference between free and paid offerings but it also defines the relationship and expectations a customer or buyer will have with the company.

Flickr provides a good example of this in action. You can upload a fixed number of photos for free and share them with anyone, but for a large collection of pictures, there is a small  fee ($25 per year for a Pro account). Flickr commits to never deleting your photos, even if you fail to keep your paid account current. They’ll simply restrict your access to them.

So why is this important for customers/buyers? It positions the company very clearly as one that is in business to generate revenue, that will deliver a set of services or offerings that have some intrinsic value that costs actual money, and one that, if successful, will be around in a few years time to continue delivering the service that is being paid for.

I like free stuff as much as the next guy, but if I’m going to commit my time and effort to using someone’s services, I’d like to know that they’ll be around so I can continue to use them. Now, there are plenty of companies that charge for their services that go belly up, but that is not new to the Internet. That’s a simple fact of life for any business. But I’m sure you’d agree that it’s more likely that a company that DOES charge money for their service or has a very clear and scalable revenue model will be likely be around longer than one that doesn’t.

5. It’s the right thing to do

rightthingWhy are most businesses started? To make money? Well more bluntly, to make money for the founders and investors in the company. If that is the case, then it’s Business Basics 101 that understanding the market, potential customers, their buying needs, budgets, willingness to pay etc. are all critical to any form of business planning. So, why not start right and do some homework upfront?

It used to be the case that the investment to build a product was significant, typically involving manufacturing processes, sourcing from suppliers, warehouse and delivery expenses and logistics etc. But the combination of mature software development tools and the Web as the distribution medium has created an environment where creating and distributing the “product” is simple and rather inexpensive. In fact, identifying buyers, buyer needs, budgets etc. is likely harder than creating the product. So what do many people do? They build something and see “what sticks”.

While there is benefit to this approach, it should not be done without forethought to the business aspects that will underlie the offering. Both product definition and business planning need to be done together and up front. Just as iterations are needed to get the product right, iterations will likely be needed to get the business working well. Both product and business strategy need to evolve together, and as knowledge is gained and changes needed, then those changes can be made in tandem.

And while people will hold up the few successful companies, like Google, as their models for achieving success, it’s telling that they willfully ignore the myriad of companies that tried the same “we’ll figure out the revenue model later” approach and utterly failed.


Guest Post: There’s no such thing as MEDIUM

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

NOTE: The following is a guest post by Tzvika Barenholz, a Product Manager living and working in Israel. If you feel inspired to write a guest post of your own, click here to find out how to submit it to us.

We all know the situation: you’ve collected a bunch of product requirements, put them into a nice excel sheet or clever table-like GUI front-end; you’re all psyched about making the big decisions, prioritizing and leading the product to the proverbial “next level”. You sit in front of the screen, crack your fingers, stretch a bit and place your hands in the typing position.

“First item, feature xyz” – yes, you say it out loud, you’re psyched remember? – “First column, Importance” (or priority, or appeal, or whatever is your favorite alias for customer value)

OK – now what *was* the priority of feature xyz?

Let’s see. A couple of big customers have asked about it in a recent expo, so probably high, right? Then again, it’s one of those things that make the product more complicated, so call it low. Having said that, it would really improve average sale price, which is aligned with the five year plan, so high it must be. But what about breadth? It really would only appeal to a fraction of our customers. Back to low again.

And on, and on.

Exasperated, you note that after 20 minutes you’re still on item #1 out of 37. It’s looking more and more like a long night of pizza and coke with the developers. The next thing you know, there’s a little voice inside your head that whispers: make it a medium!

Of course! How foolish you’ve been to overlook this possibility before. A medium is right in the middle between high and low. It’s the perfect answer for what seems to be neither here nor there, or both here and there. Your right index finger then makes it merry way to the m key.

But STOP – you’re just a moment away from falling into a trap as old as the hills. Why? Because there is absolutely positively no such thing as a medium, except maybe as a shirt size.

“Medium” is a shirt size, not a useful priority rating

Prioritizing something as medium is just a way chickening out of making a decision. If you don’t have enough information to make the call, go get the information, then make the call. If you’re piling up different qualities like “broad appeal”, “helps sales”, “improves margins” and “technologically strategic”, then by all means, add 4 columns, fill them out with highs and lows (or yes or no, for the more advanced practitioners who know how to make an even cleaner cut), and then rebuild the priority column as an index composed of them all.

But whatever you do, don’t just cop out. Don’t just type medium and move on to the next item, or you will end up building the wrong things for the wrong reasons.

Happy (belated) birthday to us (again)!

Add to FacebookAdd to DiggAdd to Del.icio.usAdd to StumbleuponAdd to RedditAdd to BlinklistAdd to TwitterAdd to TechnoratiAdd to FurlAdd to Newsvine

Well, just like last year, we did it again and forgot our own birthday.

It was June 1, 2007 that the first item was posted on this blog. Now, two years and 280+ posts later, life on the blog is thriving. That’s about 1 blog post every 2 1/2 days for the past 2 years!

I’ve met a number of really great people through this blog — other bloggers as well as readers. It still amazes me when I go somewhere and meet someone who recognizes my name from the blog.

Here are some highlights from the past couple of years. We wrote a several series of articles on:

How to be a Great Product Manager

Conducting Win/Loss Analysis

Discussing Social Media

  • The Lowdown on Social Media Parts 1, 2 , 3 and 4

Contrasting Product Managers with Product Management

  • Product Manager vs. Product Management Parts 1, 2, 3, 4, 5, 6

We were nominated for awards…

But we didn’t win anything 😦

A simple post on an uninterruptible power supply…

Became an important lesson for APC on the perils of social media

There was a LOT of talk about Agile/Scrum this past year

We held our first ProductCamp here in Toronto

We (macro)blogged about Twitter

We Discussed Organizational Structures

And US Politics

We oversaw a few kerfuffles

Wrote some Haiku

Parodied some songs

And had some sympathy for the Devil’s Dictionary

It’s been a good couple of years. Thanks to the ever growing audience to this blog for reading and commenting, and soon guest blogging.

Maybe next year, we’ll remember June 1 as the anniversary. Here’s to another 140 posts for the next 12 months.


Book Review: The Product Manager’s Desk Reference

There aren’t a lot of really good books available for Product Managers. That may be simply because only a few people  truly understand what Product Management is, AND have it in them to write good books about it.

There are quite a few books that try to cover specific parts of the Product Management function, such as up front analysis, pricing, product launch etc., but very few try to look at the breadth of tasks involved in Product Management and describe them at a thorough level of detail.

The Product Manager’s Desk Reference, (PMDR for short) by Steven Haines, tries to take on that daunting task.  At roughly 700 pages, this tome contains a broad array of information.

The book is divided into 6 modules each containing several chapters. The Modules are:

  1. Foundational Elements of Product Management
  2. Making the Market Your Primary Focus
  3. The Start of the Product’s Journey and the New Product Development Process
  4. Continuing the Journey: Post Launch Product Management
  5. Professionalizing Product Management
  6. The Product Manager’s Tool Box

As mentioned each of these Modules is composed of several chapters. There are 23 chapters in the book. Some of these chapters are:

  • Chapter 1 – What is Product Management?
  • Chapter 3 – Leadership: Creating Influence
  • Chapter 6 – Finance for the Product Manager: Keeping Score
  • Chapter 14 – Justifying Product Investments: The Business Case
  • Chapter 20 – Lifecycle Product Portfolio Management
  • Chapter 23 – Organizing for Product Management

There is also a good glossary and a healthy index. Both are signs of attention to detail by the author.

In Chapter 1, the author delves into defining Product Management in detail. He asks: “What is a Product Manager?

He provides 3 bullets to answer this question.

  • The product manager is the a person appointed to be a proactive product or product line “mini-CEO” or general manager
  • The product manager leads a cross-functional product team.
  • The product team’s responsibility is to optimize the product’s market position and financial returns, consistent with corporate, business unit, or division strategies.

Emphasis on the word optimize is mine. I like that word a lot because Product Management truly is an optimization function. i.e. define how to invest limited resources in an optimal manner to deliver product to market, ideally with a high level of quality that is inline with market needs and expectations and that achieves business goals. Yeah, real easy. 🙂

He later defines Product Management as follows:

Product Management is business management at the product, product line or product portfolio level.

Again, emphasis on the word business is mine. Note that there is no reference to technology, development, engineering or anything similar.

Product Management truly is a business function, and this is something that is clearly not understood or acknowledged by many in the high-tech community. Unfortunately, many within the high-tech community view Product Management as an adjunct to Development or Marketing.

For software and technology companies, one aspect of Product Management is related to technology, and gathering requirements and seeing them through the development process. But it is far from the only thing Product Management should do.

Given the book is 700 pages in length, there is a lot more that I could write about it.  Chapter 23 — Organizing for Product Management — is an interesting chapter. The author focuses a message towards “managers of Product Management and those who are responsible for evolving the Product Management organization”. i.e. management and Sr. Management in a business.

He covers cross-functional teams, Product Management objectives, how to transform an organization that doesn’t have Product Management well defined, coach Product Managers and a case study on Airline Recruiting Corporation (ARC) and their ARC Compass division.

How to best organize, structure and implement Product Management in companies is not a well understood topic. It usually just happens organically at some early stage in the company lifecycle. While far from perfect, this chapter is one of the few, if not only, texts I’ve seen trying to put some structure around this subject. There is a lot more to discuss and write on this topic, particularly as Product Management evolves, but this is a good starting point.

I only have one complaint about the book:

Module 6 — The Product Manager’s Toolbox — is simply 50 pages of templates of various documents printed in book form. While this does bulk up the book, the reader would have been better served by having actual templates downloadable from the author’s website, or some other place on the Web. I’m not a big fan of templates in general, but for the new Product Manager, they can provide some structure that may not be present otherwise. And I find it surprising that other vendors  and consultants actually charge for these kinds of tools.

Overall, it’s not light reading, but certainly much more accessible than the other commonly cited tome on the subject — The PDMA Handbook on New Product Development — which is rather academic in style and consists of a series of chapters written by at least 20 different authors.

The Product Manager’s Desk Reference delivers on it’s promise. It’s not a book that you will read cover to cover, nor is it a book that lays out a strict how-to or recipe for Product Management. It’s a comprehensive reference book that describes a broad business function that is ill-defined and ill-understood in many companies, and attempts to put some rigour and structure around it.

Will you use it every day? Not likely. But then like any other “desk reference”, you wouldn’t expect to. But when you need to better understand some aspect of Product Management, it’s likely that this book is a good first place to look.


Not a Book Review: Software Product Management

software-product-managementJust a quick shout out about a new book on software product management, aptly titled: Software Product Management, Issues and Perspectives. The book is a collection of articles by various authors, published by Icfai University Press in India.

The book consists of 22 chapters divided into three main sections:

  1. Development and Engineering
  2. The Team
  3. Sales, Marketing and Intellectual Property

The contributors consist of a mix of Indian, European and North American writers. I’ve never heard of many of them, but a few are familiar:

Yup, that last guy is me.  I feel like I’m in pretty esteemed company.  And to top it off, my article entitled Product Management Axioms (originally printed in magazine), is Chapter 1 of the book!

More info on the book can be found on the publisher’s site here.