The Enterprise Software Playbook- 6 Steps to Better Deployments

Thanks to Bryan Boroughf, David Schach, Andrew Yang, and Joan Tyner for contributing their expertise as reviewers and editors. For more on the playbook’s editors, please see the Editors Page.
CRM-project-failures-sizedDepending on whose figures you believe (summary figures), failure rates for CRM implementations are 50-70%, as good or worse than a coin toss. Yikes.

Just implementing a system might have been good enough 20-30 years ago, but today we need to do better than this to stay competitive and relevant.

Why is the failure rate so high? I don’t know about you, but pretty much all the CRM implementations I’ve seen had the benefit of smart, well-intentioned participants. And we’re not splitting the atom here- the systems and tools are forgiving and easy to use.

We’ll have to dig in a little to figure this out. For starters, I subscribe to the idea that it’s important to define your problems explicitly before you explore solutions. The playbook material that follows aims to deliver on four key problem areas, which I’ve collected and prioritized based on my own experience and consultation with other practitioners.

The idea is that these four problem areas are root causes. So, for example, ‘low user uptake’ would be a symptom of these root causes. Also, I’ve framed them all in terms of alternatives since the goal here is to offer an actionable playbook that delivers better outcomes.

(What’s your view on key problem areas? Please, post a comment below- the goal here is to continuous improvement as a community of practitioners).

Frankenstein-CRM1. Order Taking vs. Consulting

You talk to the head of sales, the head of support, the head of operations, the head of finance, note their specific requirements, and using those requirements you construct your masterpiece. To your dismay, instead of the beautiful thing you thought you were releasing into the wild, it’s frankensteinian. After wreaking some havoc, it’s pursued by angry townspeople with torches.

While doing exactly what we’re asked by the user/customer is a good way to avoid blame and conflict, the amalgamated requirements rarely make for a good system or a good outcome. Many engagements can be improved through more constructive consultation on delivering what users need.
Three-Little-Pigs-Design-Sized2. Building vs. Designing

Salesforce makes it so easy to build something — check a few boxes, add a few fields, and you have yourself a fancy new CRM, right? Well not if it’s implemented ‘wrong’.

This is my favorite definition of ‘design’: to assign in thought or intention. Many enterprise software implementations fail due to a lack of thoughtful design. They could be improved through better discovery and definition around users and processes, and regular integration of design thinking into the deployment process.

Dorothy-Oz-Papering-Problems-Sized3. Papering Over Problems with Software vs. Solving Them

Software allows us to operate with the regularity and efficiency of a machine, and so it should bring order and regularity to an unruly mob of humans working together. This proposition sounds silly when you speak it out loud, yet I think it drives a lot of what’s wrong with enterprise software.

Too often, users and processes that need more thoughtful attention end up with an arbitrary layer of Salesforce around them, raising the failure rate on implementations. Design is neglected and we skip forward to implementation of the software because it’s there, it’s what everyone else is doing, it’s (relatively) easy to turn up and just start using.

It’s always a combination of a) thoughtful design around users and processes and b) appropriate enterprise software that delivers good outcomes. Enterprise software can only automate and standardize processes that humans design, so you have to know in advance what you want it to do. The software itself is unlikely to make those processes better and very like to make them worse if it’s implemented in an arbitrary way – it can only enforce processes, not improve them.

It’s important to engage on issues of substance and sketch a working solution around people and processes prior to layering software on top of the issue.

Little-Grey-Mouse-Composite-Sized4. Big Batches vs. Iteration

We burden ourselves with projects and we gratify ourselves by closing them. When we pack up for the day, we look at what we’ve checked off our to-do list.

Yet for something as complex as automating and standardizing the way individuals work together, output and outcomes are very different things.

Layered on the belief that the  perfect system will ‘fix everything’, we just want to get the whole system online. Assumption is compounded on top of assumption (implicitly or explicitly) to do this ahead of actual observations about user behavior, and the result is a (big) frankensteinian mess that no one likes. ‘The System’.

The Playbook that follows offers a 6-step process for more effective enterprise software deployments, be they small and tactical or large and strategic. Following these 7 steps won’t guarantee success by itself, but making yourself fluent in these techniques will definitely make you a more effective contributor.

The Playbook

The Playbook describes a 6-step process where the input is a business need and the output is a validated (or invalidated) solution. It’s scary and unpopular to talk about the possibility of invalidating a solution. A plan that looks predictable is more comfortable. Corporate IT is intolerant of the possibility of failure yet achieves it all the time (if you buy the stat’s above).

The Playbook minimizes the possibility and scope of failure by a) thoughtful, user-centric design practices and b) validating work in small batches:

(I created the diagram above in an application called ‘LucidChart’, which integrates with Google App’s. You can download the template above and are free to use it with attribution back to this page: PROCESS DESIGN TEMPLATE.)

01: Frame In the first step, you’ll frame the business need you’ll be fulfilling. We’ll start by framing the linkage of our deployment to the company’s business model. Then we’ll frame processes. Mention the word ‘process’ and people’s eyes start to glaze, but, trust me, this is a tool you can use to frame a tactical business need in casual conversation or constructively organize a multi-year IT project.

The summary above is an example.

Deliverable: A Process Inventory

02: Diagnose Here we’ll learn to use some simple tools from design thinking to make sure we understand and describe our users and the problems we’re going to solve for them.

Deliverable: Personas and Problem Scenarios

03: Propose One of the least interesting things we do in corporate IT environments is deliberate about what to do, and the higher the stakes, the more deliberation.

In this step, you’ll learn to propose solutions in soluble chunks with context that will constructively engage your audience and lower the stakes for everyone, avoiding indecision and hedging.

Deliverable: Problem-Solution Pairs + Validation Criteria

