Archive for the 'Product development' Category

Product Camp Boston and “ignorant” customers

Saturday, November 14th, 2009

I went to my first Product Camp this month.  It was the second one held in Boston.  These are “unconferences” organized in the barcamp style.  That is a self organizing conference.  Anyone who wants to give a presentation puts a short description up on a board.  Everyone has a few colored dots to place on these proposals to vote their preferences.  The number of votes a presentation gets determines what room it’ll be held in and to some extent when it is scheduled.  Then everyone attends the presentations of their choice except when they are giving one.  There were a couple of invited presentations that all attended and then about 5 rooms running simultaneously.  There were 140-180 attendees.

I proposed a session titled “Ferreting out Customer Needs.”  It was more popular than I expected.  I anticipated leading a discussion with a dozen people around a table like the first session I attended.  Instead I found myself giving a podium presentation in the biggest room with 2 screens before about 70 people.  Good thing I decided to type my notes into Powerpoint instead of Word at the last minute.  Risk management, you know?

Still, I did go through the room asking everyone why they attended and what they hoped to learn.  My focus was on the importance of understanding your customers’ needs and how to do that.  Yet three people wanted help making their customers understand they don’t need features they were demanding.  I think all three were from software companies.

My bias is to assume in a case like this YOU are the one not listening to your customer.  I diplomatically hinted at that but did not provide the definitive and fair answer they deserved.  I might be right but it occurred to me later that one of the tools that I talked about could be used to address this question.

The concept is simple.  Customers have needs.  They buy products (and services) that offer certain benefits to meet those needs.  Features provide the product’s benefits.  Engineers design features.  Someone has to do a mapping between the customer needs and product features.  (Often that will be the product manager.)   This is how you insure the engineers are working on the right features.

Not doing so means you spend a lot of time and money on features the customer won’t value (i.e. pay for) because they don’t meet any need.  Moreover, you risk completely missing customer needs leaving an opening for the competition.  After all, the single largest reason for product failure is developing products that don’t meet real customer needs.

This concept is easily pictured.

CUSTOMER has        PRODUCT        ENGINEER designs
____Needs___==>   Benefits   <==___Features____
……..need 1                                         feature 1
……..need 2                                        feature 2
……..   …                                             feature 3
……..                                                  feature 4
……..                                                  feature 5
……..                                                   …

If you can’t map a feature to a need, that’s a sign it shouldn’t be there.  If you have needs not met by any feature, they have to get into the product requirements and you have work to do.  This is a good tool to help you focus on the features you should develop and to put off those you shouldn’t.

What if you think your customer is demanding features they don’t need making you waste time and money?  The first possibility is that you really don’t understand their needs.  You need to revisit your voice of the customer work to see what you missed.  The second possibility is that you are right.

My answer in either case is that you should sit down with your customer with the lists of needs and features and map the connections together.  The customer might put needs on the list that are supported by the features you thought were unnecessary.  Or you might be able to demonstrate to the customer that these features do not connect to any of their real needs.  Be aware that emotional needs may not be obvious yet can be more important than any functional need.  An unused feature may provide a feeling of security for example.  “It’s there just in case I need it.”

This is a good exercise in any case and is likely to lead to surprise learnings for both of you.  The process should also bring you closer to your customer and that can’t be bad.

Can you outsource product management?

Monday, September 29th, 2008

Does that make sense? Alyssa Dyer took on this question in an article I came across while cleaning up. I saved it because I agreed. It depends. It can be a good thing in the right circumstances and with the right division of labor.

When you need a partisan. Some things you don’t want handled by an outsider — for instance, representing your company at conferences or in sales situations.

When you need a mercenary. There are tasks that an outsider may do better. Alyssa cites gathering requirements and prioritizing them. I would sharpen that to include the front-end market research like voice of the customer (VOC) activities.

The key is that you need to hire someone experienced. They will likely be more skilled at asking the necessary “why” questions and they are less likely to hold the biases about your customers that pervade your organization and industry.

