Skip to main content

August 2010

How Is Your Company Using Social Media?

Allow me to pose the question again, but this time as a multiple choice question:

How is your company using social media?

  1. As a hip way to fill business cards and e-mail signatures with nifty Twitter and Facebook icons
  2. To communicate to employees and customers
  3. To transform and broadcast media monologues into social media dialogues (Wikipedia)
  4. As a powerful platform to drive new, innovative products into the market

Take a moment to select the answer that best describes your organization. And be honest -- no one's watching. Go ahead… I'll wait.

If you answered "D" and you really, really mean it, allow me to lay down the gauntlet to put your company to the test. My good, wicked-smart friends at Kalypso have issued a challenge for all of you product development companies out there… a competition, in fact. Allow me to introduce you to the first annual Spike Awards to recognize the best use of social media and social computing to improve innovation, product development and product management. Spike Awards will be given to companies in four categories: Technology, Life Sciences, CPG, and Manufacturing. Nominees will be measured on the quality of their responses and how creative their social media solution was in solving the business problem. So, put your money where your mouth is and submit your entry today -- nominations must be in by Friday, September 3, 2010.

Winners will be announced on October 19th at PDMA's Annual Global Conference on Product Innovation Management. This conference always delivers meaty content and presents incredible networking opportunities. And with the presentation of the Spike Award winners, setting the example of how social media can be used to drive innovation into the pipeline, this conference should not be missed! See you there!

Portfolio Management and Agile Programming

When Kent Beck first articulated the principles of agile programming, he spearheaded the greatest change in software methodology in the last twenty years, and therefore perhaps of all time in such a young art.

As I cannot hope to improve upon his exposition of the synergetic principles of Extreme Programming, I would like to explain how agile programming relates to Portfolio Management and in particular to the critical need to give executives transparency into the status of a software project.

As Pat Durbin and Terry Doerscher write in Chapter 2 of their recent book Taming Change with Portfolio Management under the heading "The Elusive Nature of Knowledge Work":

Knowledge work is difficult to plan, estimate, and complete. Unlike physical work such as construction or component assembly, knowledge-based activities are often one-of-a-kind endeavors with no direct historical comparison for estimating purposes. Knowledge-based work also lacks discernable indicators of progress.

The concept of Velocity in Extreme Programming, or Agile Programming, is an attempt to provide a discernable indicator of progress for software projects.  It answers a simple but critical question for an executive of a software company:

How close to being done are we?

Therefore it allows the more interesting question to be answered:

What is the best compromise between what we want (our demand) with what we can do in a period of time (our capacity)?

Velocity is the amount of work completed by a team in a fixed, but repeating, period of time, called a Sprint. At Planview we use two-week sprints. However, the complexity of programming tasks, called Stories, varies widely, so you cannot simply count up the tasks. Rather, you measure the complexity of a completed task in an abstract measure. At Planview we call this measure Story Points, but you could call them "complexitrons" or anything you like. Every task must be consistently estimated in these Story Points.

If you measure the number of Story Points completed in several sprints by a particular team, you have the best measure yet devised for predicting how much work will be successfully completed in the next Sprint by that team. If you have all tasks estimated in Story Points, you can predict, with reasonable accuracy, when the project will be done. To an executive, portfolio manager, or project manager, this transparency enables good decision-making.

There are, however, some subtle keys to Estimation, Story Points, and Velocity that experience has taught us:

  • The whole team participates in estimation.
  • The estimate of a story must never change once it is decided. Time may show that the estimate is wrong, but to change the estimate is like telling a debtor he owes twice as much as previously agreed for no reason.
  • A story may be split into smaller stories, but the Story Points, like money and energy and momentum, must be conserved.
  • Estimates made quickly, relying on the ineffable thoughts of a skilled programmer, are about as good as detailed estimates.
  • Expect velocity in any given sprint to vary about 40% around a multi-sprint average.
  • Story writing is an art, but it is not a black art. A team and their product manager should be able to write 15 reasonable stories in an hour. Perfection is no better than "good enough"-ness. Do not allow the perfect to become the enemy of the good.
  • When programmers disagree on estimates, resolve the disagreement by consensus and discussion.
  • "Done" means "Releasable". A task is not done until it is releasable. You may not be willing to ship a single story, but if that story is not done to the level of quality your customers demand, it just doesn’t count

A Pocket Full of Nuggets from ProductCamp Austin

