You and your development team

In this video we’re going to talk about how you create a successful interface with your development team. If you take the simplified view of the development process it puts in and working software that you can put in front of a customer out, your most important job, your number one job is to supply strong inputs here. Even if everything here works perfectly, technology infrastructures, perfect bug free, project management is excellent, and predictable. If the inputs are weak here, you’re going to get something out here that is not valuable, not desirable to the customer and then everything else falls apart. That’s why they say it’s the number one job.

If there’s a number two job, and there is, it is to close this loop. And that means making sure that whatever it is that you’re trying to achieve with these features that you’ve described in these development inputs, you know what dial, what metric of meaningful performance you’re trying to move with this feature, and you know how you’re going to measure it. And decide in a way that you can both, be decisive for yourself and explain to the developement team, so they understand the significance of what they’re doing, whether or not you got there or you’re going to iterate again and try something else.

Your job is not to push them on their estimates, or rush them, or otherwise kind of be a proxy manager for development. That’s the job of the development managers, or possibly something you can work on with the project managers. But not something that you should be doing in your job, because it’ll take your focus away from this, and it’s best done by somebody who is more focused on understanding the way that this particular development team is working. A very common failure mode is that customer yells at you, I need these features, I need all these bugs fixed. You feel bad, and then you turn around and yell at Dev. Go get this stuff done.

We need to fix this for the customer. And it’s not like you don’t get customer input that’s important or sometimes urgent. And it’s not like you don’t need to prioritize things for development and stuff. But you want to make sure that it’s a marathon not a sprint. And that you have kind of a balanced view of which things to which customers are really on the a list at any given time versus which things are just going to have to wait. Because you’ll never be able to do everything for everyone and that’s hard. But that’s a big part of your job is to make those hard choices.

Explain them and test them in terms that are workable for the rest of your team.

Your development team has a finite amount of energy and time to execute features. Let’s say it’s represented by this milk bottle here. And you’re going to fill that milk bottle up with initially relatively high level inputs, maybe propositions. If you remember the talking bicycle compass example, a really high level proposition might be, we want to add time left on the route to the functionality of our app or our device that we’re going to offer to these people. So that they can periodically know, how much time they have left on their bikes. Because we’ve observed them, we’ve talked to them, we know that this is important. And we think it’s going to move some kind of needle.

Growth, engagement, and that’s what we want to do. And we’ve got validated learning, that that’s going to be valuable. That’s sort of step one. We’ve filled up the milk jar with the bigger marbles. And then those marbles get broken apart to be more discussable and more actionable in cooperation with development. So that they’re understanding those propositions as you move along. So these slightly smaller marbles are things like agile user stories, prototypes to show ideas of how you might approach some of these stories. And that may or may not be your job to break those down. There’s a role called product owner in Agile, and that may or may not be your job.

You may work with a counterpart who more so focuses on that. Depends on the team patterns that you’re using. And then finally, all this is blended together into actual working software you can put out to the customer and very, very quickly, hopefully, test whether or not you’re right about the needle, that it was going to move, the dimension of performance that you wanted it to increase. That is the way that we create a successful interface with the development that helps us drive to value and something that works for the business.

Pretty good.