A look back at the best from this week in the past.

Foundation Series: User Experience Disciplines

UX, pronounced you-ex, is the shorthand for user-experience. It represents the science and art of tailoring the experience that users have with a product - in our case, software. UX is a relatively new term, rapidly overtaking HCI (human-computer interface) and CHI (computer-human interface) as the acronym du jour. In some circles it is known as human-factors engineering, applied to software design. There are several disciplines within this field, we’ll introduce each of them.

Top Ten Tips for Preventing Innovation

At a recent presentation in Austin by Seilevel about the goals and methods of requirements gathering, a member of the audience asked “What can we do with our requirements to assure innovation?” That’s a tough question with an easy answer - nothing.

What if the question had been “What can we do to prevent innovation?” That’s a better question with a lot of answers.

How To Write Use Case Triggers and Preconditions

Use case writing is key to effective requirements management. Each use case represents a single idea or logically grouped behaviors. When you define a use case, there are several mistakes you can make. Preventing those mistakes is the first order of business. The second order of business is making sure that the use cases in the system work together. This requires an understanding of the context in which the use case happens. To fully understand a use case you have to know what is promised to be true before the use case happens, as well as what causes the use case to happen. These are subtly different.

Project Scheduling - 80% Done, 80% Remaining

Johanna warns us that there is “no such thing as percent complete” when it comes to tracking status on a project. Your managers and customers want to know percent complete - and there is a way to report it. Project planning and scheduling involves walking this fine line.

Fortune is running a fascinating story about Steve Jobs that does a great job describing his character flaws and humanity, but also what makes him able to lead Apple to make products that inspire such rapid passion in their customers. The article made me think about Product Management in relation to a “genius designer” [...]

UML Class Diagrams can be used not only for documenting software design, but for documenting software requirements. One of the challenges in writing clear, unambiguous requirements is being precise about what a particular word means. This is especially true with symbolic terms like “quote” or “customer” - where everyone knows what they mean - but they mean different things to different people.

Why Create UML Class Diagrams for Requirements?

One of the first articles we wrote in 2005 provides a very simple class diagram example, and an explanation of why you should use class diagrams to clarify your documents.

In prose, we could also capture the same information as follows:

1. The system shall include a representation of customer orders.
2. Each order will have a single associated customer, and each customer can have multiple orders. Note that a customer is not required to have any orders.
3. Each order will have at least one, and possibly multiple line items. Each line item is uniquely associated with a single order.
4. Each line item represents a single product. Note that a product is not required to be represented in a line item. A product can be represented in multiple line items (even within the same quote).

OOA is compellingly powerful as a descriptive tool – it took less time to draw the diagram, and it can be easier to read than the prose.

A Picture is Worth A Thousand Requirements

UML class diagrams, in addition to being potent for communication, can also help with requirements discovery. They provide a clarity and explicitness of understanding that helps you gain insight into the topics being explored.

Getting Started or Getting Refreshed

If you already know UML, or generally know how to draw UML 2 Class Diagrams, you can “test out” of this article, and go to the best, most thorough explanations we know of, courtesy of Scott Ambler.

• UML 2 Class Diagrams - an explanation, in detail, of how and what and why to draw things a particular way
• UML 2 Class Diagram Guidelines - advice on how to make your diagrams consumable and appealing

If your eyes glazed over, that’s ok. There is a lot to absorb. There are a lot of advanced concepts that can be represented in class diagrams, and Scott provides explanations and examples of how to do most of them. If you are new to modeling with UML, or are only interested in what you need to know to document requirements, those articles may be too advanced for now. We’ll try and close the gap. Keep those links handy, both for reference, and for deeper explanations than we cover here. If Ambler’s articles are written to help you be a master craftsman, we want to help you become a journeyman first.

Class diagrams are incredibly powerful tools for anyone doing requirements work. I never wrote about them before, because Ambler already did. And he didn’t leave me wanting more, so I never knew what to write. After a recent conversation with someone new to modeling, I discovered that he did leave a gap. There’s a fair amount of learning you need to do before you can really get the value from his articles. Ambler also addresses both the analysis and design uses of class diagrams.

We will focus exclusively on using UML class diagrams for analysis. So if you are a business analyst or requirements analyst, this will help. If you are a developer, this will help you read the diagrams that analysts create. If you are a product manager, this will help too, but I think you’ll need to do this less frequently than a business analyst would.

We do assume that you are already comfortable using Microsoft Visio, but have not used it for creating class diagrams. You don’t have to use Visio, but the tools in Visio are good ones for creating class diagrams.

Visio Template for UML Class Diagrams

The easiest way to get started is with the default drawing type already available in Visio.

Create a new file, and select the Software category, then scroll down and select “UML Model Diagram” in either US or Metric units. When you do, a number of stencils will automatically load for you. You want to use the UML Static Structure stencil.

These are the shapes that you use to represent objects in a class diagram. You can safely ignore all of the other stuff that Visio provides in the other templates.

The Class

When you drag the “Class” shape onto the page, you get the empty looking box on the left. Visio automatically names it for you as “Class1.” The class represents a concept, entity, item, or object. It is important for analysts to remember that what you are drawing is “how the business thinks about these objects” - not “how developers will implement a representation of the objects.”

There are three areas in each “class” shape. The shape on the right shows that the top area is where the name of the class appears (in bold), the middle section represents attributes, and the lower section captures operations that can be performed by the shape. This feels like describing an implementation or design. The terms attribute and operation certainly sound like programming. UML Class Diagrams may have initially been created to help developers design solutions, that would certainly explain the names. There is still a lot of power to be unleashed - so take it on faith for now - we’ll present some examples that demonstrate the value of class diagrams for analysis.