04: Execute Now we go build stuff. The goal is to execute the simplest possible implementation that will allow us to validate (or invalidate) our proposed solution. We can layer in more content in subsequent iterations if we validate that we’re headed in the right direction.

Deliverable: User Stories + Working Implementations

05 Test If we did a good job in step 3, this part should be easy: We’ve created simple validation criteria, and now we test our solution against those.

The last thing this should be is a simple ‘thumbs up, thumbs down’ from users (User Acceptance Testing). Given the interrelated scope of just about any enterprise software project, that’s an unreliable indicator. We’ll learn more about how to create best practice validation criteria below.

If our testing is successful, then we move on to the next step- package. If not, we journal our results and then revisit our diagnosis (step 03) and proceed from there.

Deliverable: Testing Journal & Validation Results

06 Package If we’ve arrived at a solution component that’s a keeper, we package up our solution- not an encyclopedia, just the bare minimum of things we’d want to have if we were picking up the solution from someone else to modify it.

Deliverable: Packaging of the Implementation

The Playbook’s job is to help you deliver better solutions to your clients and users, drawing on best practices in design thinking, lean/Lean Startup, agile, and process design. The playbook’s tools are

thoughtful yet actionable,

practical yet structured,

iterative yet plannable.

Most importantly the playbook itself is complete yet changeable in response to new learnings. I hope you’ll take the time to share your experience in the Comments below or in the forum of your choosing.

01. Frame

If you’re reading this, odds are you’re a pretty hard worker. Your favorite plan of action is …action!

I salute you, I resemble you, and, more often than not, getting to work and trying things is the right idea. That said, positive outcomes in this case are driven by good design and good design is driven by focus. In this case that focus requires a quick description of company strategy.

I know what you’re thinking- no one’s paying me to think about strategy. I’m just supposed to get the enterprise software right. Your client and/or managers feel they know what they want and that it’s the software’s job to sort everything out. You know that’s not true- that software can only standardize and automate work that you already know how to do.

I think you’ll find you that a lightweight strategic framing doesn’t take up too much time or goodwill and it will help encourage the change and focus any substantial enterprise software implementation requires. With it, you’l get:

  1. Structure.
  2. Linkage to success criteria.
  3. A drive to explicit, discussable designs
  4. Linkage to company business model & strategy.

With a little practice, you’ll be able to talk through this strategic framing in 20-30 minutes- not bad for a project you may be on for months!

In the next two subsections, you’ll learn both strategic and tactical framing for enterprise software deployment. Both tools come complete with ready-to-use (free) online templates.

01.A Framing Business Focus

For our business framing, we’ll be sketching answers to three key questions:

  1. Who are the buyers, users and why do they buy?
  2. What is the end-to-end customer experience?
  3. What activities are strategically important?

We’ll be using a tool called the Business Model Canvas. It’s chief virtue is that it’s pretty transparent and self-evident and I think you’ll grasp it just fine in the steps that follow. That said, here’s a Business Model Canvas Tutorial and Business Model Canvas Workshop, if you find yourself wanting more background.

The first thing you’ll want is a copy of the Canvas. I recommend making notes on the printable version in your early drafts, but here is a Google Doc’s template you can use and which I’ll reference in the material that follows:

Before we dive into the Canvas, let’s make sure we know this business. Draft a standard positioning statement to make sure you have all the basics on hand:

For (target customer) who (statement of the need or opportunity), the (product name) is a (product category) that (statement of key benefit – that is, compelling reason to buy). Unlike (primary competitive alternative), our product (statement of primary differentiation).

Here’s an example statement I created to describe ‘Children’s Theater’, the example we’ll be using here:

For children (k-12) seeking an expressive experience through the arts, the Children’s Theater is a performing arts institute that offers affordable programming to low-income schools and children. Unlike private institutions, our product offers national quality programming with a long track record of success.

The positioning statement’s a handy way to make sure you understand a business- with a little practice you’ll be able to improvise it during calls, meetings, etc. for clarification.

Back to the Canvas- the first thing you’ll want to do is think through the key customer segments and personas to answer our first framing question “Who are the buyers, users and why do they buy?“.

What are the different types of customers and are there major differences among them? What key value propositions does the business deliver to them? Sketch these out and then draw lines for any key linkages. Below is an example for Children’s Theater. (For more on creating personas & value propositions, see the Personas Tutorial.)


Now our second key question: “What is the end-to-end customer experience?”. For this, I like a framework for the 19th century: AIDA, which stands for attention, interest, desire, action. They weren’t that big on services in the 1890’s, so I also like to add onboarding and retention- AIDAOR. This is a good way to make sure you understand the customer journey, at least at a high level.

One thing I like to do to make sure I’ve really thought through a customer journey with AIDAOR is to storyboard it. Here’s an example for Children’s Theater:


If you’re interested in some tools for the storyboard, see ‘Storyboarding Customer Acquisition‘.

Once you’re thought through the customer journey, ask yourself what kind of Customer Relationship you need over the course of the AIDAOR journey. The typical spectrum is dedicated personal service (if you have a question about your stocks, you call Bob your financial advisor) to self-help online (residential, Gmail, for instance). In between you have intermediate options like personal service (a call center or retail floor) and web-based support (filing requests online).

Following from the Customer Relationship, you have Channels, the means you’ll use to deliver that relationship to your various segments. Both of these items may differ over the course of the AIDAOR journey and/or between Customer Segments.

Here’s how they look for Children’s Theater:

The key point with this part of the Canvas is to have a nice, clear summary of the customer experience. This is important first because much of enterprise software is about customer experience in some way and also because the items we’ve covered so far should be driving the left (infrastructure/delivery) side of the Canvas- and that’s the part which directly drives our next section on process design. Our last question speaks this this left part of the Canvas.

What activities are strategically important?“. These activities should be both important and unique to the company’s strategy. So, for example, it might be important to keep the books straight, but that’s probably true for every company.

