Category Archives: Lists

Many articles at Tyner Blain are lists of tips, techniques, or good ideas related to software development and requirements management.

First Five Capistrano “Oh Crap! Oh No!” Tips


In a slight segue from our agile project articles, here are five tips that may help other first time Ruby on Rails / Capistrano deployments. Even with the great resources available on the internet, there were some unexpected and obscure hurdles for a new-to-rails developer to get a site up and running. While Ruby favors convention over configuration, not all hosts are set up with the same conventions – so there isn’t much help available for the really weird problems.

Continue reading First Five Capistrano “Oh Crap! Oh No!” Tips

Ten Supercharged Active Listening Skills To Make You More Successful

attentive labrador puppy
[Update: Welcome carnival readers (and more and more and more), thanks for the visit, we hope you like this and the other articles here and stick around to share with the community! Scott]

Active listening is about more than gaining understanding. Active listening is about giving. Giving assurance that you understand someone’s needs. Giving confidence that you will address those needs. Giving feedback and acknowledgment that someone’s input is valuable. If you haven’t tried active listening, you may think it is a passive, receptive activity. Here are ten active listening skills that will help you, your customers and your team.

What is Active Listening?

McGraw-Hill’s accurate yet insufficient definition of active listening is “Giving undivided attention to a speaker in a genuine effort to understand the speaker’s point of view.” That’s fine, but it doesn’t tell you why you give undivided attention, and it doesn’t tell you how. And active listening is much more that paying attention really well. That implies a one-directional communication. Active listening is bidirectional. This definition doesn’t tell you what you’re giving to the speaker and that’s the most important part.

Why Practice Active Listening Skills?

There are plenty of generic reasons to be an active listener. Dale Carnegie swears that active listening is the key to making a great first impression (he’s right). Dr. John Gray promises to improve your cross-gender relationships with active listening that gets to the heart of the unimaginable motivations of the opposite sex [tongue in cheek].

As a business analyst or product manager, you have some very specific goals and challenges. Joy at Seilevel recently wrote about the challenge of convincing people that documenting requirements is important. She looks at the motivation of the naysayers, and recognizes that the reasons may not be logical, or they may not have the data. This is a great example of the kinds of situations, beyond gathering requirements, where active listening skills can help.

The Center for Rural Studies [yeah, I know, it is odd] provides a great list of ten active listening skills. We’re re-purposing that list here to

  • Make you more successful.
  • Make your products better.
  • Make your customers happier.

