Empowered Teams

Now that you know what part of the customer journey will have the biggest impact? The question is, how will you get there? Do you focus on delivery or do you focus on outcomes? So we need to understand that shipping is not value, right? Shipping alone isn't going to impact this metric. If you've been in a product team for any period of time, you know that you've built things that never get used, right?

Shipping feels good. It sounds good. As creators ourselves, I always joke around and say, strategists want to do more strategy designers want to do more design, developers, want to do more development, and none of that helps your cause as a business. So the whole goal around aligning around a metric chasing that is to give your team the ability to use that as a lens for the level of craft that they put in.

At Headway, we call it craft within constraints. So it's understanding how we attack this metric together, and understanding that going faster in the wrong direction means that we're going to have to pay off more tech debt later. It means there have to support more things. And so understanding that features won't save you, and a lot of features are built with the best intentions, right? They usually come from ideas from the team. They might come from customers, but they never get used and they don't move the needle.

So when we think about, making an impact as success and not actually shipping and sure you can celebrate the small wins, shipping big releases, but when we can celebrate impact for our customers, that's really where the most fulfillment happens.

So the thing that we need to ask ourself is what's expected of this new. Let's take a look at everything on the roadmap. What impact are we trying to make? And if we can, in this example, take customer views, that the customer views the first data visualization and increase that to 80%. We know that we're going to help them on that journey.

We're going to be more successful as a product. So as we move forward, though, we need to know. If this is a metric who's accountable for that? Who is going to take ownership and make sure that gets reached, because if everybody takes ownership of that metric, nobody does. And so what we normally see in a lot of teams is department structures. So structured around different sets of hard skills. We have strategy, we have design, we have development and those in their own right are super valuable. But many of you watching in many, product teams are structured in this product team structure doesn't mean everything's figured out just because you're working closely with strategy, design and development doesn't mean all of your problems go away.

So the question is. How can we align that team around a metric for a specific customer? How can we empower the team to take ownership, to build more empathy and really understand the journey that they're on? So where we'd like to start is with the customer at the center of everything. So the customer is just a person that we're, that we have to serve.

Right. It's, it's very good and useful to have, um, someone specific in a specific set of customers that journey they're on, but ultimately all of your customers and the different segments, as Ryan mentioned last. Are going to have these key jobs. Some jobs are going to align. Some jobs are going to be different.

Some jobs might not be met at all. And so when you put the jobs around the customer, they're usually for a specific segment and the features are the things that we're building your teams building that are assumed to actually deliver on that job to actually get them to that outcome for that specific customer.

And the last part of it is really this platform concept where, you might have different platform teams, you know, you might have a team that's in charge of platform as a whole. You might have teams that are divided up by mobile by web, but there's ultimately nuance in that. And I think one of the things that's really interesting, as we dig deeper into this model is how it aligns with other models out there. So if you empower your team to be aligned around a customer and moving a metric, moving the needle for them, we have to figure out. As I mentioned how we build that understanding so that team can actually make decisions with that context.

So this reminds me of, or is very closely aligned with Simon Sinek's "Start with Why", and that really outlines the customer and the job. So making sure that we understand who we're serving, what journey they're on, and then moving out from there, understanding how are we going to solve. What are the things, the features, the solutions that we're going to create that are ultimately going to deliver on that.

And ultimately, where does that happen? What sort of platform does that? Mobile? Is that web, is that a wearable? Is that a service? Right. And all of these things build upon each other. And so our recommendation, as you try to empower your teams is to orchestrate them around customers and jobs.

And I'm going a little bit deeper into that. We get to see a specific customer with a job, and then you layer in, okay, how are they experiencing our platform? How are they experiencing the features? What are those metrics that we're trying to move for them? And in this case was making sure that they're able to view that data visualization.

That first one is a key moment in this entire journey. So going back to. Going back to our product team. That's structured around a specific vision and outcome and a mission with common goals. We see that. A lot of teams can be structured this way. And that's kind of best practice. When you think about agile or you think about cross-functional teams.

But the question we have to answer is how can we create a matrix organization essentially like this, where we have leadership in those key pillars, we have career development, we have career paths, progression all of those things. But then we have these key teams that are empowered with specific metrics that are potentially empowered to own an experience for a customer, and then they can go solve and they know what's gonna move the needle for those specific users.

So as we think about the difference between feature teams and empowered teams and really start to pick those apart, what's the difference?

So feature teams. Get features to build, right? These are things that come down from leadership, from management, from, you know, the heads, the stakeholders ultimately prioritize and decide what gets put on the roadmap and the feature teams are there to design and build.