It was an impressive turnout at ProductCamp Austin (PCA) this weekend. Here’s the breakdown:

  • Close to 700 people registered for the un-conference
  • More than 500 people actually showed up… on a SATURDAY (that is dedication!)
  • Roughly 50 sessions were offered up for voting by campers on a variety of topics
  • A total of 35 sessions were delivered
  • And the winning presentation was: "How to be a Product Marketing Genius, Ninja, Guru Rock Star, Wizard"

While it didn’t win best presentation, the session that put the most nuggets in my pocket to take back to the office was by David H. Friedman titled: "What Engineers Wish Product Managers Knew." I always knew there was a fundamental difference between my brain and that of my favorite Development Manager, but this presentation spelled it out for me in black and white: they are right-brain thinkers and I am a left-brain thinker. We are wired in completely different ways! Dr. Friedman spelled out for me where Engineers excel, where they struggle, what motivates them, and how I can successfully work with them. I feel like I’ve received the keys to the kingdom! With this knowledge, my product is going to take off and smoke the competition! Intrigued? Check out his presentation and blog at his website.

There were other great sessions that were offered, but with only 5 available slots, I know I missed some good stuff. Luckily, PCA takes advantage of technology in every aspect and all presentations from the day can be viewed at the ProductCamp Austin website.

Already looking forward to the next two PCA events:

  • January 15, 2011
  • August 6, 2011

If you need an energy boost, I highly recommend you plan to attend!

Why Integration Doesn't Have to Be Hard, or the Secrets of a Good Partnership

Throughout my career, there have been a few examples of good business partnerships -- partnerships that are truly beneficial for both sides. I have many more examples of "Barney" type partnerships that take a good chunk of bandwidth for little return. The most successful partnerships, in my experience, have been built around a "build vs buy" product decision. The best example of this has been the integration platform decision -- if you are an enterprise software company, why do you want to build and own integrations? It is not your business…AND the infrastructure alone is cost-prohibitive, the resources needed to support integrations are expensive and the ability to keep up with all releases of software changes is daunting! And then throw SaaS into the mix! So one of the best decisions you can make is partnering with a good integration infrastructure provider -- and we chose Pervasive.

Any software veteran will understand that integrations are not easy -- our jobs as software providers are to make this as easy as possible. One can argue that the hardest part of integrations is to "talk" to the other applications, databases, ESB, etc. Once this connection has been established, the mapping of one field to another is much easier. This is the approach that Pervasive has taken -- they provide 200+ connectors out of the box and an easy interface to do the mappings. Since we embed Pervasive's technology in our software, all we have to worry about is building and maintaining web services around our product.

I attended the Pervasive Metamorphosis 2010 Conference a few weeks ago (I also had the privilege of speaking at the event -- hear for yourself what I had to say here) and it was amazing how many similar success stories I heard around the "build vs buy integration" decision and the documented achievements that had been realized. The show was very interesting in many aspects, especially hearing the vision of integration technology and how far along "integration in the cloud" has come. My advice to anyone looking at this integration "build vs buy" dilemma: stick to your core competency and let the experts do integrations!

Product Development Portfolio Optimization: Bottoms-Up vs. Top-Down

Written by Steven Cristol, Founder and Managing Partner
of Strategic Harmony® Partners

Steven Cristol

I've never met a homebuilder who wants to build a roof before pouring a foundation. Yet when I talk with executives about optimizing their product development portfolios for customer appeal, competitive impact, and resource allocation, they sometimes ask this question first: how can we do a better job of optimizing development investments across our major lines of business? That's essentially the roof of the portfolio.

This recently came up in a conversation with an iconic financial services company that wanted to improve how development resources are allocated across its retail banking, commercial banking, retirement, and insurance businesses. Of course, the C-suite of every diversified enterprise in any industry must concern itself with such issues. But sequence is critical. And in this case, the sobering reality was that there was more work to do to optimize new product development resources within each business unit before they could possibly optimize across units.

It's a paradox that this is obvious and yet so often ignored: the only way to optimize a company's product development spend is to first optimize it at every intersection of a product line and a target market segment. At each of those intersections is a set of needs and attributes that drives whether a customer chooses Product X vs. Y. When the development pipeline is optimized at each intersection, only then is the company able to optimize across multiple portfolios and business units by working with building blocks that are already optimized.

Like building a house, portfolio optimization is necessarily a bottoms-up discipline. Where there is excellence in product development prioritization and resource allocation at each segment-product intersection, senior management can be much more confident in optimizing across all product lines, customer groups and, ultimately, across business units -- knowing that each brick in the corporate product development house is, on an ongoing basis, an optimized brick.