Product velocity is as much emotional as tactical

Here’s a word we didn’t expect to hear in a conversation about product velocity: “voodoo.” Although velocity can be considered a hard measure of time, the factors that impact velocity are a lot more mercurial. And during our chat with Yammer product manager Anna Marie Clifton, she made it clear that product delivery is not just a function of a well-oiled dev team. “It’s easy to consider velocity a thing that your engineers do or don’t do,” she says, “but it’s a much, much, much bigger problem than that.”

It’s been more than a year since Anna Marie joined Yammer, where she currently leads the growth initiative. She also hosts a podcast, Clearly Product, with Quibb founder Sandi MacPherson, and shares a mix of personal insights and meaty product reads on her Medium account.

We recently chatted with Anna Marie about her goals for the coming year, and her answer was all about building a sense of psychological safety with her team. Her approach to velocity is an extension of that people-first thinking: achieving and maintaining velocity is as much an emotional question as a tactical question. How you talk to colleagues, how you approach uncertainty, the energy you bring to the project — all of these factors can unlock or impede velocity as much as your on-paper processes.

First of all, give us some context. What does velocity mean to you?

I think about velocity in terms of: how long does it take from deciding that something is possible to getting it in front of customers? What is that total time?

There’s the velocity of idea iteration on that early side. How quickly do you validate or invalidate ideas with your research team? Or with your data analytics team, before you even bring an idea into the design phase? And then how quickly do you work with the designer to drive towards the goal and get to a point where you’re comfortable presenting your designs for review with the head of product?

“The reason velocity is so important is because it’s literally survival for your company.”

And then how quickly do you get your engineering team up to speed on what it is you’re trying to accomplish and why. How bought-in are they to those goals? Because that can derail your velocity later on.

And then there’s always the question of, what happens during project execution? What does it take to get that final mile out to customers? Are you doing messaging? Is there any change management? Did you think about that enough in advance? So really when I think about velocity I’m thinking about laying down the tracks in front of your team, and making sure you’ve thought of and uncovered a bunch of things before your team hits them.

Jussst in case it’s not obvious: why is velocity so important to a product org?

It’s one of those heartbeats of the company. The question of how much you’re going to get in front of customers. How viable you’re going to be, how quickly you’re going to be able to respond to market trends. And you only have so many resources. Every single organization in the world feels like they’re understaffed and they don’t have enough resources to approach the problems they want to approach.

The reason velocity is so important is because it’s literally survival for your company. Velocity and direction are the two things that control whether or not you’ll be around in a few years. First of all, there’s the entire product direction: where are you going, your thesis, why is this the angle that you’re betting on? The combination of those two will determine if you survive. It determines if your competitor is going to outpace you or go in a better direction than you and acquire all the customers.

Can you tell me about a time you really struggled with velocity on a project? What happened?

Really early on when I first joined Yammer, I was working on a project that was, engineering-wise, not that expensive. It was a pretty small UI change. We were trying to promote a different type of behaviour and a different flow in the product. But the visual design of it was a really big piece. And I didn’t have a lot of clarity with my designers around what the goal was. And because of that, we floundered for a little while trying to land on a design that everyone was happy with.

We came to a head at one point, where I was like, “Okay, people are frustrated, I’m frustrated, designers are frustrated.” We peeled it back and uncovered that the reason why everything was stuck was that we had two competing goals that were kind of antithetical. And the designers didn’t know how to prioritize between those goals. We wanted users to both feel a sense of completion and we wanted to give them the next thing to do. And those are antithetical goals.

It’s really easy to look back and talk about that, but at the time I had no idea what was going on. I had no idea that the goals were unclear. I didn’t even really internalize that the goals were antithetical. It took a serious moment of, “Oh fuck, this is about to go real south.” And then we sat down and talked about: what’s going on? And through those conversations, figured out that goals weren’t being clearly established, prioritized and communicated.

It sounds like it can be really hard to see the things that could impede velocity when you’re in the moment. Is this a skill — or “spidey sense” — you’re constantly working on?

It’s something that I’m learning about every single week. I’m in probably 8 different projects right now in various stages, and so every single week each of those projects is in a different stage. I can lean into what I’ve learned from one early stage project as I start the next one. I don’t think you ever resolve or finish or uncover or unlock velocity. I think one of those things you have to constantly work towards.

“I don’t think you ever resolve or finish or uncover or unlock velocity.”

I just made an ongoing list in my brain of things that have gone wrong before. And so as you encounter those problems, you add them to your shitlist. And then you can also have an institutional list that other people have reference points for. “Hey, remember how this goes wrong?” One of the things I’ve done is try to bring in touchpoints into our process that remind us to think about the things that have gone wrong with other projects. Because that can save you a lot of time in the long run if you uncover it early.

You’ve worked at high-growth companies like Yammer and Asana. How have they paved the way for a healthy amount of product velocity?