She cautions against hiring a telemarketing company because they are typically about asking “what” questions. I would expand this to include many of the traditional market research companies that might hold focus groups and ask “what” people want, “what” they prefer. Gerald Zaltman tears the market research community a new one in the first part of his book about “how customers think” for exactly this reason. Also, because those kind of methods influence the answers you get. They are right for refining your solution but wrong when defining the product and requirements.

Experience also helps you know when you’ve gotten enough information. I recommend Abbie Griffin’s paper listed on our Resources page for more about when your sample is enough.

Obviously it’s an interesting topic to me since clients outsource key product development and product management services to Breakthrough NPD. The things we excel at and do that are on her list include:
# Customer research
# Gathering requirements
# Prioritizing requirements
# Competitive analysis
# Positioning and message validation
# Website review and alignment
# In-depth quality checks with customers
# Setting up and running a customer feedback council

In fact, anything that is best served by a neutral 3rd party, like calling customers or reporting up to management, is a good candidate for using an external party. Outsiders have less to lose by giving management the facts especially when they aren’t pretty.

We do some product management functions that are good for outsourcing if we have the right experience but are likely to engage a partner or provide a referral instead. For example,
o Sales tool development and review
o Evaluating and conducting a release debriefing (lessons learned)

And there are the product management functions she lists that we generally don’t do but we might be able to make a referral.
— Win/loss reporting (it is good to keep sales dept. bias out)
— Pricing
— Planning and managing product launches

So when is this good for your organization? Bringing in help to take on some of these product management functions makes sense at these times:

1. As a stopgap until you can fill the job internally or with a new hire. (Keeping the product moving, cutting down schedule risk, keeping work from piling up).

2. Helping deal with the backlog of PM tasks that built up while searching for your new PM.

3. Bringing in experience to raise the level of your internal PMs.

4.Breaking outside the box created by internal biases. (To make big innovation steps.)

With the economy tightening I think a lot of companies will cut back on new development. Outsiders can help with specific tasks or projects to help you survive with a smaller staff during a lean period. They can also help you manage risks. That’s more important when you have less margin of safety. Furthermore, smart companies know that the lean time is a good time to prepare new products because by the time they are ready the economy will have turned around and you’ll have something new to capitalize on the upswing while your competitors get left behind.

“Is it possible to outsource your product management?” Alyssa Dwyer, Mass High Tech, Feb. 9-15, 2007, p12.

The Voice of the Customer, Abbie Griffin and John Hauser
(scroll to the end of list)

How Customers Think, Gerald Zaltman

Hey, why not let everyone help develop your products?

Friday, June 27th, 2008

Another way companies are breaking down the barriers between themselves and their customers or other folks outside is via “crowdsourcing.” That is a way to get people on the outside to provide value to the organization on their own time. It is essentially the open source model applied to more than just software.

The best example I know is the Goldcorp story. Their president put all their proprietary geologic data for a mine on the web and held a contest. The winners with the best ideas of where to drill would share half a million dollars. The diversity and originality of ideas they received was far beyond anything they anticipated. Years later they were still drilling sites suggested by contestants. They were mining so much gold they were the only gold mining company that was stockpiling for better prices in the future. Furthermore, their stock price went up thirty fold. (See Taylor’s book referenced below.)

The internet and the decentralization of expertise has enabled crowd sourcing and it is typically used to develop solutions. That is at the back end of the product development process. Companies can gain key advantages via crowd sourcing.

achieving goals not possible with a limited fixed staff

This is the advantage of scale. For example, large companies experience many more customer demands for new products than they can keep up with. Some have formed external networks to act in an advisory role or even do project work directly (as in the Goldcorp example) to develop more new products. NASA has used volunteers to process enormous amounts of data making images available months earlier and freeing up researchers to concentrate on higher end work. Google essentially uses crowdsourcing in the way it ranks pages for its search engine.

access to a larger number and far more diverse range of ideas than possible in-house

