Archive for the 'Product Development' Category

Stage-Gate and software don’t mix

Published June 25, 2010 Engineering , Product Development , Small business , startup Leave a Comment
Tags: , , ,

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.

Rallying a team behind unsexy projects

Published June 3, 2010 Engineering , Product Development , Product Management , Small business , Software , leadership , startup Leave a Comment
Tags: , ,

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

Published June 2, 2010 Engineering , Product Development , Small business , startup Leave a Comment
Tags: , ,

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

Published June 1, 2010 Product Development , Product Management , Small business , startup Leave a Comment
Tags:

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.

When not to roadmap (hint: Lean Startup)

Published May 28, 2010 Product Development , Product Management , Small business , startup Leave a Comment
Tags: , , ,

Recently I had an interesting debate with an old friend about product roadmaps.

Before I share that story, I should disclose that I am a strategy junkie and a compulsive planner.  I make lists in my sleep.  I have driven the product strategy and maintained the product roadmap for the last several companies I was associated with.  A roadmap exercise is the best way for the product team to get out of the weeds and see the forest, and everyone I worked with knew where I stood on that topic.

So I found it funny that I ended up waxing lyrical about a completely opposite position in this debate. My friend was arguing for the need for a roadmap in a startup in its infancy (6 months after incorporation), to lesson thrashing and reduce waste.  I instead argued that for such a young startup, a roadmap is worthless.   Instead, the company should direct its energy towards testing their ideas with customers until the company hits the killer idea.

In such a young company, thrashing is not waste.  Overinvesting is.  On this point I am 100% in alignment with the Lean Startup philosophy.

In Peter Bregman’s words, sometimes not having a plan can be the best plan of all.  Only when the killer idea is well defined, the target market has been identified and quantified, the personas have been decided on, and a product platform has been developed, does it makes sense to work on product strategy and create product roadmaps.  That’s typically at least 1-2 years after incorporation.

I often come across as a roadmap nazi because I harp incessantly about its importance as a symbol of a well thought out product strategy.   But like all debates, absolute statements are silly.   If your company is young, iterate until you are in a position to grow. If you are in a growth state business, then by all means, roadmap and plan to your heart’s content!

Where should product management live in an organization?

Published May 27, 2010 Engineering , Product Development , Product Management , Small business , leadership , startup 2 Comments
Tags: , , ,

I attended Product Camp in Boston over the weekend and the topic of where product management should live in an organization came up once again.  I had a blog post about this on my abandoned old blog, so I dragged it out and looked at it.  I realized I now agree with bits of it and disagree with other bits of it.

On the bits that I agree with, I continue to stand by my basic tenet:

Engineering and product management must be peers.

In my old blog post I went on to advocate that Product Management reports directly to senior staff as peers of Engineering and Marketing. I still think that’s the best possible structure.

However, the reality is that very few startup companies and small businesses are equipped to support this structure.  The CEO is typically terribly overloaded and is often not equipped to give the head of Product Management the support that he or she needs on a regular basis.

At the time I thought the next best thing would be to have Engineering and Product Management report into a Product organization which then reported to the CEO. With one more company and a couple more years of perspective behind me, I no longer believe this is practical for a small company. When the company has 20 or fewer people, 3 product execs is 1 exec too many. A much more practical solution is to have product management report into either Marketing (prefered) or Engineering (as a last resort).

It all depends on the people we have in a company and the skillsets they bring to the table. If Engineering has access to resources who are great at understanding customer / buyer needs and wants and can generate their own functional specification as a service to product management, then I think a more strategic product manager with substantial product marketing skills would make sense, and that person would work well in the Marketing organization. Conversely, if product strategy and roadmapping is well covered by other executives, and the need is for detailed product design and specification, then a technical product manager reporting to Engineering could work just fine.

I still believe Product Management should have a seat at the senior staff table together with Engineering and Marketing. But I think other less optimal structures can be made to work. The trick is to clearly define the role within the organization and make sure the product manager can succeed in their role.

The dreaded “dark side”

Published April 5, 2010 Customer research , Product Development , Product Management , startup Leave a Comment

I am currently working on a product and service combination where there is a hardware component and an online software component.  Predictably, our customers are split between those who go on line and those who don’t.  Also predictably, we know vastly more about our on-line customers than our off-line customers.

This really came to a head when we were doing customer satisfaction surveys.  Almost all respondants are on-line users.  But what about the “dark side” – our off line users?  Are they happily off line, or did our product become a paperweight?

Of course, there is only one way to find out: interview them by phone.  These folks have proved to us that they don’t go on-line to use our software tools, or respond to our emails.   They most definitely won’t post anything on a forum or tweet us their thoughts.  We would have to revert to old fashioned phone calls.

The issue is the time commitment: we can blast off an online survey to on-line users any time we want.  We can always squeeze one in no matter how many other initiatives we are chasing.  But to get 20 quality phone interviews from the dark side, we are probably going to have to actually call 200-400 people, maybe even more.  The time commitment is so immense that it nearly always get postponed when the subject comes up.

Some time soon, we’ll bite the bullet and call our “dark side” customers and find out what they love or hate about our overall user experience.  It’s no different from how anyone else did primary market research 20 or 30 years ago.  It’s just interesting to observe how our expectations have changed with these awesome on-line tools. We are so spoiled :-)

Beware the focus group of one

Published February 28, 2010 Product Development , Product Management 2 Comments
Tags: , ,

I read a great post by Jeff Bussgang (an entrepreneur turned VC) where he talked about “Mother in law market research”.  He shared a quote by his MBA classmate:

