Kathy Korevec
Efficient Developer Discovery Lessons from Vercel and GitHub

Kathy Korevec is the VP Product at Vercel. Kathy has specialized in developer experience for over a decade at companies like Google, Heroku, and most recently GitHub, where she was part of the product leadership team for over four years. She has a passion for the power of open source, perfecting usability of developer tools, and making it possible for anyone, anywhere on the planet, to build and ship world-class software.

Collapse
00:00:00
00:00:00

Introduction

Developer Discovery

Hey everyone. My name's Kathy and I've been working with developers for about 15 years at places like Google, Microsoft, GitHub, and Heroku. And today I run the product team at Vercel, which is a company that makes building, deploying, and running super performant web applications really easy and pretty delightful.

I love working with developers and building developer tools because I like watching what people do and seeing how they express their creativity, and I love seeing their work bench. There's this aha moment when you're working with a new framework or you're deploying to a platform you haven't used before, when everything starts to click.

And it's in those moments that everything starts to work, that I've heard people call an expression of developer flow and all of this fascinates me. So I've dedicated my career to helping people get to their aha moments.

Building for Success and Sparking Curiosity

So while I was preparing for this talk, I took a product manager-first mindset. And for me, that starts with identifying the problem. There are a lot of different ways to write down a problem statement, and this is just one of them. My recommendation when writing problem statements is to make sure they're always rooted in user pain points.

With this one, I already had my challenge and I knew what I had to do. That's where I started with what I was trying to solve. I want to identify the user right away and the medium and think through how I'm translating my experience with developer tools to you.

Then I want to end on what the user can take away. And in this case, it's your own curiosity. The first thing you do after you've got the problem statement is take it to the team to work on a solution. So how am I going to solve for mine? I'm going to go work with the best development teams at some of the best developer tools companies for about 15 years.

Introduction to The Five Pillars

Just kidding. I'm going to talk about five areas or lessons that I've learned through those 15 years and give you a little bit of a proposed shortcut. We're going to talk about taking a customer-first path and what it means to really get to know your competition and use that, to continue to get inside your customer's head.

And we'll go a little bit deeper on what I mean by developer flow, and then talk through how to maintain your curiosity while not getting distracted by all of these shiny ideas around you. And finally, I'll end with a little bit of how to iterate in public. And I know that can be really scary, but

it's one of the best things you can do to move fast while also building trust.

Pillar One: Customer-First

I've heard a lot of people talk about taking a customer-first mindset, and I think it can mean a lot of different things depending on who you are and where you're working in the organization. And for me, it's really all about getting inside the customer's head and understanding the pain that they have with using your application. And then thinking through how to resolve that pain, but using a human-centered application development approach.

And when I approached talking with customers for the first time, especially when I'm not even really sure what kind of customer is going to be using my tool, I like to start with a drawing. And your drawing doesn't have to be sophisticated at all. In fact, it can literally just be pen and paper, it can be a screenshot, it can be a photo you took. And I have a reMarkable tablet, I like to sketch things and ideas there all the time. And that can be really quick for me to iterate on.

And then once I have something, once I have an idea, I like to mock it up in a wire frame, which is what you see on the screen right now. This was some early thinking that I did on the newsfeed that I wanted to add to the GitHub dashboard. And I wanted to test some ideas for really getting content that a developer was personally interested in. So this sketch starts with an onboarding experience, which allowed me to surface up information that could be qualified with user input.

And then what I did was I pinged some developer and designer friends of mine, and I asked them just for 20 minutes to talk about these sketches. So I set up 20 minute conversations with a few of them, and I walked through the sketches and I asked a couple questions and I took some notes about their first impressions.

You can see I'm using whimsical.com, which is a great tool for really quickly mocking something up, mocking up a wire frame, or annotating a screenshot. I sent them this URL and I said, "Hey, if you don't have 20 minutes to meet with me, totally cool. Just go to this URL when you have time and write down five bullet points for me, if you wouldn't mind." And that was a very low friction way for me to interface and get some really quick first feedback.

