Customer Types and Scenarios

Before starting a job in my new role as programming writer I met with few super smart people. I wanted to pick their brain and hear insights for success.

The key theme was along the line – “keep your customer in the center.”

Wisdom of obvious? Maybe. But the more I thought about this simple truth the more insightful it got.

To add clarity to the key theme I came up with the simple frame for how to think about the customers. It is customer types or personas and questions they might ask.

Customer Types – Personas

Back when I was an MCS (Microsoft Consulting Services) consultant I worked with several types of people. I recalled the following personas:

  • Business Stakeholder who buys software from Account Manager - must know the big picture.
  • Account Manager who sells software to Business Stakeholder - must know the big picture.
  • Architect who figures out feasibility of the solution - must know what's needed for the solution.
  • Dev lead who designs the solution - must know internals and how it works.
  • Developer who implements the solution - must have end-to-end how-to's, reference, and code samples handy.
  • Test Engineer  who tests the solution - must know how to automate test harness and monitor the test lab.
  • Operations Engineer who maintains the solution in production - must know how to monitor and troubleshoot the system in production.
  • End user uses the solution – it should be desirable, useful, and usable.

What Drives Customers

During my work in the field as consultant I observed time and again customers get frustrated by investing too much time to complete the task, losing money on labor or missing customers demand, and poor performing software. I also observed customers get frustrated by unusable software (one of the reasons they call consultants). So the main drivers for customers are:

  • Save time
  • Reduce cost
  • Improve quality
  • Enjoy experience

Development Lifecycle Phases

I found it helpful to look at the development lifecycle to better understand each persona customer type:

  • Inception - Account Manager, Business Stakeholder, Architect discuss the requirements. The outcomes are the problem and the vision statements. To test the outcome one can ask a simple question “What is it we really need?”
  • Planning - Architect and Dev Lead discuss and define the building blocks for success. The outcomes are the architecture blueprint and the project plan. To test the outcome one can ask a simple question “Does it fit our vision?”
  • Build  - Dev Lead and Developers work hard to realize the vision and stay on plan.
  • Stabilize - Test Engineer helps answering two questions – is it functional? Is it usable?
  • Maintenance - Operations Engineer works hard to keep up the SLA’s for End User.

Problem Scope

After reviewing the data points above I came to a conclusion that the problem scope can be summarized by three questions.

  • What' is it?
  • How does it fit?
  • How to make it work?

It is interesting that “How it works (internals)?” question is not explicitly there.

Applied Problem Solving Content

Here are few examples of how the three question approach can help building scenarios (key questions) driven content:

  • What is Windows Identity Foundation (WIF) and Azure AppFabric Access Control Service (ACS)?
  • How does Windows Identity Foundation (WIF) fit?
  • How to make it work?

More Info

Related Books

Comments (1)

  1. JD Meier says:

    Customer is a strategic question — it's who's in, and who's out.

    I find that the teams that hone in on a customer that they can serve extremely well, tend to do the best.

Skip to main content