Previous month:
October 2009
Next month:
December 2009

November 2009

The Three Management Lessons of Body Surfing

Growing up in Southern California, I spent a lot of time at the beach.  Since I preferred being in the water to lying on the sand, I took readily to body surfing.  I loved the feeling of crashing down the face of a wave, riding a swell all the way into shallow water, and pretending not to notice the admiring stares of the young ladies as I returned to the surf.  OK, that last part never happened, but body surfing was great fun, and taught me three lessons that I've applied in my product management and strategy roles over the years.

Start Swimming Before the Wave Gets to You

I quickly learned that you'll always miss the wave if you wait for it to arrive before you take off swimming.  The energy of the wave is ahead of its crest, and you have to start swimming when that part of the wave gets to you; it will sweep you up to the crest where you can push forward and catch the wave.

In product strategy terms, swimming before the wave gets to you means that you have to see the trends in the market, industry, technology, and other relevant environments before they become obvious (to you and everyone else).  Unless you're getting hot tips from Johnny the Shoeshine Man (Department of Obscure References), reacting to a trend when it's defined will not put you out front in the market.  At best, you'll come in with a me-too product which will never deliver home-run types of returns.

It's late summer, 2003.  Our CTO is on a sales call with a major bank.  The sales team is explaining how the iPass mobility management service will save the bank hundreds of thousands of dollars in access charges.  The bank executives seem distracted; many are checking their pagers and leaving the meeting.  Back in the office, I notice that my access card doesn't seem to be working.

The next day, the news hits about the SoBig and Blaster viruses.  Many companies are forced to shut down all outside access to their networks, a "nuclear option" to control spread of the viruses.  While we were pitching the bank on a solution that would save hundreds of thousands of dollars, the bank was losing far more than that when it had to shut down network access to its remotely connected loan origination agents.

We realized that, as one IT Manager put it, "IT departments will only get one free pass".  Another virus outbreak and heads would roll.  We expanded our search for companies with security technology that would complement our existing security services.  We acquired a company that offered a solution for managing devices "in the wild" and quickly rolled out an upgrade to our mobility management service that incorporated this device management technology.  In short order, the notion of fine-grained device security and management went from a nice-to-have to a must-have, and we had a solution available.

Look Outside

"Outside!" is a well-understood refrain for body surfers.  It means that there's a wave coming that you probably can't see (because you're in the trough of the wave in front of it) and probably don't want to miss... or at least want to put yourself in a position to miss without causing great bodily harm (more on that in a moment).  It seems like every set of waves has one that's a little bit bigger, and breaks a little farther out, than all the others.  Failing to look outside (or heed others' calls to do so) can mean missing the best wave of the set.

Failing to "look outside" happens to lots of companies.  You don't want to take your focus off of the product you're working on now, which is understandable.  But you have to have the discipline to "look outside" at regular intervals:  has anything changed to make this opportunity more attractive? less attractive? Is a different approach becoming required?

We certainly seemed to be "riding the wave" when iPass went public in 2003.  Sales were up, margins were good and we were gaining recognition as a leader in our field.  Most of our customers were using dial-up access to the Internet and (from there to) their corporate networks, and we were hard at work "federating" Wi-Fi networks in the same way we had done this for dial access networks.

What we didn't fully appreciate was that many iPass users were dialing up to the Internet and their corporate networks from home.  Sometime starting in 2004, these users switched to a "home broadband" connection--one provided by the cable television company or phone company and not iPass--to get to their corporate networks.  As if that weren't enough of a problem, coffee shops and other venues starting offer free Wi-Fi access.  And all of our systems were set up to "monetize" our service by charging for use of iPass networks.  Houston, we have a problem!

We got people from Marketing, Finance, Product Management, and Engineering together to frame the problem and come up with solutions.  We were able to create, implement, and promote a "per user"--vs. per-session--fee for use of any network accessed through the iPass service.  We installed pricing plans that gave enterprise IT managers the flexibility to mix and match types of access--dial, Wi-Fi, home broadband, and networks not supplied by iPass--along with usage-based and flat-rate charging methods. We extended our security software integrations to provide better support for user exposure to "rogue" networks of uncertain safety.  The result was a significant recapture of value (and revenues) that otherwise would have been lost.

Be Decisive

It happens to every body-surfer:  you find yourself staring at a giant wave that's sure to wipe out everything in its way when it crashes on the shore.  The tide is running out quickly, as if the water itself is scared to hang around.  Pretty soon it's going to be you, the wave hitting you full-force, and nothing but sand to hide under.  You have to decide whether to run/swim toward the wave and dive under it before it breaks, or run like hell toward the shore and escape the brunt of the wave when it breaks.

And you have to decide now.

We've all been around people who have trouble making decisions about important stuff.  They ask for innumerable analyses, "what-if" scenarios, and so on.  They convene meetings to decide what to do, and decide that further study is required.

As with body-surfing, there are times when a decision--any decision--is required.  Knowing how to recognize those times is a critical skill.  And knowing what you need to know, in order to make a decision, is also critical.

As we brought out a new WiMax product at SOMA Networks, there was an ongoing debate between Sales and Engineering, concerning the required level of lightning protection for the tower-mounted radios.  Sales felt that the solution had been over-engineered and was too costly.  Engineering felt that the risks and costs associated with a lightning strike and power surge justified the extra expense.  As we moved toward product release, a decision had to be made if the project was going to stay on track.

We gathered those with expertise and strong opinions together to get the facts and considerations on the table.  On one side, there was the argument that initial cost was a barrier to sales.  On the other side, there was the argument that a resettable surge protection device would reduce the number of "truck rolls" required to visit a site and reset the radio.  After everyone had their say, we opted for a one-use surge protection device at the radio, together with resettable devices for rooftop-accessible equipment.  Overall cost was reduced, the forecasted consequences of a lightning strike weren't appreciably changed, and we kept the project moving.

Ride the Wild Surf

Department of Obscure References

Managing product strategy and development is always a challenge in technology companies, given the constant state of change.  Pay attention to these lessons:  you'll do a better job of riding the waves to your company's benefit and spend a lot less time coughing up sand and salt water.

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   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  Fortunately, the same person that designed the Remedy solution was able to recreate the solution on  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.