The Web offers all of us an incredible opportunity to get the word out about who we are and how we can help others solve problems that matter to them.  That’s your personal brand.  Personal branding can help you in your job search if you are between jobs or help you remain more flexible in your current job.  Getting good at personal branding is easy, but it will take commitment on your part.

I was happy to see that I’d already done a few of the steps, but there are lots more for me to follow. How are you doing on your personal brand? Leave me a comment to let me know.

On Language – Defending Against Language Pedants – NYTimes.com

So I say outpedant the pedants, and allow yourself to gluttonously revel in the linguistic improprieties of yore as you familiarize yourself with the nearly unique enormity of the gloriously mistaken heritage that our literature is comprised of.

Ammon Shea tells the pedants to take a chill pill, and tells us how to handle those pedants, in this clever and useful “On Language” column from the Sunday, 4 October 2009, New York Times Magazine.

Product management is a complicated and multi-faceted activity, and each of these concepts offer useful guidelines as we strive to create successful and useful products that kick ass. But there are several other characterizations I’ve found helpful over the years both to understand what I do, and to explain it to others. Since they’re not common, I would like to share them (over several posts):

One aspect of the product manager role is to do impedance matching.

From Wikipedia: The term ‘impedance’ means the resistance of a system to an energy source. For constant signals, this resistance can also be constant. For varying signals, it usually changes with frequency.

Impedance is an unfamiliar concept if you’re not an electrical engineer or a ham radio operator (I was KA6HAJ). But it basically means the resistance of a medium to information transmission, usually between components of different types. I think we can all agree that customers and developers are “different types” – and there’s naturally a communication barrier.

The product manager’s job is to bridge that barrier. In the language of electronics, the product manager is a type of transformer.

Wikipedia again: … [transformers are] used extensively in modern communications, particularly in frequency conversion mixers to make cellular phone and data transmission networks possible.

The product manager takes the signal from the market – needs, desires, complaints, misunderstandings – and transforms it into a signal that the engineering organization understands – requirements, specifications, defects, enhancement requests, and so on. Likewise, the product manager takes the signal from the engineering organization – a product with features – and transforms it into a signal for the market such as a value proposition, a set of benefits, and talking points.

Link: How To Talk To Your Mom About Product Management

I’d love to hear your thoughts – either here or on the Innovation Jam!

Several mobile phones. (Image via Wikipedia)

Do you remember this situation? You made some plans with friends, got to the meeting place, and they weren’t there. You hung around waiting, they never show, having gotten a better offer (“party with Bono, dude!”). Or they show up an hour later (“had a flat tire, dude!”). Or I don’t show up (“got in a fight with my girlfriend, dude!”). In any case, the plan breaks down and the whole thing goes off the rails.

Well, this rarely happens today. I would have called them, or they would have called me, and the whole experience would be back on track. In fact, with cell phones, our plan for the evening would be completely different to start with. It wouldn’t even be a plan – it would be a series of checkpoints. We’d review where we were and then make decisions about where to go next. Obviously, the overall goal would remain the same, but getting to that goal becomes a matter of coordinating.

This came to mind when listening to a 2005 Clay Shirky talk on the (awesome!) TEDTalks series. He said that with the cell phone revolution:

We stopped making plans – you say ‘I’ll call you when I get there.’ There’s a general replacement of planning with coordination.

We’ve all experienced the fragility of these plans – whether in our personal lives as in my story above, or at work, where we usually call it “the waterfall methodology” in software development. Once something goes wrong – or not according to plan – it can be extremely difficult to get the plan back on track.

And isn’t that just what “agile” does – replace step-by-step planning with a process of coordinating to achieve a goal? At every point everyone is in touch (if necessary) to get clarification, to make sure progress is being made toward the goal, and to ensure that indeed the final goal is worthwhile arriving at. When circumstances change (“Bono wants the product with feature X instead of feature Y, dude!”) we can adapt because we’re coordinated.

Comments?