“I think [this consumer product] will be a hit because I can see my mother-in-law buying it.”

I don’t have to explain why such an assertion should never be made without supporting data (e.g. does the MIL match the primary or secondary personas?  Does she have the right demographic / psychographic profile?  Was there qualitative and quantitative research to prove the same?)

The “focus group of one” happens to the best of us, regardless of our roles.  Sometimes we use the MIL, most times we project our own views onto the target personas.

It generally goes like this.  Someone in the company becomes fixated to some product feature.   99% of the time, he or she is not a good match to the target personas.   (He can be a man commenting on a product to fix hot flashes for menopausal women.)  He or she would share his/her opinion:

“Yesterday I saw a demo of <product feature>, and it immediately made me think people can <achieve improbable application of product feature to unrealistic use case>.  I am now absolutely convinced we must line up all our resources to optimize the user experience for <unrealistic use case> because if I thought of this,  lots of other people would want to do that too.”

I’ve seen it happen to  founders, CEO’s, CTO’s, COO’s, or SVP’s of something-or-other.  For all their brains and success (present and past), they fall into the trap of believing they can project themselves into the minds of target end users, without taking the time to really understand the latter.

Unfortunately, these guys routinely underestimate the magnitude of thrashing they can cause.   Let’s face it, if the SVP Sales declares that product feature X must do Y, the product team isn’t going to spend 2 minutes convincing her otherwise.  Instead, it is going to spend 2 business days putting together a well structured argument, based on facts.  Then they will make an appointment with her to present their arguments.   They may even commission a new research study to put the argument to bed.

And let’s face it… if she remains unconvinced despite hard facts, and the company is set up in that way, Feature X shall do Y in the next release.  Forget about the research results and the needs of the end users.

So, to folks on the management team:   please don’t become the focus group of one.  At best, you will waste much more time of your product team than you realize.  At worst, your stray comments could cost your company its ability to develop great products.

Positioning statements

Published February 26, 2010 Product Development , Product Management Leave a Comment
Tags: ,

There are many templates for positioning statements, and different ones exist for brand, product and services.

Being a product person, I must admit that I really only care about functional positioning statements for products or services.  I am partial to the product version below (courtesy of GrowthConnection):

Product Position Statement

For [target end user]

Who wants/needs [compelling reason to buy]

The [product name] is a [product category]

That provides [key benefit].

Unlike [main competitor],

The [product name] [key differentiation]

Just for laughs I am going to apply it to a fictitious product that I would love to buy: a miniature kitchen composter that doesn’t take up much space, requires no worms, maintains a high core temperature purely from absorbing energy from the lights that are on every night,  and doesn’t smell at all.

For consumers passionate about the environment,

Who practice green, sustainable living in every aspect of their lives,

The magic composter is an indoor composter

That provides a fast, odorless way that sustainably converts all your kitchen waste into compost every day, 365 days a year.

Unlike the Worm Factory(R),

The magic composter has the footprint of a 2.5 gallon trash bin, emits no odor, can keep up with the kitchen waste of a family of 6, costs only $15, and requires no worms to operate.

Now I am sure my magic composter needs lots more work, but that’s the idea.  This format forces you to think about why the product exists and what it does for the target persona. I love it.

Beta programs

Published February 22, 2010 Customer research , Product Development , Product Management , Small business , Software , startup 1 Comment
Tags: , , , ,

This is the eighth post in my Customer Research series.

What is a beta program? The Wikipedia has the following definition:

“Beta” is a nickname for software which has passed the alpha testing stage of development and has been released to users for software testing before its official release. It is the prototype of the software that is released to the public. Beta testing allows the software to undergo usability testing with users who provide feedback, so that any malfunctions these users find in the software can be reported to the developers and fixed. Beta software can be unstable and could cause crashes or data loss.

In my mind, the beta program provides an early window into how the market will receive the product release.  It generally happens at the very end of the development cycle.  I generally run small-scale beta programs as follows:

  • Recruit 10-20 beta testers to match the primary and secondary personas that the product is designed for
  • Do a kickoff meeting (either one on one or in a group) to set expectations on what’s in the new release, and how we expect to collect feedback from beta testers
  • Ask beta testers to use the product in the target environment of use
  • Schedule a call with each tester on the phone 1 week into the program, to ensure everything is going smoothly
  • Use phone calls and email to keep track of progress during the program
  • At the end of the beta program, schedule a phone conference or an in person debrief to collect feedback.

Since beta programs occur at the very end of the development cycle, typically weeks before the target release date, it is really only useful for testing things that can be iterated right before the release: positioning and messaging, delivery and support mechanisms and the like.  There is a great recent post on beta programs by Dave Daniels of Pragmatic Marketing that outlines all this – do take a look, it brings into sharp relief many of the questionable practices a lot of software companies take for granted.

Findings from beta programs can also be used to pull a release if (gasp!) a customer discovers a fatal bug that the QA department failed to find.  Lastly, it can also be used as a vehicle to collect customer feedback for the next release.  It is NOT a vehicle for usability testing – it is way too late in the game for that!  Usability studies (whether in lab or extended use tests) should be done early in the development cycle, before the product is finalized and when there is still time to effect change.

Using beta programs to test positioning is a great idea.  One can save a lot of money in marketing programs by iterating the messaging with target buyers until winning messages are arrived at.

Next Page »

Subscribe in a reader

Subscribe by Email

About Elaine Chen

I'm a 17-year veteran engineering and product management executive in the local Boston startup landscape. Click here to view my full profile.

Twitter Updates