Imagine that you are thinking about a lamp. Perhaps you are designing an emergency battery backup system, and one of the things you need to think about is how much wattage a lamp requires to operate. The wattage of the lamp, in English, is a characteristic of the lamp. Programmers call it an attribute. For our purposes, the terms are interchangeable.

A lamp can be turned on. That is pretty intuitive. We imagine ourselves turning on a lamp. Actually, all we do is turn a dial (or flip a switch). When we turn the dial, the lamp turns itself on. If we were really playing with language, we might say “When the user requests illumination, the lamp turns on.” We would never use that phrasing for a concept as simple as a lamp, but you get the idea. The operation is something that the object can do. Dogs bark, cats meow, lamps turn on.

When we are creating class diagrams for requirements discovery, we will always use class names, almost always use attributes, and almost never use operations.

A customer, in the diagram element above has an address. The customer also has a credit rating.

The two elements above represent the same information. A product has both price and weight. We also find, during our requirements exploration, that we need to know if a product is available. Perhaps our users need to know if a product is available right now before suggesting it as an up-sell item to a customer. If that is our requirement, we realize that we need to know the availability of the product. You can either include the question “Is it available?” or a single name for the attibute - “Availability.”

It is better to use the word “Availability” for two reasons. First, it is consistent to say “price, weight and availability.” You could achieve consistency with all questions - “What is the price?” “How much does it weigh?” and “Is it available?” But that becomes overly wordy. The second reason for using a single word is to avoid embedding rules in your requirements.

Consider the “Credit Rating” attribute for the Customer object. What we really want to know is if the customer’s credit is good. The definition of “good” will change over time, or may become complex. “Good enough for small purchases”, “Good when putting 20% down” are examples of the definition of “good” becoming complex. Or maybe you’re loaning money, and you can improve your profits with notions of “pretty good” and “really good.” You will create business rules to define what you mean by good. You happen to know that those rules will reason about the customer’s credit rating, so you should capture that value.

You could but should not represent the notion of “Is Credit Good?” with an operation:

You end up specifying design here - however unintentionally. Depending on how you interpret this, you are either saying “Customers are responsible for determining if their credit is good” or “The credit worthiness of a customer is determined without considering anything other than the customer.” While precise for programmers doing design, this is a pretty ambiguous thing to document in an analysis. By adding this operation, you are not providing unambiguous insight into how the business thinks about customers. So don’t do it.

Next Up

In our next article on UML Class Diagrams for analysis, we’ll look at relationships between classes.

If there’s something in particular you’d like to see explained, add a comment below and we’ll either fold it into the series or answer in the comments. And remember - you can subscribe to the comments for any article, just click the link.

We all live in a World with tradeoffs. When you write a requirements document, is every requirement non-negotiable in order to ship the product? If so, you’ve traded off completeness for time or resources. If you’re like me, time is your biggest enemy, so even if the requirements outline the ideal solution [...]

We read a lot about the value of listening to your customers and understanding your markets. We don’t hear as much about what happens when you ignore your customers. Thanks to documents exposed as part of a class action lawsuit, we get to see just how bad it can be. Maybe even billions of dollars.

Microsoft Pays Immense Price

Microsoft’s Windows Vista operating system release just over a year ago has been a smashing non-success. You would be impressed to know that they sold 100 million copies of Vista in the first 14 months. Until you realized that 250 million personal computers were sold last year - and most of them still came with Windows XP. Then you would be much less impressed. Microsoft intended to end-of-life (stop selling) Windows XP shortly after the Vista launch. But there was too little user adoption, too many bad reviews in the press, and too much push-back from their biggest customers - OEMs.

This week, Microsoft announced that they were lowering the retail price for Windows Vista. Not that that really means anything - the vast majority of copies are sold to OEMs. But it does put them back in the spotlight, as they try and do some sort of damage control for their poorly managed product / product release.

Note - it is important to point out that this is not a criticism of the Vista operating system. The quality of the OS, good or bad, is unrelated to what we focus on in this article. Simply put, Microsoft ignored the feedback from their customers prior to launch, and immediately after launch. And they are paying for it.
A judge ruled that consumers can file a class-action lawsuit for how Microsoft marketed Windows Vista. The suit may cost Microsoft a lot of money in settlement fees. It certainly costs a lot in bad publicity, which translates to revenues, and therefore market capitalization. And all because they ignored their customers and caved to the pressure of another heavyweight - Intel.

Intel Outside and Inside

We regularly hear the horror stories about people feeling like they got a “bait and switch” when it comes to buying new computers equipped with Windows Vista. Most computers (70-80% of all produced models at the time of launch) sold by OEMs (Microsoft’s customers) were labeled “Vista Capable” but could not run most of the features of Vista - including the new user interface that was the most visible change (to novice and competent users). It turns out that only between 20 and 30% of the desktops and laptops could run the Aero glass features (the cool new UI) at all, and then only poorly. Most computers had an older, cheaper Intel 915 chipset, with the 945 chipset available in a minority of computers.

In February 2007, just after Vista launched, Microsoft’s Steve Sinofsky told CEO Steve Ballmer that the 945 chipset, required for the “Vista Premium Ready” logo, could barely run Vista. And everyone (inside the PC industry, at least) knew the widely used 915 chipset that was awarded the “Vista Capable” logo couldn’t even think about running the advanced display driver model used to deliver the fancy Aero interface, considered one of the major selling points of Vista.

High time for Intel to get serious about graphics, Tom Krazit

Thanks to the class-action lawsuit against Microsoft, the court has released 158 pages of emails (pdf) specifically about the “Vista Capable” logo and Intel.

Tricia Liebert summarizes the situation today for Tech Republic:

