The Kick Ass Curve for developer relations

So here's the goals, one, introduce Kathy Sierra. Two, introduce her Kick Ass Curve. Three, show how the curve is really useful to work that everybody in dev rel does. And then four, have fun. That's the main goal actually, really.

So, Kathy Sierra, some people know of you. Imagine you're in the early aughts of this century, right? And you're sitting there dealing with mostly enterprise people and all the documentation sucks and everything is really complicated and nobody's really connecting to you on a personal basis. And then along comes my Captain Marvel, right? For me, she was the hero that we all needed, that were doing dev rel.

So, this is Kathy. Kathy, this is one of our good quotes from her. "Upgrade your users, not your product." "Make people better at something they want to be better at." And she wrote the Head First series. Have any of you seen like the Head First Java or the Head…? Yeah, all those books. That was originated out of Kathy when she was working at Sun. She was one of the early people that was very user-focused and very developer focused.

And so, what I loved about her was that she really focused on being empathetic with your users and making them better at what they want to do, not thinking about what you want them to do. Does that make sense?

Okay. So, unfortunately, she is no longer on the intertubes. She was one of the very first examples of doxing and it was pretty bad. And so, she basically gave up on the intertubes for forever. She did go back, so here's some later reading. She's written some books, you can find some YouTube videos by her. Her headrush.typepad.com, that's all her original blog posts. And I think those are recommended reading for anybody in dev rel.

Okay. So, let's get on to the curve. Is that enough intro? Everybody good? Are you all convinced that Kathy is somebody you need to read? That was the main point of the whole talk actually.

Goal: make users happy and successful on our product/project

So, in framing the curve, I want to talk and remind us that the goal for us as developer relations people is to make users happy and successful on our project or product, and I'll use those interchangeably. I know we work on different things, but everything that we do should be focused on this goal.

When you're evaluating your strategy, when you're thinking about what you're doing, this is our primary goal. I would posit, right? And so, don't just do things for the sake of doing. Make sure that you're fitting it into the goal. And this is where Kathy's thing comes in and helps us.

The Kick Ass Curve

So, our axes are labeled on the kickass curve on our graph. I'm a good scientist. On the x-axis, we have time and that's from first time, like someone just starts using your product all the way up to years and decades. Because for some of our products, people will use them for years and decades. On the y-axis, we have ability, and this is the ability of the user to do what they want to do. So, in the beginning, there's struggling and frustration, and at the top, they're in a productive flow state. That make sense? Okay, we're good with that?

Okay. So, imagine two arbitrary lines imposed on this graph with ability. There's the suck threshold and then there's the kick ass threshold. So, in the kick ass threshold, once you cross that, you're in a flow state. Like, everything's good, you know exactly what you want to do. You sit down at your computer and you're ready to go.

At the suck threshold, you're sitting there and you're constantly frustrated, you have no idea what's going on, you're switching between documentation and you're cruising stack overflow all the time because you have no idea what's happening, copying and pasting madly hoping something works. Right?

So, it depends on where it is for your product and the person. Right? And then this is the curve, right? It's nothing complicated. It's a normal logistic curve that she shows.

And the idea is users, this curve, one quick point, you can view this curve in one of two ways. One, it is the trajectory of a user over time, right? So, they start here, down in the bottom and over time they work their way up like this.

The other thing is you could see this as an aggregate of all the user's trajectories over time as well. It's an average curve. Good? Thanks.

So, the idea is, user starts out sucking, they hate everything and everybody, then they cross the suck threshold, then they're in a space of good. And then after eventual time, they're awesome. And that's when they're kicking ass.

And so, what is our goal? Our goal is to make users successful and happy. So, our goal is to get users from here to here in the least amount of effort and time possible. Because the more time they spend here, the more time they have chances of quitting your product and hating you. Right? And even here, if they are even here and something else comes along and they can get here or here faster, they're going to leave you.

And so, that's the main point that Kathy is trying to make with the Kick Ass Curve is get users up here as fast as you can.

Different trajectories

So, if we talk about this, I showed you the typical curve, this would be an ideal curve. Not even curvy, right? For a person putting in a unit of time, they get a linear feedback about getting better. Nice and quick, I spent a day working, I feel more professional, I feel better. I can do better things.

This is a bad curve. And I put that up because a lot of people think, "Oh, everybody will eventually get here." No, there are some products where people will never get there. Right?

And so, if you take these three curves, I can summarize those in different kinds of user experiences at the end, I had to put emojis in because that's the new kitten GIFs, right? We all needed a cat. Now we all need emojis.

