Archive for June, 2010

Stage-Gate and software don’t mix

[tweetmeme source=”chenelaine” only_single=”false” service=””]

I recently read this interesting article from Nielsen Wire on new product development for consumer packaged goods (CPG).  This article talks about how to realize the most revenue from new product development in the CPG space. Key takeaways:

  • Manage ideas loosely (have an innovation team live far, far away from headquarters with low involvement from senior staff)
  • Manage the process precisely (a formal Stage-Gate process is recommended)

I found myself scratching my head over how to translate these astounding insights to high tech new product development in a software startup or small business environment.  My take: they don’t translate.

I agree in principle with managing ideas loosely – no blue sky work can occur if every new idea is shot down by someone who is too concerned with the here and now.  But is it prudent to have a completely separate blue sky process in a startup when the entire startup needs to all march to the same tune?  This structure seems advisable only for corporations with a strong established business, which generates the revenue to fund the innovation process.  For pre-revenue or early revenue-bearing businesses, there is no separation between new product development and the business itself – they are one and the same.  A company like that hasn’t earned the right to send a team off to another city and go blue-sky on everybody else.

The second point made in the article, regarding tight management of process, is even less transferable.    Let’s take the application of Stage-Gate for an example.  Imagine managing web software development with a 2 week release cycle, where each release must go through the 5 typical gates:

  • Gate 1: initial screen (to decide whether the idea is worth pursuing)
  • Gate 2: approval to proceed to building a business case
  • Gate 3: approval to proceed to development
  • Gate 4: review outcome of development before going into QA
  • Gate 5: review outcome of QA, decide whether to release

“Absurd” is the only word that comes to mind.

I believe in only as much process as it takes to maximize efficiency and guarantee a high quality of output. (That is a whole lot more process than most entrepreneurs I work with are used to.  I can’t help it – if I am to execute I have to set up an efficient environment.)  I also believe in tailoring processes to suit the industry and nature of programs.  Different processes are established for different things.  You can’t apply a consumer electronics hardware development process naively to shrinkwrap software development, and you cannot apply shrinkwrap software development processes naively to web application development.

Stage-Gate can work for CPG and hardware development programs with a long turnaround time, but is completely inappropriate for fast turnaround programs and most software programs.   It behooves senior management to understand enough of the principles of Stage-Gate versus Agile or Mini-Waterfall so they can apply an appropriate level of oversight without bogging everybody down with inapplicable processes.


On deadlines

[tweetmeme source=”chenelaine” only_single=”false” service=””]

I just read an awesome post on deadlines from Seth Godin. The key takeaway is that deadlines work and we should set deadlines and stick to them for ourselves. Amen to that!

His post illustrates something unflattering about human nature.  Many people procrastinate until, or after, the very last minute. And then they spend far more time making excuses, complaining about extenuating circumstances that made them miss a deadline (and presumably miss some sort of benefit) than it would have taken them to hit that deadline to begin with.

A culture that tolerates misses removes accountability and encourages sloppiness in execution.  Conversely, a culture that doesn’t tolerate excuses and celebrates milestones as they are achieved on time sets the stage for an empowered team to execute effectively and with a great quality of output.

An “Oh Crap” moment

[tweetmeme source=”chenelaine” only_single=”false” service=””]

Today I had an “Oh Crap” moment.  An alert coworker discovered that a product that was released and on the docket for a much-anticipated marketing launch had developed a fatal flaw.   Said coworker basically saved my behind, because it would have been very, very bad if that product got launched on schedule (and on my watch too – unimaginable).

The product release was a textbook example of excellent teamwork and extraordinary efficiency in execution.  The fatal flaw was mainly my fault.  That kind of fatal flaw had happened before on a different platform.   The lead engineer on the project hasn’t seen it before, but I have.  I should have anticipated it and made sure SQA tested for the condition that would have triggered it. But I missed it.  I was colossally lucky someone caught it before it was released into the wild.

To our credit, we didn’t run in circles, scream and shout. We called all the key people, triaged the situation, and in 30 minutes we had a calm and rational plan of record to fix the problem. To quote the lead engineer, who turned around halfway through his drive home to partake in this quest: “We are going to do this right; we aren’t going to do this as though our hair is on fire.”

Fortunately, or unfortunately, I’ve lived long enough to have had several “Oh Crap” moments.  So I know from past experience that speedy acceptance of responsibility leads to a speedy resolution of the crappy situation.  So I sent a mea culpa email, explaining what happened, apologized, and explained what we were doing to fix this.

So it’s all out of my system and we are moving on to a fix.  While I feel like crap,  I am very proud of how my team behaved in a time of crisis, and how we are able to mobilize and deal with the situation.

Rallying a team behind unsexy projects

[tweetmeme source=”chenelaine” only_single=”false” service=””]

It’s easy to get a team psyched and energized on sexy projects – the kind that have huge and visible customer impact, which gets your senior management and your board all excited.  Think of a software UI and workflow redesign that makes it ridiculously easy for your target end users to achieve their goals within your product, or a release of a new product with new and highly visible features.

It’s not as easy to get a team psyched and energized on highly strategic projects which, when done perfectly, has no visible manifestation whatsoever (except in subtle ways, such as improved performance of a software application, or a reduced incidence of rare catastrophic failures).  Think of architecture work, refactoring, server architecture rework for hosted applications, cost reduction exercises for existing products and so forth.  These sorts of projects are like plumbing: nobody notices the work if it is done right.