A good way to zero in on this is to think about the company’s business type. The basic proposition here is that successful businesses have a focus that coheres to one of these three fundamental types:


Infrastructure-driven business are scale oriented: being able to sell a lot of whatever they have in a relatively consistent fashion is their key profit driver. The ones above may not be traditionally thought of as ‘sexy’ businesses, but this not general true of the type- educational institutions, for instance, are infrastructure businesses.

How does this matter for enterprise software again? Reasonable question! Consider this simple example: Would you implement a CRM the same way to support residential DSL at Verizon vs. accounts at a private Swiss bank? If you did, you’d almost certainly have a bad outcome at one of those clients.

Verizon is an infrastructure business whereas the private Swiss bank is a scope-driven business: it provides a set of services to wealthy individuals, Customization, flexibility and adaptation to individual customer needs is critical, whereas that’s not true for Verizon DSL (we all get the same thing and that’s fine).

The last category, product-driven, offers something unique and proprietary to the market as its core activity.

For more on this idea of business types, see the original HBR article ‘Unbundling the Corporation‘.

After arriving at a core business type, think about the Key Activities that drive the business. What are the 5-8 activities that deliver against the preceding items having to do with customers? The closely related item is Key Resources- what are the assets that the business has or will develop that enable the same?

Here is how it looks for Children’s Theater (along with the other last few items in the Canvas):

Business-Model-Canvas-Enterprise-Playbook-Example-v2Our next is to develop an inventory of process designs organized against these strategically significant Key Activities. We’ll then use those processes to draft a process-driven blueprint for our enterprise software deployment.

01.B Framing Processes

Few of us would object to the wisdom of ‘beginning with the end in mind’, yet how many times have we conveniently told someone, “We get the idea/we’ve got it,” when we’re not really positive we do understand?

It’s natural and it’s common, but it’s not productive, that mismatches in understanding will cascade and grow over the course of a project, turning it into a much larger mess at the end.

Conveniently for us, there’s a handy tool we can use to frame just about anything in this area: the atomic process. It has this general form:

Atomic Process

With a little (really, just a little) practice, you’ll be able to use the tool in casual conversation with stakeholders or to define a major project.

An atomic process always has

1. A discrete input (see circle on the far left)

2. A series of transformative steps (see the rectangles, triangles and flows)

3. A discrete output (see the circle on the far right)

4. These three metrics: process, output, outcome (more on that shortly)

The first three items are probably pretty self-evident, but about the fourth you may be thinking: ‘Everyone gets crazy on metrics; I can skip that one.’ Well, yes and no, is my answer.

‘Yes’ in the sense that of course you don’t need to instrument metrics for every little process.

‘No’, however, in the sense that if you can’t identify the three metrics for a process, it’s likely you’re on a shaky foundation that will crumble under the weight of everything you subsequently do.

Even if you’re not going to create or even pay attention to reporting for a particular metric, being able to at least identify these metrics is an important part of making sure you have a discrete, manageable process.

Let’s step through those metrics.

1. The Process Metric
This is a measure of raw throughput. If our subject was production in a doorknob factory, the process metric would be something like ‘doorknobs produced/hour. In a salesforce automation (SFA) context dealing with leads, it might be ‘new leads created/day’.

2. The Output Metric
This is a measure of ‘adequate’ throughput, meaning that it conforms to our definition of what a doorknob should look like. In doorknob production, it might be ‘flawed doorknobs/total doorknobs’. In our SFA example, it might be the number of leads that don’t meet minimum basic criteria- they’re duplicates, the email bounces, the contact phone number is incomplete, etc.

3. The Outcome Metric
For most of us, this metric is (relatively speaking) the hardest to formulate, yet at the design stage it may be the most important. This metric deals with the question of ‘Did the outcomes from this process move the dial on our  core objective? Did anyone care?’.

In doorknob production, the metric might be validated customer uptake (volume of new sales) and satisfaction with the doorknob (Net Promoter Score). In SFA, it might be the underlying effectiveness of the sales channel for connecting with and servicing the target customer segments (for example observed in any or several of: customer count, churn, dollar volume of sales, customer satisfaction).

That’s it. If you can make yourself fluent in formulating processes this way, you’ll be laying a much stronger foundation for you and your teams.

If this is feeling a little classroom-y, don’t fear. We’re about to apply this tool in a simple hallway conversation.


Our example takes place in the hallway outside a glassed-in ‘fishbowl’ conference room. It’s between a Salesforce consultant, ‘Salesforce Guy/Gal’ (SFG), and the client’s head of sales, ‘VP Sales’ (VPS). The client company is called ‘Nexus Energy Solutions’. It installs and operates energy-efficient systems at commercial properties.

SFG introduced herself yesterday at a meeting of the department heads and she’s been trying to get a sit down meeting with VPS. SFG runs into VPS and they start talking about lead qualification, VPS’ pet topic at the moment.

VPS: We’re wasting too much time on unqualified leads right now. That’s something I’d like to fix.

SFG: Got it. Well, we can do that! What’s your process, checklist, etc. for qualifying them now?

VPS: We don’t exactly have that. I was waiting for the system for that.

SFG: No problem; no time like the present. So, the input to the lead qualification process is an unqualified Lead and the output is a qualified Lead. Is the item to be qualified always a Lead record in Salesforce right now?

VPS: It’s not always a Lead- sometimes they have a Contact tied to an Account, even though the lead is not qualified.

SFG: How is that working, the use of both Leads and Contacts pre-qualification? Is that something you want to change or keep the same?

VPS: Change. We know how to qualify, we can qualify. The guys will do the qualification if there’s structure- they’re just getting sloppy because there’s nothing systematic in place.

SFG: You want to enforce qualification on Leads before they convert to Accounts, then?

VPS: I do for right now. That’s what I want to try. The question of when to convert varies a lot, but I think this is the right thing for the company right now. We’ll want to keep an eye on that, though.

