It is now commonly accepted that user knowledge is the keystone of any successful product. It is an ingrained belief, a desire expressed at all levels of the organisation. Sales and marketing teams, product and development teams: all derive satisfaction from selling, promoting, designing and delivering features that will really serve a user.
- Knowing the user ensures that we develop solutions that respond to their problem .
- Understanding this issue, making sure of it, can only be beneficial for the design and selection of the features to be implemented. Isn't that right?
Unfortunately, the reality rarely reflects this pious will...
At the very beginning of a start-up's history, all the players share the same level of knowledge of the user and his problems. The players are few in number, share a lot and easily. The information is known by all and impacts on the decisions taken for the product.
But as the start-up grows, information becomes diluted, segmented and even compartmentalised .
Really? Why? Why?
Well, each team has to structure its daily activity to remain efficient and to cope with the increasing workload. All of them unilaterally define criteria for categorising users to carry out their tasks.
For example, the sales team breaks down the customer portfolio by sector of activity, and Customer Service divides the calls by tool. Marketing segments customers to better target e-mail campaigns, while the Product Manager establishes personas to write User Stories.
These segmentations serve everyone's interests. But then...
- Everyone has some information, but very often this information is not centralised .
- The user repositories useful to each team multiply and are not shared .
- They all end up working on part of the perimeter but not on the whole.
- All speak of the user as a whole entity, sometimes unique, whereas users can and should be broken down into different customer typologies, and therefore different needs.
In this case, why doesn't the organisation align itself with a customer typology?
When you work for your users on a daily basis, you feel that you know your users and what they need. Each team masters the user characteristics that concern them. It's a real feeling! But the mapping and knowledge of users is not shared.
Why spend precious hours when you already know everything? Taking the time to align all the teams on a project launched at full speed seems long, complex, inefficient. Each team has the information it needs, so Why participate in a joint effort that seems unnecessary and unpleasant at this stage?
But this flawed operation has a cost and the negative consequences are numerous... (for your product AND your teams)
- We lose sight of the user and his needs
- Development teams are demotivated and have no interest in producing value
- The developments carried out are not very relevant and do not correspond to expectations
- We lose the commitment around the features "It doesn't matter if the feature isn't delivered"
- To reach new customers who do not fit our current product we will force features and thus devalue the overall product
- Priority changes are frequent
- Prioritisation is difficult or inconsistent
- Demonstrations are of little or no interest to stakeholders because a false problemis being solved
- You create a product that speaks to everyone...but speaks to no one. No one is fully satisfied
- The commercial approach is not prioritised correctly and the clients on whom we concentrate our efforts are not those who really make us live
- Not everyone is interested in our features (although they are valuable!) so we may tend to underprice them because we lack confidence in their value and legitimacy.
If you believe that user knowledge is the key to your success then grouping your users around common characteristics across your organisation is essential. By defining and sharing this repository, you will be able to more easily identify the features that are of value to your users.
How can you easily and sustainably lay the foundations of your customer knowledge?
You've probably already heard of personas. Making personas means understanding in depth the users for whom we want to create solutions and thus prioritise them better. All teams will rely on these personas to carry out their activities, especially the development teams who will develop high-value functionalities specifically for each persona. But the teams can also use these personas to test the features directly and gather feedback, to confirm hypotheses or discover new markets.
Personas give context and meaning to every feature and action the organisation undertakes.
Personas are the result of a genuine exploratory approach that will allow us to deconstruct and understand the needs of users, their pain points, their way of feeling things and making their choices. This exploratory, sustainable and methodical approach is based on interviews, interviews that must be transcribed and analysed, questionnaires and sample studies. Carried out by experts : UX researchers, agencies and external service providers, it requires a significant commitment of time and resources .
Ouch, ouch, ouch. At this stage of the reading you are thinking that it is long and expensive.
This is the mistake most start-ups make! Considering that the process of defining personas is a long, costly, opaque process (in other words, a good old V-cycle...), whereas it is a process that can be iterative and start today .
This is the good news of the day! How do we do it?
Define proto-personas. (Of what?)
The difference between persona and proto persona is the difference between hypothesis and truth.
- The proto-personas are your organisation's collective intuitions about your users, in other words your starting assumptions, made in relation to your current customers.
- Hypotheses that will later be confirmed or refuted by your exploratory approach whendeveloping your personas.
- Bringing together all the departments and players in your organisation
- Identify broad assumptions and feed them with examples
- Avoid endlessdebates, we are not looking for an absolute truth
- This highlights what everyone shares (what must be true) and what they do not share (what seems to be in dispute), but also what questions remain unanswered. Spend some time on these points.
At this stage, types of users and customers should emerge: these are your proto-personas.
Note It is essential that this work is facilitated by an external facilitatoror at least someone who is not biased of the different teams that express themselves.
And this is where you can ask yourself high-value strategic questions.
- Do we manage to categorise our customers by proto-persona? Do we have to re-cut?
- Did our pre-existing breakdowns respect these personas or not at all?
- Which proto-persona is addressed most in our current user base?
- (the €10,000 question) Is it really this client that you are most interested in working with?
- (the €20,000 question) If so, is the value produced and delivered today by our organisation centred on this proto-persona or not?
You see what I mean...
Starting with proto-personas is easy, fast, and simply applies the principles of Lean Start-up to your target personas.
Do you want to be in a continuous improvement process in the functionalities and the value you bring to your customers? You need to take the same approach to knowing your customers and their needs (which are constantly evolving).
If you release a perfect product, it's because you released it too late...if you take 6 months to define and understand the perfect user and their need, it's because their needs have already evolved.
In our last webinar, we shared with you methods to define your proto-personas in 2 hours (or more!). We apply these methods with our clients in the framework of our Vision Sprint methodologyWe invite you to discover them 😉 .