Customers are not always good at explaining needs or product issues. They may not even know enough about the product to realize possibilities that they are missing. Just asking customers about a product is not enough. Usability labs are useful, but nothing beats watching a customer use a product in their home environment.

In the early days of the company, Intuit had a program called “Follow me home”. Intuit product managers literally waited in the stores until someone bought software off the shelf (remember, that’s how we used to buy software!). They then asked the customer if they could go home with them to watch them use the software. One example they noticed was that users were having problems aligning checks up on their printers, so they introduced a feature to correct this issue. You can read more in a profile with Scott Cook, founder of Intuit here. Intuit moved into the small business market with QuickBooks when they realized that customers were using their personal finance software to run their business.

Another example that I came across in my thesis research was how Nissan engineers were surprised to see how often people were eating in their trucks when they went out on site visits. Engineers really got to understand the importance of the cup holder feature after some on-site visits.

I once spent two weeks on site at a customer during the initial launch of a major release of one of my products. It was eye opening. As a young manager, I was not sensitive to the issues that some older users were having reading some of the smaller fonts used in our product. The biggest revelation was the amount of customization and macros that users had created on top of the default shipping product. After experiencing customer pain firsthand, I persuaded our dev team to build a feature that automatically converted these macros to the new release format.

This all sounds good in theory, but how does it impact today’s agile development world? A true product owner needs to understand the market and his customers if he is going to be involved in design tradeoff decisions. You can’t do this sitting standing in a scrum meeting every day. The product owner needs to get out to visit with customers from time to time, and may not make every meeting. If anything really critical comes up, he/she probably has a smartphone these days.

They don’t always know what they want.

“Our plan is to lead the public to new products rather than to ask them what they want. The public does not know what is possible, but we do.”

                         – Akio Morita, former CEO of Sony Corp.
                           (As quoted by Barabba and Zaltman, 1990)

With all the emphasis that is placed on market research, voice of the customer, and listening to the customer, it’s worth remembering sometimes that sometimes you just have to ignore your customers. Sony is an example of a company that did not rely on market research. Early users of both Walkmans and VCRs were confused by the new products and showed little enthusiasm. Sony seems to have lost its way recently, and I can’t say that I’ve followed it closely. Did they just put too many costly features in the playstation? Perhaps they have started listening too closely to every customer request?

New Coke was introduced in the 1980s after undergoing extensive market research, but it turned into an expensive flop. After the fact, they determined that they had conducted their research using incomplete questions.
Market research is probably more useful for evolutionary product design, rather than for generating innovative new concepts. Some of the better marketing books that I’ve seen state that market research should be used to support decision making, and never as the primary basis for a decision.

Or what they want may not be a good idea …

My first job out of college was at Boeing. At the time, the company was in the middle of a huge new development of a major new airline, the 777. The innovative new feature in early designs was a folding wing. American Airlines, the launch customer, said that they wanted a folding wing on the 777. The idea was that the airplane would be able to fit into older, smaller airport gates if the wings could fold in half in the middle, almost like a fighter jet on an aircraft carrier. It seems bizarre now, doesn’t it? Most engineers at Boeing thought it was a bad idea – unsafe and heavy. Yet Boeing spent millions on early design feasibility. Then American Airlines changed their minds and they didn’t want it. That was the end of that. Sometimes you have to be prepared to tell customers what they are asking for is not a good idea.

OK, so the title may be a  bit extreme, but a good product manager should be able to have meaningful customer conversations that reveal customer issues and their goals, rather than just literally copying every feature request that the customer relates. Customer needs should be aligned with the technological possibilities that the customer may not understand. Use cases and stories are a great way to relate this type of information to the development team to get the conversation going.

Useful thoughts to keep in mind while planning new software releases.

The Product Management consortium in Seattle had a lively discussion over lunch last month about the role that social media can play in getting product feedback and providing product direction. I’m glad to see that there is going to be an event specifically devoted to this topic. I just signed up to attend on Wednesday. There’s been a lot of talk about how product managers can leverage social media to learn about their products and customers. It should be a good event.

I attended a good talk sponsored by the WTIA a few weeks back. Mike Repass the product manager for Google’s App Engine gave a presentation on Google’s world view of cloud computing. Given that they are in the early stages of development of cloud computing applications, Mike is relying heavily on the feedback of early adopters and Beta testers. Mike mentioned that Twitter has been a valuable tool for him in collecting and gathering user feedback as they build out the app engine functionality. (I hope that the WTIA will post this and the recent Amazon talk on the same topic on youtube, since they recorded the presentations.)

PowerTech Compliance & Security Assessment

At my last company, PowerTech, we provided a range of security solutions for the IBM mid-range server market. Many of the users of this expensive server equipment were simply not aware of the security exposures associated with it. They knew that they were keeping mission critical data on there. It was not unusual to find IT groups that were oblivious to the regulations with which they had to comply. PowerTech developed a tool that assessed the security configuration of the servers and presented a report with recommended remediation.

We did a nifty job of exposing the data in Flash interface in a browser. You can see an example here. Ratings and recommendations were updated based on the data found on the server. Everything was tied back to CobiT and the ISO 27002 standard – essentially educating customers about their audit requirements.

At PowerTech we also published an annual security study based on the results of audit assessments that we conducted every year. It got some great coverage in the press (i.e. ComputerWorld). It established credibility for what the company was doing. The best type of marketing is free publicity. You can’t beat the ROI when your initial costs are close to zero.