It begins with the Intel chipset. In Feb 2006, the chipset in bargain notebooks was the 915. Unfortunately, the 915 chipset cannot provide the graphics power necessary to power Aero Glass. Intel voiced concern to Microsoft that it would not be able to supply the certified 945 chipset in sufficient numbers to qualify enough PCs for the Vista Ready logo. Microsoft’s response was to certify the 915 chipset, knowing that it would not be able to deliver the entire Vista experience.

What Microsoft was willing to do for “Wintel”, Tricia Liebert

Todd Bishop also writes a good detailed review of the documents. In another article, Tom Krazit highlights just how important this would be to Intel:

Intel apparently felt that if only 945 chipsets were deemed Vista Ready, that demand for systems with 915 chipsets–still a significant mix of its products–would fall off the face of the earth. And also, that it would be unable to produce enough 945 chipsets to meet its committments to PC makers–orders that might otherwise go to Advanced Micro Devices.

Microsoft emails reveal Intel pressure over Vista, Tom Krazit

So Intel shoved, and Microsoft toppled. But Microsoft’s customers were screaming “NO” at the time. And Microsoft ignored them.

As Bishop points out for us, John Kalkman, a Microsoft exect said in an email in Feb 2007:

In the end, we lowered the requirement to help Intel make their quarterly earnings so they could continue to sell motherboards with the 915 graphics embedded.

Customer Says…

The New York Times summarizes Dell’s opinions on several fronts, as expressed in the released documents. Slide 5 of a presentation from Dell to Microsoft (p14 of the court documents) explicitly asked Microsoft to not lower the bar for hardware to allow the entry-level machines to get tagged with “Vista Capable.” Dell cited concerns with education of their customers, setting of expectations, and communication. Dell also complained about the complex product (sku) structure that Microsoft was using.

Walmart also complained, as did HP. Some folks within Microsoft were listening, but unable to prevent the mistakes. Mike Ybarra said on Feb 01, 2006 (a full year before the launch) “I am passionate about this and believe the decision is a mistake.” One other Microsoft exec commented that this feedback was consistently heard from “all retail customers.”

It would be bad if Microsoft’s customers didn’t express their desires and concerns. It is horrible that they did, and Microsoft chose to ignore them.

Best Buy did provide an interesting perspective - they felt that if Microsoft kept their original approach of only labeling those machines that could run the full Vista capabilities, then Best Buy would prefer to delay until late summer of 06 to announce (instead of CES at the start of 2006).

One voice of futility from the trenches (p 137 of the court documents) that made me feel some compassion:

Based on the objective criteria that exist today for capable even a piece of junk will qualify :)

So based on that yes 865 will qualify.

For the sake of Vista customers, it will be a complete tragedy if we allowed it. I don’t know how to help you prevent it.

Anantha Kancherla, Mar 01, 2006

The Lesson

Listen to your customers, and stand up for them!

A look back at the best from this week in the past.

Prioritizing Software Requirements - Kano Take Two

In our previous post on Kano requirements classification, we introduced the concepts and showed how to apply them. One of our readers commented privately that we didn’t show how to use the techniques for prioritization. We’ll do that in this post. Thanks very much for the feedback!

Product Life Cycle and the ROI of Agile Development

The product life cycle is a description of the presence or behavior of a product in the marketplace over time. The framework for description is a function of the sales volume of the product versus time. Over time, products are created and introduced, and sales grow, peak and decline. The product life cycle uses phases to describe these different periods in the life of a product. Understanding the product life cycle is also key to calculating the ROI of agile development.

Agile Development and Software Maintenance Costs

Over 90% of the cost of software development is software maintenance (cite). This alarming trend was predicted as early as 1972. McKinsey suggests that CIOs should spend no more than 40-60% on maintenance. Gartner’s IT Spending and Demand Survey (2002) reports that CIOs are spending 80% of their budgets on maintenance (p12 of presentation). Agile development can help reverse this trend.

Do you recognize this early logo from Amazon.com? Future Now has a great article detailing how Amazon evolved their “add to shopping cart” implementation. From reviewing this summary of the evolution of one feature, we can see that Amazon decided there was value in reinvention. The improved the way their product did something over time. Have you?

Continuous Improvement

Software developers understand the value of continuous improvement. It is a core tenet of agile development - as you do more, refactor what you’ve done so that it is better. Some people who promote agile explain that refactoring is a barrier against spaghetti code and broken windows. That is certainly true, but there’s also merit in simply making the product better.

The key is to define “better.” Refactoring as part of implementing something new comes from a simple idea - “elegance” in design includes an analysis of how well the code solves the problems it is being asked to solve. When you add new functionality, you redefine the context by which you analyze. When you extend your code base in unanticipated directions, you are likely to be reducing the elegance of your solution. So you refactor, to make sure your design is elegant given the new context for analysis.

One of the development teams we’re working with right now is proposing a rewrite of a set of utilities that are part of an enterprise architecture. A small piece in a very large puzzle. Unfortunately, their argument is that “the code is not good.” Instead of looking at their specific situation, we can ask the question - “When is there value in rewriting?”

Value In Rewriting

First, we should define rewriting. Imagine that your software is a “black box.” It accepts inputs, and provides outputs. It does some work or analysis or magic or something inside the black box - you don’t know what. When you feed it an input, it responds with an output. Our definition of rewriting for the purpose of this discussion is that the “black box” view of the product does not change. The same inputs produce the same outputs. Not faster, not prettier, not less buggy, not more scalable, nothing. No (externally) perceivable difference.

In other words, the developers are saying “let me rewrite, instead of writing new code.” New code changes the behavior of the black box - the outputs are better or faster or different, inputs are handled differently, etc. A “noticeable” change. As product managers or analysts, we’ll assume that noticeable and valuable go hand in hand. :)

Newton’s First Law of Software: Software, when unmodified, behaves the same way it always has.

What are valid reasons for changing how it is written?