At Yammer a major motivation that we tap into is motivation from autonomy. We have a really strong mode of working where we expect that whoever is closest to the problem should be the one to call what the answer is going to be. I’d had this problem where I had a project team where we wanted to do something, and I had a product manager say, “I don’t think that’s a good idea.” I was like, “Look, I’ve looked into this, I’ve done a lot of work on the ground floor, and I think it’s a good idea, and we’re going to do it.” And he was like, “Okay, cool. I don’t think it’s a good idea, but you’re closer to the problem, so go ahead.” So making sure people who are closest to the problem are the ones who make the calls about what to do.

One of the things that Asana leans into to promote velocity is that they have a lot of transparency about who’s doing what and when. And that’s by nature, since their product is a tool to figure out who’s doing what. The product you’re building internally is going to have a lot to do with how you operate. Especially when you’re building a workplace collaboration tool. Asana was also very much aligned with the expectation that whoever is closest to the problem should solve it. And they have a lot of explicit transparency into who is supposed to be solving what problems, because every problem is listed in Asana and every Asana task has an assignee. That’s how their product works, and so that’s the way the organization works.

We’ve talked about the importance of direction and clarity for velocity. What are some less common pain points you’ve experienced when trying to increase or maintain velocity?

Here’s one that’s not very obvious. We have a localized product, which means we have 37 different languages that our product can be used in, and the UI is translated. That means that whenever we add a new piece of UI that has a copy addition, we need to get that localized into 37 different languages.

These are problems that you face at scale; this is not a problem that startups have. But in order to get something shipped, if we want a last-minute copy change, we have to go through our translation service. One of the things you can do as a PM is have your copy really thoroughly vetted, and make sure you get all the right eyes on it and no one’s going to say, “I didn’t see this. I think it needs a few tweaks.” Because a little change like that can mean a couple weeks of delay.

One of the jobs of the PM is to consider all these different inputs and make sure that you, as you kick off the project, are thinking about what other teams need to get involved. Our engineers run the project management of the actual engineering themselves, but there are a lot of other inputs in user research and analytics and copy design and translation. We could bring in someone to do an accessibility audit too late, and then find there’s a whole bunch of voiceover missing or some elements of the UI aren’t accessible. It’s important to get the right people to consider your feature earlier on in the process. Because if you have to go back and redesign something because someone who only uses a keyboard can’t use it, that’s going to put a huge, huge slowdown on the project.

With so many inputs and stakeholders to consider, how can interpersonal issues affect velocity?

As we discussed, one of the things that’s been an issue on some of my teams is ambiguity about what to do. If no one knows what you should do about a problem, the whole team will just kind of halt. That’s one of the big roles of a PM: making sure to shelter your team from ambiguity.

Sometimes issues comes up where I’m like, “Huh, I have no idea what we should do about that.” If it’s not obvious, I’ll be very explicit about the fact that we’ll handle this at a future point. Then I make a point of figuring out when it’s going to become a blocking issue, versus how many things we’re working on that we would do the same, no matter what we do about this issue. Then I’m like, “Okay, up until next Friday, we can continue working on the project as we were working on it, because everything we’re doing right now does not impact this issue, and no matter how we deal with it, we’d still have to do this other work anyway. So carry on, don’t worry about this one right now. But I’ll be bringing this up in a product team meeting, or I’ll get user research involved, or maybe I’ll dig into analytics and figure out what the answer is or what the answer should be.” And then come back to the team with, “Hey, here’s what we should do.”

I think it’s a big, big problem if you, as a PM, sit in a meeting and are like, “Yeah, I don’t know what we should do.” I’ve done that before, and I’ve seen my team totally lose all their mojo.

So is a big part of velocity giving people a sense of comfort that they’re not going to be wasting time, or making people feel a sense of security?

Here’s the thing. A lot of the stuff that we do in software development is really uncertain. And that’s kind of nerve-wracking. Like, I don’t know if this feature is going to be well-received. That’s one level of uncertainty. I don’t know if this feature is going to accomplish what we want to accomplish. I don’t know if the way I’m building this feature is the best way. I don’t know if this is actually going to work in this way.

There are so many different things that people on your team don’t know, and it can be debilitating. So whenever something looms up, and it looks like it’s going to threaten my team’s ability to have confidence in what they’re doing, I try and absorb as much of that and deal with that on the PM side.

It comes back to what we said earlier about how it’s so imperative for the PM to align the whole team around the goals. Because those goals will be a guiding light in those times. And there really aren’t right answers; that’s the uncomfortable truth about product management. There are “best guesses” and “probably rights” and “mostly rights,” but there’s not “definitely rights.” And that’s something that is very, very emotionally difficult for a lot of people. I think that’s one of the challenges that you sign up for as a PM, is dealing with that existential angst. One of your jobs is to absorb it away from the team, so they feel confident in moving forward.

It seems like velocity is as much an emotional question as a tactical question. What “soft skills” are important to velocity?