Ten Active Listening Skills

  1. Acknowledging. You send cues to the speaker that acknowledge that you are hearing them. You have to demonstrate that you understand the ideas. Make eye contact and dilate your pupils, raise your eyebrows, nod your head. This is more than just acknowledging that you here the words (and be aware of different cues in different cultures). You have to acknowledge the ideas to be effective. When you don’t understand something, you can make the “I don’t get it” face.
  2. Restating. The best way to overcome missed signals in the non-verbal attends that represent acknowledgment is by restating what you just heard. The key to restatement is not reiteration, but paraphrasing. You demonstrate that you’ve absorbed a concept by rewording it. If you missed a key concept, your reworded restatement should make it obvious to the speaker that you missed the idea. In an ideal world, she will be practicing active listening skills too – and will restate your restatement, providing another means for you to grasp the idea.
  3. Reflecting. Imitation is the most sincere form of flattery. Subliminal imitation is sort of what reflecting does. You pick up on the body language and emotions of the speaker, and reflect them back at her. Several “how to get ahead” management books will tell you to emulate your boss. This is because we are all pre-wired for a little bit of xenophobia. We tend to like people who are “like us.” More importantly – by demonstrating that you are developing the same reactions as the speaker, you are affirming that you have reached the same understanding.
  4. Interpreting. Ah, the psychiatrist’s trick. “I see from your uncontrollable twitch that this has upset you. Tell me why…” This is generally focused on being empathetic, and encouraging people to talk more. However, this is also where you can ask for clarifications, to make sure you understand what your speaker means. “Are you saying you need ‘drag and drop’ because you need an easy to use interface, or because people will be using a tablet pc with no keyboard?
  5. Summarizing. When you ask a good open ended question, you will get a relatively long response. When applying active listening skills to requirements gathering, you often want to let your speaker go off-topic a little bit, as it helps identify other requirements. Make notes of those other topics for followup, then summarize the parts of the answer that addressed your initial question. You’re reinforcing for the speaker that you understood why they said what they said, and that you didn’t muddy the waters with the other information they gave you.
  6. Probing. People often summarize in order to communicate effectively. Developers will use design patterns to allow them to describe detailed software implementations in a word or two. People in general will use symbols as replacements for compound ideas. Ask a clarifying question or two to assure the speaker (and yourself) that you understood what they intended you to understand. This can also help you with credibility with the speaker, as it demonstrates some knowledge of or comfort in their domain.
  7. Giving Feedback. By sharing your opinions about particular ideas, you create a collaborative bond with the speaker. You should focus on affirmation of their insights or ideas, instead of criticisms. If you tell someone that their question is stupid, you encourage them to shut down and shut up. Listen to speakers or panelists in a Q&A session – they regularly start their answer with “That’s a great question.” The really good ones will say “That’s a great question, because…” Without the because, the feedback can start to sound like a pre-programmed platitude. Quickly snap off half a dozen “Great Question. Here’s my answer.” answers without the rationalization, and people will tune it out as noise. If you’re struggling for responses, use anecdotes. “That’s a great question, I had a client who never asked it – and here’s how the disaster unfolded…”
  8. Supporting. Validation of the speaker’s ideas and concerns is important. By supporting their worries as being valid, and ultimately resolving those worries, you create loyal customers. Dell recently launched their Idea Storm website to elicit exactly this kind of feedback (among others). If they add their voices to the mix, providing support for the ideas that people present, they will get more and better ideas. If they follow-up, they can demonstrate a clear cause-and-effect for their customers. “You said it. We did it.” That would generate some loyalty!
  9. Checking Perceptions. When you’re actively listening to someone, in addition to getting data, you are forming impressions and perceptions. You need to check the validity of those perceptions with the speaker. When gathering requirements, this often leads to identification of the true requirements, and even implicit requirements. You’re also letting the speaker know that you “get it.” This is a great opportunity to double up on the supporting and feedback active listening skills with responses like “I think that is a great requirement, because it will prevent incorrect orders from being shipped, and that will reduce field-servicing costs. Or was there a different benefit you had in mind?”
  10. Being Quiet. Interviewers use this technique all the time. Silence can make people uncomfortable, so they tend to fill the void – the only way they can, by talking more. While this is effective for confrontational interviews, there are more positive and enabling reason to do be quite. First, you need to temper your exuberance to provide feedback, support and summaries, so that you appear to be listening and not talking. You’re meeting with someone so that you can understand their perspective – not so that they can understand yours. Second, you want to give people time to think. If you are creating a “take all the time you need,” positive, supporting silence, they will use that time effectively. The attends and emotional affirmations you’re providing are what make it supporting and not interrogative.
  11. [Bonus] Extension. This is a variation on the restating technique. Many people you interview will be providing you with data from a discrete perspective. When gathering requirements, you have to find a way to abstract that information into market requirements. People also often talk in terms of their existing tools and processes. You may be getting great information, but it may be overwhelmed in implementation details, either about how they do their job, or how they envision the future system to be. A great way to validate that you’re generalizing the salient parts of their ideas is to extend the ideas. “I need to be able to sort the accounts receivable list by name, even though Joan sorts them by outstanding amount” can be combined with other requirements and extended to “Each user shall be able to organize outputs by field in the UI.” And you just discovered that Joan is a stakeholder who uses the same functionality for a completely different purpose.


Active listening skills are critical to communication, and more importantly, collaboration. Requirements gathering – for product managers AND business analysts, is the essence of collaboration. It isn’t input only. Use your active listening skills to make the conversation bi-directional, and you will get better information. You’ll also have better products, and happier customers.

5 Return On Investment Calculation Tips


[Update 2007/02/12: Welcome TamsPalm readers from Carnival of the Capitalists. We hope you like what you find and stick around. Let us know what you think!]

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.

Continue reading 5 Return On Investment Calculation Tips

How to Write Good Use Case Names – 7 Tips


The first step in writing the use cases for a project is to define the scope of the project. One way to do that is to list the use case names that define all of the user goals that are in scope. To do that, you need to know how to write good use case names. Good use case names also serve as a great reference and provide context and understanding throughout the life of the project.

Goals of Use Case Naming

