Great Data Products Are Built for Personas, Not People
Why listening to those closest to you might not be the right choice.
In one of my first data science roles, I sat near the marketing and sales teams. There were two amazing people in those groups that I talked to every day. They were highly successful at the company, commanded the respect of those around them and were viewed as de facto leaders in the space. So when they asked me to build a dataset and corresponding dashboard for them, I didn’t think twice.
I wish I had. The dataset and the dashboard took me a solid month of extra work. I put all of my extra time and even worked over the nights and weekends to push it over the line. The day I showed it to them, they were elated! Then they both left the company in the next month. No one ever touched that dashboard again.
I was pretty upset. I actually got quite frustrated with sales and marketing. After all, I had built something outstanding, right? Nope. I built something for specific people, not the personas they represented. Here’s what I mean by this:
Personas are general representations of a user or customer. We build personas to represent different user types and characteristics of those users that use the product we build in a consistent or similar way. People are not personas. An individual person is full of nuances and unique background, intentions and training. We need to actively create personas, we do not just “find them”.
So what exactly did I do wrong? I did not stop to think about what general needs and desires the sales and marketing teams’ requests represented. I did not spend time thinking about whether they represented a general need for all of sales and marketing or if they were one off requests that served the needs of those particular people. But I didn’t know this. I just wanted to help. I wanted to add value.
This desire to help without thinking about personas is exactly where data products go off the rails.
The builders of the data products are well intentioned. They are trying to do their best. They are listening to customers. It just happens to be the customers they are listening to are the loudest in the room and often those they are most familiar or comfortable with in the organization. We need to work actively against this tendency.
Here are 5 things I suggest organizations consider to think about personas, not just people:
Spend time defining the key personas in your organization that use or are impacted by data products. It is much easier to define these personas upfront that do it in an intense moment of planning or prioritization where time and patience are often much lower in availability. If you have these personas and socialize them in your company, you’ll be much better off when it comes to hard decisions.
Centralize the decisions about what to build either in a product management, project management or some other variation of them. There will always be embedded data teams but that does not mean the decision about what they build needs to be embedded. The more eyes you have on a data product decision, the more likely it will be the questions about what general personas it addresses will arise.
Push actively against the “Person X wants us to build Product Y” mentality. Many organizations I have been a part of justify product decisions with a name of someone who wants it, rather than the personas that they product actually serves. Specific people and decision makers are temporary at companies, but personas are long lasting. Ask about the persona. This is where having the personas laid out already pays off.
It sounds simple to say focus on the persona. But power structures in an organization are a very real thing. It is hard for a data scientist or product manager to tell a VP that the product doesn’t clearly address a persona. This is where leadership matters a great deal. If you want to see change in this space, it cannot just be put on individual contributors. Leadership needs to sponsor these ideas and these processes.
Be patient. Changes like this take a lot of time in most organizations. The decision making processes that often rely on highest paid person in the room or biggest title in the room are fairly well ingrained in corporate culture. Even asking about personas might be strange at first. But we need to start somewhere. If we don’t ask the questions now, we have little chance of real progress later.
You might be reading this, thinking, “Where do I even begin?” Think about the person (or persons) you are closest to at your current role. Try to define the general personas they represent. Or in most cases, identify what information you’d need to know in order to better define those personas.
I wish I could go back and give myself this advice before I spent a month building what I thought was the next game-changing data product. Unfortunately, we still don’t have time travel. So this post will have to do.
Happy Friday! Thanks for reading, and please share with others if you enjoyed reading.
Great Data Products Are Built for Personas, Not People
I can relate very much to the above points. As part of Data Quality team, we tend to isolate the stakeholders and build data quality solutions for them. After reading your post, I do realise the pain points and understand enough to see that it will take time to remove those behavioral traits. Nonetheless, a very good and detailed information.
That’s a good point. In a similar vein, I would request the stakeholders to fill up a card or a few cards - “I’m a [role] and I [want to know …] so that I [can …]”. This is like the agile/scrum method.