There are many ways to rally a team.  A steady stream of ongoing feedback and encouragement is a must.  Small victories should be celebrated as they come up.  I make sure my team is well fed if they have to work weird hours in support of some big initiative.  I like a little champagne to celebrate major milestones.  A private word of thanks and some token of appreciation is always appropriate as well.  But a much bigger part of it is public recognition of a job well done.

For jazzy projects, this is easy: everybody can see the end results and the quality and speed of execution of the work is self-evident.  For plumbing projects,  it’s much harder: even senior management often misses the magnitude of the achievement.  One could have a team toil for months on a huge project with everyone else scratching their heads on what this team achieved with all those man-hours.

In these cases, it is imperative that we explicitly call attention to the speed of execution and the quantity and quality of the work done by the team in a public manner, and make sure the team is recognized for excellence in execution.  We simply have to work harder to frame the achievement in a way that is immediately understandable by people outside the fray, so they can appreciate and applaud the contribution that the team made to the cause.

Issued patents don’t represent innovation

[tweetmeme source=”chenelaine” only_single=”false” service=””]

Are patents symbols of innovation in this day and age?

My take: NO.

Today I went to the USPTO site on a whim to see whether I had any new issued patents (my last company had a huge patent portfolio with me as a co-inventor in over half of them.)   Lo and behold, 3 of them were newly issued.

This is gratifying since I got to update my issued patent list.  But it got me thinking about the whole system.

First of all, I should add that I do believe there is value in the patent system as a mechanism for startups and small companies to protect their core intellectual property, build an image as an innovator in their chosen domain, and shore up their valuation during fund raising activities.  Having mostly worked for startups with a hardware component, I have seen first hand how one can really monetize a strong patent portfolio and defend one’s position as a thought leader in the marketplace.

I agree with Brad Feld in general about the absurdity of software patents, but I believe

(a) novel hardware and human interface ideas are generally worth protecting,

(b) novel algorithms that deal with very complicated math/physics problems are generally worth protecting too (even if they are implemented in software).

That said, I have become increasingly disillusioned by the entire US Patent process as a way to protect and encourage innovation and invention.  Here are some anecdotes from my prior lives.

  • The US Patent Office allowed a patent application for which the WIPO (World Intellectual Property Organization)  found a piece of prior art it apparently read on.  We had to modify the claims for the WIPO filing and file an IDS (Information Disclosure Statement) with the US Patent Office about this new piece of prior art, which promptly issued the patent as is with no changes required in the claim set.
  • The US Patent Office once issued us a final rejection letter – with instructions on how to rewrite the claims and pay a fee so we can get it allowed in the next round.   (How’s that “final”?)
  • The US Patent Office let a few claims through which I believed was too broad to be defensible, and too nonspecific to protect the associated core technologies.  And I think some of them read on prior art.  This is, of course, our fault; we did a lousy job  on claims development.  Still, the fact that those claims came through said something about the due diligence that the patent examiner did NOT do.

It’s a fine theory that the patent process rewards novel inventions, but the reality is that the system is not equipped to tell the difference between a truly innovative idea and a truly pedestrian idea. Consequently, anyone with an adequate budget, a moderately articulate patent application, several years of patience, and substantial flexibility about the language of the claims can get their US patent application to eventually issue.  The only patents I’ve seen that aren’t issued are those that were abandoned due to lack of budget.

At this point, my personal opinion is that a strong patent portfolio is a business tool, and is fundamentally not correlated with whether a company owns any intellectual property of note, or has invented anything novel that is hard for competitors to imitate.   We pay to play in the high tech world and I suppose I have to be at peace with that.

Product strategy: finding patterns in chaos

[tweetmeme source=”chenelaine” only_single=”false” service=””]

I had an informational interview with a young friend who was interested in starting a career in product strategy.   The first question that came up was this: what IS product strategy?

In thinking back through my various encounters with strategy work, I came up with the following core elements:

  • Data collection.  Any strategy work without data is just guess work. Data is crucial for helping us make fact based decisions.  For instance, one could be in the field doing contextual interviews to collect raw data for a persona project. That’s data collection.
  • Data analysis. Once you have the data you must crunch it to see what it means.  One tries to find patterns in the chaos of raw data.  For a persona project, that means looking for common threads amongst the one on one conversations.
  • Recommendations. This is what I call the “so what” part: given this information, what should we do moving forward?  For a persona project, this involves naming the primary and secondary personas and explaining why they make sense.

To some extent, the first two elements are skills that can be taught relatively easily to anyone who has a reasonably good aptitude and is capable of seeing data through objective lenses.

Coming up with recommendations, on the other hand, is a whole different proposition. It involves integrative thinking; it requires those doing this work to synthesize new data with domain knowledge and other information.   It involves finding patterns in the chaos of raw and synthesized data.    It’s not unteachable; but it does involve experience with the subject matter.  A few years on the job doesn’t hurt either.

I enjoy all three elements, but ultimately, it’s the recommendations that matter.  It takes a lot of hard work to get to the point where you are ready to make a recommendation.  But once you do, and if you are right, nothing beats the exhilaration of having helped to point the company towards a direction that will mean success for everybody involved.

Twitter Updates


%d bloggers like this: