Do you have a CTO, CIO or developer persona profile that you can share?

I have a fairly extensive persona methodology which I wrote about here (https://www.workinproduct.com/blog/elements-of-a-positioning-system-part-2-customer-personas).

Rather than get prescriptive with an explicit example here, I’ll share something I run i nto a lot that I think gets it wrong – bucketing CTOs/CIOs into the same “Technology Executive” persona.

There may be some overlap, and it’s tempting to consolidate profiles, but in any modern organization, these jobs are vastly different, and should be treated as such.

Both are responsible for making company-wide technology decisions, but CIOs make internal IT decisions, and CTOs make external production decisions. Their teams cascade differently, too – an IT Admin has a much different job than an SRE.

The most important aspect of my persona methodology is really understanding what the person is on the hook for – both CIOs and CTOs have SLAs related to availability, resilience, and security (among other things) of infrastructure and software. CIOs have an SLA internally with the company, CTOs have an SLA externally with customers.

So I’d recommend going through a persona building exercise with that distinction in mind – the specifics will play themselves out accordingly.

Developer personas are diverse! You could rename them "technical practitioners" to better describe this group of humans. High level, in the business world, they are the folks who put fingers on the keyboards, not the folks who write checks. The operators. Because of this, there are personas that will work for some products, and not others.

Some of the ways developers can be grouped is by job title:

1. Software developer
2. Software engineer
3. Mobile developer
4. App developer
5. Web developer
6. Data scientist
7. Data engineer
8. Machine learnist
9. Network engineer
10. SRE
11. Security engineer
12. Cloud architect

The list goes on... and there is probably someone yelling at their computer screen that I missed an emerging role right now. ;)

Another way to group them is by the language community they belong to. I love the GitHub Octoverse Report for updates on these communities, and highly recommend it as a must-read.

Beyond these, it's also really useful to break developers down into two key categories: influencers, and delivery teams.

Influencer developers are those that work in the same teams that make product and business decisions. Marketing to influencer developers can lead to opening up deal flow, and will typically include innovators, early adopters, and early majority folks on the Innovation Adoption Lifecycle. They will tinker, hack and figure out how to use the new technologies and will often do the bleeding edge use case work with your product.

Delivery developers are those that do a lot of the outsourced work for companies. These developers are the unsung heros of making stuff work for so many enterprises. They will have less influence over technical tooling, but their ability to be successful with products makes or breaks successful business engagments. Certification programs and growing this ecosystem is really helpful in building trust and confidence in later adoption curve stage customers.

As you work on developing the personas for your product, I also recommend the materials as part of Clair Huntsaker's talk for Heavy Bit.