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.