SFG: What’s the best way for me to understand the qualification process you want?

VPS: Sit down with Matilda, one of our top salespeople. She wrote me an email about it and does a good job qualifying her leads. That’s a good place to start.

SFG: Will do, thanks….

SFG’s just done herself a huge favor. Before she delivers something in SFDC that all the Salespeople are forced to use, she’s going to work with an expert to diagnose the what they actually want to have happen.


From her hallway conversation with VPS, SFG has the following framing of the lead qualification process:

Example Process-Framed

She also knows that the input should be a Lead record and the output should be an Account, Contact, and Opportunity, and only if all the qualification criteria pass. She needs to diagnose what that really means in her next conversation, with Matilda in sales. More on that conversation shortly.

This is just one process. If you’re doing a larger project, you may find you want to do a larger framing by creating a process inventory. For more on that, see: Supplement A: Creating a Process Inventory.


If you want to… See
Link a process redesign project with corporate strategy and the Business Model Canvas or create a process inventory Appendix A: Creating a Process Inventory

[DISCLAIMER: I don’t know much of anything about energy provision, utilities, commercial buildings, etc. I chose a topic I didn’t know so I’d avoid using any specialized terms or concepts.]

02. Diagnose

Thoughtful diagnosis of what problem your implementation’s solving and how it’s going to solve it requires the balanced application of empathy and creativity. These are the pillars of ‘design thinking’.

By way of counter-example, the (all too common) antipoles of failed diagnosis are a) doing precisely what the user asks for and b) assuming you know best and just doing what you think is right.

For diagnostic tools, we’re going to borrow from the core product design curriculum. Our foundation tool is the use of personas, humanized descriptions of our users.

Now, you may be thinking ‘This sounds excessive- I’m not trying to sell them the next revolting energy drink or hit mobile app. It’s enterprise software. They have to use it- it’s their job.’

Persona-Think-See-Feel-DoI’d say- ‘Good point. We’re not here to create work and we are here to question assumptions.’ But here’s the thing: 50-70% of enterprise software implementations fail and I’ll put forward one root cause as being little-to-no attention to empathizing with the users-  understanding who they really are and what they need to do their jobs better. Here’s the good news- once you make it a habit, creating personas is quick.

A persona is a composite of an actual customer or actor in your domain of interest. At our example company, Nexus Energy Solutions, one such persona might be ‘Sven the Salesperson’.

Personas have two primary components:

1) Who are they? Can you think of 5 examples of this persona? What’s a day in their life? What shoes would they wear?

2) What do they {think, see, feel, do} in your area?

Think-See-Feel-Do, is a kind of checklist for you to make sure you have a durable description of how your persona acts in your area and what propels them to action. We’ll walk through an example below (‘Sven the Salesperson’).

Once we know who we’re working with, we organize what we’re going to do for them around ‘problem scenarios’. Before you dive into a solution, it’s import to be explicit about the problem(s) you’re solving. Otherwise, how will you know if what you’re doing has any relevance?


In a business context, problem scenarios are a way of identifying the fundamental jobs that our persona is doing. In the areas SFG (Salesforce Guy/Gal’) has discussed with Nexus Energy Solutions, a few important problem scenarios might be:

Adding Profitable Customer Relationships
Encouraging the Use of Learned Best Practices in the Sales Process
Consistently Apply Qualification Criteria to Increase Close Rate
Supplying High Quality Inputs Downstream to Solutions Teams
Providing Visibility to Management on Sales Progress

If a problem scenario exists, you should be able to readily identify current alternatives. Understanding those is important- Yes, you’re implementing ‘the system’ that’s supposed to make everything awesome but the reality is that all it can do is automated, standardize, and store what users are already doing. For example, our heroine, SFG, astutely identified that she needed to get direction from VPS on where to find best current practices on lead qualification. SFG’s not going to blindly implement these current alternatives into Salesforce, but that alternative her primary input into laying out an explicit process to define, validate with VPS (on paper), and then validate with real users.

After understanding the problem scenarios and alternatives, you move on to generating valuable solutions (aka ‘value propositions’ in general product design). For example, SFG is already thinking about how she’ll translate the best of what Nexus Energy Solutions has learned about qualifying leads into something that can work in Salesforce. Way to go SFG!!

Rube-GoldbergAt this point, you’re ready to dive in and start designing processes. Without a foundation in personas and problem scenarios, the Salesforce-Guy/Gal runs a very high risk of creating overly complex, impractical solutions divorced from actual user needs and business imperatives. Diagnose carefully to avoid complex, irrelevant Rube-Goldberg implementations!

How do you actually go create all this stuff- personas, etc? Direct observation of your users in their natural environment is the most important thing. What do they actually do?

As the consultant/SFG, you’ll usually be ushered into a conference room to talk with the head of {sales, support, operations, etc.}. From this, you’ll probably learn very little about the actual end users who will determine the actual success or failure of your implementation. So, have that meeting with the head of {whatever}. But then ask if you can walkabout and meet end users. Look at what’s posted on their cubicle walls. Ask them if they’ll show you how they do what they do, and ask them if they have any ideas on how to improve things. If they’re using wacky Excel sheets to do their job, get those spreadsheets and make sure you understand them- they’ll tell you a lot about problem scenarios of importance and the current alternatives.

For more on design thinking and the creation of personas, see the Go Deeper subsection below.


With license and direction from VPS, SFG meets with Matilda, who, according to VPS, understands and has made notes on the lead qualification process:

SFG: Hi Matilda. Thanks for making time for me.

M: No problem at all.

SFG: [VPS] mentioned you were the state of the art on lead qualification. I want to make sure we incorporate Nexus Energy Solutions’ best practices into the Salesforce implementation and so I was wondering if you could tell me about what you do and what you’ve learned is effective.

