What are the type of Personas for Operations as a Product
The first approach I took was thinking about where the requests to operations come from for a very simple reasons. They want something, and you produce results for them. Site is down, then bring the site up. They want you to provision a new server, then you deliver a new server. Of course, we are creators and artists of various crafts, so we want them to be done in certain ways, as opposed to the requestors, or personas, who don’t really care HOW IT gets done. They just want IT to be DONE.
Let’s look at some examples:
Consumers (External Customers)
Consumers or Cusotomers are users of the product that operations team supports. It could be your news readers if you produce newspapers, it could be shoppers who are shopping on your commerce site, or it could be gamers on your gaming platform. Usually, but not all the times, consumers and operation engineers don’t have any direct personal relationships. When that’s required, most organizations develop some sort of customer support team to handle that. In other words, there is no face to face interaction between consumers and engineers.
Business or Corporate
I have seen both words used interchangably. These are people who generate work either to make more money or save more money.
Sales generate revenues and can generate last minute work to realize revenues or not to lose revenues. It can generate last minute unplanned work across teams/organizations - product, developers, operation engineers, releae engineers, QA and anyone involved to save the company’s revenue.
Marketing, on the other hand, are on the different end of spectrum. Its goal is to increase the number of consumers / users, or simply genearte some hypes about the product. To achieve that goal, Marketing often uses blogs, social media, newsletters and other means to spread the word, and they sometimes produce unplanned / uncoordinated campaign that affects engineering and operations, or employ third party contracts creating shadow IT products.
The last but not the least example is the top down orders coming from senior executives. For example, in one meeting CEO of the organization might ask for some simple report, and behind the scene, it can genearete lots of busy work for many different reasons. It could have been that the people who were in the meeting with the CEO are under pressure and they overreacted to the simple request and made it more complicated. It could also be that CEO was just not in good mood, and he or she dindn’t mean anything by it. Or CEO really had some critical piece of information he needed. Either way, executivess can generate lots of work with a very simple honest sentence because people like to reverse engineer human psychologies.
You can also imagine how finance, legal, audit, HR and other corporate functions could generate work either directly to Operations or via development or product.
A team that works with business and engineerineering to define and priortize work. In engineering centric organizations, Product works side by side with engineering and usually sits together (and often some sort of technical background). But I have seen plenty of organizations where it’s not structured that way. I’ve seen a plenty of ongoing debate whether enginerring should report to product, or product should belong to engineering in large companies. That means this is a real problem, despite what Agile manifesto might tell you what product managers mean. It’s likely each product has its own persona.
These are well documented team. I will just note that within engineering, some are more front-end based, some are more back-end oriented, some are always in hunt for most bleeding edge stuff, some are for super conservative, some have operatons background or have a very good understanding of infrastructure/unix/systems, some don’t. The point is you can’t have a single persona within engineering group. There are multiple personas within this group but possibly the personas are defined by scrum teams. Some people deeply care about infrastructure and scalability concerns, and some don’t. Saying “Dev-Ops” in this context doesn’t mean as “dev” has multiple personas (“ops” also has multiple personas but we are not talking about that yet).
Quality Assurance / Engineers
Depending on the organzations, QA might not be part of engineering/development. Some QAs can write code and crank out some cucumber code, and some people don’t know a thing abotu writing code.
With the rapid developent of technolgies, we have created a mess of data everywhere, not by design but just because we didn’t know. As we learn more about the mistakes we have been making, security becomes more important and produce important stream of work both for applications and operations. For ops, it ranges from user management, CA/Key/SSL/SSH management, volume encryption, patching, threat assessment, WAF, DDoS, log management, compliance, and the list goes on and on. There are multiple personas based on the problems at hand.
Other members within operations
Let’s not forget team members generate work too. Depending the organization structure,
Next, I want to talk about why defining personas might help raising the awareness of what operations do, and even further better plan and organize the work operations need to produce. I’ll focus on what does it mean to develop “Operation as a Product”.