Energy and optimism. That’s so imperative to have on the team, and it doesn’t necessarily have to come from the PM. But the more optimism and energy you have inherent in the humans you’re working with, the more oomph there is to take to a challenge. It’s also really nice to balance the team with a few pessimists so you find those problems.

“That’s one of the big roles of a PM: making sure to shelter your team from ambiguity.”

But a single optimist on the team can bring that energy for everyone. I think there’s a lot of voodoo around that. And that’s something that I’m still spending a lot of time focusing on and trying to understand and lean into a bit more. One of my personal strengths is having a whole bunch of energy. There are always tradeoffs. But it’s a strength that I’m trying to find the best sides of and bring them to my team.

What are the emotional consequences if velocity just isn’t there?

There’s the compounding issue where it can give you a moral feeling of delay. And that’s really sticky, because you’re not working with contractors, you’re not working with a one-time crew, you’re working with people you’re going to keep working with. And it’s really important to keep thinking about, whatever you do with this project, if it feels like it slowed down a lot at the end, then they’re going to feel that way about you and about your projects and working with you moving forward. You have to manage the feelings as much as anything else.

Let’s get tactical. What are the concrete ways you try to enhance velocity?

We’ve already talked about uncovering problems in advance. There’s a system that I like to use here. We have a meeting that we run with our engineers shortly after we kick off work on a project called the edge case bash. And we sit the whole team in a room and have a list of edge cases that have been problems in the past. And then we go over all of the edge cases and we think about, “Okay, how could this edge case affect this product?”

I’ll give you an example. We start with the empty case. And we think about, “What are all the different ways that, if there’s no data here, this could impact this feature?” What happens if someone doesn’t have an image? Or what if they don’t have their name; they just have their email address? Or what if there’s no content in this group yet? Or what if this is a brand new network and they don’t have any groups?

We have a list of about 25 types of edge cases that we go through as a team. And we think about, “How could this be a problem in our project?” And we usually end up with 30 or 40 different edge cases that we come up with in that one hour meeting. And then the PM will go back and consider, okay, how likely are these edge cases to happen, and how bad are they if they do?

You’ll always, always be finding more issues as you go. But this is a super-charged way to uncover as many ugly issues as you can at the beginning.

What other essential boxes do you check to maintain velocity?

One of the things a PM can do early on is bring in people from other product domains and bring in issues that might surface.

“You have to manage the feelings as much as anything else.”

We have someone who is an accessibility guru and champion internally. I always schedule a meeting with that person really early in the ideation phase to just go over what I’m planning to build and see if there’s anything we should consider. Because what happens at the end of the project is if you didn’t do an accessibility audit early on, someone will come by and be like, “Hey, these are accessibility issues.” And you’ll have to address them and you’ll think you’re about to launch and then you end up delaying a couple weeks because you have to go back and rethink something.

One of the other things I try to do really studiously is that whenever anything changes during the execution phase, I make the point of surfacing that information as quickly as possible up the chain in product, in case there’s some chance that there’s something I don’t know about, or product may have a competing reason why we shouldn’t do that. So just in case something is going to be a problem, they can surface it early.

You mentioned the “final mile” in getting a feature to market. What are some of the challenges around velocity in that final mile, and how do you alleviate them?

So much of what we’ve been talking about has been: how do you anticipate problems, and then get them in front of the right people in time so it’s not going to end up delaying your engineers? Your engineers are on one track of work, but there’s a whole bunch of other stuff that happens on other tracks. And the point is, kick those off as early as you can. So that by the time that train comes to the end of the station from an engineering perspective, you don’t have other trains that are still pushing along from accessibility or copy or marketing getting the right messaging out, or things like that.

So the tactical solution there is just, constantly be messaging with your partners in other teams, or partner teams, around what you’re working on or what your timelines are. And make sure you’ve gotten that information to them so you know how much time they need to react.

“One of the ways you can promote velocity best is just by exhibiting it internally.”

When you join a new team, it’s figuring out, do I need to talk to marketing? Who’s the security person that I talk to about security concerns? Figuring out what all those steps are is a big part of PM onboarding. And every time you run a project, I find something else that I want to add to my list of things that I check for next time. There’s really something about having tenure at an organization that can help you understand what you should be kicking upwind in order to make sure that things don’t drag on at the end.

My advice there is just that PMs should lean on PMs; shadow other PMs’ projects well into your tenure at a new company. Go to their weekly meetings and listen to the challenges that they’re bringing up and stock that away in your mind when you’re running your projects.

What is the #1 thing you do to promote velocity in your day-to-day?

One of the ways you can promote velocity best is just by exhibiting it internally. People see what you do and they watch how you do it. When you come to a project with a lot of energy, and when you’re knocking things off and treating it as a priority, and ensuring that you get back to people quickly, close those loops fast, that communicates to other people what’s reasonable. What your baseline expectations are. They see that that’s what you’re doing for yourself. The biggest signal you can send to people is how you operate.

One way to stop impeding product velocity? Try one of our roadmap templates to align the right people on your strategy ahead of time.