• Fiat. A corporate mandate may come down, stating that all software will be written in a single language, or will run in a specific environment. These types of mandates are intended to drive economies of scale and reduce costs by inspiring teams to leverage competence and knowledge across multiple products. Microsoft Office and Apple both apply this approach in designing consistent user interfaces to their products. People familiar with one application will be able to be productive with a second application more quickly. So there is potential future benefit here.
• Cost of Change. When a product is being actively modified, there is a cost associated with making those changes. That cost is a function of how hard it is to make those changes. Making the code easier to work with does have value, in that it makes the cost of change lower. There can also be benefits here, but they are probably smaller than the value of doing something new. Until they get big. That may be the genius of refactoring as you implement new functionality. By keeping the code base “always good”, you incur small incremental refactoring costs in the context of implementing new features. The argument is that these small costs immediately pay for the next incremental refactoring due to time saved in adding functionality. It is a positive feedback loop.

It rarely makes sense to just rewrite for the sake of rewriting. If development costs represent 20% of the cost of a solution, then you need to reduce development costs by 5% for every 1% of incremental value (from redesign or new functionality) that you postpone. You can easily show that a 5% reduction in development costs “pays for itself” quickly if you operate your development team as a cost center. You should instead be operating as a profit center.

Value in Redesigning

There can be dramatically more value in redesigning a product. Redesigning is one step up from rewriting. These changes are externally visible. The software still does the same things, only it does them better. Better can mean an improved user experience, higher quality, faster responses, more accurate analyses, higher scalability, etc.

From a requirements perspective, a redesign does not change any of the functional requirements. It changes the non-functional requirements. Since non-functional requirements exist to support specific goals, a change in non-functional requirements reflects a change in value. And value drives prioritization.

You can, and should, prioritize redesigns along with adding functionality. Amazon, as the Future Now article (hat tip to Mary Schmidt’s Idea Pool) indicates, valued the repeated attention to, and redesign of the “add to cart” button on their web page. They were clearly making intentional trade-offs between strategic goals. As an example, with one design, they promoted other corporate initiatives at the expense of conversion rates (turning users/clicks into transactions).

Is Your Product Improving?

Our unscientific perception is that most software product teams are myopically focused on “what else should we do” and are forgetting “what can we do better?” It may be that you’re tackling such a large problem that “more” overwhelms “better.” But you should do the analysis.

Ask A Good Product Manager is a new blog just launched by Jeff Lash, who also authors How To Be A Good Product Manager, one of our favorite blogs.

Why Have a Separate Medium

Jeff runs a blog with a very distinctive style - each article starts with advice on how to be a Bad product manager, and the contrasting advice on how to be a Good product manager. Each of us can choose. It is a great approach to implicitly show that Jeff’s advice is not a collection of rules, but more of a cause-and-effect. There are things we can do as product managers that make us better, and things that make us worse. His advice is good, and his approach to presenting it is novel and effective.

I had the pleasure of meeting with Jeff not too long ago, and he mentioned that he was looking for a way to share answers with the broader community, to questions that he is regularly asked offline. Jeff came up with the new blog, and chose to incorporate answers not only from him, but from other bloggers. What Jeff and I have both been working towards over the last couple of years, along with other folks, is to create a sense of community around product management. Nature abhors a vacuum, and we’ve been gradually filling it. Jeff and I have both had good success with the blogging paradigm: broadcast and encourage discussion. But that still left a bit of a void.

The “ask a question, get an answer” space has not been completely filled. There are message boards that fill part of this need - Seilevel’s in particular covers a lot of this very effectively. Seilevel’s board feels more collaborative, and the discussions are very open and free-form.

What Jeff is doing is addressing a targeted set of questions and answers. Over time, it may build up into a FAQ (frequently asked questions) for product managers - we’ll see where it goes.

Jeff made a good decision, in my opinion, to not dilute the theme or message of his primary blog. He has found a way to share the answers - if the question is asked once, the answer is likely to be of interest to many. And he’s doing it well.

Questions So Far

Jeff has launched the blog with a great set of questions:

• How do product managers prioritize requirements?
• What to do when your main competitor is your best customer?
• What should I study to become a product manager?
• What is the key to writing a good use case?
• What tips do you have for a new product manager?
• Do all products need a product roadmap?

There are answers for new product managers, and experienced product managers. And there are comment threads for each question, where other folks can chime in with their advice, agreement, disagreement, and feedback to each question.

A look back at the best from this week in the past.

User Centered Design and Bridging the Canyon of Pain

There is such a thing as too much choice. For new users, too much choice (or control) is too much. For experienced users, too little choice is a problem. Ease of use usually comes from reduced control - but users don’t stay “new” for long. There’s a “canyon of pain” to quote Kathy Sierra in that transition from “new” to “experienced.” We call them “competent” users and we have to help them cross the canyon of pain.

Project Dashboard Icons

We create project dashboards all the time to show status, or to give upper management an update. Dashboards and scorecards are great for giving us a “quick view” into the health of a project - they give us a way to drill down. Many of us use the colors red / yellow / green, with a stoplight metaphor. The problem is that some of us are colorblind. Johanna Rothman gives us a GREAT tip. We give you a set of icons / images.

Measuring the Cost of Quality

Should we test our software? Should we test it more?

The answer to the first question is almost invariably yes. The answer to the second question is usually “I don’t know.”

We write a lot about the importance of testing. We have several other posts in our series on software testing. How do we know when we should do more automated testing?

Jeff Lash of How to Be a Good Product Manager launched a new site yesterday to solve the problems of his savvy readers. The new site , Ask a Good Product Manager is a place for Product Managers to ask long-standing Product Management practitioners any question about Product Management. Even if you don’t have a question, the information on the website is a great resource to help you grow from a good Product Manager to a great Product Manager.

I encourage all of our readers to visit this site. What have you got to lose!

