Cook 'em Dan-O

Product Management in Times of Change

Here's a presentation I made to the Silicon Valley Product Management Association a while back, talking about some of the challenges in managing a product/service when the environment is changing under your feet.  The specifics may or may not be of interest, but the principles remain valuable... especially since most technology-based companies by definition operate in times of change.

Enjoy, and let me know what you think!

Download Product Management in Turbulent Times

Getting to No

 Department of Obscure References

Bad Cop

Here’s a conversation I’ve had many times, as a Product Management type talking  with an enterprise salesperson…

“I need an answer on that feature request for customer x.”

“I don’t have an answer yet, I’m still working on the business justification and design estimate.”

“I need an answer now!”

“OK, the answer is no.”

“I need another answer”

“OK, hell no!”

Managing the Feature Request Queue

For whatever reason (and there have been many reasons put forward) feature requests are a fact of life for Product Managers, especially those serving enterprise customers.  And as often as not, the focus of the “we need to manage our feature requests better” conversation tends to be on more efficient methods of capturing these requests and reporting on their disposition... Because what you don't know will come back to bite you. I had a country manager for New Zealand literally show up unannounced at our office one day, asking where his feature request of who knows how many years ago was.  I wanted to tell him that I knew sales representatives with bigger quotas than his projected market revenues, but I bit my tongue.

There are times when the right decision is to flush the queue entirely; Marty Cagan has written on this topic.  But sooner or later you're going to have to manage a list of feature requests, so let me share a way I found to do that.

Welcome to iPass.  Now where's my feature?!

When I joined iPass as their Director of Product Management, one of my marching orders was to make the feature request process more transparent.  Salespeople complained that the requests went into a “black hole”, never to be seen again.  The Product Marketing group had attempted to provide an interface to Sales, with the intention of doing the market justification legwork for requests before handing them over to Product Management for implementation.  The problem was, Product Marketing didn’t have the resources to do any market justifications; they were busy enough just managing product launch and sales support activities.  To compound matters, there was no throttle on submitting a feature request—anyone could do it, and at least a few sales engineers thought that submitting a feature request was in and of itself justification for implementing it.

Once I set about creating a feature request management process, my first step was to turn over all the rocks and see how many requests were out there.  It turned out that every Product Manager had their own list, managed in their own unique way.  When I pulled all the lists together, and canvassed the field with a “speak now or forever hold your peace” request for discovery of any other requests, I ended up with a pile of some 400 items.  Sigh.

The Right Tool for the Job

So, with a healthy dose of skepticism about whether all these feature requests needed to be done, I started on the task of how to at least manage the queue in a more efficient and transparent way.  First stop:  the in-house database experts.

iPass made heavy use of the Remedy software for managing trouble tickets in its Customer Care group.  Since part of what I needed was a workflow tool to manage the request process, I went to the Remedy people for help.

Within fairly short order I had a system that could capture feature requirements, track their progress through a series of decision steps I had defined, and report on how the request queue was being managed.  The system gave me the ammunition I needed to bet money at a company sales meeting that all feature requests would be responded to within three days of submission—not that they would be done, but simply that they would be approved, denied, or (in the majority of cases) in need of more information to develop a justification.  Problem solved, right? Not exactly.

I Need Another Answer

The stated problem was that Sales didn’t know where their feature requests stood.  Of course, what Sales really wanted to know was that the requests were going to be done, and when they could be expected (and promised to the customer or prospect).  So the “where are they” question was resolved, but now the latent issue—business justification—came to the fore.

As it happened, iPass was in the midst of changing its sales force automation system, to salesforce.com.   Since the Remedy solution couldn’t easily be extended to capture business justification data for these feature requests, I decided to recast the solution using salesforce.com.  Fortunately, the same person that designed the Remedy solution was able to recreate the solution on salesforce.com.  Now I had a system that automatically tied feature requests to sales opportunities.  This turned out to be a huge step forward.

Any experienced Product Manager has their stories about feature requests that were tied to some Big Opportunity, which somehow never materialized after the product work was delivered.  Or they can tell you about feature requests that were justified as “strategic”, as in, “well, if we don’t do such and such, we’ll never break into this account”.  In poker terms, this has the feel of going “all-in” before the flop. Tying feature requests to described sales opportunities was like seeing your poker hand before you had to bet on the flop... Was even a small bet to see more cards worth it? Was the opportunity ever going to justify the likely investment needed to capture it? (And by the way, was a product change the only factor in determining who won the business?)