I think William Taylor says it best in this chapter title from his book Mavericks at Work: Ideas Unlimited: Why Nobody is as Smart as Everybody.

Inviting people from other boxes to work on your problem is a pretty easy way to get real “out of the box” thinking.

I see parallels to the kind of work we do at the front end to understand the problems you should be working on in the first place. You can use crowdsourcing methods to find out what the most important problems are for you to solve, as well as to craft solutions. That is, from voice of the customer to voice of the collaborator. We have actually done both here.

For more,
“On the Edge,” by Tim Gilchrist, PMI Network, May 2007, p32.
Mavericks at Work, William C. Taylor and Polly LaBarre, Harper Collins, 2006. (See Chapter 4.)

Flexible Product Development

Friday, September 28th, 2007

This month a new book hit the market “Flexible Product Development, Building Agility for Changing Markets” by Preston Smith. Some of you might remember him from “Developing Products in Half the Time” which he co-authored with Donald Reinertsen in 1991. That was a seminal work in the time-to-market field. His new book could be another big step in thinking for product developers.

I probably should say at this point that I reviewed several chapters for Preston while he was writing the book. I am mentioned at the end of the book with the others that helped out. The small contributions I made show up mostly in the sections on customer needs and risk management. Even so, any bias you may detect here has more to do with how I see product development rather than any loyalty to the book.

To oversimplify, Preston takes concepts from Agile software development, translates them, and where necessary adapts them, for people developing other things besides software. Hence, many of the concepts aren’t new, but will be new to much of the audience. At it’s core the material revolves around how to deal with change in a development project. It is that familiar struggle — setting the plan and requirements and working to them versus changing things late in the process. Scope creep and changes late in a project can blow costs and schedule off the planet. On the other hand, when the world takes a sharp turn on you, proceeding as planned can make the entire effort futile.

This book is about working so you can make changes later in a development project without disrupting the work or costs. It’s about knowing when to preserve flexibility, how to preserve it, and when you must make hard decisions. For me all this boils down to risk management, particularly trading off the risks on either side of these decisions. An interesting part of this book is that Preston goes beyond the typical risk analysis to discuss what to do about the unknown risks or the “unknown, unknowns.” (Now who made that phrase famous a couple of years ago? Never mind.)

Preston thinks bringing flexibility to the product development process is increasingly important today. First, is due to an accelerating and increasingly chaotic world. Read that as shorter timelines, rapidly advancing technology, global competition and more knowledgeable customers (they use the internet). Second, is because current management processes reward rigidity, which then runs organizations into the buzz saw of his first reason.

To me this exposes an open secret known to many who have labored under rigid development processes in the past or still do. That is, smart developers circumvent their company process when it becomes an obstacle rather than a support. These troublemakers know you can’t steam ahead when a sudden change in the marketplace or regulatory environment, or competition just pushed an iceberg in front of you. They know that salvation will come from reworking the plan, rather than working the plan.

If Flexible Product Development helps codify that common sense for more general use Preston will have helped product developers take another big step forward.

It is an easy read and I like that he ends each chapter with a summary list of the key takeaway points to remember.


A Tale of Two Conferences

Thursday, June 28th, 2007

Two very different innovation conferences: The Front-End of Innovation (by PDMA & IIR) and TiECON East (by TiE-Boston).

PDMA = Product Development Management Association
IIR = Institute for International Research
TiE = The Indus Entrepreneurs

I’ve attended the last few FEI conferences and have also helped organize the VOC conference for PDMA/IIR. After attending last year, I helped work on this year’s TiECON East. Since I have had the perspective of an attendee and an insider now of both I thought I might be able to make a useful comparison.

Both have been held in Boston for as many years as I’ve known about them.

Both have generally been in May or June.

No contest here. TiECON East was $300 compared to $2300 for FEI.