So, Hey, whatever you say right there. They're following orders essentially. And when you do that, you kind of turn off the half of your brain. That's analytical, that's critical. That thinks about how can I use my creativity to ultimately move the needle for our customers. And they're not really involved in product discovery.

Also with feature teams, product managers are project managers and they're focusing on schedules and deliveries. They're not really accountable for the results and they're measured by feature output and roadmap, velocity. Hey, what's our velocity. How, how many points can we do this sprint? Not really asking themselves, are we making the right impact with the points we have?

Most teams would be much better off cutting their velocity by a quarter, slowing down and making sure that they're able to actually, produce impact for their people or for the customers they serve. So what that means is your feature teams are waiting for direction, so they don't have any autonomy to go and make decisions on their own.

Ultimately categorize as ticket takers. What we find usually in, in talking with folks from these teams, as they're less fulfilled, you have less control over the impact and value that you can provide. You can't really show up as your full self here. You're taking the next ticket in the queue and moving it forward.

Now for many feature teams, their roadmap looks like this, which is six months of features planned out. None of them really backed by behavior or customer intent. None of them really checked back through with customers. A lot of them are just ideas. Hey, we think this will move the needle.

We think this will make an impact. We think this will move things forward. The reality is if you've been a part of, one of these teams, that's rarely the case. I mean, it doesn't mean it can't happen. There's no absolutes here, but when we think about increasing the likelihood of success in what we do, it's about making sure that we can empower teams to own something.

And so, as we look at the differences between a feature team and empowered, They get problems to solve, right? Like the metric we're talking about the stakeholders partner with them, the stakeholders give their key insights about the industry or about the customer or things that we can't quite get access to.

But the teams are there to discover the best way they see fit to solve the problem. And that's not them just saying, Hey, we think this is good. That's them taking them through this journey, that ultimately checks things with customers and gets it in front of them. They're so involved in product discovery as well, meaning they start to understand how customers think.

As we think about that last diagram, they're really in tune with the needs of the customer, the goals that those customers have, and they can start to really use their brain to think through how can we serve them better, not only the metric, but overall. Also on empowered teams, product managers act as CEO of the product.

They focus on value. They focus on viability and they're accountable for the results. And these sorts of teams are measured on their value and outcomes. The biggest thing is that they're on a mission. They know what the mission is. They know how to, how they can impact it. They know what's valuable to the business. They know what's valuable to the customer and they're able to act on that.

So with that, understanding that these teams are data-driven and they're always in motion, right? They're never waiting because they have a mission that they're on and they know how they can use their skills in concert with each other to make an impact.

They can take ownership and we see more meaning and fulfillment there. And I think that's important because so many teams can be structured in a cross-functional way, but still have this feature team aspect to them essentially, where they're waiting for tickets, they're waiting for someone to really tell them the next step, when really they could show up and take ownership over it if they had the right environment and if they had the right capabilities.

So part of that is taking a look at this empowered roadmap, which is kind of an adaptation of that feature roadmap, where you see a lot of the things are blurred out. Things start to fade. Hey, we might know what we're doing in March and April. But some of those things are discovery, right? We're doing discovery, we're doing prototyping.

This is not really the full feature roadmap of what we're getting into delivering into production. But this is what things we're going to test with the customer. And so we know two to maybe four sprints out what things we'd like to test on the roadmap, the backlog of things that we're going to produce and really figure out how we can hone what the future looks like with our customers.

And really co-create. So as we think about what does this look like in practice? We start to look at this model, which blends in discovery and delivery, and you might've seen it in different ways, right? Double diamonds before, right where you go through it and ultimately get to a solution. And then you have to figure out how to iterate.

But a lot of teams, a lot of startups that we know do that early validation and they cut off discovery, meaning they're focused on delivery, right? They did all this research upfront, all these customer interviews, all of this first person, primary research, they figured out where they could solve a problem for them.

And as they started getting traction, they went okay. Back to kind of what we mentioned earlier in this series. We know what our customer wants and really we need to get into the details. And so if you just do delivery, you're going to be missing out on the entire experience, because the reality is you're serving your customers through a product, not through a person, right?

If you had an objection, if you had a question face to face, you could ask me and I could explain why, but your product needs to do all of that explaining. So as we look at this model that. We're going to go through next. It's all about putting the metric at the center of this journey, right? Increasing that effectiveness to 80%.

So that means we're doing discovery and delivery around this. We're going, we're exploring potential options based on what the data is telling us. We're going into prototypes and saying, how might we solve this? What are the different solutions and pathways we have then once we prove those out with customers, we move it into a pilot where we do a small test.

Then ultimately we're scaling that up to all of our users. So using this model, you can start to look through the lens of metrics and of your customer, really at the center of this, to make sure that you're making decisions on the roadmap that are going to have impact that you want.