Getting to Yes

Now I had the ability to see for myself what size of opportunity would be leveraged by a feature request.  I didn’t have to ask, because the opportunity was already in the system.  And since Sales had set up metrics for defining the probability of closing an opportunity within a given time, I didn’t have to account for one salesperson's “80% certain to close the deal” estimate compared to another’s estimate.  Further, if the opportunity wasn’t in the system, I could kick out the feature request, or at least park it until the opportunity was there.

This solution was a great success.   It provided transparency into how the feature requests were being handled.  It enabled reporting on the revenues or cost savings tied to feature request implementations (the system was later extended to manage professional services projects).  It (when tied to another system I adapted for project delivery tracking) gave salespeople visibility into when feature requests would become available to customers or the general market.  Perhaps most importantly, it greatly reduced the incoming rate of feature requests.  Instead of making Product Management into the Bad Cop that always said “no”, it made everyone aware of the need to tie these requests to the needs of the business.  Everyone involved in the product-sales interface better understood the costs and benefits of feature requests, and lots of people said “no” before I ever had to do so.

So if you find yourself with a pile of feature requests, get a tool like the one I described, and use it to be smart about getting to a “yes”—or “no”—for each one.

Break on Through

Place Your Bets

I've met with a number of companies recently, as I seek to pitch my career tent in a new campground, and have noticed one common theme.  These companies are looking for ways to break away from their competitors, especially as economic conditions improve and (as it were) the tide begins to rise for all boats.

And the news media, eager to report on any good news, has noted the uptick in mergers and acquisitions as one vehicle for growth.  So you have Dell and Perot Systems, Adobe and Omniture, Oracle and whoever's in their sights now that's not named salesforce.com.

But the companies I've spoken with are focused on the more common route to growth:  innovation arising from R&D investments.  So I was interested to read an article in the latest issue of MIT Sloan Management Review that touted a tool (always a key word for MIT folks) for measuring (ditto) and thus managing R&D effectiveness.  The author, Alexander Kandybin, has labeled this tool "ROI²"--Return on Innovation Investment.  [Here is where I normally make some snarky remark about consultants (Kandybin is with Booz & Co.) and their penchant to rename and reposition ideas, but as I have nothing witty to offer, I'll leave that to the reader, as an exercise (my favorite phrase from my Calculus book, but I digress).]

Kandybin advocates building an "innovation effectiveness curve", in which "[we] plot annual spending on innovation projects against the financial returns from those projects, measured as a projected internal rate of return."

From here, managers can quickly see which (handful) of projects are the "stars", which are losers (at the tail of the distribution) and which live in the grand middle of good ideas that generate decent but not spectacular returns.

So far, so good.  And this is exactly the kind of tool I had been looking for as a fresh-faced graduate from MIT Sloan, eager to put my knowledge to work.  So how does the idea stack up in the real world?

Imagine If You Will

First, recognize the "simplifying assumption" here.  In order to calculate an internal rate of return (IRR), you have to estimate revenues attributable to the investment over the lifetime of the resulting innovation.  So the first requirement is that you actually think about how much the innovation is going to make (top line) or save (bottom line) for the company.  Some companies are more disciplined about doing this than others.  Developing these revenue estimates was a part of developing a "Commercial Specification" (think forecast plus product requirements) when I was at Nortel.  At other, typically smaller, companies we didn't take this step.

Second, this calculation or estimation of an IRR is a projection--you haven't made the money yet.  So your IRR for the project is subject to whatever estimation errors you might make.  If you're working in an industry with stable competitive and market forces, you might look to the measured returns of similar projects to better estimate an IRR for this project.  The problem for me is that I've never worked in such a stable industry, so looking to the past is of limited use in predicting the future.