Barry Boehm, inventor of the spiral model of software development, may also be the originator of the CRACK acronym for the type of users we want on our projects. When defining (and executing on) projects, we don’t just want CRACK users, we want CRACK stakeholders. And we want them to stick around. In fact, we’re addicted to them.

What Are CRACK Users?

We are not talking about substance abusers here. We are talking about users, and stakeholders in general, who have the following characteristics:

• Collaborative - stakeholders define goals and provide feedback and are available to work together
• Representative - they characterize (or embody the personas) who make up our key users
• Accountable - along with collaboration comes a sense of ownership: we succeed or fail together
• Committed - not just in percentage of time dedicated to the project, but also continuity of involvement over time
• Knowledgeable - understanding more so than knowledge leads to insights but both improve our deliverables

Thanks, Mike Griffiths, of Leading Answers, who points out the value to agile teams of having CRACK users. His article is actually focused on what to do when you can’t get users - and I love suggestion number three. Thanks Mike, and keep it up!

Before giving Mike all the credit, I wanted to see if anyone else was writing about CRACK users. Several of the top search results pointed to articles or presentations by Barry Boehm, who, due to his significant software engineering contributions, gets our “he must have invented it” accreditation.

As a quick tangent - during the search, I found a couple presentations by Barry were awesome.

• 2003 SERA Keynote Address - talking about agile and deliberate (non-agile) project approaches
• Systems of Systems: Characteristics and Challenges - dealing with enterprise architectures and projects in the tens of millions of lines of code arena.

This is a short one, but the idea is strong, and the linked presentations give you plenty of good stuff! Thanks Barry and Mike!

A colleague of mine is looking for a full time Senior Product Specialist in the Telecommunications Industry. The role is based in the heart of Sydney working with a fun, energetic team. The JD is attached.

If you’re a Product Manager looking for growth, please send a copy of your CV to Adrienne Tan at actan@brainmates.com.au and I’ll pass on your details.

Job Description for Senior Product Specialist

Keeping your website dynamic is one of those marketing must-dos to keep your corporate portal sticky. Unfortunately, improving visitor stickiness can also be a sticky task – or should I say an icky task!

Peer Bremer speaks to us about his wonderful product smileCMS: a content management system that makes website administration a piece of cake.

Janey: Peer, can you tell us about how you came to be involved in content management systems?

Peer: I come from the communications industry having worked in and for Advertising Agencies on campaigns, print, packaging and corporate identity. I then started to get more and more involved with web design and application development to a point were I am now almost more of a programmer than a designer.

Janey: So, this led to the development of smileCMS, but were there other inspirations that prompted to you create your product?

Peer: Many of my clients are small to medium businesses that need to change the content of their web site regularly but don’t have the budget to retain a full-time webmaster. They were constantly requesting only small text changes but the whole process became inefficient and costly for them.

This motivated me to investigate several CMS solutions but most systems I looked at were very complex and not easy to learn or use. The users still had to know how to edit source files, tweak programming, and once they have everything up and running the resulting websites were not easy to navigate and were not visually appealing. Most systems also come with a price tag of several thousand dollars; even the ones that come with no license fees require the average customer to hire an external consultant. As a response to my clients concerns, I developed smileCMS as a more affordable alternative that would also provide functions to create better designed websites and offer a great user experience.

Janey: Can you tell me more about smileCMS and your favourite features?

Peer: SmileCMS is a content management system that allows the user to edit website content right on the web page. All you need to do is just browse to a page, click on the text and start typing. There is no need to know or learn any programming languages, not even html. The system is fully e-commerce enabled with an integrated interactive shopping bag. Managing and adding products for sale onto a website has never been easier.

My favourite feature is the ability to edit right on the web page. Most other system use pop up windows and dialogue boxes to manage or edit page content. But my favourites don’t stop there; the rest of the system is as easy as the text editing. You can upload images, resize and crop them within the system before dragging and dropping them onto the web page. You can also sort menu items by simply dragging them to a new position; create links by dragging and dropping selected text; and create or remove pages with one click.

Janey: smileCMS sounds like a dream-come-true for people who aren’t technical or website savvy. What is the main benefit companies will receive from using your product?

Peer: A big advantage is the minimum time required to learn the system. Everybody, even people that have no experience with web editing can learn and use the system right away.

Peer, thanks for sharing smileCMS with us – a product innovation created to solve specific market problems. It’s a story of product development at its best.

We’ve been promoting use cases as the right way to approach agile requirements, and in a recent article, Alistair Cockburn stresses the importance of use cases. Over the last three years, he has found that teams that avoid use cases consistently run into the same three problems. We defer, of course, to Alistair as the expert. But we’ve been independently promoting this practice too. So today, we get a cookie!

Alistair Promotes Use Cases for Agile Development

First, a hat tip to Rajeev Singh for pointing us to Alistair’s defense of use cases in agile projects. In discussing his findings from the last three years of talking to agile project teams, Alistair writes:

I keep running across organizations suffering from three particular, real, painful, and expensive problems.

[…]

In particular, use cases fix those three problems.

I’ve been testing this out for the last 3 years – I walk in and ask, “On your agile project(s), do you by any chance suffer from any of these three things?” … and then list the three … Much stronger than even I expect, there hasn’t been a single organization I asked these of that hasn’t said, “Oh, Yes, and How!”

Why I still use use cases, Alistair Cockburn

Alistair finds these problems both when teams replace use cases with user stories (or use scenarios) and when they eliminate either approach and move to a feature-driven product backlog.*[See “Scrum” Section at the end of the article.]

Paraphrasing the three problems (”Without use cases, …”):

1. Designers lack the context of the goal that the user is trying to achieve.
2. The team does not get a early indication of the scope of the project.
3. Alternate user-behaviors are not identified in advance of the commitment to deliver.

