Apple Juggles the Notebook Constraints

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 constraints.

Unfortunately, none of the notebooks supports full 1080p HD resolution.

User Experience and Product Management

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 take on this issue.

Since one of the primary responsibilities of a product manager is to thoroughly understand the prospective users of the product, it's natural to conclude she should design the user experience. Yet a primary responsibility of an information architect is to be an expert on the principles of user experience and how to maximize usability. So it's also natural to conclude that information architects should design the user experience.

Jeff and Chris resolve that the product manager is the final arbiter:

Ultimately, since product managers are responsible for the overall success of the product, they are the final arbiters of what the product should do. A good market-focused product manager understands the market context and customer needs and makes appropriate decisions about features and functionality based on first-hand experience and all available research.

but that the product manager should take input from user experience specialists:

Good product managers understand the role and importance of user experience specialists. They value their input and use their research and recommendations to create good products. Just like the president takes advice from cabinet members, product managers should use their cabinet members—user experience, marketing, technology—to inform decisions that they need to make.

I resolve the apparent conflict a bit differently than do Jeff and Chris. To me, the user experience responsibilities of a product manager and information architect are as follows:

A product manager frames the usability metrics. What usability problems do users need to solve or avoid? Are they afraid it will take too long for them to learn to use the product? Are they afraid it will take too long for them to accomplish their functional goals? Based on his understanding of users, the problems they are trying to avoid, and their tolerances, a product manager specifies the ways of measuring these aspects of usability and places constraints on them that will be acceptable to the user and the market.

An information architect designs the user interactions and interfaces that will satisfy these usability metrics. How will the user interact with the product to achieve her goals? What interface will the product present to the user? An information architect answers these questions by fleshing out use cases and composing screen mockups.

Some product managers have a knack for information architecture and can play both roles. Either way, the two roles should work together for the best chance of product success.

Product Strategy in a Vacuum

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.

Jyte Claim and Branding

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.

Conceptual Models and Estimation: A Process

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.

1. Compose a conceptual model of the system. Typically, most of the nouns mentioned in use cases appear in the conceptual model.
2. 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.
3. 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.
4. 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 in one cluster will differ from the muliplier for concepts in other clusters. This step requires close consultation among product management, architects, and developers to determine the most realistic multiplier.
5. Compute total man-hours. The total man-hours is equal to the summation of the products of the number of concepts in each cluster and the concept multiplier for that cluster.

After estimating the project using this object-oriented method, you can compare the results to estimates based on a functional estimation method.

Introduction to Conceptual Models and Estimation

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 of the system. Conceptual architecture is the partitioning of the system into components assignable to separate teams of developers. Conceptual models are an object-oriented decomposition of the system. As such, they expose the portions of the system that are eligible for shared use.

A desirable characteristic of a system architecture is that, to the extent possible, components of the system service multiple use cases. Conceptual models provide an architect with the first clues about how best to partition the system into components that maximize this sort of sharing. Done properly, more component sharing typically translates into substantial reductions in development time.

In my next entry, I will outline a step-by-step process based on conceptual models for estimating the cost and duration of a software project.

What Is Information 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.

Essential and Real Use Cases

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-trival 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).

Citizendium

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

REAL Requirements

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 business requirements is because the REAL business requirements have not been defined adequately. In turn, the primary reason the REAL business requirements are not defined adequately is because conventional requirements models mislead people into believing that system requirements are the requirements and thus warrant all the attention.

Confusion over requirements concepts is not just a semantic or academic issue. Goldsmith recognizes that product development organizations are losing sight of what a product really must do and be to create value.

Feature Requests

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.

Mind-Reading UIs?

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 interfaces based on reading people's minds.

Credibility through Questions

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.

Tests and Requirements

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.

What is Test-Driven Development?

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:

1. 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.
2. 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 understands.
3. It ensures on-going adherence to requirements insofar as developers run the tests regularly.

In an agile product management environment, product managers update the requirements iteratively as development uncovers unanticipated customer needs. Developers update the tests accordingly, and the new tests drive changes in succeeding iterations.

B2B versus B2C Naming

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 the products, and the decision-makers at the businesses that buy them may care more about the corporate reputation than the image of the individual product. In such cases, a descriptive product name still carries the weight of the corporate name attached to it.

Kawasaki on Obstacles to Market Adoption

Guy Kawasaki tells us common mistakes companies make that hinder market adoption:

1. Enforced immediate registration.
2. The long URL.
3. Windows that don’t generate URLs.
4. The unsearchable web site.
5. Sites without Digg, del.icio.us, and Fark bookmarks.
6. Limiting contact to email.
7. Lack of feeds and email lists.
8. Requirement to re-type email addresses.
9. User names cannot contain the “@” character.
10. Case sensitive user names and passwords.
11. Friction-full commenting.
12. Unreadable confirmation codes.
13. Emails without signatures.
14. Supporting only Windows Internet Explorer.

Check it out for details.

Strategies or Tactics

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 customers most pressing problems that our product can solve?
• What are the key themes that all of our marketing campaigns should stress?

Has your company authoritatively answered these strategic questions? Has it even asked them?