Archive for the 'Management' Category

Product Camp Boston and “ignorant” customers

Saturday, November 14th, 2009

PRODUCT CAMP
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.

MY SESSION
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?

IGNORANT CUSTOMERS
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.

MY ANSWER – MAP FEATURES TO NEEDS
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.

NOT TO OUTSOURCE
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.

BETTER OUTSOURCED
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.

WHO TO OUTSOURCE TO
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.

WE WILL DO
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 MIGHT DO
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)

NOT FOR US
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

WHEN TO OUTSOURCE
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.)

IN A TIGHT ECONOMY
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.

References:
“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

Trends You Need to Know

Saturday, July 12th, 2008

The June 2008 PMI Network magazine lists 5 business trends we all need to know about … or else. Future survival gets my attention. The thing that stood out to me was how important the ability to understand needs will be for all 5 trends. To me that means increasing value for the kind of “voice of the customer” skills we practice going beyond customer research. Let’s take a look.

TREND 1: THE BATTLE FOR THE RIGHT PEOPLE
A technical skill shortage is developing across all regions and markets. Even the low cost talent pools in India and China are drying up. Looking forward that means companies need to get better at two things:
— recruiting top talent
— managing talent internally

Well, if you want to attract good people, you need to understand what makes them tick, what they need and want. Then to keep them you also need to understand and meet their needs. So VOC skills are an advantage coping with this trend.

TREND 2: THE RISE OF EMERGING MARKETS
Emerging markets are the part of globalization that is breaking growth records. Most companies don’t do a good job of understanding their domestic customer as it is. Then they hope to develop products for, and sell to, a different culture? Good voice of the customer work is even more important and more tricky in this context.

For example, Breakthrough NPD supports foreign clients but with a catch. Unlike the U.S. & Canadian markets where we will do everything if requested, we only do certain parts of VOC work overseas. We train our foreign clients in VOC methods and we will coach them, even being in the room as they conduct customer interviews. The key difference is that a native familiar with the language and culture must conduct or lead the customer interactions. They must ask the questions and interpret the answers. Keeping bias out of the process is hard enough and would be much harder with the filter of outsider bias in the way as well. We can provide a neutral and unique perspective that ads value to the interpretation but should not be driving the work.

TREND 3: INTERACTIVE INNOVATION
This boils down to using Web 2.0 tools to incorporate customer needs into your business at every level. That is, from core business strategies and project goals to testing new product concepts and getting feedback on your existing products and services. Examples are having your own internet forums, blogs, social networks, on-line communities, customer advisory boards and so on to better understand customer needs. This essentially means expanding what we do now to define new products and their requirements to also help guide the business and improve operations.

TREND 4: REALISTIC RESPONSIBILITY
This is taking responsibility for the impact of company actions on communities, stakeholders and society. Social responsibility is going from a “nice to have” PR stunt to standard operating procedure for good business reasons. This involves a wide range of things from labor practices, living wages, health and safety, civic infrastructure, environment, etc. I’ll admit that the link from VOC skills to this trend is weaker but they still will give you clearer vision of your impact on everyone else.

TREND 5: THE HERE AND NOW
Globalization has pushed companies into 24/7 schedules and operations. With this comes the push for quicker returns on investments. Obviously this is about running faster. Less apparent, it is about being more clear on what you need to achieve. You can do more with less if your goals are clearly defined. That means continuously tracking the needs and goals of the end user, establishing methods that allow your teams to react to changing business needs, and prioritizing what can or should be done in view of the larger context. The best way is to involve customers, stakeholders, and advisors throughout your projects. Again, skills to acquire input and understand your customers will be invaluable.

A medical device case study in the article illustrates that this goes beyond getting the specs right. I think this quote from the company involved makes that case well, “customers jumped at the chance to participate once they saw we cared about their needs.”

Let me emphasize the “we cared about their needs.” The bottom line folks is that it is all eventually about the people. It is about the individuals whose lives are benefited or burdened by your offering.

Do you believe these trends are real and will affect your business? If so, you should also see that getting better at understanding the voice of the customer, (broadly defined), will be important to benefiting from rather than being buried by these trends.

For more on the trends:
“Pay Attention,” Sarah Fister Gale, PMI Network, June 2008 ps 35-41.

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.