How do use cases address these problems?

1. Gaining Context With Use Cases

Even in agile projects, use cases are an enabling mechanism for companies to achieve goals. An approach that uses structured requirements provides that context.

Each use case exists in the context of the goal. A couple years ago we wrote about the reasons for writing use cases. Those goals could easily be addressed with use scenarios and user stories. The problems that Alistair articulates arise from choosing something other than use cases to meet those goals.

2. Getting An Early Indication of Scope

Politically, the largest problems in getting an agile project launched in a waterfall organization comes from mis-set expectations. Setting expectations and thereby securing both funding and support for a project can be more important than execution.

If you don’t have the support of a sponsor, your project will fail. If you have sponsorship and funding, your product could still fail. Both are necessary, neither is sufficient.

To set expectations, you have to identify the scope of your project immediately. Here’s an example of the scope definition for our nexus project from last year. Setting scope is as much about managing stakeholders and prioritizing stakeholder objectives as it is about controlling delivery time frames and schedules. [Tangent Warning: even if it means delivering incomplete requirements.]

The key is to get a breadth-first overview of the scope, and then a deep understanding as you iterate.

3. Avoid Scope Creep With the Rigor of Use Cases

As Alistair points out, this is hard to differentiate from “managing scope.” The distinction is that the scope-definition issue is one of discovering functionality broadly, where this scope creep issue is one of understanding complexity sufficiently.

The right approach to defining use cases for agile development starts with a definition of scope. Once you’ve defined the scope, you define the use case names, then progressively prioritize and define the use cases in more detail, in priority order, as you incorporate them into your time-boxed project schedule. You also refactor your use cases, consolidating and defining subordinate use cases where appropriate, and defining extension use cases as needed.

Scrum

Scrum, as an organizational approach to agile does not preclude the use of use cases. Scrum projects commonly choose to use a feature-driven backlog. We actually really like scrum as a mechanism for managing delivery. But we feel that it works most effectively when time boxing each iteration specifically in terms of use cases. When using use cases as the quanta of your iteration backlog, you get all the benefits defined above, plus the benefits of Scrum as a delivery vehicle.

Conclusion

Use Cases Rule! [”If it’s our blog, then it’s our pizza.” - Mr. Hand from Fast Times at Ridgemont High]

A look back at the best from this week in the past.

Software Requirements: Processes and Roles

Our previous post, Requirements vs design - which is which and why, describes our position on which parts of the software development process are requirements-activities, and which parts are design activities. The debate among professionals about these distinctions is ongoing, and continues in the comments on that post. The length of the debate, combined with the skills of those debating demonstrates that it isn’t a black and white issue.

In this post, we will try and explore the reasons why this debate is ongoing. We will do that by exploring the symbolism of the terms involved, as well as the roles of different members of the software development team.

Writing Requirements Unambiguously

stuff

Writing requirements without ambiguity

This is one of the harder parts of writing good requirements. Marcus tells us to avoid it with a good example here. Jerry Aubin at Seilevel has written an outstanding post on the subject, The art and science of disambiguation. Jerry starts his post with a gripping example from Weinberg and Gause

Writing Functional Requirements to Support Use Cases

Background:
In our previous post, Sample use case examples, we created two informal use cases. The use cases were written to support product requirements defined as part of a project to reduce test suite maintenace costs. In this post, we will define functional requirements that support these use cases. This process is an example of using structured requirements, applied to a small real world project.

A successful agile team requires someone on the team to act as the voice of the customer, someone to lead the developers, someone to lead quality assurance, and someone to organize, coordinate, and assure execution. For an agile team to succeed in an enterprise ripe with political resistance to agile, someone has to be the “voice of the team” as well.

You can approach this by classically assigning roles and responsibilities - but that isn’t the only way. Agile teams are most effective when they have specializing generalists who can mutably adapt to the immediate needs.

The Politics of Agile

Barbara Nelson of Pragmatic Marketing has a new article, The Politics of Agile, where she provides a great overview of agile in the enterprise. Barbara shares insights into some of the perspectives and prejudices that we encounter in larger organizations when talking about, exploring, and piloting agile projects. She provides an introduction into a few flavors of agile that product managers run into most often, and leads into the pragmatic approach - what they call XPM (extreme product management).

Pragmatic Marketing’s approach, to oversimplify, is to have a product manager be the voice of the customer, who lives as the interface between an agile execution team and the rest of the organization. As she points out in her article, the political environment in which the team has to operate can make or break the project. She provides several tips for how the product manager can shepherd the team through those political mine fields.

Software Development Roles

Barbara also points out that there are five roles that need to be filled for any successful product team - agile or waterfall. [Links inside the quote are ours]

When building products for a market of customers (as opposed to a single customer), five roles are needed whether you practice agile or waterfall.

• Product manager: messenger for the market; defines what problems need to be solved and for whom
• Product designer: expert in design, defines how the problems will be solved
• Development team lead: liaison to the developers
• Quality assurance lead: assures that the product solves the problems identified by the product manager

• Project manager: manages the schedule and resource allocations

Barbara Nelson

She points out that these five roles don’t have to be filled by five different people - especially when you don’t have five people to staff the team. Where we “agree*” (we agree, but with an asterisk) is where she draws a clear line that the product management role should not be shared with other roles. [Note: Dev team leads can also be free electrons, if you’re lucky!]

Even if there are not five people, these functions need to be performed. If the product manager takes on any of the other roles, it will be at the expense of becoming the market expert and having the right information to be the single voice of priority. Let the developers develop. The product manager identifies what needs to be built, not how to build it. Validate with the market that what the developers are building and how it is being built resonates with buyers and users.Barbara Nelson