Another challenge with coming up with an estimated IRR is that it's subject to being "gamed".  Once you know "big IRR is better than small IRR" there's a temptation to fit the estimate to the desired result.  Nortel had a fairly rigorous R&D allocation process, that tried to match "top down" views about how much aggregate investment should be made in each line of business with "bottom up" views about what revenues and/or cost savings could be "rolled up" from individual R&D projects.  These "bottom up" views were typically discounted, given that the returns across all proposed projects were on the order of 10X the estimated returns for the business unit.

Making ROI² "Fit for Purpose"

These considerations don't make the ROI² tool bad.  It just has to be adapted so as to be (in the words of my former boss, Joel Wachtler) "fit for purpose".  Here are some examples.

• Track the revenues, even if it's in the aggregate vs. attributable to individual projects.  When I ran Nortel's ISDN & Networking Group, I had the Finance people put together reporting on revenues arising from my group's hardware and software.  I might not have known how an individual project paid out, but I knew what the total R&D spend delivered in terms of hard cash.
• Track the opportunities leveraged.  Sometimes you have to deliver a feature or enhancement to close a deal.  Follow up and make sure you got the business.  At iPass, I had a slew of feature enhancements that had to be delivered to steal a marquee customer from a competitor.  You can be sure I followed up to make sure they signed, and kept track of how much revenue they were generating.
• Look for a small bet that will prove the case.  At one of our iPass partner meetings, someone suggested a utility that could live on a user's laptop, and tell them the location of the nearest iPass Wi-Fi hotspot.  The idea had been tabled with the CFO, but was held up for want of a business justification.  I suggested we commit a quarter's worth of R&D and licensing costs to set up and distribute the utility, and see what happened with Wi-Fi usage.  The revenue benefits were obvious, and the "hotspot finder" became a huge hit.
• Look for "traceability" of R&D efforts.  You can usually understand what part of the product, service, or system the R&D effort is touching.  So you can ask, "if this part is improved, what's likely to happen?"  Creating standard pricing and contract vehicles for one service at CGNet meant that we could turn proposals around in two hours, instead of two days.
• Verify that your R&D projects aren't driven by the need to keep a group of R&D folks busy.  Marty Cagan, of the Silicon Valley Product Group, has written about this in his Feed the Beast.  One way to get at this is to ask yourself: "if I was starting this company over, would I hire an R&D staff with this mix of skillsets?".  Maybe you once had a need for a large hardware engineering team; is that still the case?  

Maybe you're in a situation where the ROI² tool would work.  If so, that's fantastic.  If not, you can still adapt the idea of evaluating projects according to their projected contribution to make sure that you're not filling the R&D pipe with "polishing the doorknob" types of projects.  Some of these ideas may help you adapt such a rigorous evaluation method to the messy realities of your innovation circumstances.

How Not to Treat Your Customers (a continuing series)

So my wife, Crystal, is on the phone with Dish Network, supplier of our Daily Bread:  football, reality television, Chris Cox horsemanship, the Food Network.  And she's reviewing our bill, looking for ways to save a few bucks each month.

Turns out, there's a five dollar charge on the bill, levied by our service provider, because we don't have our DIsh Network receiver hooked up to our phone line.  Never mind that there's no phone jack near the receiver.  Never mind that we nearly got rid of our phone line anyway.  Not Dish's problem.

Why do we need to plug our receiver into the phone line? So that we can order pay-per-view programming.  We never order such programming, but that apparently does not matter.  What matters is that we are preventing Dish Network from selling us their extra-cost programming.  And for that privilege, we pay.  Five bucks a month.

I remember the guys that would show up at our front door in the summer, saying they'd painted our house number on the curb and asking us for money.  We told them to go away.  They could learn something from Dish Network:  "Hey, I'm here to paint your house number on the curb.  Or for five bucks, I'll go away." 

What a business model!

You Built It... Now, Will They Sell It?

You Could Sell It... But That's Someone Else's Job

I wrote recently about the need to look at your product or service as if you were actually the one selling it... Could you answer the "why should I buy this?" question.  Here's a related consideration, one that I've learned (the hard way) over the years:  will your salespeople sell your product?

"That's absurd!" you say.  "Of course they'll sell it.  They want to make money, don't they?"  Yes, they want to make money.  But it's not that simple, as I will show...

Show Me the Money