M: Sure. The main things I focus on are the vendor and duration on their current contract, … [a few other general things].

SFG: Could we walk through how that worked on a recent lead?

M: Definitely. That would be [customer]. Here’s what happened: [now SFG gets more actionable detail on what works].

[they go through another example or two]

SFG: That’s excellent, thanks. How do you define success on these qualifications? What’s a good outcome vs. a bad/less good outcome?

M: Obviously, whether we win the opportunity or not. But I guess specifically on this, I’d look at whether I missed something I could have used to qualify, something where I ended up wasting time on chasing a deal I should have disqualified earlier. Also, the Solution Engineer’s work- did they get what they needed?

SFG: What’s a Solution Engineer? What do they do?

M: They’re a cross functional role between sales and operations. They draw up the proposals and quotes for customer. The good ones help us balance making the offer compelling with making sure it’s something we can deliver and make money on. We can’t close a deal without them. They use the qualification notes I make to create the proposals that go to the customer.

SFG: Got it. Who’s your favorite Solution Engineer?

M: I don’t like to play favorites, but Sonja is great.

SFG books time with Sonja and learns about the proposal formulation process, which she needed to do anyway based on the scope of her Salesforce project. She also learns that inputs from sales are patchy- Matilda generally emails pretty good notes that they can use to make a proposal with minimal additional investigation, but that’s not the case with all of the salespeople. In a lot of cases, the inputs are just about useless and the Solution Engineer has to call back the customer or even go on site to get what they need. This doubles the amount of contact with prospects, which annoys them (if they respond at all) since a lot of what the Solution Engineer asks the prospect claims they’ve already told the salesperson.


To date, SFG has created two personas for her project, .

Note: SFG’s firm has a library of such personas and she was able to use these as a starting point, reducing the amount of work in this area.

Sven the Salesperson
Sven-The-Salesperson-Persona-SizedSven’s got the most honest job in the world: he gets paid when he sells. Professionally speaking, his world revolves around that fundamental driver.  If he’s not on the phone or in front of a customer, he’s not making money.

Paperwork, which is anything that doesn’t directly involve closing business, is a necessary evil and thinly tolerated. He appreciates the importance of taking care of his colleagues in other departments, but given his background often delivers drinks at the bar or a fruit basket when they’d prefer better housekeeping around deal inputs and account management.

Thinks He knows that deal implementations get held up downstream, but doesn’t have time to really dig into why. He suspects that it’s just the burden of people who only get paid if they sell to push and pull the salaried types along to get deals done.
Sees Competitors that have good tools and support book deals and those that don’t make it too hard for the customer lose deals.
Feels Sales doesn’t get the respect it merits. Everyone he deals with outside of sales doesn’t get what it’s like to have doors slammed in your face, to wonder every night what your quarterly bonus (aka how he pays his mortgage) is going to look like.
Most bureaucracy, and this definitely includes CRM, is a pitiful waste of time. Produce or go home.
Does Right now, Sven only puts deals into Salesforce when he needs to move them to formal proposal, since that’s the only way proposals get generated. Generally, the deal description and qualification are patchy.

Sonja the Solutions Engineer
Sonja-the-Solution-Engineer-PersonaSonja’s the glue between sales and operations, even though formally she’s in sales. Her job is to take whatever sales brings in and try to bring it to a place where sales can get the deal, the customer is going to be happy once they start getting billed, and the deal is a good one for the firm.

She’s usually at her desk or at customer sites working on projects. She gets dragged into more meetings than she’d like to discuss product and sales process.

Thinks What works and what doesn’t is pretty clear, but she doesn’t want to get in the middle of the shouting match between sales and operations.
Sees Deals come in without much description on a regular basis. It’s a lot of work to really get things in a place where there are no surprises once the account starts getting bills.
Feels She’s often the bottleneck on moving deals to revenue and every night she goes to bed feeling like she’s not doing enough, that she’s disappointing the company by not getting more done. It sucks.
Does She’s tried to create her own system for getting things done as best she can. The inputs and the requirements at the other end in operations keep changing, though, so it’s hard.

Before we move on to problem scenarios, a final note on people vs. roles for when you’re creating personas. In an enterprise software context, it’s generally advisable to be role-oriented vs. individual-oriented.

Let’s say that two years ago when Nexus Energy Solutions was really young they had two salespeople who did their own solution engineering work and then one salesperson and one solution engineer. What personas then? I would say the same: a Salesperson persona and a Solution Engineer persona. If there is a clear difference in role, creating your personas that way will keep things clean. If an individual acts in more than one role, there’s no harm in that.

SFG has identified the following anchor problem scenarios that she’ll use to focus and validate her subsequent work:

Problem Scenario Current Alternatives Your Value Proposition
Adding Profitable Customer Relationships (This is a kind of parent problem scenario for those that follow). Currently the company is using Salesforce with a few ad hoc customizations. SFG will design implement, and train on a Salesforce configuration that increases both efficiency and effectiveness, helping the company increase performance while scaling.
Encouraging the Use of Learned Best Practices in the Sales Process SFG is still learning what works well for them. SFG will help them implement these on Salesforce and put them in a position to continually reinforce evolving best practices.Just getting visibility into what the salespeople are really doing (via regular use of Salesforce) will be a huge win in evaluating and refining best practices.SFG will keep the implementation of salesforce automation to a ‘maximum of simplicity’ to reduce the overhead for sale and encourage regular use.
Supplying High Quality Inputs Downstream to Solutions Teams Right now, a few Salespeople supply good notes over email, but most put in just a few criteria and the Solution Engineers end up starting more or less from scratch. SFG will help Nexus standardize on their current best practices in this area and continue to propagate those as they evolve.
Providing Visibility to Management on Sales Progress Right now the various Sales Directors end up compiling a gigantic spreadsheet since there just isn’t enough reliable data in the CRM system. SFG will help management refine a set of actionable metrics and implement supporting reports in Salesforce. But that’s the easy part.SFG’s real value proposition here is implementing an end-to-end CRM process that all the participants regularly use and to which they supply quality data.