On large teams, and waterfall projects, and organizations that “are bureaucratic”, we couldn’t agree more. But for agile teams, it depends. And it depends on the people who are on the particular team. Agile teams intentionally staff with specializing generalists so that they can respond to “whatever is needed right now” within a sprint/release/cycle.

Specializing Generalists

The idea of specializing generalists is easiest to grasp by first saying what it is not. It is not staffing a team with a database expert, a user interface coder, a SOA (service oriented architecture) guru and an architect. With four specialists, each development task has an obvious owner. Database changes and refactoring go to the database expert. Reworking the UI goes into the queue for the AJAX hotshot. The problem is that this approach is only efficient when each team member is equally loaded with work. Since an agile team is continuously reprioritizing their work based on repeated feedback cycles as part of each release, this doesn’t work. The team will never face a situation where the (for example) four most important things to do are one item for each specialist. You can very easily have a release where all of the most important tasks are focused on the user interface. So all of the non-interface-experts are either working on lower-priority tasks, or even worse - they are idle. And you delay the most important work until the specialist can get to it.

By staffing a team with people who have an area of expertise, but can do anything, you can maximize the value of each delivery cycle. In our example, where all of the tasks for a release are UI tasks, they can be interchangeably assigned to any of the developers. The UI expert may suggest an implementation approach, do code reviews, or provide guidance to all the other developers. But every developer (including the database guy) can sling code effectively to get the job done. Specializing generalists.

This is very effective for making the “development engine” a black-box. Feed it the highest priority stuff, and it all gets done. We can take that approach to the next level. Designers can implement, project managers can design test plans, and yes, product managers can specify design. Twitch. Back up a sentence and read it again.

Specifying design is not the job of the product manager. True. Very true. Emphatically true. But specifying design can be what a specializing generalist does, even when that person is also responsible for defining market needs.

Wearing Two Hats

Wearing two hats can be incredibly hard - and it can be a disaster for someone who isn’t experienced enough (or good enough, frankly) to know which hat he’s wearing when he does something. And this is why we only almost disagree. We have seen enough examples in the real world of superstar specializing generalists to believe in their value. And we want to make sure that when you have one of these dynamite people on your team, you don’t prevent them from applying all of their skills to make your product great.

How do you know when you have one of these people? There are at least three archetypes who are brilliant at it. There must be more, but these are the ones we’ve seen more than once.

• The Evangelist. A product manager / product designer. A person who is completely attenuated to the needs of the market and who unconsciously and capably designs solutions to meet those needs. Steve Jobs is the example that comes to mind first, probably because he comes to mind first ad nauseum. Edison is another great example - he tapped into market needs and invented solutions. Or the guys who knock on venture capitalist’s doors with “the next great thing” - which is a marriage of need and solution. [As an aside, I think a sign of a market bubble is when companies get funded with only one but not both of these things.] Another way to think about this - combining the voice of the customer with the voice of the user. Some people can say not only “They need to do X” but also say “And doing X this way is ideal.”
• The Innovator. A product designer / development lead. I’ve had the pleasure of working with a (very) few of these folks over the years. They combine a visionary approach to solving a problem with mad skillz at implementation. When you share a problem with a great designer, she comes back the next day with a mock-up of a fantastic solution. When you share the problem with an innovator, she comes back the next day with a working solution. Where a great developer will create an elegant implementation, an innovator will create an elegant solution.
• The Cold Fusion Reactor. The development lead / quality assurance lead. One of the enabling elements of an agile development approach is that you create tests as you go, “protecting” your existing code. This allows you to make invasive changes with minimized risk and effort. This is the secret to refactoring - you aren’t forced to live with the “bad stuff”, because the cost to replace it with “better stuff” is so low. And that, as Kent Beck points out, allows your design to always be “the best design” even with emergent development and an evolving code-base. There are developers out there who are so effective at testing that it takes them less time to implement. They can make bold moves and refactor “good enough for now” solutions into elegant designs on the fly. They can harness that atomic power, because they can rely on their testing “containment field” to keep things safe. And that safety leads to less stress and cooler heads.

When you have these people on your team, the issues of roles and responsibilities become smaller. If you ask someone who isn’t one of these people to play dual roles, you’re asking for trouble. But if you have one of these people on your team, and you limit their role, you are also limiting their value. It is important for product managers to not specify design. It is also important to realize when the person who’s business card says “product manager” is also an evangelist with designer skills.

Too much information about requirements or too little? Too much documentation or too little? Use the NICE framework to get it just right.

How Much to Understand and Document?

One question that plagues many analysts is “when do I stop?” People justifiably fear analysis paralysis. You can spend forever trying to figure out the the perfect solution, or craft the perfect document. The risk of delivering the wrong product makes it hard to stop analyzing or stop documenting. There is no magic answer - we can’t write 1.25 paragraphs per function point, or have 2.3 reviews per requirement.

Kiran Garimella wrote an article on BPM and ROI where he introduces us to Roger Burlton’s (of Process Renewal Group) NICE framework. Roger’s NICE framework can be applied to requirements management, and help us think about how we approach our work as business analysts and product managers. [Note: I could not find any articles about the intended uses of Roger’s framework, but our unintended use is interesting.]

The NICE Framework

The framework presents itself as a Venn diagram, as Kiran describes it - the two axes are “Level of Understanding” and “Level of Detail.” The first axis is a representation of how much we understand about the domain of the problem, and the second represents how much information we have documenting the domain. There are two categories for each axis - “Little” and “Lots.” Lovely alliteration.

• Level of Understanding (Little or Lots) - How much insight do we have into the domain?
• Level of Detail (Little or Lots) - How much detailed information have we captured about the requirements?

The four squares in this diagram are mapped to the NICE acronym.

Is It Five O’Clock Yet?

• Little Understanding
• Little Detail