My first Product Management assignment, at Nortel Networks, was to bring a simple printer-sharing software program to market.  My boss thought it should take a couple of weeks to complete.  (It took several months, and a tour through most of Dante's seven stages of hell, but that's another story for another day.)  I worked hard to bring "EasyLAN with Meridian Extension" (the name kind of makes you fell all warm and fuzzy, doesn't it) to market... and sold perhaps a few dozen copies.

What happened?  Probably the biggest reason for "tissue rejection" by our sales force was the commission disparity.  This software sold for maybe $50 a seat (remember those days?!).  The problem was, it was being sold by a direct sales force that was used to making communication system sales in the tens if not hundreds of thousands of dollars apiece.  A salesperson could scratch their nose thinking about selling my little piece of software, and eat up all their commission in the time it took to do so.  Later, as we moved to a two-tier distribution model, the problem only got worse.  Now, that nose-scratch had to be shared between the channel account manager and the channel salesperson... clearly the wrong kind of product for a two-tiered distribution system.

If I were bringing such a product to market today, I'd be thinking about selling this via some sort of "application store", where the user pays for the software, downloads it and uses it.  But such "stores" didn't exist at the time, and the product would have required other work to greatly simplify its installation and troubleshooting by a non-technical end-user.

The lesson here? Ask yourself a basic question:  "If I'm a sales rep, why is it worth my time to sell this product?"  If you can't answer this question quickly and directly... you likely have a problem.  Salespeople are a lot more like independent contractors than other company employees.  They often have a wide degree of latitude about how they spend their time.  While they may be measured on a number of criteria, making (and exceeding) their sales quota typically counts much more heavily than anything else.  So if your best answer to the "what's in it for me in selling your product" question has more to do with corporate loyalty than personal financial gain, be prepared for disappointing sales results.

How Can You Tell a Pioneer?

One of the challenges I faced at iPass was getting the sales team to sell Wi-Fi as an access method for connecting on-the-road employees to their corporate networks.  This was a critical problem, as it was clear that people were moving away from dial-up connections to Wi-Fi and other broadband methods.  

Things came to a head with a meeting of all the sales leaders and the product group.  Imagine an angry mob, pitchforks, and people constructing a bonfire and you have a pretty accurate impression of how the meeting was going.  The sales team had gathered a long list of all the ways that our implementation of Wi-Fi support was lacking.  They felt they couldn't sell the product as it existed, and they wanted a commitment to fix the problems they had highlighted.  I was able to agree to implement a plan, with regular reviews, before the bonfire was lit, and went to work addressing their issues.

The funny thing was, after about six to nine months, sales leaders stopped participating in the reviews.  We product folks (being good soldiers) continued to carry out the resolution plan, but clearly the issue had died in the minds of most salespeople.  What happened?

If this were a job interview, I'd emphasize how I had listened to the sales team's needs, addressed their concerns, communicated the results, and kept a dialog going to continuously improve.  And I did all that.  But something else happened, of equal importance:  customers got used to the idea of using Wi-Fi.  The technology had gone from something new and scary to IT Managers, to something that they couldn't live without.  As one of our sales leaders said, "once you use it, you won't go back to dial".  So for instance, where originally one of the complaints was that we needed to provide better tools for tracking and managing per-minute access costs, within months customers were telling us they didn't need such tools and preferred instead to have "all you can eat" subscription plans.

The lesson here? Don't expect your salespeople to be pioneers.  If you're rolling out a service early in the adoption cycle, pay attention to the supporting tools needed to get people comfortable with the technology.  

Are You in the Zone?

Not long after we got Wi-Fi rolling, the issue of worms and viruses on laptops and other devices became a hot topic.  IT Managers began to realize that their networks weren't protected until every device--local and remote--that accessed their networks was protected.  iPass had been working with a couple of companies to bring out a service that provided protection for devices "in the wild", so the timing seemed fortuitous.  We put together the service, rolled it out... and things stalled.

Our salespeople had some early, bad experiences going in and selling the service, which we called "Device Management". This left the balance of the sales force reluctant to touch the service.  These early "pioneers" in selling Device Management ran into a couple of problems:

• They were selling to a different set of decision-makers.  Whereas our sales force was used to dealing with networking and telecommunications people, device security was the domain of Chief Security Officers and other security types.
• Most salespeople lacked a depth of knowledge about security.  They understood Device Management and its value statement, but when challenged about their knowledge of other security topics, they could not respond with authority, and lost credibility as a result.

From a product and strategy standpoint, we thought we had hit a home run:  we had redefined out space from the un-sexy "remote access" to "mobility management".  But our sales team had trouble making this leap, and had trouble getting comfortable with the idea of selling Device Management.  The vision sounded great, but selling the reality proved much more difficult.

The lesson here? Be aware of your sales team's "comfort zone".  If you're going to put out a service that pushes the edges of your team's comfort zone, be prepared for some resistance, and plan on providing the training, tools and support needed to help them expand that zone.

Can Your Sales Team Execute on Your Product?

If you follow (American) football, you know about the Hook and Lateral, Statue of Liberty and other such "gadget" plays.  You also know that running off-tackle is much more common.  So it is with your products.  It's easy to get enamored with the ground-breaking technology you've introduced, the innovative positioning, the redefinition of the product category.  But if your sales team can't execute--can't sell--than all that innovation and cleverness won't benefit you or the company.  Make sure you reality-test your product with your customers.  Make sure your sales teams feel like they can succeed selling your product.  Do these things and you'll be much happier with your sales results.

You Built It. Now, Can You Sell It?

Can You Think Like a Salesperson?

It's a hazard of the job as a Product Manager, to develop a rather myopic view of your product or service.  If you've done some work on product discovery, or otherwise put some effort into validating the usefulness of what you're building, it's easy to think that all that remains is to get the thing designed, built, and into the market... Sort of a "Field of Dreams" approach.

Not so fast, bucko.  Are you overlooking one of your Marketing "P's"?  You know, "Placement", the one that's a "P" because nobody would remember "The Three P's and One D of Marketing"?  Ah yes, placement.  Also known as "distribution", meaning how do I get these widgets out of the factory and into paying customers' hands?  As I've worked in and around salespeople, in both direct selling and channel sales structures, I've learned a lot about what sales folks need in order to be successful selling your product.  Hint:  they need more than a great product.

So put on your fedora, grab your briefcase and appointment book, and join me in living in our salespeople's shoes for a day.  If you're lucky enough to have had a sales job, stop reading and send me a note to tell me how much I've gotten right and how much more I have to learn.  If the last thing you sold was lemonade or World's Finest Chocolate Bars, you'd better keep reading.

"Ms. Prospect Will See You Now"

So here you sit, across the table from your prospect, the one you hope is going to buy your gizmo.  As with other structured social interactions (think speed dating and job interviews, inter alia), you've got roughly four minutes to make your pitch.  Here's what you need to cover:

• What is it?
• What problem does it solve? 
• For whom does it solve this problem? 
• What will it do for me? 

  Let's take each of these questions in turn.

What Is It?

As a former (and future?) California governor once said, sometimes "less is more".  What's needed here is a simple, declarative statement about your service.  When people asked me what iPass did, my reply was "we provide enterprises and their employees a way to connect to the Internet and their corporate networks in a simple, secure, and cost-effective manner".  If you have to pause for a second breath in answering the "what is it" question, you're going too deep.  If you have to pull out a stack of PowerPoint slides, you're not sufficiently focused in on summarizing your product.

There's a reason why this question is so important.  Your prospect is trying to establish a point of reference for your service.  "I'm selling dreams" doesn't tell him/her what to compare it to.  "I'm selling real estate investment trusts" provides a point of reference--other real estate investment vehicles.  Some people fear that providing this point of reference will weaken their product pitch:  "it's like eBay, only better!".  I can see the point, but I think it's more important to give your prospect a way to think about your service, rather than claim that "it's totally revolutionary."

What Problem Does It Solve?

Now we're getting closer to the infamous "value proposition"... but hold your horses!  Your prospect isn't inviting you to launch into a presentation on how your product solves the issues of the day--not yet.  He or she is trying to figure out if this product solves a problem he or she actually has.  Why? Because your prospect gets called on all the time by people claiming to have the latest thing to revolutionize your prospect's life.  He or she needs to sift through the crap to get to the products that might actually deliver on that promise.  If you're solving a problem I have, I'll listen.  If not, I'll toss you out or politely wait until the salesperson offers to buy me lunch.

As with your "what is it" response, you want to be crisp in stating the problem to be solved.  "We take the pain out of managing your remote and mobile devices."  If you and your sales partner have done your homework, you already know that this a problem your prospect faces.  So now you've got them leaning forward:  "tell me more".

For Whom Does It Solve This Problem?

If your prospect has in fact leaned forward and started salivating (and lunch hasn't been served) then you've already made it past this question.  If not, be prepared to answer.  The heart of the question is this:  "is this a problem I have to worry about?"  If I'm selling salesforce.com's online sales automation service, I'm telling a sales representative that it solves the problem of keeping track of sales and commissions--that's what they care about.  If I'm selling the same service to the IT manager, I'm talking about the problem of bringing up and maintaining a salesforce automation tool.

What Will It Do For Me?

This is the famous "WIFM", or "What's In it For Me" approach.  Here's where as Product Champion you get to wax eloquent about how great the product is, how it's going to make your prospect's life so much better.  This is also where a lot of product pitches founder--because they focus on product attributes ("dual core processors") without relating them to the "so what" of WIFM.  So it's especially important to stay away from a long recitation of the features and benefits of the product, and all the improvements from the last version.  Everything is focused on showing the prospect that your product solves an important problem for him or her.

Finally...

If you're thinking like a salesperson, these questions are never far from your mind.  And as you're shaping your service, you're continually testing to see if you have clear and compelling answers.  So far, so good.  But even you know that products don't "sell themselves"--people do.  Next I'll focus on what those people who do the selling need in order to love your product as much as you do.

Managing to a Successful Shot

I learned a while ago that knowing how to do something isn't the same as knowing how to teach someone to do that thing.  How many times have you seen an athlete struggle to explain a skill to someone else?  Shooting a basketball seems like a simple act until you try to explain it to someone.

I'm often reminded of this truth when I work with others to get things done.  Despite the fact that I'm working with talented people, it's not enough to say "do this" and expect to get the result I want.  I can say, "show me the value proposition for this product" and have a clear picture of what kind of information I should receive.  But the person receiving this request may not have such a clear picture, or perhaps has an equally clear--but distinctly different--picture.  So the "value proposition" comes back to me, and it's not what I had in mind.  Doh!

Here's one example from a recent sales training call.  I had asked one of my managers to pull together training materials for our sales team on a new product.  It needed to answer questions such as:

• what is it?
• what are the components that make up the product?
• how do the components fit together?
• how do I configure it?
• how do I order it?

I had pulled together  a presentation that attempted to show in simple pictures how the system came together, but the manager had other ideas, preferring to put together a Word document that described the system one part at a time.  As we were on the call the sales team started asking for a picture, saying they didn't have a good idea of how the whole system came together and where the decisions were needed that determined specific configurations of the product.  

Fortunately, this was just the first sales training call, so we were able to supply the presentation later and address the sales team's needs.  And the component-by-component view was still useful.  It was just easier to digest once people had a picture of how the entire product came together.

This situation reinforced the old saying, "you can't expect what you don't inspect".  If you're asking for a particular outcome, be sure the person understands what constitutes achievement of that outcome.  And use the opportunity to "inspect" the results to create a learning situation.  Had we reviewed the sales training materials before our call, the manager and I could have identified the need for a big-picture document to go with the detailed one and saved ourselves some extra work.

So anytime I get revved up and start tossing out directives for work to be done, I try to step back and remember that it took me a while to learn how to shoot a basketball.

Two Management Gems

These from Adriaan Theron, a fellow Product Management type who is now working as a recruiter.

• "Building a product is easy, building a company is hard".  I couldn't agree more.  As hard as it is to build a successful product (and it is hard), building a company means putting all that other stuff in place so that the product can be successful.  And it means creating the organization and culture that will allow future products to be built and launched.  Lots of companies are started in order to take someone's great idea and turn it into a winning product or service.  Some (perhaps most) of those companies fail to figure out how to turn that great product or service idea into something that everyone wants, is available everywhere, works first time every time, and so on.  Others succeed once, but then stumble.  There's a point where the company becomes more than Engineering and Marketing.  Successful companies build a foundation by bringing people in who have already solved problems the emerging company is only beginning to see.
• "There are four D's to every product:  Define, Design, Deliver, Deploy.  Most companies focus on Defining and Designing, and neglect Delivering and Deploying."   Anyone who has worked at a startup knows the craziness associated with getting the first product out the door; at times it feels like the clown act at the circus.  Successful companies realize that the methods used to ship the first product won't scale, and put an emphasis on creating methods for delivery and deployment that are both repeatable and scalable. If your methods are repeatable you can bring in new people and train them to do the job... which means you can grow.  If your methods are scalable, you can ship a hundred units with not much more work than it took to ship ten... which means you can be profitable.

  

Food for thought!

Screen Wars

You've no doubt heard about the term "market share"--what portion of the total market for something is controlled by one brand or one company.  And I recall that in the 90's one of the management fads was "customer share"--what share of the customer's IT budget your product accounted for.  And I'm sure there are a dozen more "___ share" terms floating about.

You've also heard about web ventures that want to "attract eyeballs" as a way of "monetizing their asset".  Which in English means, "we can get paid a small amount of money per person who views and/or clicks on an ad... and that's how we're going to get some revenue to offset all the costs in programmers and servers that we're racking up with our web 2.0 service".

Of course, the monetizing isn't that easy.  More on that later.  But now that I've been interacting with email, photo sharing, social networking, and other web-based services, I've come to see that the battle is all about "screen share"--whose screen you see when you go about your internet business.  In other words, whose application will you use, and therefore whose ads will you be exposed to.

Take the example of sharing a photo.  Thanks to advances in cell phone and digiital image technology, and the avaiability of reasonably cost-effective bandwidth, taking a photo on the spur of the moment and sharing it is quite simple.  Had Brian been willing to stand still long enough, I could have taken his picture at the top of the run at Heavenly Valley, with Lake Tahoe in the background, and posted it or emailed it before I got to the bottom of the mountain.  (Of course, with my skiing skills, Pony Express could deliver it before I got to the bottom of the mountain, but that's another story).

So consider my options for sharing that photo:

• I can send it as a "multimedia" message... basically a text message with a photo attached (except that I have an iPhone, which doesn't support this basic service)
  
• I can email it to my friends using a service like gmail or Yahoo mail
  
• I can post the photo to a photo sharing site like Kodak Gallery or Phanfare
  
• I can post it to my Facebook page
  
• I can post it in a "discussion" on my LinkedIn page
  
• I can send a "tweet" with a link to the picture 
• I can post it to my weblog
  

There are pro's and con's of each approach.  But what's interesting is that wherever I choose to post it will determine what ads you see when you view it.  Unless you view the photo on my weblog (which has turned out to be a not-for-profit venture), someone's going to be showing you ads.  They may be targeted ads, like something at the top of the gmail browser that says "ski vacations, click here".  They may be unrelated, like the "IQ" ads I keep seeing on Facebook.  Or they may be anywhere in between.

And the odds are that wherever you view that photo, you will likely respond using that same web site or application.  If I send a text message or email, you'll likely reply with a text message or email.  If I post it on Facebook, you're less likely to send me an email saying "cool picture, who's the stand-in for an actual skier?!", and more likely to comment via posting a comment on my "wall".  And if you write on my "wall", guess whose ads you'll see?? And when everyone else sees that you commented on my picture...

So it's clear that the first battle may have been about creating a fan base (and keeping it interested).  The next battle is about steering that fan base to your application for all their social networking needs.  And since social networks are non-exclusive clubs, and since we all have text messaging and email accounts, it's all about creating the most useful, easiest to use application.  After all, we're all lazy in a way, and will use your application to carry on our conversations if the application is reasonably easy to use, reasonably unintrusive, and so on.

So the battle is on, and corporate America is beginning to pay attention.  Hell, even Oprah and Shaq use Twitter.  Who will win? Whose cuisine will reign supreme? Oh, sorry, wrong show.  It will be interesting to watch...

All A-Twitter

So now I'm on Twitter. How I got there... More later. When Twitter was about "now I'm picking my nose" I wasn't so interested. But now it's being seen as part of the marketing mix. So I'm "following" a couple of randomly chosen people and organizations.

And to think only this morning I was explaining the difference between Twitter and text messaging!

Much, much more to come.