Use case names are also known as use case titles. When creating names, we have a set of goals:

  • Clearly indicate the user goal represented by the use case.
  • Avoid specifying the design of the system.
  • Make people want to read the use case, not dread reading it.
  • Allow for evolution of use cases across releases.
  • Define the scope of the project.
  • Write consistently

Common Use Case Mistakes

We identified the top ten use case mistakes in a couple of articles about a year ago. They still hold true today:

From Top Five Use Case Blunders:

  • Inconsistency
  • Incorrectness
  • Wrong Priorities
  • Implementation Cues
  • Broken Traceability

From Top Ten Use Case Mistakes:

  • Unanticipated Error Conditions
  • Overlooking System Responses
  • Undefined Actors
  • Impractical Use Cases
  • Out of Scope Use Cases

Writing good use case names will help avoid errors in consistency, implementation cues, scope management, and traceability. They will also help us make people want to read the use cases. Think of the use case name as the headline of a magazine article – does it make you want to read it, or avoid it?

Good use case names also serve as reminders of what a particular use case does. Weeks after we’ve written a use case, a quick scan of the title will remind us of what the use case represents. On a large project with dozens of use cases, this is invaluable.

Tips For Writing Good Use Case Names

Here are the best practices we’ve adopted, and some we’ve collected from around the internet.

  • Good Use Case Names Reflect User Goals. A good use case name reflects the goal of the user (or external system). A name like “Process Invoices” doesn’t tell us what’s being done – is it collections, organization, auditing, or some other function? A more insightful name would be “Collect Late Payments From Customers.” The goal in this example is to collect payments from delinquent customers. The second name does a much better job of defining what the user is trying to do when they perform the use case.
  • Good Use Case Names are As Short As Possible. Some people suggest 5 words, or even two words. There are just too many examples that make setting specific word-count limits impractical. In the previous example, “Collect Late Payments From Customers,” which words would you remove without losing meaning? This name is as short as we can make it without losing clarity. This short name is better than “Collect Late Payments From Customers Who Are Past-Due.”
  • Good Use Case Names Use Meaningful Verbs. Usually people will suggest that we should prefer strong verbs to weak verbs. That is effective advice for general writing. For writing use cases, we can be more specific. A meaningless verb is one that, while indicating action, does not specify the action with enough detail. “Process the Order” can be improved with a more meaningful verb. “Validate the Ordered Items” makes it much more clear what the user is trying to achieve.
  • Good Use Case Names Use An Active Voice. A call to action is a hallmark of good writing. Using an active voice will inspire action more than a passive voice. “Calculate Profitability” is more inspiring than “Profitability is Calculated.”
  • Good Use Case Names Use The Present Tense. “Create New Account” is in the present tense. “New Account Was Created” is in the past tense. The present tense implies what the user is trying to do, not something that has already been done.
  • Good Use Case Names Don’t Identify The Actor. Some people prefer to name the actor in the use case, because it is more specific. We like the idea of using evolutionary use cases to manage the delivery of functionality across releases. When we do this, we are often releasing the first version of the use case for one actor, and the next version for another actor. For example, “Rank Employee Performance” might be our use case. In the first release, we want to enable the functionality for supervisors – who can rank their direct employees. In the second release, we want to add the ability for managers to rank the employees that report to multiple supervisors. We prefer having two versions of the same use case over having two use cases (Rank Direct/Indirect Employee Performance).
  • Good Use Case Names Are Consistent. We should always apply the same set of rules across all of our use case names. Inconsistent application of the names will create a sense of discord for our readers. Consistent names will make it more comfortable for readers, and provide a sense of cohesion for the overall project.

Other References


Good use case names take very little effort once we are used to writing them with a consistent style, following the tips listed above. Good names also provide benefits down the road when reviewing and reading the use cases. Good names are short, clear, and stylish. They also make us want to read the use cases, and easily jog our memories about the user’s goals.

Marketing Truths – Don’t Tell the Developers


Marketing is as foreign to most software developers as flying is to fish. We’ve found a list of ten truths of marketing, and we’re secretly sharing them with the developers who hang out here. Shhh. Don’t tell anyone in marketing.

Marketing 101

John Dodds wrote Marketing 101 For Geeks, where he shares 10 observations about marketing that might make sense to geeks and coders.