So then I could keep going. And the reason why that was so important to me is because I really wanted to do the least minimum amount of work that I could, while still getting a bunch of feedback from customers. And that kept me from going down one rabbit hole instead of kind of seeing the broader picture and kept me really thinking about my customer first.

Getting Into the Customer's Head

So if talking to customers feels kind of daunting, here are some great tips to just get you up and running. So I already talked about starting with a drawing and the more you do this, the more comfortable you'll get, especially with showing lower and lower fidelity drawings.

And then just set up 20 minutes. I talked about the 20 minute thing, it's the perfect amount of time to gather some quick insights. It's not daunting for the customer either, for the person on the other side to just do a quick 20 minute conversation. I actually leave a 20 minute research meeting up on my Calendly and I have my Calendly on my Twitter profile and my DMs are open.

And the reason why I do that is so that I can capture as many opportunities to talk to customers as possible. Now, these customer conversations, don't let one conversation or one data point fool you into thinking you fully understand your customers.

You have to continually be curious and continually be looking for that feedback.

And if you ever hit a roadblock or a stumbling point, or you're just at the end of your conversation, and you're only at 15 minutes instead of 20, ask the magic wand question, which is, "if you had a magic wand, how could you make your experience of this application better?"

And it may be about what you had just talked about, it may be something completely new to you and asking that question can open you up to a bunch of different ideas and pain points to go and solve for later on.

Pillar Two: Learn From your Competition

So a lot of folks ask me about competitors. And the questions usually center around how well do we know our competition? And I like to reframe this for myself and ask, "what am I going to learn from my competition?"

And that question, "how well do we know our competition?" I think it comes from a natural desire to beat the competition, which is totally great. We all need to get a leg up on our competitors. But at least for me,

it's really, really difficult to find a solution that's going to allow me to get that leg up, unless I bring it back to the user.

So that's why I'm constantly thinking about how can I learn.

Beating Your Competitors vs. Solving What They Can't

Instead, I ask myself, "what are developers missing from my competition's application?" And one thing that's really nice about developers is that they will tell you. It'll be on Reddit, blog posts, it'll be on Twitter, it'll be all over the place.

Developers love talking about tools and why they chose them over other tools, they love sharing information that might help others make decisions about what's in their tool chain.

This is a whole article about why this company uses GitLab instead of GitHub. And it's a great example of what developers might be missing from one platform over another. And this article is great, but you still have to kind of take that as one data point, one piece of feedback and synthesize it. And while I'm synthesizing, I like to build a quick competitor review of all of the problems that I'm trying to work through.

And I like to think through where my competition is excelling, or where they're failing. And I don't think there's any one clear win-them-all competitive analysis example. But I like to use this framework, which plots out my main goals or focus areas against my competition and the competition that I'm looking into.

Last year, I wanted to solve a bunch of developer pain associated with GitHub documentation. So I looked at some devtools, doc systems that I'd heard about that our customers really enjoyed. And I plotted that out against things that I find really valuable in documentation like legibility guides, navigation, searchability, and interactivity.

Now, I recommend as you're going and doing this, not to take more than hour to write down the entire system. So that's doing the research, looking through your competition, and that's also writing down your notes.

I actually limited this. I probably could have gone and done 10 different competitors, I limited this to what I thought was the top three, which were the ones that I heard about the most coming from my customers. And then I time boxed it to one hour.

The reason why I do that is because it's really easy to get distracted by what's going on with your competition. And I wanted to make sure that I could just get enough information that I could then go and use to be creative about solving some of these problems.

Pillar Three: Be Curious and Try Anything

And that brings me to "where to do I start, how do I get going? How do I maintain and be curious and kind of try anything out?"

Seeking Out Failure and Building According to Needs

And the first thing to remember with this is that you are not the user. I joke about this all the time with my team. We're all developers making developer tools for developers.