This is where it gets interesting. Both programs were essentially the same number of days, with special evening events and big name speakers. Cost did not correlate to quality in terms of the speakers. Whereas FEI had a VP from Google, TiECON East had a founding board member from Google. You can go down the list like that. FEI had a number of CEOs and VPs, some you’ve heard of some you haven’t. TiECON East had some very big names we all would know. For example, Reed Hunt, the FCC commissioner responsible for the deregulation that led to the telecom industry we have today. Or, Patrick Deval, the Governor of Massachusetts, though he had to speak via videotape at the last minute. In fact, Senator John Kerry, who was not even in the program, dropped in unannounced to speak to us for about 20 minutes! Even at the same price TiECON East would have been more attractive. At 7 times less expensive it is a real deal.

FEI had around 700 people, TiECON East had around 1200.

The most stark difference was here. IIR is a large conference organizing business that has a contract from PDMA to produce several of their conferences. My experience working with them on the VOC conference is that they are in it to make money. That colors their view of what is in the attendees’ interest. They also have a lot more say than volunteers on the PDMA side. So I saw them drop benefits to the attendees (like the book of slides) without the PDMA Chairman even knowing before we arrived at the conference. This is also the reason for the high cost. It was very hard to get innovative ideas into the conference because of the way IIR staff dominates what happens over the PDMA volunteers. There was a very large corporate feel to how they work. Not innovative (like what is preached at the conference) but what does happen is generally professional.

TiECON on the other hand was almost entirely done by volunteers from TiE-Boston. They had one group whose sole purpose was to come up with new and innovative ways to add value for the attendees (a very different mindset from IIR). At one point there were 8 separate initiatives being worked on. Some I’d never seen at other conferences. That fell to 5 due to the limited number of volunteers to work them. As in any volunteer effort, the quality varied, but the energy of the people involved was impressive. It should not be a surprise that working this had a feel that was more entrepreneurial. Not always efficient, occasional glitches, but great content and value for attendees.

Most of the attendees at FEI that I met are mid-level people working in large corporations. The next largest group may have been consultants and service providers. After that a few executives from smaller companies, academics, and press.

Most of the attendees that I met at TiECON East are entrepreneurs, wannabe entrepreneurs, officers in startups, venture capitalists, and service providers.

I just told you whom you’d meet at either. Both conferences scheduled time and events for people to meet and network, from breaks to dinners. Unique to TiECON East was music and dancing at the end of the dinner program.

Some of the innovations at TiECON East were to help the right people find each other. For example, at one event a number of entrepreneurs got to give short pitches or set up tables. This was for attendees, not exhibitors, to make their case and get noticed by the right people. The exhibitors had their usual arrangement nearby.

Speaking of exhibitors, at FEI they were almost entirely consultants, a few selling software and a business bookstore.

At TiECON East a lot of the exhibitors were VCs, bankers, and business service providers. There were some consultants as well.

First, you will learn a lot from both conferences. Neither is a waste of time.

FEI is a good conference if you’ve never been before and someone else (like your company) is paying the admission. Since I’ve seen speakers from the same big name places repeated year to year I don’t think it’s necessary to go every year (like I have been) especially if money is tight. It is expensive. It is particularly suited to you if you work for a large company. You’ll meet peers from other large to mid-sized companies and hear some very good speakers with experience relevant to you.

TiECON East is focused on a different market – entrepreneurs. This one is ideal for folks from small companies or anyone on a tight budget. Again, great speakers and interactive panel sessions but with a focus helping the little guy hit a homerun. (Read that as IPO.) They also seem to get bigger thinkers on the program.

On the topic of innovation, I’d probably recommend this for anyone. The cost is minimal. Moreover, the sheer energy of people excited with very new ideas is far greater. Folks from large enterprises won’t find as many peers but they will be exposed to new ideas and people for which innovation isn’t just their job.

The chairman of the FEI conference told me once that they studied small companies like the one I was with to “teach the big boys how to do it.” TiECON is a chance to mix directly with the little guys some of whom will change our world. The problem is you’ll have trouble telling who they are. Don’t feel bad. The VCs have the same trouble.

The conference links tend to go out of date so I’ll instead list the organizational links. You can look at their events to find these conferences.