From:
[email protected]
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.