Based on all this, SFG drafts detail into the lead qualification process so she can review it with Matilda and then VPS:



If you want to… See
Learn more about applying design thinking Tutorial: Personas & Problem Scenarios
Template: Creating Personas
Workshop: Venture Design I ‘Achieving Customer Relevance’
Using storyboards to think through your concepts Workshop: Storyboarding
Creating empathy for your personas Exercise: A Day in the Life

03. Propose

Propose-Agree-DeilverThe triangle between proposing, agreeing, and then making an acceptable delivery has bedeviled software development since its earliest days. If you struggle here, don’t feel bad- most of us do

A. Start by Proposing Problems

If you find yourself answering questions about a solution where not everyone’s in agreement or clear about the problem(s), you’re already in trouble. Lead with your problem scenarios, get agreement on their definition and priority and then move on from there.

If you’re on a larger project, you may want to nest problem scenarios at various levels of detail, for example:

Adding Profitable Customer Relationships
Encouraging the Use of Learned Best Practices in the Sales Process
Consistently Apply Qualification Criteria to Increase Close Rate
Supplying High Quality Inputs Downstream to Solutions Teams
Providing Visibility to Management on Sales Progress

This nesting will also give you a handy tool for tuning your presentation for different audiences whose preference for detail may vary.

B. Propose a Testable Solutions
I won’t belabor this since you’ve probably heard all about it, but evidence-based work patterns are at the core of best like Lean Startup, lean enterprise, and Test-Driven Development. The diagram below summarizes my take on how it should work in enterprise software deployments:


The idea(s) you’ll take through the process should come from your diagnosis- they’re the problem scenario-alternative-value proposition trios. Hopefully, at this point you’ve completed ‘step A’ above and have validated a prioritized list of problem scenarios with your stakeholders.

In our case here, this will always be some formulation along the lines of “this will be usable by the audience in question and, for the company as a whole, better than the current alternative.” The actual formulation of the hypothesis may be quite different for work in the area of lead qualification vs., say, order management- but the core attributes of immediate usability and surpassing the current alternatives should always be present.


How will you know if it really is usable and better? Assuming you’ve validated the basic propositions, start with usability. In most enterprise software projects, just getting everyone to use the system in a standardized way is a win. That sets the stage for continuous improvement and automation, where applicable.

On experimentation, move from detailed observations of a small set of users (probably with relatively frequent tweaks) to more generalized observations of a  larger set of users (hopefully with less frequent tweaks). Don’t fall into the trap of trying to get ‘statistically significant’ results, particularly at the early stages.

Just because we’re using the scientific method doesn’t mean the results need to look like a chemistry experiment. Starting off with deeper testing on fewer users will almost always lead to better deliverables quicker and also more intuition about success criteria for the system at large. It will also help you avoid the slippery slope of going into ‘psuedo production’ and all the operational complexity that likely requires. Small scale testing with just a few users will generally give you a pretty free license change the system at will.

A good starter test is to have a single set of applicable users (one from each function) work a real business item through the system as they would IRL (in real life). The users should not be management (assuming management doesn’t normally do the tasks in question) but they should be top performers. These top-performing users are harder to get since they’re busy, but it’s important because at this point your job is to generate a single set of careful observations and to include as many ideas as you can from the company’s best current practices.

Have the users execute the process from start to finish with a real item (Lead, Opportunity, Call Log, etc). Keep it as realistic as possible. For instance, if it’s a salesperson working with a solution engineer (sales engineer, etc.), don’t have them sit next to each other and talk through the item if that’s not what they’d normally do. Have them go back and forth through the system.

(You might want to have them sit with you and walk through the process but that should have been in 02 Diagnose since at this point you’re validating a solution you’ve already formulated.)

You’re want to see if the solution is workable for a well-informed, thoughtful user, and, if so, how. If that fails, you’ll want to revise. The validation criteria will be that the users successfully create viable outputs from each of the processes, including any attributes you’ve identified as pivotal to the new solution. We’ll walk through an example below.

Following that, if you can manage it, go to pre-production with a larger user subset. In either case, you’ll want to set validation criteria around mainstream usability of the system. For example, such a criteria might be that 90% of the processes deliver outputs without escalation (needing support on use of the system).

Set the expectation that you’ll need time to audit the processes once the system goes to production- checking in on individual users and records to make sure there’s more or less concordance with the design and reality. This will help avoid the situation where the project moves too quickly, delivering more scope on top of solutions that aren’t actually working and need revision.

A final tip in this area: Create (with placeholders) the presentation you plan to deliver based on your validation testing, even if the presentation is a simple email. Testing delivers one of three results: validated, invalidated, or inconclusive. Envisioning your presentation will help you make sure you’ve put together everything you need to get an actionable result.

C. Propose Small Batches

Project plans create the perception of certainty and we all like certainty. And with the money, time, and people an IT project occupies, naturally we crave an airtight plan. Unfortunately, even the most thoughtful implementer is unlikely to predict the interaction of all these elements accurately enough to create a meaningful plan. IT projects notoriously miss their dates and budgets. Trying to create a plan ahead of substantial visibility and then conform to it drives destructive priorities, approaches and distracts from identification and delivery on important problem scenarios.

Why do we keep creating plans at a level of detail that exceeds our visibility? One classic reason for needing a plan is for accountability, which is legitimate. But for what decision, exactly? Billing? Advising changes in plan? Changing staffing? Canceling the project altogether?

For almost all of these, small batches (1-3 week iterations) against priority problem areas are a better solution. Each of these should have a prioritized set of objectives and deliver some working items- personas, problem scenarios, process designs, or working software. For those of you familiar with agile, this is probably old-hat.