And so it can be really easy to say, "well, I'm a developer, I know what's best."

And I actually threaten to buy this T-shirt for my team all the time, and I remind them, "stay in the mindset of a scientist, keep being curious, keep trying to get inside the head of your customers." You don't want to get distracted by all of this, so while you're doing things like looking where you're scared or looking where you're told not to, you're still kind of seeking out that failure, you're operating like a scientist and you're documenting along the way.

I really encourage you to keep a diary, share your notes. But one of the most important things for maintaining focus is

don't build it until you really need it.

Backlogs and ice boxes are your friend here and keep them clearly articulated, Linkify them, make them available to the rest of the team. That is a really great whiteboarder space where you can put a lot of ideas and flush them out without letting those ideas distract what you're actually currently building and working on.

Pillar Four: Developer Flow

And speaking of focus, let's talk about developer flow. Developer flow is that magical moment where you're coding something and you sort of forget what you're doing entirely. And when I'm building developer tools, one of my primary goals is to always get developers back to the business of coding.

This is the 2021 CNCF Cloud Native landscape, and it is massive. I couldn't even fit it all in one slide. And you can see at the top here, it's kind of like the elephant banner to end all banners. It says, "overwhelmed? Please use the CNCF trailhead to navigate this whole entire landscape." It's so huge.

Enterprises use over a thousand developer applications in their tool chain and that means that engineering managers and developers are faced with these massive decisions about selecting their tools. This landscape's amazing, and there's so many wonderful tools to choose from. I can only imagine that a lot of folks feel overwhelmed and they're asking themselves, "what is good for me? What can I build? How do I contribute to this? What do I use for X, Y, and Z?"

Removing Friction and Inserting Dopamine

And that's why I always like to come back to this software development life cycle. And this is kind of where developers spend the most time. All day long, they're moving up and down the SDLC (Software Development Life Cycle) and going deep and going wide on it. And because of this and decision fatigue that comes from selecting tools, it's your responsibility as a team building developer tools to remove as much friction you can because developers are literally jumping walls as they move through the software development life cycle.

And you want to keep them flowing as naturally as possible so that you get them back to that moment of aha and back to the code.

And the easier that is for them to do with your application, the more they're going to recommend that to their friends, the more they're going to use it, the more they're going to want to plug that into their tool chain, because it is just easy to use because it fits into the SDLC, which is where they spend their time.

Pillar Five: Iterate in Public

And when you're ready, I highly recommend shipping early and then iterating in public. And this will increase your opportunity and your chance to get as much feedback as you can and continue to ground your decisions and your focus in what your customers are telling you and how they're using your application. And we often did this at GitHub. We're doing this at Vercel too.

At both companies, I led a team that worked on something called Papercuts, which translates to pain points with the application that when bundled together really add up to a lot of hurt on the system.

At GitHub, we asked for feedback directly on Twitter and in open public repositories. We got hundreds of feedback requests and people reaching out and talking to us about the application, about what they wanted to see, which led us down the exact right path that we needed in order to resolve some of the biggest pain points and remove friction that was getting in the way of getting the developers on GitHub to developer flow.

And at Vercel, we're doing this too. We are actually building a heuristic to help us triage Papercuts more effectively and quickly. We use this to maintain focus and not get distracted by things that may be a little bit too big for the Papercuts team, or might touch too many teams, or actually cause too much internal friction.

So we use this to kind of maintain that drip of what are all of these small pain points along the way, because those add up to bigger things, but we don't necessarily want to take on big ones because it might totally distract us, or we might spend weeks trying to solve it, where we're letting these smaller pain points kind of languish.

Conclusion and Final Thoughts

And that's it. I hope you learned a little bit about developer discovery, how I approach it and are excited to keep going throughout your week and learn as much as you can about building for developers. And if you'd like to chat, please do reach out. I love talking with anybody who is thinking about building developer tools. If you're interested in Vercel or GitHub or anything in my background, I love talking to developers and people in this space. Thank you so much.