I’ve also seen a lot of debate lately on where the product management role fits in an agile development environment in webinars and blogs. We had a lively discussion at a Product Management consortium lunch meeting on the Eastside. The Cranky PM has got the most comments ever on one of her posts on agile. John Dex got a spike in traffic at his blog when he posted that “Agile broke product management“. Dean Leffingwell has a very good series on this topic alone. The product management community is still trying to figure out how best to work with agile methodologies.

Here is what the people of goodagile.org say in their  Scrum primer . It’s one of the better introductions that I’ve seen to scrum techniques, although I don’t agree with this statement:

“However, the Product Owner is somewhat different than a traditional Product Manager because they actively and frequently interact with the team, personally offering the priorities and reviewing the results each two- or four-week iteration, rather than delegating development decisions to a project manager.”

Perhaps I’m not traditional, but in my experience a good Product Manager should be actively and frequently interacting with the dev team. The Product Manager needs to be the respected go-to person for questions about the market or customer needs. Maybe this was easier because I have worked at smaller companies recently. Product Owner is a subset of what a good product manager should be doing. Product Owner is primarily tactical and Product Management should also have a large strategic component. Ideally, the Product Manager should be the CEO of their product, dealing with pricing, promotion, and competitive issues and setting out long term strategy and vision.

In larger companies, this may be too much work to load onto one person and some division of responsibilities needs to occur. The Product Owner role still needs to report into the product management team to maintain that connection with the overall product strategy. The big challenge for product managers is to maintain a strategic vision while dealing with ongoing day to day tactical issues.

Of course, one size does not fit all. Size of company has a big impact on how roles are organized. There is a big difference between an internet startup and an established enterprise in a regulated industry. Teams may also have to adapt depending on the people that are available and their skills. I have never worked on a project that has been a pure implementation of waterfall, and I have never worked on a project that has been a pure implementation of agile. Companies and teams always selectively adopt the methods to suit their needs.  

1.       Use market research to collect information about your customers and their requirements. Focus groups can be adapted to suit the needs of your development project. The web is a very convenient and appropriate way to collect information from software users.

2.       Involve customers throughout the product development cycle.  Beta testing is too late!  Bring customers on site regularly to review prototypes and to participate in usability testing.

3.       Visit customers to understand their requirements. Include all development staff on “direct observation” visits –programmers, testers, technical writers, and customer support.

4.       Prototyping should be used throughout the development cycle to elicit feedback from customers on the progress of the design.  Management should also use prototypes to establish milestones to control progress.

5.       The person that documents or writes the requirements specification should stay closely involved throughout the development cycle and see the project through to completion.   Ideally, this will be someone in a role like a product manager, who acts as a technology integrator between marketing and development.

6.       Competitive analysis is a key source of input.  Monitor the press and newsgroups, and listen to what your users are saying about other products.  Use competing products when possible.

7.       The requirements phase is crucial in the overall software quality assurance effort.  The firm should make a strategic decision about the level of quality that they wish to obtain in their products.  This decision will affect the software development process in general, but especially the requirements phase.

8.       Project selection should be related to customer needs and activities. Use techniques that concentrate on customer usage scenarios.  Competition between different technologies and groups should be avoided by planning for multiple projects and multi-product families. 

9.       Establish a clear and consistent vision for each major release, which is closely aligned with the overall company strategy.  The vision may consist of a few broad themes, but it should not consist of too many competing goals.  Senior management should review progress to ensure that the development goals are aligned to company strategy.

2, 4, 5, and 8 fit in very well with an agile product managment philosophy. I’ll expand on those in more blog postings. I’ve already thought of some others based on my experience in the real world. More posts to come …

A thesis was required as part of the degree program. I chose “The Requirements Phases in Development of Software Applications”, advised by Prof. Michael Cusumano.  My goal was to look at the best practices across established industries and then to see if there were lessons to be learned in the software industry. I featured case studies of SAP, Microsoft, Intuit, Netscape, and Yahoo along with research of available literature.  Four of these still exist as independent companies. Netscape was acquired by Sun before I completed my thesis, and Sun may be taken over by IBM any day now. Yahoo almost became part of Microsoft.  These aren’t the only changes. A lot has happened in the last 10 years, specifically relating to my work and this topic:

·         Agile Development and Scrum are firmly established and widely used.  I read/heard somewhere that more than 45% of companies are using Agile techniques now.

·         I’m older and wiser. At the time I did that research I had primarily a technical background. Since then I have 10 years of practical experience working in product management at 3 different software companies – typically building enterprise software for business customers.  Research is one thing, but it also helps to look through the lens of a company that is pushing to make next quarter’s number.

·         Web 2.0, Social media, YouTube, blogs, Facebook, Twitter etc. are impacting the way that we develop products and interact with our customers.

Now I have just finished with my last company after it was acquired. What better time to dust off my old thesis work and take a look at it again. It’s time to review what’s relevant, update it with what’s new, and lessons learned. Instead of letting my work gather dust on a shelf in dark corner of the Dewey library at Sloan, I can share it with the world now. At least that’s the plan as I start my blogging journey. My first post will be a review my conclusions from 10 years ago, and then through the blog I’ll explore each of the topics in more detail, updating with latest thoughts and insight.

I’m sure that there will be diversions along the way. It is a blog after all. One of my favorite reads in the last year was Bill Simmons, the sports guy, at ESPN sharing about his dog – “Ode to the Dooze”.  Rather than talk about some of the day to day tactics, frustrations, and challenges of product management, I hope to focus on strategies for new product development and innovation. I’m sure I’ll find some time for some book reviews and occasional rants. Oh and let’s not forget some of the other good stuff, that’s happened in the past 10 years.

The Red Sox won the world series. – twice! Ireland won a grand slam in rugby. Wonders never cease.