For billing, this offers smaller finance commitments with more success milestones. pay-as-you-go. If management wants the prerogative to advise changes in the plan based on their observations of how things are going, management should make themselves available at the end of each iteration to review the output and provide advice. If management wants the prerogative to change staffing or cancel the project, smaller batches leave them a freer hand and more visibility with small batches.

D. Propose Accountable Reporting

Every successful engagement/project manager knows the importance of regular reporting. For managing clients and managing upward on use of the playbook, I recommend weekly emails drawing on agile’s ‘daily standup’ practice where for the project you answer these questions:

What did we accomplish this week?

What will we accomplish next week?

What obstacles are impeding our progress?

This last item is particularly important for managing clients or resources from other departments. For example, if you’re waiting for input from a key user that you’re not getting, it’s important to raise that early so everyone’s not trying to unravel a mess later.

Even if you’re compiling more elaborate reports and even if the project materials are online at an extranet, you may find this simple summary email to stakeholders delivers better results for you.


Based on her initial cues from VPS and subsequent investigation, SFG has client agreement on the following prioritized list of problem scenarios for short term execution:

1. Consistently Apply Qualification Criteria to Increase Close Rate

2. Supply High Quality Inputs Downstream to Solutions Teams

3. Standardize and Automate Proposal Generation

This is more than she’ll be able to execute in the next couple of iterations, but she wanted a longer list so that she can continue working on priority deliverables even if she gets held up.

She’s formulated a set of validation criteria for these, which she included in her pitch. SFG plans to operate in one week batches/iterations, including a short meeting each Friday with management and key stakeholders.


These are her validation criteria for the solution propositions she’s formulated:

Proposition Validation Tests
Implementing best practice lead qualification in Salesforce will drive more effective prospecting, selling, and proposal generation. PHASE 1
Preconditions: A complete but loosely instrumented lead qualification update to the curent implementation (first in ‘Sandbox’).1: Selected sales lead (Matilda H.) can readily input her last five lead qualifications into the new interface and progress them to a qualified opportunity, where applicable (including conversion to Account, Contact, Opportunity)
2: Independently, selected solution engineer lead (Sonja R.) can generate a proposal from one of the selected Opportunities.
3: Selected sales and solution engineer can successfully run a new Opportunity through the system, through to proposal.
Preconditions: A validated  lead qualification update to the curent implementation on production (validated per above; iterated as needed until success).Training and office hours for all current sales staff.1: 90% or better qualified Leads are successfully converted to Accounts or disqualified if not qualified in the salesperson’s opinion
2: 70% or better qualified Prospects go to proposal without any subsequent customer contact
[similar propositions for other problem scenarios if available] [similar validation criteria for other propositions if available]

The following is a an example of her weekly email for week 1:

What did we accomplish this week?
– Defined and prioritized first batch of problem scenarios (3)
– Working with sales and solution engineers, drafted preliminary process design for lead qualification
– Presented above to management; validated next week’s content
– Set up staging environment

What will we accomplish next week?
– Complete alpha version of lead qualification module
– Complete Phase 1 validation tests for above
– If validation successful, prepare move to production and sales training module
– If not, iterate

If more time is available:
– Review proposal generation practices, standards and customer interactions

What obstacles are impeding our progress?
– None at this time


If you want to… See
Lean Startup Tutorial: Lean Startup
Template: Creating an Assumptions Set
Workshop: Venture Design II ‘Iterating to Success’

04. Execute

Finger-Painting-Enterprise-SoftwareBecause Salesforce is so easy to do, often we do it too easily. Anyone can use finger paint, but that doesn’t make it any easier to create something really good.

So when I suggest that you invest the time to transition your problem scenario-value proposition pairs into explicit agile ‘user stories’ before you start modifying Salesforce, that’s why.

This level of definition is often skipped in facile environments like Salesforce- Why write a user story for something when anyone can just go in and modify a picklist or create a text field? The reason is that having an explicit, sharable, discussable, and above all testable view of what you want to accomplish is important. It’s not modifying the picklist that’s hard, it’s figuring out if that makes any sense at all.

User-StoriesIf you’re new to agile user stories, they have this specific syntax:
“As a [persona], I want to [do something]
so that I can [derive a benefit]”

Epic stories describe a more general action. Stories detail the epic and test cases are written against those stories for supplemental detail. We’ll go through an example below.

Here’s what I find whenever I sit down and pencil out a set of stories: What I’m planning to build isn’t as simple as I thought- at least not a nice implementation that I think the user will like.

Another advantage of this approach is that it’s systematic, repeatable and testable. Think about all the time you’ve spent in meetings on email discussing (arguing) about what should be done. Well, with some practice you can focus all this into something more constructive. Here’s a summary view of our approach so far:


And here it is in reverse:



SFG begins implementing the user stories against the process design she created in the last step:


As she gets to the story for step 02 ‘Qualify meter configuration’, some interest questions arise. What do they really want to know about the meters? Is there always one meter or are there multiple? Working with Matilda to structure her checklist on qualification even further, they come up with the following set of basic criteria:

– Number of meters
– For each meter: type, location utility vendor, and current reading
– Notes for anything else pertinent

From Sonja (the solution engineer)’s perspective , the most important thing is that she can assign the qualification back to the salesperson if the inputs aren’t complete or clear, and that she can clearly communicate what they still need back to the salesperson in that request.


Working through this, SFG arrives at the following epic story about qualifying meters (step 02):

Epic Story: “As a salesperson, I want to qualify the prospect’s meter configuration so I understand if I should progress with them and am able to supply inputs to solution engineering that can go straight to proposal.”