So, you have users loving you, in the ideal curve, that would get you a lot of love in your product. Typical, "Okay, you're like every other product out there, but I don't hate you." And if you end them up in this space, I'm not going to say… I said it in DevRelCon in London. I'm not going to use the F-bomb in this talk here.

So, we're good on those ideas? Any questions? Good. I'm perfect in all my descriptions.

So, why the differences in the curve? You say, "Oh, well it's obvious, it's all up to me." No, life is not under your control. You can only control yourself. There's a lot of things that are outside of your control.

Background knowledge and experience of users

So, there's certain things your team can do, but also the background, knowledge, and experience of the user can put them on a different trajectory, right? If you're an advanced product, like let's pretend you have a network product and I hate networking and you have a networking product, I'm never probably going to ever get off that bad curve on your product, no matter how good your documentation is, just because I hate it and I have no background knowledge and that's not up to you, right? So don't blame yourself on that one.

Quality of documentation and teaching material

The quality of your documentation and teaching material, this is up to us, right? We do control this and this can definitely help the trajectory. Most developers are, in the words of, I forget who it was at Twilio way back when, most developers are doers, right? And so, the more ability you give them to do on their own, the faster they'll get up on that curve. And that comes through documentation and teaching material.

Product and API design

The actual design of the product and the API. So, I saw a great quote about this once, and I wish I remember who said it, but they said, "The only reason we have dev rel is because of poorly designed products," right? If products were designed really well, you wouldn't really actually need developer relations because people would love it on their own.

So, I can't emphasize this enough. People talk about how we are just talking heads and stuff. This is also critical for us. Our job is to give feedback into engineering about what makes a product good and not good, and easy to use and not easy to use. We are one of the ergonomic experts for the product, right? So remember that as well.

Size and helpfulness of community

And then the size and helpfulness of your community. And I'm sure you've all experienced this, right, where you're stuck, you're a doer, you want to do something right now, you have no answer in the documentation, you go do a Google search or you get on a Slack channel and no one answers. And that's going to keep you in that suck zone longer, right?

So, these are just some of the things I could think of in coming up with this. All right, let's move on.

Why we often disagree with PMs and Engineers

So, why we often disagree with product managers and engineers. Is this a common theme among most of you dev rel people that you find yourself disagreeing with PMs and engineers? Round of applause if you do. Yeah. Okay.

So, I think the Kick Ass Curve gives us some insight into this. This is one of the beauties of giving a talk, as you probably all know, is it helps you refine your thinking and brings you into new areas.

Where we spend our time

So, this is where we spend most of our time with users, right? Right. We're teaching users how to get started with the product, maybe getting them up of a curve a bit. We try to get them from here at least to here as soon as possible. Maybe we do a little bit of work up here, but most of our work is down here.

So, this is where most PMs live, because most of them are out talking to customers or out talking to teams that have already implemented stuff and teams that have already implemented stuff with our products or projects already know a lot about our products. So, they're interacting with users who are actually quite advanced compared to the users that we interact with.

So, when we tell them there's a bunch of problems with people getting started, they're like, "I saw no problems at that company," right? "Everybody was already up here, so I don't know what you're talking about."

And then this is where engineers are. So, sometimes engineers are our friend, and it's usually when you ask them to use a part of the product that they've never worked on or when they're new to the team because then they have no idea what's going on.

But, for the other part of the time when they're actually working on the part that they know, they're up here. Right? So, are they thinking about adding features here? Is their brain in this space most of the time? No. Their brain is up here, thinking about, "Oh, it would be super awesome if we could take this widget and make it do x, y, and z, and this really advanced thing."

And one of our challenges is, and it's a big challenge and I bring this up a lot and it's always a struggle with PM engineers is, that's great that we are awesome up here. That's fabulous. I love that. But if I can't get them through this valley of despair, I'm never going to get them up to your peak of awesomeness.

Like, if I can never get them to the kick ass part or even above this suck threshold and in a timely fashion, you're never going to get to see these pieces you're all excited about. So, I think that's a really important argument to make with them. And this can help us illustrate why maybe we're seeing different things.

Assumed greenfield for product adoption

All right. So, for the home stretch, that's all assumed all her curves, and this is an extension on her work that she did with her curves, and my extensions on this came up because I was working with a team that was working in a marketplace that already had a bunch of products in it.

Like, all of her curves assume either the product is, you're releasing a new product and so they have to upgrade and that's a new upgrade curve they have to go through. Or it's greenfield, right? Like, "Oh, I'm not already an expert in something else. I'm learning your thing and it's going to be all new to me," which is very rarely the case for most of us.