Here’s John’s list with our comments:

  1. Marketing is not a department. A great way to segue into the conversation – as an engineer, the first visual I always have of a marketing department is the one from Dilbert (Scott Adams draws marketing people as if they are at a perpetual cocktail party).
  2. Marketing is a conversation.* This is hard for developers. Conversation requires two-way communication. That’s a truth. But good marketing pre-empts questions and answers them. Imagine the reader having a conversation with your copy (marketing materials): “I wonder what this is?” “oh.” “I wonder how we could use that?” “oh. cool.” “where can I get it?”
  3. Simplicity does not negate complexity. A clear, easy to understand message is what coders might call “incomplete,” “over-simplifying,” or “simplicistic.” The secret that marketers keep to themselves is that this clear message is what opens the door – making it possible for customers to (eventually) understand and appreciate the power of a product that might be described with greater complexity.
  4. Think what? not how?. As cool as it might be that your search engine uses a trie data structure, what potential customers care about is the fact that you can search a billion documents in a tenth of a second. This secret seems to be the reverse of a simple definition of geek – “someone who cares about how it works more than what it does.”
  5. Think will not can. Featuritis is the condition of having too many features. Even the swiss army knife eventually became too large to slip in your pocket. We have to focus on what users need to do, and not everything that could possibly be done.
  6. Only you RTFM. Think about the obvious ways to use a product. Intuititive user interfaces have affordances. They don’t require people to read the manual. And the manual should be written to help people accomplish their goals- not as a description of the functionality.
  7. Technical support is marketing. Every touch-point with a customer is a marketing opportunity. Remember, we market not just by purchasing ads and putting up booths at conventions. We market by word of mouth.
  8. You’re not marketing to people who hate marketing. Remember the disdain you had when you started reading this list? Well, we’re not marketing to people who hate marketers. People want to know how to solve their own problems. They want to know how they can use our products to help. And they like the people who tell them.
  9. You’re not marketing to people who hate technology products. The people who get our message are the ones who are technology-agnostic (see #4 above). They neither love nor hate the product. But they love solutions.
  10. Marketing Demystifies. Remember the conversation from #2? As the conversation progresses, we enlighten our customers, and eventualy they develop an understanding of what they can do with our product. And from this, they develop a desire to buy our product.

*John’s original point #2 was really an anti-jargon point. We thought the conversational part of his point should be stressed instead.


Don’t let them know, but we’re on our way to understanding how this stuff works.

Ten Requirements Gathering Techniques

The BABoK (Business Analyst Body of Knowledge) lists 10 techniques for gathering requirements. Here’s an overview of each one. For more details, check out the latest Guide to the BABoK.

  1. Brainstorming
  2. Document Analysis
  3. Focus Group
  4. Interface Analysis
  5. Interview
  6. Observation
  7. Prototyping
  8. Requirements Workshop
  9. Reverse Engineering
  10. Survey

1. Brainstorming

Brainstorming is used in requirements elicitation to get as many ideas as possible from a group of people. Generally used to identify possible solutions to problems, and clarify details of opportunities. Brainstorming casts a wide net, identifying many different possibilities. Prioritization of those possibilities is important to finding the needles in the haystack.

2. Document Analysis

Reviewing the documentation of an existing system can help when creating AS-IS process documents, as well as driving gap analysis for scoping of migration projects. In an ideal world, we would even be reviewing the requirements that drove creation of the existing system – a starting point for documenting current requirements. Nuggets of information are often buried in existing documents that help us ask questions as part of validating requirement completeness.

3. Focus Group

A focus group is a gathering of people who are representative of the users or customers of a product to get feedback. The feedback can be gathered about needs / opportunities / problems to identify requirements, or can be gathered to validate and refine already elicited requirements. This form of market research is distinct from brainstorming in that it is a managed process with specific participants. There is danger in “following the crowd”, and some people believe focus groups are at best ineffective. One risk is that we end up with the lowest common denominator features.

4. Interface Analysis

Interfaces for a software product can be human or machine. Integration with external systems and devices is just another interface. User centric design approaches are very effective at making sure that we create usable software. Interface analysis – reviewing the touch points with other external systems – is important to make sure we don’t overlook requirements that aren’t immediately visible to users.

5. Interview

Interviews of stakeholders and users are critical to creating the great software. Without understanding the goals and expectations of the users and stakeholders, we are very unlikely to satisfy them. We also have to recognize the perspective of each interviewee, so that we can properly weigh and address their inputs. Like a great reporter, listening is the skill that helps a great analyst to get more value from an interview than an average analyst.

6. Observation

The study of users in their natural habitats is what observation is about. By observing users, an analyst can identify a process flow, awkward steps, pain points and opportunities for improvement. Observation can be passive or active (asking questions while observing). Passive observation is better for getting feedback on a prototype (to refine requirements), where active observation is more effective at getting an understanding of an existing business process. Either approach can be used to uncover implicit requirements that otherwise might go overlooked.

7. Prototyping

Prototypes can be very effective at gathering feedback. Low fidelity prototypes can be used as an active listening tool. Often, when people can not articulate a particular need in the abstract, they can quickly assess if a design approach would address the need. Prototypes are most efficiently done with quick sketches of interfaces and storyboards. Prototypes are even being used as the “official requirements” in some situations.

8. Requirements Workshop

More commonly known as a joint application design (JAD) session, workshops can be very effective for gathering requirements. More structured than a brainstorming session, involved parties collaborate to document requirements. One way to capture the collaboration is with creation of domain-model artifacts (like static diagrams, activity diagrams). A workshop will be more effective with two analysts than with one, where a facilitator and a scribe work together.

9. Reverse Engineering

Is this a starting point or a last resort? When a migration project does not have access to sufficient documentation of the existing system, reverse engineering will identify what the system does. It will not identify what the system should do, and will not identify when the system does the wrong thing.

10. Survey

When collecting information from many people – too many to interview with budget and time constraints – a survey or questionnaire can be used. The survey can force users to select from choices, rate something (“Agree Strongly, Agree…”), or have open ended questions allowing free-form responses. Survey design is hard – questions can bias the respondents. Don’t assume that you can create a survey on your own, and get meaningful insight from the results. I would expect that a well designed survey would provide qualitative guidance for characterizing the market. It should not be used for prioritization of features or requirements.

Outside Reading: Top 10 Signs You Should Not Write Requirements

reading outside

Seilevel has a post that presents the top 10 signs that you should not pursue a career writing requirements, check it out.  Thanks Joy for the great article!
Our favorites:

#10 You cannot quickly understand new concepts

#9 You don’t have the patience to deal with customers

#4 You cannot form a mental model of all the pieces

Our take

Writing requirements is much more than taking dictation.  To develop great software, you have to develop an understanding of the needs of the customer.  From those needs, you have to synthesize a solution approach.  And you have to communicate that approach, both with customers (to validate it) and with the engineering team.  All of Joy’s entries (except the bonus #0 item) support this general framework.

We agree with Roger’s comments on the post that agile processes are not mutually exclusive to writing requirements.  Charles posted recently about the new product manager – implying that an agile product manager is different than a non-agile product manager.

There are many different agile processes, which use differing amounts of up-front planning, and differing formats for documentation.  Feature-driven development (FDD) does high level planning to understand the general approach of the product.  Details are then defined incrementally.  Incremental development works best when the most important stuff is worked on first.  This doesn’t preclude the need to communicate with customers and developers.  The fact that this communication happens incrementally doesn’t make documentation irrelevant.
The conversation about item #0 continues on Seilevel’s discussion forum, join in there, or add your thoughts here.

Customer Independence Day

Spirit of 76*

If This Be Treason, Make the Most Of IT! (Patrick Henry)

The customer is always right, except when he is wrong. When we have bad customers, we should fire them. Declare today as Customer Independence Day, where we declare our independence from bad customers.

The Loophole

While the customer is always right, there’s a big loophole – when the customer is wrong, he should stop being our customer.

Hawkins on Firing Customers

Christopher Hawkins provides a list of 11 customer archetypes who should be fired. Having them as customers is just bad business. Christopher provides a lot more detail, and here is his list of abusive client types:

  1. The disillusioned
  2. The suspicious
  3. The chiseler
  4. The bully
  5. The something-for-nothing
  6. The slow-pay
  7. The flake
  8. The liar
  9. The blackmailer
  10. The money pit
  11. The clinger

Our Take

We agree that people who exhibit these traits tend to make bad customers, friends, bosses, etc. We should always strive to resolve conflicts or change the behavior of our clients when it is unacceptable. Only when all else fails should we abandon a customer because of a personality problem.

There are times when we have great relationships with our customers, and we simply become unaligned. We should fire those customers too. Perhaps the client’s strategy is changing, and it isn’t one we want to support. Perhaps the customer’s needs are such that they ask us to perform work that we choose not to do. Perhaps our direction has changed, or is evolving, away from an existing customer’s business needs.
We will dilute our efforts if we try and be all things to all people.

As a small company starting out, it can be very hard to walk away from a bad “opportunity” with no paying alternative in sight. Someone once said “the hard thing to do is often the right thing to do.” It could be for you. It has been for us in the past.

Be Professional

We’ve decided to fire customer X. We don’t want to dump a shipment of tea in the harbor. Customers have memories, and they also have friends. Even if we never want to work for customer X again, we don’t want a bad reputation.

Some things to do when separating from a customer:

  • Be courteous and polite.
  • Provide ample lead-time. Two weeks is a minimum, even if the customer wouldn’t have provided it to you. Some situations require more lead time.
  • Review your documentation and update it as needed. Presumably, someone else will take the post we decline (or abandon). Make sure they have all the information they need to know everything you did.
  • Be proactive about knowledge transfer. Don’t wait for the client to ask for knowledge transfer – actively contribute to the plan, and drive it forward.
  • Reccommend alternatives. If you can propose your own replacement (and vouch for her) – even better.

– –
*(based on The Spirit of ’76 by Archibald Willard 1836-1918)

Know Thy Customers’ Markets

Profiler logo

Michael on Product Management and Marketing has posted the first in his series of product management commandmentsKnow Thy Customer. He provides five tips on how to know your customer better. We extend his idea to include understanding our customers’ markets, and provide more tips. By analogy, this is the difference between a detective who studies a criminal and a profiler who seeks to understand a class of criminals.

Why Must We Know Our Customers?

As Michael points out, the key trait of an effective product manager is one who knows her customers. As product managers, we have to understand our customers’ problems and convert them into requirements. From those requirements we define solutions, represented as products. Without a good understanding of our customer, we can’t identify the most important problems, and therefore can’t create the most valuable solutions.

Michael suggests five ways to know our customers better:

  1. Listen to customers.
  2. Usability tests.
  3. Follow-me-home.
  4. Walk-a-mile.
  5. Customer surveys and focus groups.

Michael’s article

Know Thy Customer’s Market

One of many points that Pragmatic Marketing makes in their training is that product managers need to focus on multiple customers, not individual customers. They replace the “become a customer expert” goal with “become a market expert.” This helps drive their point home. We think we need to know our customer’s market, and not just our customer.

Understanding the market our customer requires us to know not only our customer, but our customer’s competition. Knowing our customer helps us understand the important and valuable problems. Knowing her competition’s problems helps us know which problems have value for multiple customers. One-customer problems require custom solutions. We want to maximize the time we spend on creating reusable valuable product features.

Michael definitely uses the plural when talking about understanding customers. We are taking this one step further, to include understanding of potential customers.

Things to Know About Our Customer’s Markets

  1. The competitive landscape. Are there few or many companies in the space? Is it an oligopoly, monopoly, or free market?
  2. How does our customer compete? What are the factors that our customer believes make them (or will make them) competitive? Do they compete on price or features? Do they rely on existing customers or new customers for their growth?
  3. Is the market growing, shrinking or stagnating? Is our customer fighting for a larger slice of a shrinking pie?
  4. What might disrupt this market? Our customer’s market is at risk of being obviated or obliterated at any time. Our customer may or may not accept this reality. At a minimum, we will understand our customers better by understanding their risks.

In addition to learning about potential customers, we also get a deeper understanding of our current customers by studying their markets.

More Sources of Customer Information

In addition to Michael’s five tips, we would suggest the following for each major player in the market:

  1. Read the annual report. In addition to market data, we will find out what the CEO believes to be the most important objectives of our customer. This will help with prioritization of requirements.
  2. Understand the users. Creating personas to characterize the users of our software at our customer helps us make better design decisions.
  3. Diagram the political power in the organization. Politicians hold the trump cards for all software projects. By understanding who the real decision makers and influencers are, we can markedly improve our prospects for successful software sales. [Note: This applies to enterprise software more so than shrink-wrapped software.]


It is neccessary, but not sufficient to understand a customer. It is far better to understand the market of customers.