Monday, January 23, 2012

New Product Development & Projected Users

In developing new products it is important to start with customer needs, but understanding user needs is not easy. As there are no single user type, most users have a common need but have different use cases. It is therefore not possible to identify all the user needs and then start developing products to meet those needs. Instead, it is better to create an abstracted class of users - called as "Projected Users" and then list out the product needs in a generic way - which then leads to projected product specifications.

The notion of Projected Users is a very powerful tool especially when developing a new-to-the-world kind of products such as iCloud or iPhone. As the users have never seen or used such a product, identifying the user needs is doubly difficult. The idea of Projected Users helps in a big way.

Projected Users Concept

Developing new products is very expensive. When a company is developing new-to-the-world type of product, the expense for understanding user requirements cannot be easily justified and quantified. In that stage, there are no customers and hence there are no "real" customer use cases. Therefore one cannot really document the customer needs either. To overcome such challenges, it is vital to create an abstract class of users called as "Projected Users" .

The projected users is essentially a vision/view of the product developers/designers on how customers will use the product and why. The early users of this new product will be the product developers themselves. So it is very important that all the developers have a very good understanding of the basic customer needs - i.e, the basic problem and then start visualizing the customer use cases that arise from that need.

For example, while developing the requirements for a secure authentication system, (see: Need for a Central Multi-Factor Authentication as a Service ) there were no real users - but we started with a real need. Once the real necessity for the product is fully understood by all the developers, then one can start visualizing the use cases - which then can lead to real product development.

Defining the Projected User

Once the basic product need is understood, it is very important to define the "project user". It is very important to characterize the "Projected User" - i.e., start giving a personality to the projected user: Age group, Gender, Income, Education, Lifestyle, etc.

Developing a personality of the Projected User has four distinct steps:

  1. Develop a user profile
    Define the user demographic/physcographic profile. Understand the user needs in context to the product usage.

    Having a deep understanding of users can help development team better understand the wants & needs of the targeted customers. This will help the development team relate better with the target user.

  2. Develop user tasks
    Define the physical and cognitive operations done by the user to perform a task with the future product. i.e, How the user will use the product to perform a task.

    Understanding user tasks helps in developing design solutions that will ensure that the user expectations are met & avoid design errors and customer frustration.

  3. Develop a focus group
    Create a group of real people who match the user profile as closely as possible. The focus group is used to understand the user environment, the use cases and user needs.

    This provides an early insight into the product concept acceptance, user behavior, and desired feature sets in the upcoming product.

  4. Market Survey
    Market survey is usually done to collect data about target users and customers. This is necessary to validate certain assumptions or to collect actual field data.

    This is particularly important when target customers are widely dispersed and rich quantitative data is needed to build accurate business models.

Benefits of Projected Users

Creation of Projected Users requirements is a must in developing any new-to-the-world products. Often times while developing such new products the product design and development gets influenced/driven by inventor's or developer's perception of user requirements - and leading to product disasters.

Creating a projected user models will keep the development team rooted to a realistic user requirements and minimizes user frustration with the real product.

For example, while developing a software product I find that most of the developers are very comfortable using a command line interface, and developers start assuming that all the customers are comfortable with UNIX command line interface, then when the final product reaches a Gen-Y user, the product will fail to excite the customer.

While developing a new "touch screen" phone, Blackberry developers built-in a sliding keyboard in addition to the touch screen - see Blackberry Torch 9800 (http://us.blackberry.com/smartphones/blackberrytorch/). Soon after launch, the product bombed. Critics lashed out at Blackberry for missing out on the real user interface requirements.

On the other hand, Apple's success with iPhone was due to its extensive insights into projected user needs and was based on observations & learning's from Apple Newton, iPod, Palmtop devices - from Palm, HP iPaQ etc.

Dealing with Design Errors

A Projected User is an imaginary user which does not exist in reality. So when the final product come out in the market, the real customers may have few ideas to make the product better and may give suggestions to correct the design faults.

At this stage, it is vital to observe the actual customer behavior, customer use cases and then start redesigning the product to fix the early design errors. Typically it takes 1-2 additional revisions to get the final product. These revisions must be rapid and the final product MUST meet real customer's expectations. Trying to override customer objections will not work. At this stage, there are real customers and real users of the product, so it is time to retire the projected user concept and start working with the "real" customers to improve the product.

Another example is Google Chrome Book. The Chrome Book was developed by engineers using laptops - thus designed a "NET Ready" laptop computer - when the real users wanted an iPad! Google was quick to realize this mistake and worked on Android tablets.













Closing Thoughts

Developing new products is difficult. Developing new-to-the-world products are doubly more difficult, developing a successful new-to-the-world category product is infinitely difficult.

Developing a well defined "Projected User" is the best way to visualize customer requirements, define product requirements and develop new products - when there are no real customers to start with. Once the product is released and real customers exist, then work with customers to enhance/improve the product till it gains wide user acceptance.

No comments: