Cauvin

One of the struggles that companies face in a competitive product environment is juggling feature constraints. For example, in the notebook computer industry, the following variables tend to trade off against each other: screen size and resolution weight I.e., a notebook computer with a large screen size and high resolution tends to weight a lot. This trade-off is problematic for prospective purchasers of notebooks, because: Most computer users are much less productive when they work on small screens with low resolution. It is difficult to lug around a heavy computer. Product comparison guides often exist in highly-competitive business such as notebook computers. Using CNET's notebook comparison guide, I set a filter to show only those notebooks with a screen size of 16" or greater and a weight of at most 7 lbs. Only five notebooks remained. Four out of five of these notebooks was an Apple. Apple seems to have done the best job confronting the screen size versus weight constra...

Jeff Lash pointed me to a couple of articles that he and Chris Baum wrote about transitioning from user experience to product management. You can read the articles here: Part 1 Part 2 A user experience professional is someone who designs a product's user interactions and/or interfaces. This role is sometimes called "interaction designer" or " information architect ". Jeff and Chris note: The most common conflict between user experience and product management roles comes into play when discussing what the product should do and how it should do that. There are often arguments about who should be responsible for defining the features and functionalities of the product. Product managers feel as though they should be responsible since they manage the product, but user experience professionals feel as though they should be responsible since they spend time researching user needs and interacting directly with customers and users. I have a slightly different...

When you are deciding on new products and strategies for your company, do you miss the obvious step of actively soliciting input from existing and prospective customers? If so, you are not alone. Luke Hohmann tells us about a recent experience in which a company had put together a new product development group. Their process included a number of inputs but conspicuously failed to mention input from customers. It's easy to neglect activities like visiting and interviewing prospects, because many executives are busy fighting internal political battles or feel that the customer contact through sales or customer support is sufficient. While the product managers that work for you should be gathering input from internal sources, their main responsibility is to understand the customer through direct, facilitated contact.

Yesterday, I signed up for a Jyte account. As usual, I'm following the lead of my "early adopter" friends, Brandon and Cote . Members of Jyte post "claims" (statements that may or may not be true). Jyte scores the claims based on the votes of other members. I posted the claim, "The best brand names are not descriptive of the product or service." As I type this entry, the votes are 86.7% that the statement is true. Sign up and go here to express your opinion.

In my last entry , I introduced the notion of using conceptual models to estimate the cost and duration of a software project. In this entry, I outline a process for doing so. Compose a conceptual model of the system. Typically, most of the nouns mentioned in use cases appear in the conceptual model. Identify concept clusters. A concept cluster is a group of related concepts. Groups of concepts that have many associations among them are good candidates. Concept clusters roughly correspond to the components of the system assignable to different teams of developers. Count the number of concepts in each concept cluster. The number of concepts in a cluster is roughly proportional to the level of effort required to implement the corresponding component of the system. Assign a concept multiplier to each cluster. A concept multiplier represents the number of man-hours it will take to implement the functionality related to a single concept. In some cases, the multiplier for the concepts ...

Over on Tyner Blain, you can read Scott Sehlhorst's in-depth look at estimating the cost and duration of a software project with use case points. The method Scott describes is a functional estimation method. In this entry, I introduce an object-oriented estimation method. Estimating the cost of a software project requires knowledge of the architecture of the product. I.e., in order to know how much time and effort it will take to develop the software, understanding the requirements is not sufficient. You have to delve into the architecture (high-level design) of the system. Use cases describe part of the information architecture of the system. In particular, they specify the interaction design; i.e. the way users interact with the product to achieve their goals. Use cases are functional decompositions of the system. Scott's recent series of blog entries focuses on estimating with use cases. Conceptual models are a starting point for describing the conceptual architecture...

Information architecture specifies the design of information exchange between the user and the product, in particular: How the user interacts with the product. What information the product presents to the user. What information the user supplies to the product. Use cases and screen mockups are examples of information architecture specifications, since they both describe user interaction and information exchange. User interaction designers and user interface designers are information architects. FYI, the Wikipedia entry on information architecture notes: An alternate definition of information architecture exists within the context of information system design, in which information architecture refers to data modeling and the analysis and design of the information in the system, concentrating on entities and their interdependencies.

A use case is a sequence of interactions that a user makes with a product to achieve a goal. When your user interaction designer fleshes out use cases, she has a wide range of choices of how specifically she describes the interactions. If she chooses abstract language that is relatively free of technology and design assumptions and user interface details, then the use case is essential . If, on the other hand, she specifies concrete steps that assume technology and design commitments and details about the user interface, the use case is real . Essential and real use cases are on the extreme points of a continuum. No non-trivial use case is purely essential (often, the very order of steps in a use case represents a design decision), and no level of detail in a use case can render it purely real (there is always some room for developers to make additional technology choices).

You're probably familiar with Wikipedia , but have you checked out Citizendium ?

Robin F. Goldsmith gets (registration required) it. Sorting through the maze of so-called business requirements, system requirements, functional specifications, and software requirements , he counsels us about what the REAL requirements are: REAL requirements are business requirements, which are in business terms and are what must be delivered to provide value. He then remarks that what many in the requirements community call "system", "software", or "product" requirements are in fact design: System requirements represent a human-defined product or system which presumably is one of the possible ways presumably how to accomplish the presumed REAL business requirements. As such, system requirements actually are a form of high-level design. Finally, Goldsmith tells us that failing to recognize that so-called system/software/product requirements are in fact design has practical negative consequences: The primary reason products/systems don’t satisfy the REAL...

Does listening to customers mean reacting to all of their feature requests? No, according to Jeff Lash: Reacting to each individual request will take up all of your time and leave you with a product with no discernible focus and a hodge-podge bunch of reactive features without clear benefits. To maintain product focus and deliver value, cut through feature requests to understand the core problems to solve for customers.

Recall that one way to determine whether a requirement is design-free is to consider a fantasy solution : Consider the problem that a requirement is supposed to address. Think of the most desirable solution to the problem, no matter how unrealistic it is. If the requirement doesn't allow for this solution, then it contains design assumptions that you should purge from it. For example, for ease of use requirements, imagine the user could use telepathy or psychokinesis to accomplish their goals. Sometimes what might seem like fantasy solutions are in fact feasible. Last year, I cited research into "pass-thoughts", a technology in which computers read a person's thoughts to authenticate his identity. Now the Guardian tells us that a "team of world-leading neuroscientists has developed a powerful technique that allows them to look deep inside a person's brain and read their intentions before they act." This sort of technology opens the door to user inte...

Jeff Thull counsels us: The best way to develop exceptional credibility is through diligent preparation and thought-provoking questions. Prospective customers will not have confidence you are able to solve their problems unless you have asked them the questions necessary to understand what those problems are.

If the tests in test-driven development (TDD) drive product design, who needs requirements? Actually, some advocates of agile development contend that the tests are the requirements. Instead of composing a requirements document and then developing tests, they argue, just develop the tests. One flaw in this approach is that tests do not always directly reflect requirements. As I have argued before, requirements are testable in principle but not always directly testable in practice . A requirement straightforwardly captures and communicates a stakeholder need. Tests may indirectly ensure the product meets these needs, but they don't always do so in a way that communicates the needs in a clear and concise manner.

Test-driven development (TDD) is a product development practice in which developers develop tests before they develop the product itself. The purpose of TDD is to drive the design of the product by clearly defining, in the form of pass/fail tests, the criteria by which to judge whether the product satisfies the requirements. (Developers also employ TDD in developing the internals of the product, including "unit testing" of individual methods and classes in software products, but my focus in this entry is at the system or user acceptance level.) Developing tests first has several benefits: It serves as a requirements review. One of the best ways of ensuring that requirements are understandable and testable is to create tests for them. It forces product designers and developers to understand precisely what goals they are trying to achieve. In translating requirements into executable tests, the developer expresses them in measurable and concrete terms that she readily understand...

Steve Johnson recently wrote about naming products: There are two strategies for naming: descriptive or unique. Names that are unique like iPod, Nuvi, and RAZR work best for B2C products. For B2B products, the descriptive approach, such as that CA is following, is best. Certainly when you have hundreds of products, the name has to carry the positioning message along with it so that customers (and sales people) know what the product does just by reading the name. Johnson's claim is that B2C product should have unique names (which almost by definition are not descriptive of the product). Different guidelines apply to B2B products, he maintains; descriptive names are best for them. Johnson draws attention to an important branding distinction. Corporate branding differs from product branding. In a B2B situation in which a single company sells many related products, the corporate branding is arguably more important than product branding. A strong corporate brand will carry all of th...

Guy Kawasaki tells us common mistakes companies make that hinder market adoption: Enforced immediate registration. The long URL. Windows that don’t generate URLs. The unsearchable web site. Sites without Digg, del.icio.us, and Fark bookmarks. Limiting contact to email. Lack of feeds and email lists. Requirement to re-type email addresses. User names cannot contain the “@” character. Case sensitive user names and passwords. Friction-full commenting. Unreadable confirmation codes. Emails without signatures. Supporting only Windows Internet Explorer. Check it out for details.

A lot of military and political pundits have recently criticized President Bush's "surge" in Iraq as not being a new strategy, but merely a tactic. A strategy is a plan for achieving end goals. Tactics are the details that execute the plan. Execution is important. But tactics don't matter much if the strategy is flawed or doesn't achieve worthwhile goals. Are your marketing efforts heavy on tactics and light on strategy? If your company is like most organizations, then chances are you are wasting a lot of time and effort on tactics and paying short shrift to strategy. Instead of asking tactical questions such as: Who is going to write the next white paper? Who is going to man the booth at the next trade show? Who is going to design our web site? Who is going to design our brochure? You should first be asking strategic questions such as: What types of people will buy our product? How is our product different from our competitors' products? What are our customer...