Naive Requirements. When you don’t have sufficient understanding of the domain, and you don’t document requirements in detail, you are capturing a naive view of the world. Imagine an out-of-touch manager who joins the meeting late, interrupts the discussion and says “All we need is social networking for our [spare-parts-resale] website, because word of mouth is what drives business.” He demonstrates a lack of understanding, and provides no detail.

How successful do you think that project would be?

A Whole Lot of Nothing

• Little Understanding
• A Lot of Detail

Incomprehensible Requirements. An overwhelming pile of documentation cannot overcome an absence of understanding. If anything, it causes more problems than naive requirements. At least when you don’t share what you don’t know, people don’t waste time figuring out that you haven’t said anything. We had to “clean up” for a client after another consulting firm had done a very large, very expensive analysis of part of their business. The firm produced a couple inches of documentation. Among other things, they created a spreadsheet with ~1500 “requirements” that made little sense, and had no traceability back to the sources of the requirements. The requirements could not be evaluated, because they lacked explanatory context.

When exploring and validating a sample of about 10% of those requirements, we found that they demonstrated a significant lack of understanding of the domain. Over 2/3 of the requirements we sampled were either replaced, discarded, or corrected. We lost confidence in the rest of that documentation.

At that point, our client was faced with a tough political situation: admit that the money spent on those docs was wasted, or spend more money to “redo” the requirements. Neither path was a winner.

You’ve Got To Be Kidding

• A Lot of Understanding
• A Lot of Detail

Complex Requirements. You have an analyst who understands the domain, the stakeholder’s needs, the right solution approach, and the value of everything. Perfect. You are exactly where you want to be. You have insight and understanding. You’re positioned to make excellent decisions.

And then your analyst writes everything down. And keeps writing. And writing. The level of detail is overwhelming. You have a 5-gallon problem, and a 10-gallon spec. The problem here is that your analyst has documented too much. You’ve created a mass of information for the implementers to consume. The print-outs of those documents generate their own gravity. Time slows in their presence. At least it seems like it, when trying to review the docs.

You’ve also now invested a lot of time and money in the documentation. The more detail you document, the longer it takes, to create, review, correct, and consume the documents.

Imagine you’ve death-marched your team through reviews of the documents, and the team has started implementing. The requirements now change. They always change - at least a little. How do you let your developers know that they have to find the changed needles in a stack of needles? The larger and more complex the documentation, the harder it is to ferret out the changes.

The more detailed the documents are, the more impact changes have.

The Porridge is Just Right

• A Lot of Understanding
• A Little Detail

Elegant Requirements. There is clarity that comes from writing concise requirements. A picture can be worth a thousand words, and a well-placed diagram within a requirements document can have the same impact. When you combine a keen understanding of a domain with clear and effective documentation, you set your team up for success.

This does require additional skills - not only can you gain understanding, but you need to impart it as well. You can gain understanding by exploring and absorbing the “next level of detail” - which leads to insights. Then you have to leverage that understanding to express clearly what needs to happen and why - without all the details of how you reached that conclusion.

Conclusion

Strive for understanding to avoid writing the wrong requirements.  And strive for elegance in your documentation, to avoid costs, save time, and make it easier for other people to consume your docs and reach understanding themselves.

A colleague of mine, Dean Wood from Clear Choice Usability, spent much of 2007 travelling around Europe, the US and Asia. During that time, he undertook research on a range of International luxury products and their associated websites. He conducted in depth, one-on-one interviews with users who had a propensity to purchase luxury products. I’ve attached his research (1.1 MB)  for your review.

Even though the research targeted a specific product type (luxury products) and a specific type of user, I believe we can extrapolate and apply his findings within the Product Management domain.

1. Product Managers are key stakeholders in the development of the website that promotes and supports their product. 
   The tasks that a customer can complete online and the product information available online contributes to the overall customer experience. Product Managers are the custodian of the overall, end-to-end customer experience and the architecture of the website should not simply be left to user experience designers and information architects.
2. When architecting any product website, ensure that there is sufficient and useful product information available. 
   Product information should be easily accessible to help customers make an informed purchasing decision. A good website will increase sales and reduce the cost per sale as customers know exactly what they want when they call or visit your retail store. This may sound simple, but from Dean’s research many companies fail to deliver.

Read Dean’s research paper and tell us what you think.

A look back at the best from this week in the past.

Using ROI For Requirements is a Risky Business

We must allow for risk when calculating ROI

We’ve talked repeatedly about using ROI to drive prioritization of requirements based upon value. ROI can be used as the basis for prioritization for all decision making.

If we fail to take risk into account, our calculations will certainly be wrong, and we may make a poor decision. When we talk about accounting for risk in this context, we mean that we are accounting for the unlikely, undesired, or unintentional outcomes. We use the term expected value to refer to the risk adjusted approximation of the outcome. In financial circles, this is also called discounting.

The most common mistake people make when calculating ROI is failing to take into account the expected value of the return or the expected value of the cost of a project.

Foundation Series: Intro to Utility Curves

Utility is an abstract concept usually relegated to economics. What is it? How does it work?

Prioritization With ROI and Utility

Prioritization with ROI is generally thought of as a quantitative analysis. For hard and soft ROI, that is true. But benefits can not always be quantified. Economists get around this with the notion of utility. You have to make a prediction of the utility of the requirement or feature. How do you do that?

Five Return on Investment Calculation Tips

Return on investment calculation is critical to using ROI for prioritizing requirements. We’ve discussed how to forecast return on investment by estimating costs and predicting benefits. Here are five tips to help you when calculating return on investment.

Machine tools are tools used to build other tools, like a drill press or grinder.  As a Product Manager, our tools are the internal applications and tools we use to support our data gathering, requirements tracking, and project management needs. If you’re lucky enough to have budget for a nice set of tools for common PM [...]