FULL DISCLOSURE
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.

IN A NUTSHELL
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.)

WHY?
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.

COMMON SENSE
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.

Details

Strategy Paradox Meetup

Monday, April 2nd, 2007

I met Michael Raynor at a book launching event that was notable for two reasons — first, the thesis of his book and second, the nature of the event.

THE THESIS

The Strategy Paradox arose from Raynor’s observation that companies that dramatically succeed or fail have much more in common than mediocre companies that just get by. Spectacular success requires taking large risks and committing to your path. Unfortunately, if you commit to the wrong path you crash. The paradox is how can you ask people to commit and manage uncertainty at the same time? His solution is that you don’t. You separate these functions within the organization. The very top management should focus on managing uncertainty at the strategic level, leaving division heads to totally commit to their mission without fear of reprisal if they’ve been given a losing horse to ride. I’m probably not doing justice but to say more will spill out of the nutshell.

It was interesting to see the “revelation” of managing uncertainty to the executive business world when risk management has been a science in systems engineering since before I was born. Coming from a background in systems engineering I thought this was a place where some cross-fertilization would have been helpful to him. No matter, I agree with him that executives at the top should have more understanding of it and should take strategic responsibility. If his book helps that to happen it’s a contribution. I also think his observation about the tradeoff between the commitment to blast through barriers and the flexibility needed to lower risk is a keen insight.

Working for Deloitte, his experience has been with large enterprises and his book is directed at the leadership of the same. That’s great when you are large enough to have division heads below the corporate headquarters. His observation certainly applies no matter the size of the company. But, …how well does his solution translate to small companies? I asked him how small a company could be and still benefit from his prescription. He agreed that at some point you can’t separate those functions but didn’t know how far down you could go.

His take on startups was that they commit to their one big idea and then make it or crash, c’est la vie. Amusing but clearly a view from the enterprise world. We help startups dramatically improve their odds, most importantly by making sure they understand their customer and the problem they are solving before solving it, but also via standard risk management practices. Just because you are a startup doesn’t mean you can’t place more than one bet. Even with one big idea, you can have a “portfolio” of paths to do it, a “porfolio” of markets to try it on, etc. So though his prescription may only be suitable for large companies, his concept may very well translate into other presecriptions for startups. In fact, if someone were to study startups successes and failures they might see uncertainty management a vital part of the story already.

When I finish the book I’ll review it in more detail and there’s a good chance I’ll like it well enough to include on the resources page in our knowledge center. Knowledge Centerl

THE EVENT

The event itself was even more unusual than the book. It was best summarized by two words, “new media.” For example, it’s the first time I’ve ever signed myself up via a wiki. Strategy Paradox wiki It was a new twist for me but an interesting one. It let’s you get familiar with many of the strangers you’ll meet before you even get there. (Though some don’t show.)

Most surprising was that three quarters of the people there were not close to the target audience of Fortune 1000 executives or even business people that I expected. In fact, most of us present from the business side run or work in businesses too small to employ his suggestions. The Deloitte employee that organized this innovative event is deep in the “new media” community so most of the attendees were creatures of the blogosphere. That is, his e-friends and their network, or in other words, people whose lives revolve around digital communication about digital communication. So most of the people there were more excited about the new media way the book was being promoted than the book itself.

At Breakthrough NPD we are trying to come to grips with Web2.0 and you can see on the wiki sign up one attendee is already tired of Web2.0 and ready to move on to the next thing. One man I met publishes 4 blogs and 2 podcasts a week on his multiple websites. For these folks it was much more about the buzz, and creating buzz, in this case buzz about the book, than actually reading or using it. The book and event is something they can blog about (as I too am doing) and link up their posts to each other to drive more traffic, get a higher Technoratti rating, and so on. It seemed like it’s about handling more buzz than what one is actually buzzing about. As an outsider to this new media world I’m sure I’m painting with a little too much black and white. The people I met were quite nice and very entertaining. Without a doubt I got a taste of the future.

Other blog posts on this event.

Posts about it beforehand
(Notice these talk more about the book.)

Marksguide
Leadership Now

Posts afterward.
(If you look at any of these notice how much talk is about the event rather than the book or its concepts.)

Paul Gillin
Pardon the Disruption
Bryper