Image by Alex Osterwalder via Flickr

From the new Lateral Action blog comes “Tyler Durden’s 8 Rules of Innovation“. Brian Clark says:

So why do we find it so hard to break out of our rut and do truly innovative things?

Because it’s hard. Because it often requires us to significantly alter our perspectives and step outside of our comfort zones.

He then points out that Tyler Durden of Fight Club can help us, just like he helped “Jack” in the book and movie, to make that big step.

Tyler’s Fifth Rule of Innovation:

“You’re not your job. You’re not how much money you have in the bank. You’re not the car you drive. You’re not the contents of your wallet. You’re not your f*****g khakis.”

When we talk about fear, risk, mistakes, and losing it all, what are we really afraid of? Are we defined by the stuff we own, or would we prefer to be defined by what we accomplish and create for the world?

Do you have a favorite fictional icon on whose quotes you depend for guidance in business or life? I like to remember Rick’s perspective: “The problems of three little people don’t amount to a hill of beans in this crazy world.”

Yes, Agile can speed up the development and improve the quality of small features.  But it’s too often at the expense of the Big Important Work — the heavy lifting, multi-month market analysis and architectural work that lead to REAL customer value and REAL competitive differentiation.

I magnanimously offered my perspective on agile, boiling it down to the key points of:

• Do the most important things first
• Be prepared to reprioritize on a regular basis as the environment changes

Or, “spend your resources on the 20% of capabilities that will get you the best return.”

So far, so good. Can’t argue with that as an approach, not just for developing software, but for living life itself. And for the self-help industry, which generates tens of thousands of pages on the Pareto Principle every year. And I’m sure CPM, as we call her, is super-happy that I clarified that.

In contrast, the old way (aka “waterfall”) is more like:

1. Figure out what you want to accomplish
2. Determine the most efficient way to accomplish it

It’s easy to see waterfall’s problems when characterized this way:
a. You have to know up-front what your end game is – which makes it hard to respond to market changes
b. The most efficient way of building the full product is not necessarily the one that front-loads the value, so often low-value items are completed and high-value items end up deferred
c. You do a lot of work up-front to document things that the developers never get to

Notice that’s not how agile talks about itself. The agile manifesto talks about working code vs. documents, and interactions over tools (it does cover “responding to change”). In fact, agile, as far the methodologies and manifesto go, is solely focused on programming. (This is changing some – I just listened to Kent Beck’s talk at the Ruby On Rails conference last year, and he’s come up with a very different characterization of the goals of agile: it provides accountability, responsibility, and traceability.)

Now, given my characterization of agile’s – indeed, life’s – key goals, you can then look at agile  methodologies simply as one way to accomplish those goals. But what if, as CPM fears, the most important capability (call it The Big Dog) takes longer to deliver than a sprint or two, and requires visits to lots of customers to understand their problems, and lots of reviews with customers to see if we’re solving their problem?

Clearly, you still have to do the Big Dog. CPM should be able to tell you why. And if the methodology doesn’t give you a way to do it, then the methodology won’t work for that product.

But chances are the 80/20 rule applies to the Big Dog, just as it applies to everything else. And this large monolithic capability can be broken down sensibly into multiple passes through the “smallest thing that could possibly work” approach. Does this require the PM to keep ahead of the development organization? Yes. Is that any different from the old days? Yes and no. The PM needs to figure out the most important part of the Big Dog (the 20%), and make sure it’s understood, there are good user stories, it’s designed, architected, etc., extremely well. After all, that’s where most of the value is going to come from.

But the PM doesn’t need to document the rest of the 80% until later – if at all. In fact, it’s likely that finishing the 20% of the Big Dog prioritized to the top of the project leaves something else – the Medium Kahuna – as the next important item to accomplish. There may be some additional Big Dog-related capabilities that are “nice to have” – and they’ll be prioritized into the rest of the project, if there’s time after getting the Medium Kahuna delivering its value.

