Monthly Archives: August 2009

VP Engineering has a mandate. You need one too.

Tonight I met up for dinner with Paul Melmon, an old friend who has been around the block more than a few times. He initially gained notoriety as CIO at, and has since cycled successfully through several startups in the SF bay area, mostly as VP Engineering.

Paul shared something with me: The products are interesting, but really for him the job boils down to a few things that need to be done:

  • speed delivery
  • improve testing
  • improve the UI
  • scale the product.

Now of course a VP can’t simply show up and ask people to work harder, design better, and release with fewer bugs. Improving team performance requires a great deal of skill and experience, and a steady hand. But still, you have to like the simplicity of the mandate. Everything on the list can be measured, managed, and improved.

A Mandate for Product Management?

We need a similar mandate for Product Management. What should it be?

The list shouldn’t be long. Here’s an attempt in one sentence:

  • Align company investments with the needs of the market and the business objectives of the product line.

Unfortunately, I’m not sure how to measure, manage, or improve alignment without a LOT of hand-waving.

Go ahead, tell me what your list would look like.

- Alan

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

Note: This is the 3rd 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 3: How to Kill a Product

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

Time to Pull the Plug

The process of discontinuing a product will vary greatly by industry and company, depending on the structural makeup of the organization, the sales channels, the customers and, of course, the product itself. But there are some basic steps.

First, the product manager needs to perform the analysis described in the earlier posts. Once the decision has been made to kill a product, the product manager should provide a timeline with the following action items:

Communication plan. Work with the Marketing and Sales teams to create a plan that includes customer notification, internal communication (including FAQs), collateral updating, branding consideration. Make sure the tone and level of communication are appropriate. If the product is purely ancillary, the communications may not need to be extensive. If the product has a deep connection to the brand, for example, but is no longer performing, or is being killed for strategic reasons that may not be apparent, a more carefully considered story may need to be crafted.

Shut down marketing. Any outbound or customer acquisition efforts should cease on the prescribed date.

Sales and Finance. Work with the Finance and Sales teams to make sure sales goals are properly adjusted to account for the lost revenue. Review final billing procedures, outstanding receivables, etc., with Finance.

Provide support to Customer Support. The Support team will also need to be ready to field concerns and questions from customers, partners etc. Provide the necessary training and documents (FAQs, email response templates, talk-tracks, etc.).

Provide direction to the Technology team. If the product requires any ongoing technology, e.g. it is Web-based, make sure Technology knows when to permanently suspend functionality, and that doing so will not impact any other services. Have a plan for warehousing code and/or data, if necessary.

Make sure it’s all legal. Confirm you are within the bounds of any contracts with customers and suppliers, and that official cancellation notification is vetted or provided by the Legal team.

When working on these steps with internal teams, the product manager needs to make it clear why, at a high-level, this decision has been made. Don’t assume everyone from sales to tech knows the history of the product, or that, if they do, that they don’t have an attachment to it. A summary of the criteria that led to the decision will provide context and buy-in, which is very important since many of these people will have to do much of the dirty work of killing the product.

Product managers must make their kill recommendations by thoroughly and objectively examining the financial, organizational and strategic factors. Recommending the discontinuation of a product one manages can be a difficult prospect. But often the manager, especially a good one, will be the first to admit a product has run its course. This creates an opportunity to focus on more important, rewarding initiatives.

-  Chris Brown

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


Part 1 Why?: 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.

Part 2 When?: When is it time to kill a product? Part 2 offers up six areas to keep an eye on for telltale signs. It’s examining these areas that will help product managers build the case to kill or keep a product. should have figured out their revenue model first!

Not to sound like a broken record, but here’s a great example of what I was talking about in my recent post entitled “5 benefits in thinking about revenue models right from the start“.

A couple of weeks ago, Nambu, the parent company of the URL shortening service, announced that they will be shutting the service down. You should read their entire post because it is very well written and makes some very good points that should serve as lessons to virtually any aspiring business out there.

trim-ripI’ve also captured a jpeg image of the page in case they take down the original. Click the image on the right to read the entire text.

