# User Personas ###### tags: `DUX`, Omer Bensaadon <!-- :::warning This document has been deprecated in favor of lighter-weight personas, which can be found here: ::: --> # Background Over the course of the last few months, the DUX WG has conducted ~30 user interviews with a range of different users. I have taken learnings from these interviews and from months of thinking about Knative from the lense of a Product Manager operating within the community to create this document. ## *Why now?* 1. As Knative introduces more developer-focused functionality, like `func`, **it's important to define what user's needs we're addressing and why.** 1. As Knative matures and **seeks to onboard new vendors and integrators,** it's important to define a persona which represents them to ensure we'r considering them as we make decisions. 1. **Knative has outlasted some of its early competition** to be the standard Serverless layer on top of Kubernetes; to beat out the well-funded, well-connected recent entrants to the market **we need focus around who we are serving.** ## Outline For each persona listed, I will outline: 1. A lightweight description of the persona 2. What challenges these personas face 3. What solutions Knative offers for this persona's challenges 4. Why Knative may want to address these persona's needs --- ![Perry The Platform Administrator](https://i.imgur.com/AiNoBQK.png) ## Perry the Platform Administrator ### Background Perry is a Kubernetes "power user" more often than not and, though he'd rather not, he can repair your cluster in production. Perry is a platform administrator which serves [Deandra the Developer](https://hackmd.io/3dnh0OLBSpqxmZfwvhPPBA#Deandra-the-Developer) and developers like her. Perry is the guy you see on stage at KubeCon talking about how his team does infrastructure. Perry is an extremely important persona for us to capture. ### Challenges * **Perry wants to simplify his infrastructure stack.** * Moving workloads from outside of Kubernetes into Kubernetes where it makes sense. * Adopting products which integrate with his current toolset (CI/CD, etc). * Reduce time and risk associated with pushing to production. * **Perry speaks K8s fluently, but the developers he serves may not.** Perry wants to find ways to make K8s simpler for his developers so they don't have to call him or his teammates quite as often. (i.e. Perry cares about Deandra's User Experience) * **Perry wants to limit costs of operating his platform.** If there is a way to provide for his developers at a lower cost, he wants to take advantage of that. * **Perry cares about lock-in (sometimes)**. Perry has enough on his plate, but if he can figure a way to increase the portability of his platform that'd be great.. ### Solutions Offered by Knative * **Perry would love to move his FaaS workloads off of public cloud FaaS offerings** and into Kubernetes assuming they provide a similar UX for his developers. * **Perry would love to simplify his developers experience on Kubernetes,** providing them less options for Services would be a great start. * **Perry would love to have an elegant "scale-to-zero" solution for his platform.** Less utilization = less money * **Perry would love to take advantage of industry-standard patterns such as traffic-splitting** which can potentially save him from a costly production outage. ### Why should Knative address Perry's needs? In terms of where the product currently fits into the market, Perry is our core customer. In fact, where folks in the community consider Knative to be a product with end-users, I would argue that the Knative community we have been treating Perry as our *only* end-user. ==**It's most clear why addressing Perry's needs in particular would help Knative,**== more platform administrators adopting Knative means Knative coming closer to an "industry standard" Serverless layer, more platforms are incentivized to conform to our spec because their customers (Perry) are asking for it. ==**% of marketshare captured by platforms conforming to the Knative spec is the King of all metrics**== But the way we get there is far from straightforward. Creating a groundswell by getting people like Perry to adopt Knative is the key to Knative' success. <-- ### Where are we falling short? ==Conveying Developer Experience== You may noticed sprinkled throughout Perry's persona is "his developers." At the end of the day, Perry wants to make sure that whatever he introduces to his developers is a value-add for devs by offering new capabilities or reducing complexity. Due to this constraint, Perry often has his "Deandra the Developer" hat on and is trying to understand what the developer experience for a certain tool will look like. In short, **we aren't doing a great job of conveying the developer experience of Knative**. ==Marketing Simplicity== --> --- ![Deandra The Developer](https://i.imgur.com/dCIri47.png) ## Deandra the Developer ### Background - Deandra is a developer who has a passing familiarity with Kubernetes. - While Deandra may not have not have a cluster in her closet, the company she works for has clusters available for her to use. - Deandra probably won't be able to fix a production outage, she's got a platform team for that. ### Challenges - **Deandra doesn't care about infrastructure**, more often than not, she just wants to get her code deployed using the resources available to her. - ### Solutions Offered by Knative ### Why should Knative address Deandra's needs?