When defining a product, itâ€™s easy to write down list of features and call it the product backlog. Itâ€™s much harder to build a product which so deeply and profoundly meets the needs of its users that they just have to buy it. An agile team can use a three workshop process to create the Scrum product backlog. Workshop 1: Identify the users. Workshop 2: Figure out what they want. Workshop 3: define the feature mix which will get you to a product that the customers want as quickly as possible. Letâ€™s start with Workshop 1, the Users.
A team of 3 or 4 people brainstorming can identify the potential users of a system very quickly and effectively. The ingredients:
Why should the whole team be present? Doesnâ€™t that cost of lot of money? You are creating information about the product. If the team is present, they will have that information first hand. Otherwise, they will get the information transmitted later. Knowledge is like eggs. It spoils quickly and can (will!) be damaged in transit. And refrigeration costs money too. So itâ€™s better to have them present, if possible.
Everybody takes 3 to 5 minutes and writes down â€œusersâ€ - 1 user per card. When the time is up, everyone sticks their cards on the flip chart.
Each person in the room describes â€œtheirâ€ users in one or two sentences: who they are and what each one does or wants. 3 minutes per person should be enough.
Depending on the product you may need to differentiate based on roles or demographics. Continuing the earlier example, Congo Lomarate (CL) wants to optimize its processes and value chain integration. In this case, it is probably sufficient to talk about roles within the various companies, e.g. CL-Operations Staff, CL Operations Staff, Supplier Sales Manager, Supplier Operations Staff, Customer Operations Manager, Customer Sales Staff, and so on.
For a consumer product, the roles may split along demographic lines. For a dating site, usersâ€™ needs might depend heavily on sex, age, nationality, country of residence, marital status, sexual orientation, dating preferences, etc.
Sometimes it is useful to consider â€œextremeâ€ cases: How would a spy find a date? Or a celebrity? What about a single who is HIV+ positive? Although the cases may be too narrow to target explicitly, they may bring out good ideas which are applicable beyond the immediate context.
Some cases will be so similar, that donâ€™t need to be considered separately. Group them together as one user.
Which of the users are going to generate or save money for the company? Which users can influence the success or failure of the product? These people may not need much functionality, but if you give them real exciter functions, they can have a deciding influence on the success of the product.
In the case of Congo Lomarate, operational staff at customers and suppliers will be the primary users. But their managers (and probably their executive management) will decide whether to deploy the system, so some good reporting features will help close the deal. The dating site will target people looking for a date, but other users, e.g. advertisers or marketing partners may play a critical role in the success of the system. They need functions, too.
Look at the whole. Are you happy with the users youâ€™ve identified? Have you missed anybody? If you havenâ€™t included them already, now is the time to add â€œadministrativeâ€ users: The system administrator, support, system developers, Googlebot (a proxy for search engine optimization), etc.
I recently had a project in which discussions about the role of the system administrator lead to a discussion of who will do routine user administration. We discovered that it was possible to make the system largely â€˜self-serviceâ€™, reducing the role of customer support and thereby saving costs.
Administrative users will not earn money directly, but how the system handles their needs can have a substantial impact on the success of the system.
Especially if demographics play a role in your user roles, it may be desirable to create â€œpersonaeâ€ for each of the roles you consider important. So for a dating site, you might have â€œJane, single, 25, attractive, wants to find a long term relationshipâ€ or â€œJohn, single 18, nerd, is afraid of girls but would like to find a geek chick to hack with.â€
Whatever. Find a photo or draw a cartoon, and put the portraits up on the wall so you can identify with them as people.
So in about 2 or 3 hours you have created a list of users for your system and identified their primary objectives. Any surprises? Do you have other strategies? What works for you?