Bitacora: personas

Introduction

1. The diary (aka bitácora): towards alignment in distributed environment.
2. Bitacora: environment definition.

The environment description is incomplete without the personas. I like this concept for many reasons but the main one is because I get extremely annoyed by the use of the word user.

When designing a product/service, it is hard to agree on what a user is, specially in engineering environments. In marketing/product environments, in general is in the DNA of those involved in product design to differentiate buyers from consumers (users). Market segmentation is understood by default. In my experience, this is not always the case in engineering environments.

I must admit that I do not use this concept every time since again, in my experience, engineers tend to show a high resistance to this concept, specially those who have direct contact to users, that is, those who work in open and collaborative environments. They tend to consider it mainly a simplification not of a representation.

Groups

We will assume there are 4 groups/roles involved in our scenario. Each group will be represented/formed by one or several personas. To label the groups, I will use names associated with roles you probably are familiar with, which is not a good practice since it limits their potential translation to a different scenarios. I do it so it becomes easier for you to identify them. The groups, based on its interaction with Bitacora are:

1. Product team: professionals included in the team that will develop the product.
2. Customer representative: professionals in charge of the requirements/backlog. Responsible for the product.
3. Senior manager: professional in charge of the above groups.
4. Supporting actors: people that interact with the team and are needed to develop/launch the product. They can be part of the company, the open source community that develops the technology the product is based upon or the sponsor.

If this blog series would try to reflect the Bitacora design process sequentially, the number of personas, even groups, should be lower, increasing them when necessary during the design or development process.

Product team

•  Junior developer (jdev)
• Senior Developer (sdev)
• Artist (art)
• Scrum master (smast)

Artist represent non-technical profiles technical teams might include like domain experts, communication experts, etc. At this stage, defining 4 personas is not the right thing to do. Two (scrum master and the rest) would have been enough. only when going into details, the four personas will make sense.

Customer representative

• Product owner (pdm)
• Sponsor (spon)

Senior manager

I have considered a single persona, the engineering Vice President, which is the most common non-executive senior manager (EVP).

Contributor

• Marketeer (mark)
• FLOSS community member (cmem)
• HR representative (hrep)

The Marketeer could also be any other professional within the company that interacts with the team. The FLOSS community member could also be an external consultant/domain expert contracted to help the team.

As in the previous cases, for most initial stages of the process we will follow, the first two personas could be considered as one. The third one has a very specific and limited role in this design, based on my experience, so it could be ignored or somehow included in the senior manager persona. I will refer to it in very few (but relevant) cases.

For a close follow up you might want to download the slides.

Conclusion

As you can see, I have considered 11 personas, which is a lot at this point. But I started with 5 which must be considered the main ones:

1. Engineer
2. Scrum master
3. Product owner
4. EVP
5. FLOSS community member.

So from now own I will refer to them by their names or roles. Based on your input and the process design development I might refine them.

Series of articles

1. The diary (aka bitácora): towards alignment in distributed environment.
2. Bitacora: environment definition.
3. Bitacora: personas
4. Bitacora: Impact mapping

The following one will describe the impact mapping. This section will be updated with the coming articles.

Agustin Benito Bethencourt (Toscalix)
@toscalix
Linkedin profile: http://linkedin.com/in/toscalix