“Now wait,” you (or the CPM) say, “I can’t live with only 20% of the Big Dog – I need 100% of it – or at least 80%” And I say this is where the beauty of the agile mindset comes into play. If you’ve completed 20% of the Big Dog, and have the rest of the Big Dog as well as the Medium Kahuna in your backlog, at this point you can decide which is more important, and decide which one to do. You’re already delivering 80% of the value of the Big Dog – now you can decide if you really need to take that up to 90%, and leave the Medium Kahuna on the table, or vice versa. You have control.

Agile is not a silver bullet, and it’s hard to get right, but if it helps you focus on putting first things first and executing on the 80/20 rule, it’s done its job.

People remember experiences. They don’t remember attributes or benefits or features.

The quote is from A.G. Lafley, CEO of Procter and Gamble, in the January 28, 2005 Business Week.

It’s something I struggle with often as a product manager. Like most product managers, I’m technical, so I love all the new features and gewgaws. But as I look back at my previous releases and at customer response to them (and my own response, since I use my own product on a daily basis), I find it hard to remember which features were new and which were always there. My experience today with the product is what matters – it’s a great result when the improvement of experience aligns with the new features. I’m happy to say that the new version of my product is working out that way. But I’ve certainly shipped features in the past that excited me as a technologist, and that were expensive and fancy and worked well, but that didn’t improve the customer experience. On the other hand, was that energy wasted? In some cases yes, but luckily there are other metrics for success in addition to experience, such as addressing a particular customer’s needs, or moving to a better technology, or enabling a new capability (such as an API) that won’t affect customer’s experience except indirectly.

Solar energy will cost the same as power produced by coal, natural gas and nuclear plants in about a decade, a report released Tuesday suggests. By then, the price parity could propel solar adoption so that it accounts for 10 percent of U.S. electricity generation by 2025

If you listen to this kind of thinking, solar energy (which is defined as what, by the way?) is still far more expensive than other kinds. But solar energy, even today, has a finite payback time – if I put solar collectors on my roof, for example, eventually they will pay for themselves.

So that’s one way it’s wrong.

Secondly, the study assumes that conventional energy prices will go up by 3% per year. That could be a slight underestimate. Didn’t we just experience a three month period where gas prices nearly doubled? (That’s 100%, folks!).

I can’t make any argument about the assumption that solar energy prices will come down 18% per year. That’s a lot, by one metric, but we’ve certainly seen large and faster price drops in high tech in the past. Even the iPhone, last week, dropped in price by almost 50% in less than a year. Sure, that was partly through some magic AT&T financial pixie dust, but to the user, it’s a clear 50% price cut. There’s no reason similar magic pixie dust, whether from the government or from the utilities themselves, won’t contribute to market price declines.

The claim that solar currently accounts for less than 1/10th of a percent of the U.S. energy supply today is fine. But the assumption that it will still be less than 1 percent in 2015 (seven years from now) is curious. If we start at .1 percent, and double our solar usage every year, we end up at 128 times as much – 12.8% of today’s total. This is the amazing power of Ray Kurzweil’s “Law of Accelerating Returns.” Even if it takes two years for each doubling, we’re still up a factor of 32x in seven years. That means 3.2% today’s usage. Our total energy usage may also go up (although there are very good reasons to think it may not go up much and and will be starting a downward trajectory), but for a 32x increase in solar supply to translate to 1% of our total energy use, total energy use would have to double. Not too likely in the U.S., where population growth has stopped, and SUVs are starting their long decline.

Finally, there’s good reason to believe that solar energy will actually have a much larger share of U.S. energy usage, due to the power of “negawatts” (as explained brilliantly by Amory Lovins in this series of talks at Stanford in 2007), in which efficiency turns out to be the most cost effective way to power industry and create profits. Oh, and by the way, it significantly reduces our energy usage, by as much as a factor of five to seven!

