We're doing podcasts at Forrester now, and I'm the internal resource for how to get them done. Here's what we've learned so far:
Post new podcasts on a regular basis. Decide on a schedule — twice a week, every week, every two weeks and stick to it. Listeners look forward to new material on a consistent basis. Consistency helps you gain and maintain an audience.
Name your podcast. Consider a contest to identify a good name. At Forrester we are still working on a name. Any ideas? In the meantime, you can name the podcast after your company like we have — Forrester Podcasts.
Identify upbeat music. Start and end each podcast with three-to-five seconds of music. Use the same music each time to give your podcast an identity, like NPR's All Things Considered. Do you have in-house musicians who might enjoy creating your theme music?
Keep podcasts short. Six-to-twelve minute podcasts are ideal. If the topic takes longer, break it into two or more podcasts and let listeners know this podcast is the first of a two- or three-part series.
Plan a podcast format that fits the topic. Vary the format depending on the topic and the presenter but keep the music and podcast name consistent. Here are some formats we've tried:
Working on the PM tools research (drafted, in editing) has led to a recurrent question: what sort of requirements tool? Requirements definition? Requirements management? Something else?
Does it matter? The distinctions seem a bit arbitrary. The raw data is the same, regardless of the immediate task (collecting, analyzing, using them in a product plan, using them in feature or use case documents, tracking the progress of a release towards meeting these requirements, etc.). Why should these different bits of information be stored and managed in separate systems?
If you don't believe that having a shared repository of dynamically assembled requirements information, go work for a PM group for six months, and count the number of times you type the same information into multiple formats. For example, let's assume Friendly Customer Inc. wants a particular enhancement. A short version of that enhancement request may appear in a list of possible features for the next release. Friendly's use case might be important supporting documentation for the feature write-up. When the CEO demands to know how the company is responding to Friendly, one of the firm's best customer, the enhancement will appear in a slide. And son on.
The unbearable lightness of being a PM The unstated premise behind Product Beautiful argument is that you have to get really excited about a product to act as its product manager. The companies cited--Apple, Dell, and Amazon--imply a general-purpose solution, like an iPod, inexpensive home PC, or an online bookstore. You'll also note that these are very "horizontal" products, without specific "vertical" spins, by industry or role. (Or, at least, that's how they might appear on the surface...But that's another conversation entirely.)
If these sorts of products inspire and require passion, what doesn't?
Today’s announcement of the promotion of Leo Apotheker to co-CEO of SAP AG signals an orderly transition of command as current CEO Henning Kagermann’s contract expires in May, 2009. Mr. Apotheker has clearly been heir apparent since Shai Agassi’s departure a year ago. Although SAP put a positive spin on his sudden departure, evidently Mr. Agassi was not next in line for the job.
Mr. Apotheker, a 20 year veteran with SAP, has served as head of worldwide sales and most recently as Deputy CEO. While the practice of co-CEOs could be problematic in some environments, SAP has done this before as Dr. Kagermann ascended the throne and succeeded Hasso Plattner, now Chairman of SAP’s Supervisory Board. The transition should be orderly and Apotheker is well-suited for the job.
Additional changes within SAP’s Executive Board were also announced in the same press release. Jim Haggeman Snabe, Bill McDermott and Erwin Gunst were promoted to the Executive Board. Snabe will manage product development for both the SAP Business Suite and Netweaver. McDermott will take over responsibility for worldwide sales. Gunst, the current head of EMEA operations, will become the company’s first Chief Operating Officer. The need for a COO signals the growing complexity of the business in maintaining controls over acquired businesses (e.g., Business Objects) and new products and business models (e.g., Business ByDesign). Snabe and McDermott represent new blood on the Executive Board as well, rising stars that have done well in their respective areas.
Quickly: Conventional wisdom glosses over China's limitations and problems.
Roger Cohen's starry-eyed China tribute in the New York Times is emblematic of the runaway euphoria surrounding that emerging economy. Threat to America…threat to Asia…ready to overtake Europe in the next 10 years…exploding – the gold rush place to be...450 million cell phones…becoming highly creative and innovative…the new model…the future.
On a recent trip to Shanghai I attended a huge party for Adidas. I was there with a friend of a friend who works for Ticketmaster and specialize in creating exclusive events and PR for brands, bands and celebrities. Now this party was thumpin.' On the top floor of a trendy Shanghai "loft" with a glass floor to see all the way down to the ground 20 odd floors below. The room was chock full of people, and also huge digital billboards broadcasting Adidas commercials and branding messages.
I was at a Forrester event on Wednesday with 50 $1B+ CIOs and Enterprise Architects. When I asked the group whether they thought we were in a recession, three fifth's said "yes." Then I asked whether they thought their tech budgets would be cut this year-- one fourth said "yes." And one smart ass CIO said, "Hey my budget always gets cut -- nothing will be different about this year."
Demian Entrekin at the IT Toolbox blog cites two problems in product management that, in my marginally humble opinion, are actually the same problem. First, there are the unrealistic schedules:
I have to admit that I have done this myself. I often put down a schedule that I know in advance is not exactly realistic. I call this the internal plan. Then there's the external plan. That plan is more vague and has something like a 50% pad built into it. Some people call this sand bagging, but I call it managing expectations.
But from where I sit, Information Uncertainty is quite a different animal. In short, Information Uncertainty means we don’t know what will happen as an idea moves through the life cycle toward becoming a project and then launch. There is a tremendous amount of uncertainty. The idea may lead to substantial change. It may lead to incremental change. It may never make it to funding. It may be a great idea that we simply fail to execute.