Story Test Cases
As a salesperson, I want to add a meter to the Lead qualification so I know whether to proceed and can supply inputs to solution engineering. Make sure it’s possible to add: the type of meter, its location in the building, the utility vendor and a current reading
Make sure its possible to add as many meters as they need
Make sure the number of meters auto-calculates and is visible on the record
Make sure the following instruction copy is readily available in this context:Please record all meters. For each meter, please note:- Type (water, gas, etc.)- Location in the building (floor, suite, location on floor)- Vendor- Current Reading- Notes on anything else you feel is pertinent.
This is the minimum required. If this information isn’t present, solution engineering may not be able to execute a proposal and the Lead or Account may be returned to you for more explanation.
As a solution engineer, I want to return a Lean or Account to the salesperson with notes on specifically what I still need that they didn’t record. Make sure it’s possible to indicate on which of the specific meters (one or more) they have questions.
Make sure it’s possible to return with a general note
Make sure the salesperson receives a clear notice about the return and it shows up in their task list
Make sure a reminder goes out to the salesperson after 4 days

She’s also writing stories for the other steps and including them in a shared document (not all stories for all steps in the processes included here)


If you want to… See
Agile and Agile User Stories Tutorial: Your Best Agile User Story
Template: Creating Agile User Stories
Workshop: Venture Design V ‘Building the Right Product’

05. Validate

The good news: if everything is essentially in order, this step is smooth and gratifying (even in the presence of necessary revisions).

The other news: if it’s not, this is where that becomes clear.

Validation will have one of three results: 1) validated 2) invalided or 3) inconclusive. #1 and #2 are part of the process. #3 means the process needs work. That’s fine and to be expected as you get comfortable with these tools. The main thing is to be honest with yourself about which of the three results you have.

Pizza-SizedIt’s also important to set realistic expectations. When’s the last time you heard someone raving about the software they use at work? Aspire to build something great- that’s the purpose of this playbook. Just don’t set yourself up for unrealistic expectations. Enterprise software is like the opposite of pizza- even when it’s really well done, it’s usually just tolerated (pizza is enjoyable even when it’s not that well done; thanks to David Rosenthal at Leonid Systems for this turn of phrase).

Part of this is due to the fact that many of the benefits of enterprise software result from improving interpersonal and interdepartmental collaboration. Take the example issue at hand: Even if there some benefit from helping them qualify leads, most of the salespeople will regard the new requirements on lead qualification as nuisances. The solution engineers will have an easier time (if the implementation validates) since they’ll get cleaner inputs that create less work on proposals. But most likely the system will clamp down on certain corners they used to cut or flexibility they enjoyed but on the whole generated less good outcomes downstream.

Emotionally, we measure our sense of accomplishment locally. Rationally, every salesperson knows that the company is better off if proposals are easier to generate and better aligned with the final operating deal. But what gives them a sense of reward? Nothing even comes close to the joy of closing a deal. This goes for everyone and not just salespeople. This is just human nature and I take account of it here to help you avoid validation measures that are unlikely to succeed.

Taking a poll of how much individuals like the new system is likely to deliver tepid results for the reasons above, even if the system as a whole is making the company much more effective. Looking at the performance of individual problem scenarios and their related processes will deliver results that are a more reliable indicator of whether you’re delivering value with the system.


SFG knows her client is typical in this regard and expects the consultant to just come in and update the system, and that they’ll always ask for more time and money. She’s sold them on the process (at least such things were said in their kickoff meeting) but she knows she’s not going to get a lot of slack.

The first set of small group (Matilda & Sonja) experiments go as expected- mostly OK but substantial issues were identified for revision after a few tries.


To at least make sure they understand how she’s spending her time and their money, she journals her validation testing and revision:

5/15/[yr] Test 003: Version 0.03; Lead Qualification

Test: Three previous Leads entered by Matilda to test for usability and completeness of the system with regard to best practices.

Results: Most inputs OK. Revision required around [x] because of [y].

She keeps this log on a Google Doc so anyone on the stakeholder team can have a look if they want.

06. Package

The perfect system doesn’t exist but an optimal process does- and it requires frequent observation and revision. As such, it’s valuable to package your validated implementations so that it’s easy to pick them up a few quarters or even a year or two. Think about what you’d want to know to do this- then think about what someone else would need to know. Don’t assume any of the current participants are going to be available. It’s dull work but a stitch in time here saves nine.

If you run short on time, something’s better than nothing. If you hate to deliver sketchy work, just frame them as ‘working notes’ you’re leaving behind in case anyone wants them.

Package your solutions so they’re accessible to the parties concerned for training and future review and revision.

Closing Ideas

A few final notes on using the playbook in the short, medium, and long term.

In the short term, you’re likely to get questions about why all this definition around personas, problems, and processes is necessary. After all, it’s not that hard- we just go into Setup in Salesforce and make changes, right? Given the failure rates of CRM implementations, it’s hard to argue in favor of business as usual. Using the playbook is not easier or faster, particularly in the short term. But it gives you a foundation that will create better deliverables, facilitate more constructive discussion, and support an implementation process that’s testable so you can iterate to a good outcome.

In the medium term, you’ll probably get push back on running validation. ‘Our people have too much to do for this kind of navel gazing.’ Everyone involved in the implementation feels better (because we’re wired to measure our efficiency locally and dislike uncertainty) just getting the new system online and crossing items off a list. But the figures show what happens when the team takes this path of least resistance.

In the longer term, the company will be more efficient, more effective and smarter/more adaptive, particularly if they make a habit of these processes. That said, it takes practice and diligence to get there.

Frankenstein: John Tenniel [CC0], via Wikimedia Commons

Rube Goldberg: By Rube Goldberg (an old comic book) [Public domain], via Wikimedia Commons

Pizza: By Jakob Dettner (de:User:Jdettner), Rainer Zenz (de:User:Rainer Zenz), SoothingR (en:User:SoothingR) (Own work) [CC-BY-SA-2.0-de (], via Wikimedia Commons