The article combines a couple of types of fallacious thinking – that technological progress is linear, for example, rather than geometric, and that other factors, such as the desire to reduce greenhouse gases or realizing the benefits of negawatts throughout the economy, don’t have an additional accelerating effect on technology changes.

By the standards of six years ago, those things are free now. Of course, it’s never free as in beer, because in fact we’re now using all the bandwidth, storage and CPU power we thought we’d never need, doing things a lot of us though we’d never be able to do in real life, like watch streaming live TV on our laptops (and our phones).

Today, I listened to Jeff Hawkins’ talk at ETech a year ago, Why Can’t a Computer Be More Like A Brain?, where he announced the Numenta Platform for Intelligent Computing. I think the idea now is, “If you’re not planning for how you’ll use human-like pattern recognition in your system, you’re not planning.”

What are the possibilities? Jeff listed a few, but there will be lots we’re not even thinking about now (or think are impossible – like we thought watching TV on mobile phones would be). It’s “human-like,” but not human. It can do things we don’t have time or patience for (just like a computer can do arithmetic all day that would drive us bonkers, even if we could do it as fast). And it can do pattern matching on patterns we can’t see – whether those are in infrared, or in huge piles of data that we just don’t have the sensory apparatus for.

Here’s an example. I have a product that manages requirements and their relationships to customers and customer requests (among other things). I talk regularly to customers, and take notes on these conversations. They often mention desires or usage scenarios that are outside the scope of the topic of the conversation at the time, and that aren’t seem related to the product planning I’m doing. Two years later, when I’m actually considering adding features related to those comments, I don’t necessarily remember the conversation. Or if I remember it, I don’t remember which customer made the comment. Currently I use Google Desktop to help me find the appropriate notes, but it’s a pretty rough approach – I have to use my best guess at the appropriate key words, and I end up spending a heck of a lot of time combing through my notes again and again. I’d love to have a human-like agent do this trolling for me – on a weekly basis, review all my old notes against my current requirements and tell me where there are overlaps. And while we’re at it, maybe it can read my blogroll and find related articles I could be referring to.

I know there are a few products out there that (claim to) do some of this already, and perhaps they work (I haven’t tested them). If so, they are the vanguard of this new set of capabilities, and in a few years they will have been overshadowed by realities we’re only dreaming about now.

How are you planning for the technical capabilities – human-like pattern matching or whatever it might be – that we’ll have at our command in five or ten years?

Doug Hall, unlike most business consultants, makes quantitative claims in his book Jump Start Your Business Brain. According to his research, he can predict the effect of certain basic marketing techniques on the success of a business. For example, he says that businesses that articulate “an overt benefit, a dramatic difference, and a real reason to believe” have about a 47% chance of success, while having only two of the three gives about a 30% chance of success.

Today I just ran across another interesting set of quantitative data about success factors, from the Journal of Product Innovation Management, Success Factors in New Ventures: A Meta-analysis, by Song, Podoynitsyna, et al. (I believe the link I provided is free, although most issues of this journal are behind a paywall.)

Based on a meta-analysis of a number of other studies about successful and non-successful new ventures, the authors determined that eight factors – out of about 20 candidate factors – were the best predictors of success. The candidate factors included items like:

• A low-cost strategy
• Prior startup experience
• Patent protection

Interestingly, the eight success factors did not include prior startup experience, or what they call “product innovation”. Instead, the factors were:

1. supply chain integration
2. market scope
3. firm age
4. size of founding team
5. financial resources
6. founders’ marketing experience
7. founders’ industry experience
8. existence of patent protection

The article is a bit vague on some of these – for example, it doesn’t suggest the ideal size of founding team, just that it’s a success factor. And isn’t is obvious that a successful new venture will typically be in business longer than an unsuccessful one? As the authors acknowledge, to a large degree the article leaves more questions open than it answers.

So, getting back to the original question, if you are starting a new venture, or thinking about doing so, will you pay attention to the research and make sure you have all your success factors in a row? (Or that you have an overt benefit, dramatic difference, and real reason to believe?)