Competing products and a surplus of woe

So, again, our user is somewhere up in here. Let's assume they just got up to here on the competing product, right? So, my company does Postgres, we're a Postgres consulting house all that stuff. The users here are on MySQL or Oracle, right? And then we go to them and we say, "Oh, you should really use Postgres." So what I'm actually asking them to do, and this one of the reasons, one of the many, many reasons that devs are so resistant to listening to us is I just asked them to do that.

I've asked them to go from "I'm kick ass" and "I'm in a flow state every single day" to "I suck and I hate my job," right? And so, what we have done is created a surplus of woe, right? And so, when you create that surplus of woe, this is all resistance about why people are not going to want to adopt your product.

How many of you remember back in the days when Firefox used to import your IE bookmarks? Do you remember that? That was one of the most brilliant moves ever. Why? Because if you used IE, you're up here, you had all your history in it, rather than Firefox saying, "No, that's their bookmarks and these are my bookmarks and I'm not going to let users transfer them easy," they said, "I'm not going to fight the wave. I'm actually going to help avoid some of this surplus of woe by allowing people to transfer stuff over."

Pick your battles

So, pick your battles wisely when you induce this surplus of woe. Sometimes it is easier to just say, "We'll make ourselves API compatible or build this tool just to help Java developers adopt this new thing." Right? Because, and it might just be in your dev rel group, right? It doesn't have to come out of engineering. It can be one of those unsupported things.

How many think developers always care about supported things to get their job done? If that was true, there would never be any open source stuff to start with. Right? Because that's how most open source things start.

So, our job in dev rel and engineering and PMs and everything though is to decrease this surplus of woe. And every time you decide you're special and you need to do something different, you've thereby increased your surplus of woe. I just want to say "surplus of woe" one more last time because it really feels fun. Yeah. Although bad for the user.

Target material to who you're trying to reach

So, that's it. I'm going to wrap it up now. So one, think about who your audiences is, who you are targeting and how to get past in the suck zone ASAP. So, I bring this up, there's a talk later, I think it's maybe right after mine or two after mine, where she's going to talk about segmenting your users. This is really important because that's actually part of the reason some curves suck for some people is if you don't target your material appropriately to who you're trying to reach.

Because if you target your material towards JavaScript developers, but most of your users are Node deve.. Node - then you're right on. But if you target Java developers or your target audience is really Python or Java developers, that documentation isn't really going to help them very much. Right?

And Enterprise users, if you're going after Enterprise users, are you going to write in Rust? Are you going to give examples in Rust? No. Although it's a cool language and there's good things happening there, you are going to probably write your examples in .NET or Java, maybe some Python if it's data science, maybe some JavaScript if they're kind of an advanced looking company. Right? So, target and make sure your curve is maximized for the groups you're trying to hit.

Get people out of the suck zone

If we can get people out of this suck zone before they give up, if we can't get them out of the suck zone before they get out of the suck zone, they will give up and they'll never get to experience the power.

And I've already said this one before, remember when talking and that's lots of ways to talk, to others, think about where they are on the curve. And this is important for like workshops or when you're in the booth or something like that, right? Or when you're putting together emails. I keep saying dev advocate examples because that's where I live, but this applies to all dev rel. So, it could be when you're putting together a newsletter, it could be any of those things.

Think about where your users are, and this gets back to the metrics we heard about this morning about, so like an example at one company is when I was on the open shift team, we did a whole bunch of surveys around where users were and found out most of them were in less than two years' worth of programming, right? So we then started producing documentation that was really simple and introduced some very basic concepts because that would be helpful to our users and make them feel kick ass.

Use it when it helps

And then, I can't emphasize this one. This is actually another take-home message. This curve is nothing but a tool. Use it when it helps. Don't use it when it doesn't help. I'm a big fan of don't "all the things," all right? So, don't say, "Oh, well, you've got to go to Kathy Sierra's curve," or "What does Kathy say about this?" Use it when it helps, don't when it doesn't help. Okay?

I know it's pretty obvious, but I think we often get caught up in, "I saw that documentation is that we have to do it this way." It's just a model of how the world works. That model may not work for what you're trying to do.

Okay? And so, that's the link now if you want the deck. I give that as a hint to everybody, always put your slide link at the back end because that's when people know whether it's worth it to waste the bits on your talk or not. That's where you can find me, again, GitHub, Twitter, all those places, and that's who pays my mortgage.

All right.