From: dbucklin@sdf.org Date: 2016-06-19 Subject: The Purchase Funnel, Project Definition, and The Danger Zone The Danger Zone (thanks, Kenny Loggins) is any intersection of the sales and project definition processes that results in mismatched expectations between you and your customer. In software develop- ment, this happens when the customer pays for an outcome before that outcome is defined. This results in a disappointed or angry customer when, from their point of view, they didn't get what they paid for. In this article, well look at how these processes influ- ence each other, define the danger zone, and see how to recognize when you've wandered into it. This is an early version of the purchase funnel dating back to the late 19th century. There are newer models, but I chose AIDA because it is concise and relatable. This model was famously referenced in the 1992 film Glengarry Glen Ross. Each stage of the funnel is a description of your customer's state of mind. * Attention * Interest * Desire * Action How this happens in practice will depend on what is being sold and the parties on either side of the transaction. How I buy a candy bar at a gas station is entirely different from how a large corpo- ration buys professional services, though both of those purchases can be mapped to the AIDA funnel. How you organize activities and information relative to any conceptual funnel will depend on what you are selling, to whom, and the strategy used to move prospects through the funnel. As you spend more resources in this pre-sale phase, the cost of sale increases while risk is decreased. In custom software development, a key way to reduce risk is to in- crease the definition of the intended outcome. The tactics used to accomplish this and how they are represented to the customer will be influenced by the sales stage in which they occur. Ultimately, it is necessary to define the work to a level that is sufficient for production staff to start work. Think of project definition as a spectrum: at one end the work is undefined and, at the other end, we have wireframes, a style guide, user stories, and a technical architecture that cover the entire project scope. An engagement on the low-definition end of the spectrum is an agreement to bill the client for time spent without a commitment to specific outcomes. An example of a high-definition engagement is a fixed-bid response to an RFP that includes wireframes. In my experience, the middle of this spectrum is a danger zone ide- al for miscommunication and mismanaged expectations. Look for these signposts to see if you have wandered into the danger zone: * You've had less than 60-90 minutes to interview key client stake- holders about goals, users, constraints, and expectations of the user experience. * The client has articulated a vision, but produced no documenta- tion of their own. Watch out for a shifting vision and goal. * The estimating team has not had an opportunity to do their own investigation or accepts the information given as representative of the total scope of work. * Holes in requirements. Look for similes, jargon, nebulous termi- nology (e.g. typical, expected, standard, best practice, et cetera), and references to other elements that are not defined whether they are in or out of scope. In the end, these are all indicators that the customer expects spe- cific outcomes, but you can't articulate a plan to meet them. This is a challenge because you may not be able to capture all of their expectations and assumptions. Aim to avoid instances where you dis- cover that the client "didn't mention it" and you "didn't ask." * Spend more time with the customer to identify and manage these assumptions and expectations before commitments are made. * Define success factors from both a business and user perspective. This exercise alone can be immensely valuable. * Put yourself in your customer's shoes and Make It Make Sense. * Think beyond what the customer says they need and confirm with them that they don't want or need those things. * Your scope of work should include a list of dependencies on the client and a list of out-of-scope items that broadly cover things you are not going to provide, such as user research, performance testing, or customer support. Give yourself time to be the expert and get aligned with your client so that you can identify assumptions and manage expecta- tions. Sometimes you will have to tell them something they don't want to hear, and that's scary when you are trying to make a sale. Just know that you are positioning them to have a better experience after the sale, and are more likely to make a friend than an enemy.