About MVP’s and their link with personas
Personas. Hated by some. Worshipped without criticism by others. Don’t make them to be more than they are. They are a technique to gather your team around the shared understanding of who your target group is, to bring empathy for your users’ problems, to facilitate storytelling once your project starts, and to help prioritize the backlog and product roadmap based on insights. This is especially true when you are greenfielding a new solution, but I remain convinced that this is even so for the complete reworking of an existing application. Even if a major redesign is at hand, a rebuilding of a piece of legacy software, you will want to have focus, so you’ll better decide on who you will be targetting first. I’ll focus on this aspect in this article.
Personas and focus
Your plan for the future does not come falling from the sky when you are transforming a business. It is rooted in what you are knowing and doing today. The task at hand may seem too large, too overwhelming and too complex, and you just don’t know where to start. Well, as always, you will need to chop up this immense task into smaller chunks. In order to be able to prioritize these chunks, you must obtain a razor-sharp focus.
Personas (buyer personas but especially user personas) can help to bring that focus. They don’t just bring focus to the team, but will also help to build empathy for your users. Personas build consensus and help you become more efficient as the conversation with your team will switch to clear mental models and observed use cases. Because of this you will be able to prioritize better. As always, when prioritizing, it is important to acknowledge that YOU are not the user, even if you have been one in the past. Times are changing, users adapt, new technologies emerge all the time, so it is only logical that our insights adapt with them.
Personas: techniques to build them
How do you build a set of personas? Well, it can be done in different ways. Even from ‘inside your building’, desk research. In Lean UX we call them proto-personas. These are the personas that are living inside the heads of the team. We all have mental models on who we are (probably) serving with our software solutions. What you will want to do, is come together as a team and talk to each other on who you are serving. During this workshop you’ll come to a consensus of who you are serving and what your main persona looks like. Is this “the truth”? No. But you will have achieved something. From now on, as a team, you will have a shared understanding of who your users are.
On top of this, since you are already serving them today, you will probably have access to tons of information on your user base inside your company. Service desk statistics, NPS-reports, sales-reports, mails from your users, market research, … they all will give a voice to your users, and you will be able to iterate on your personas for the first time after creating them with your team.
It does not stop there. You will still have a list of assumptions about your personas. So you’ll have to do some research, this time the “external” kind. The kind that gets you out of your building. A lot of techniques are available, here is a good framework to map them. Remember: it is far better to start with qualitative research, and get confirmation on detected patterns by doing quantitative checks.
After you have done this for the first time, you will have a set of personas. A main persona, and ‘the other personas’.
Personas need mapping
Based on the needs detected for all these different personas, you will probably see some overlap between the needs of the different personas. It is better to cluster them together. There are needs that will be common for all personas. Other needs are limited to one specific type of persona. Cluster the needs that are common for all in one group. Others are put in different groups. A persona need mapping looks like this:
In this visual you can see that the needs of the personas are clearly overlapping. In reality it is never that simple. Some might have a very specific need, not shared with others. This is (for me at least) a sign that it might be ‘out of scope’ of your project, that you will have to decide on wether it is useful to deal with that specific need in that project or not. If it is worth pursuing because of business reasons, you will want to check if it matches the product vision of if you’d better create an entirely new product (+vision) for that target group. Do not delude your product vision too easily, it will come haunt you later on. Trust me on this.
Personas need mapping will bring clarity to your team as well. They will understand in the blink of an eye why the priorities are laid out the way they are. And it is not just advantageous for the team. It is very powerful to communicate this with the rest of your organization. By detecting these patterns, you are able to build a logical product roadmap and plan the releases of the Minimal Viable/Marketable Products. First you build the release with the items that everyone is needing. And you push back on the rest.
An example to explain all of this…
An example to make this more tangible, lets take a customer database as an example. Imagine a very small business. That persona serves only one customer. He will need a form to put in the information of that one customer. He will not need the overview to browse over multiple customers. He only has one. Imagine on the other side the multinational who serves thousands of customers, on different continents, by different departments. This persona will need the form as well. There will be a need for more input fields. Also an overview of customers. And probably, this is an assumption, some additional layers of security on who can view what customer, with multiple roles for users of the system, and so on.
Based on this example, you could say that the customer information input form is something that all personas will want to use. Now you have two options. Either you build a customer overview including the extended user management and security, OR you build a simple customer form, and a very basis customer overview. The second option is better. You will be able to ship this release quicker to your market and you will be able to start collecting user feedback right away and iterate. In the meantime, and in parallel, you can explore the more complex needs regarding the security layer, and elaborate on this with more market knowledge. The first option will cost you more, it is by far more risky, and the end result will not necessarily be better than the second option. On the contrary.
An iterative product roadmap looks like this:
Iteratively you will build value for your users AND you will learn new things. You will have a better focus on what to do first, since your decisions will be based on research and things you have actually observed with your end-users.
On top of all this, there is also an important business argument: if you start charging your users for a MVP1(*), then you are already generating an income stream that can be used to build your MVP2. Holding on for too long before releasing has a lot of disadvantages: your threshold becomes higher, in the meantime your market is evolving, and you are burning money instead of generating money.
Conclusion
Personas build a shared understanding for your team, it brings clarity on the priorities of the backlog, and thus enables a clear focus on the things to be done. You can validate these personas iteratively throughout the development phase of your solution, actively reducing risks and gaining a better insight on who your users are and where your service can make a difference for the better in their lives.
(*) MVP = minimal viable product: the smallest peace of functionality/prototype or the smallest thing you can ‘build’ in order to validate specific hypothesis.
