Don’t persona pigeon-hole users of your technology

Understand what they do and how to make their lives easier first

Here’s a brutally honest bit of truth-telling me what you are or what your role is doesn’t help me as a trusted digital transformation advisor to help you make your life easier and your business successful. Telling me what you do on a daily basis and how that contributes to your organization’s value? Now we’re getting somewhere!

Making your life easier translates into all the things we think of as business transformation – we transform because we want to be better. Also, I’m not particularly interested in what you’re responsible for in your organization as much I am about what actions you take to make sure that you get the business value out of technology and that things get done on time.

And yet… we still feel the need to somehow capture the definition of users of our technology platforms in a nice little cubby-hole. We put a name tag on that cubby and we describe the person inside with the behaviors and skills they possess and sometimes even the things for which they are responsible in an organization.

Are personas enough?

I get why we are so hung up on personas. It’s the same reason we are so hung up on user experience (UX) and user stories. Is persona definition enough to help organizations make a digital transformation a success?

For certain, it’s critical that we make sure we understand groups of target users of technology: from marketing to sales engagement and customer success right on through to product evolution and development. Tons of articles have been written on why personas are effective and great. Just as many have been published on why they fail and never get used after all the loving and empathetic work that has been poured into constructing them.

Recently, I was asked to write a white paper on personas development for API Management technology platform users. The first thing I wanted to do was understand what organizations are doing with persona development. My conclusion: a tremendous amount of work has been done in this area over the last year. Not only did I unearth a plethora of personas floating around out there but they were done by different types of teams with different
objectives.

In one case, nine personas were created by a team focusing on helping customers build API First as a practice.

In another organization, an R&D and Product team were managing no less than twenty personas within their product-management tooling. They seemed to be defined by a whole mishmash of things ranging from specific users of a component of their solution to those with more of financial responsibility in their customer base. One of them even was just labeled: “003695.” Hey man, I’m a name, not a number!

Finally, I unearthed a different set of personas created by a team that ensures the creation of valuable customer experience analytics and reporting back on that for coordinating cross-functional decisions around improving a Net Promoter Score (NPS). Release another 15 pigeons into the park.

So, I was able to dig around and find around 45 personas in a cursory online investigation. I am sure there are even more out there. Although I now have a greater understanding of the types of people targeted for API Management platforms, I don’t think I’m all that much closer in answering that really interesting question of how the technology is making people’s lives easier and what business value it yields.

Personas are not enough

All is not lost though. Combined with another construct, personas can do their job of helping us to be empathetic and understand the objectives, attitudes and behaviors of our users. This construct is known as Job To Be Done (JTBD) and was developed as a lean framework by Clayton Christensen at Harvard Business School. JTBD focuses on job statements and outcome expectations. The cool thing about JTBD is that the job statements you define when working with your users get to the heart of their needs and not their solutions. When you
understand how your technology matches needs, you understand how it can make their lives easier.

Personas can assist in qualifying job statements in many cases, especially when used in combination with the Job Story. A Job Story improves upon the classic User Story by extending and enhancing it with the construct of the Job Statement from JTBD. The Job Story approach was developed by great design companies like Intercom.

Here’s an example: a normal Job Story contains a Situation, a Motivation and an Expected Outcome and might
look like this:

When I start planning for a development sprint, I want to find existing APIs, so that I can avoid duplicating
effort and reduce my sprint time.

That’s pretty clear except I’m not really too sure who is supposed to be doing that. Is it one person that is going to get that job done? Who’s involved? Who gets the benefit of the expected outcome? Let’s modify it with some personas:

When API Product Managers start planning for a development sprint, they want to find existing APIs, so that
API Developers can avoid duplicating effort and help reduce the API Team’s sprint times.

Now I can clearly see who is doing what in this job scenario, who triggers the job, who does work and who benefits.

Have a fresh look

Try this new approach. Build up a searchable catalog of Job Stories so that different areas of your organization can work with their own definitions of personas, thereby liberating you from pigeon-holing those users and allowing you to focus directly on what your users really need.

Revisit your personas and check out JTBD and Job Stories to really make them useful. Armed with JTBD and some customer-focused personas, you too can finally let those pigeons free!