Here’s a synopsis of that post.

  • is being shut down.
  • It is good at what it does and is a popular service, but that is not sufficient.
  •’s costs are real, both in terms of development effort and operational costs.
  • Those costs need to be recouped.
  • But there is no way to monetize URL shortening and the quest to find an acquirer failed. [SK - probably because there is no way to monetize it].
  • Users will not pay for URL shortening. [SK - URL shortening is a commodity; a cheap one at that.]
  • The data that collects – what URLs people are shortening and clicking on – is of little value to outsiders because “everyone has that data” as it is harvested by bots. [SK - the collected data is also a commodity.]
  • An 800lb gorilla named Twitter has anointed a competitor ( as the URL shortener of choice. [SK - if your success is dependent on a single larger entity, be the clown fish to their anemone!]
  • This effectively blocks growth prospects for (and by inference, other competitors to

I use I like it. It’s simple to use and gives me some good analytic data about click-throughs on shortened URLs I post around the web.

But I always wondered how they made money. For as long as I’ve used the web, was the only URL shortener that I knew. Then with Twitter, others jumped in, providing extra services, like accounts, click-through stats and simple analytics. Here’s a chart of monthly visitor statistics.tinyurl-bitly-trim

Clearly, it was a losing battle for in terms of traffic. Even the venerable tinyurl, long the king of URL shortening is falling in traffic, with continuing to climb.

So the question is: how will cover it’s costs? The server and operational costs  must be significantly more than that of

How is (or will) generate revenue? Can they sell their data? If so, to whom?

Does anyone have any insight into how does or will create a sustainable revenue stream? And what has Tinyurl been doing all these years to pay it’s bills? I’m genuinely curious.


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

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

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: To Kill a Product: Why, When and How, Part 1/3

Note: This is the 1st 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.

To Kill a Product, part 1: Why?

It’s there somewhere, in the quarterly business review, a line item that shows a couple dozen customers, down from a year ago, which was down from the year before. It brings in a little revenue, probably less than a percentage point of total, but revenue being revenue, why not keep cashing the checks?

“It,” of course, is the Product That Wouldn’t Die, its longevity no longer due to any real practical purpose but to management’s reluctance to pull the plug. But pull the plug they should. Even if costs are negligible (and sometimes they’re not), ineffective products divert focus and resources from core and growth products, and ultimately dilute the overall value proposition of the business.

The role of the product manager includes performing the kill analysis – thoughtful, thorough and completely unbiased – and, if necessary, making a recommendation that is best for the business.

Why the hard decision might be the right decision

Why should an organization kill a product, particularly if it generates even a small amount of incremental revenue? The first reason should be obvious: The product isn’t profitable. But products that are clearly bleeding money are not what we’re really discussing here. The harder decisions have to be made for products that have some revenue, some customers, have low or justifiable costs, but no long-term plan, prospects or strategic relevance.

Here are some examples of how a moribund product can have a draining, distracting effect on an organization and its customers:

On the Product team: Product managers and analysts are required to field customer feedback, analyze market data and track KPIs for a product that most likely represents a tiny fraction of the company’s business, and takes focus off of supporting the profitable products and, more importantly, new product discovery and innovation. While the beleaguered product manager is trying to keep a past-its-prime product on life support, her competition is dreaming up the “next big thing.”

On Sales and Marketing: The sales team needs to be trained on a product that very few customers actually use. Often dying products are more complicated than they’re worth (hence, why they’re in decline) and therefore can require a disproportionate amount of time and knowledge to effectively sell and support. Marketing, in addition, needs to account for these products in their collateral and messaging, adding not only to expense, but to the clutter they’re continually tasked to cut through.

On Customer Support: The best customer support teams are fluent in all the products in your company’s portfolio, even those with a small number of customers. But customers of troubled products can often fill up a Customer Support’s team queue, generating a disproportionate number of phone and email support tickets. Meanwhile, customers of more profitable products are left on hold or waiting for their email response.

On Technology: Not only can there be hard technology costs associated with supporting a product, such as server and bandwidth expenses, but also the time required to maintain both internal and external (e.g. customer-facing) processes. After all, if a product breaks, even one with relatively few customers, someone has to fix it.

On customers: With customers there’s a risk that the poorly performing product becomes a customer’s focal point, and that its performance, presumably poor, will be used as ammunition in contract negotiations or, worse, as a proxy for all the company’s products. This can present considerable sales challenges and erode the company’s reputation.

All of these distractions have associated costs, which can be harder – though not impossible – to quantify. If a kill decision is particularly contentious, it may be necessary to put a dollar amount on these costs, which can be calculated by multiplying the number of hours spent supporting the product by the estimated hourly salary of the individuals doing the supporting.

The most important reason why ineffective products need to be killed, though, is because they dilute the company’s overall value proposition. If you can measure the total value your products deliver (and you should), perennially poor performing products will naturally drag down the sum of that equation. And with that downward pressure on value come declines in employee morale, confidence in senior management, and customer loyalty. No one wants to manage a dying product. No one wants to sell, support or, certainly, buy a dying product, either. To preserve its overall value, focus resources on core initiatives and customers, and maintain a vibrant workplace, a company should be willing and able to quickly put underperforming products to pasture.

-  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 in this series:

Part 2: When is it time to kill a product?
Part 2 offers up six areas to keep an eye on for telltale signs. It’s examining these areas that will help product managers build the case to kill or keep a product.

Part 3: 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.

Tweet wars: The limits of debate in 140 chars. or less

Over the last day or so there has been quite a little debate about the importance of Domain Knowledge and Product Management Skills in #prodmgmt (most of you will recognize that as the twitter tag for the Product Management topic, folks. If not, tune in!).

While the discussion itself was interesting, I found myself thinking about the medium as much as the message. How can we have meaningful dialog in 140 characters exchanges? We ended up debating in titles and, I think, really missing each others’ points. Any good dialog requires us to walk down something called the ladder of inference. At the top of the ladder is your position and my position. As we walk down the ladder, we meet at the level of positions, conclusions, and actions.

In a good dialog, we offer to walk down the ladder with each other. We examine assumptions, and affixed meaning, and selected data. If we are really lucky, we can take one more step down the

Example use of ladder of inference

Example use of ladder of inference

ladder and look at real world data. (Immanuel Kant argued that real world data can never truly be known, for the viewer always interprets.)

But here’s my problem: In twitter, we are all tweeting at the top of the ladder. There is no real ability to walk down the ladder together. Twitter constrains expression so tightly that real dialog is impossible.

I am a Twitter fan for many things. But not for debate, discussion, or dialog. Give me an ale house any day.

- Alan

PS: to my fellow debaters: I am not nearly as rigid on this topic as my tweets may suggest. I suspect that if we got in the same room, we’d find a lot of common ground. As an example of where PM Skills trump Domain Knowledge, I would hate to hire an IT practitioner who could do IT Systems Management, but not teach the organization to build and sell a product in the field. In my view however it is too easy to say “a good analyst can learn any domain”. I liked Peter Hanschke’s comment that certain broad domains are important. For example, I wouldn’t hire a great B2B PM to run a B2C product.

What was Twitter’s Biz Stone smoking?

A couple of months ago, Twitter co-founder Biz Stone appeared on The Colbert Report. Watch the interview below and then continue reading the blog post. Pay close attention during the latter part of the segment as Stone describes Twitter’s plans for revenue generation.

[NOTE: If you don't see the video in your browser, wait a few extra seconds for it to load, refresh the browser window or view the original here, or if you live in Canada, view it here]

If you were impatient and couldn’t watch the whole thing, here’s a recap of the key parts, starting at about 2:55 into the video:

Stone: Twitter provides a new way of messaging. It’s really the messaging service we didn’t know we needed until we had it. You send out 140 character bursts of information to anyone who wants to receive it; they receive it in real time and that’s when some of the magic happens.

Colbert: [looking perplexed] It’s the what? It’s the what?

Stone: [matter of factly] The messaging system we didn’t know we needed until we had it.

Colbert: [astutely] That sounds like the answer to a problem we didn’t have until I invented the answer. [audience laughs loudly]

Analysis part 1

I do agree with Stone on his first sentence. Twitter does provide a new way of messaging. I wrote about it previously in Twitter: The Napster of Messaging. But after that, Stone starts speaking mumbo jumbo.

The “service we didn’t know we needed” line makes little sense. Thankfully Colbert quickly calls Stone on it almost immediately.

Later, starting around 4:30 into the video, the following exchange happens:

Colbert: Does Twitter charge anything?

Stone: It’s totally free.

Colbert: So I assume that “Biz” in Biz Stone doesn’t stand for “business model”?

Stone: [somewhat sheepishly] No. No it doesn’t.

Analysis part 2

This in my opinion was the best exchange of the interview. Colbert intentionally asks a question to which he knows the answer, only to follow up with a real zinger; an easy target, but quite effective. This does set up the context for further questions a few moments later.

The interview later continues:

Colbert: How would you make money? Are you going to make money off of this? How?

Stone: Yes we are. We are going to become a strong, profitable, independent company. We are going to continue to stay based in San Francisco.

Colbert: You and  [audience laughs. Stone looks annoyed.]

Stone: We are recognizing a difference right now between profit and value. We are building value right now.

Colbert: Wait. What’s the difference between profit and value?

Stone: Well right now we are building on value. That means extending the service worldwide, globally, so that more people have access to the real-time network. And not just on the internet. There are over 4 billion mobile phones and when we network them together it is very transformative especially when you realize it works over both texting and the web.  As we grow that network it becomes more valuable; as we add features to it, as we make it more robust. When we get to a certain point where we feel we’ve gotten there, we’ll begin experimenting with revenue models. This is not unlike how Google approached their revenue.

Analysis part 3

This last exchange is where I think Stone goes right off the rails. His line about “value” and “revenue” is utter rubbish.

Extending the service – taking it global etc. — has nothing to do with value. That’s called “extending the service”. Value is not added with new features and capabilities. To quote Warren Buffet:

Price is what you pay. Value is what you get.

Value is delivered or derived, not added through code and new functionality. Newsflash Stone! Millions of people are getting value today out of Twitter. Even with the frequent appearances of the Fail Whale, people continue to use the service.

And what’s this about Twitter networking the world’s 4 billion mobile phones together and being “transformative”. That’s just more mumbo jumbo.  I guess with 45 or 50 million users of Twitter today, that’s just not enough to figure out how to generate some revenue?

Finally, what’s with the line “When we get to a certain point that we feel we’ve gotten there…” Huh???? Biz, could you just be a little more specific? And, hey VCs who’ve invested MILLIONS into Twitter….is this what passes for intelligent business speak from the founder of one of your portfolio companies?

But the interview continues:

Colbert: How long out is that?

Stone: How long is what?

Colbert: Before you experiment with revenue.

Stone: We’re going to start experimenting this year. But we don’t have to hit a home run right away. We have patient investors. We have time to work it out. We’re going to be exploring and experimenting starting this year and we have time to figure out what the perfect revenue model is.

Analysis Part 4

Hold on a minute. Almost immediately after saying “When we get to a certain point that we feel we are there…“, Stone indicates that “this year” is when that certain point will be reached that they will feel they are there. Wow. So why didn’t he say that in the first place?

So in summary what is Twitter?

It’s a free service that solved a problem people didn’t know they had. They’ve raised tens of millions of dollars in VC money, and the company’s goal is to be a strong, profitable, independent software company based in San Francisco. They’re currently in a phase of value building but later this year they will start “exploring and experimenting” with revenue models, but there is no urgency to find great model because they have patient investors.

For those you reading this, I’d love to hear your thoughts. Personally, I find the whole interview rather amusing; and not in the typical Colbert way. Stone seems like a nice guy, but his comments in the interview truly leave me suspicious about Twitter ever generating sustainable revenue, and also leave me wondering, what he was smoking when he went on the show?

But maybe I’m wrong. What do you think?


ProductCamp Austin was our Woodstock. Can we morph from Folkfest to Rock Spectacle?

Warning: References to the musical world are purely imaginary and will likely dumbfound most readers. I hope the rest of you enjoy the links.

On the weekend of the 40th anniversary of Woodstock, Product Camp Austin 09 became the first rock concert for product types. The Dead was there to teach us about Twitter (and how to get by with a little help from your followers … free replay here). Joe Cocker showed up to give the kick ass talk about social media that The Beatles should have done on the album. His talk went viral and was replayed around the world! The Stones didn’t show up, and The Beatles only sent George Harrison, though he impressed the crowd with some solo material and garnered artist of the day. There were some really cool new faces, for me at least. I heard that Janis Joplin’s set was awesome, but I missed it. She’s performing it again in a week or two. A fairly new group on the scene, Credence Clearwater Revival, was clearly on fire, garnering a top spot in the schedule and an excited and interactive audience.  (Full disclosure: in this analogy, I am John Fogherty. Not looking forward to having my content embargoed by Warner. I just hope I can perform my own material 10 years from now.)

Three weeks ago, the inaugural Product Camp NYC was extremely well run, and still had the smallish feeling of a folkfest that people associate with an unconference barcamp. Even with smaller numbers (150 – very respectable), the artists were top drawer. Simon and Garfunkel were still together, and James Taylor, did a decidedly quaint but inspiring version of Long ago and Far Away. (That last link was real.  Definitely quaint, but worth a listen.)

With this third Austin event, Product Camps have officially entered the category of rock concert. I say Rock Spectacle, because it’s not a single band event … it’s become Woodstock.

But can the Product Camp (barcamp) format and withstand the transition into a mainstream event?

My belief is that this format is the new main event. But there will also continue to be innovative smaller gatherings, and probably also more regular microevents. Product Camps will continue to grow, retain their self-selecting, vote-with-your-feet philosophy, and new innovators will find ways to create segmented, microsegmented, and serialized events.

Hop on the bus, Gus

I am hoping participants of any Product Camps and the organizers of past and future camps will weigh in here and debate this issue.

No more Woodstock jokes. My hat is off to the organizers, Volunteers, and sponsors of Product Camp Austin.

Paul Young was the chef du jour, with the rest of the organizing team consisting of Bertrand Hazard, Roger Cauvin, Colleen Heubaum, Vicki Flaugher, Elizabeth Quintanilla. There were also many many volunteers. If anyone from the team can post a list or some names, please do so below.

Back to the main question(s):

  • Can the Product Camp format withstand the transition from Folk Fest to Rock Spectacle?
  • What needs to change? What needs to stay the same?
  • What innovative new things are emerging will make barcamp look old? Where are the new folk festivals?

- Alan

Guest Post: There’s no such thing as MEDIUM

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.