In this video, we're going to talk about how you create a successful interface with

your development team.

If we take this simplified view of the development process,

inputs 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 infrastructure is 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 I 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 development team so

they understand the significance of what they are 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 will 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

surely miss 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.

So 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 fill 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 or

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 that

you can put out to the customer.

And very, very quickly, hopefully, test whether or

not you're right about the needle that 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

team that helps us drive to value, and something that works for the business.

Pretty good.

You and Your Development Team

Digital Product Management: Modern Fundamentals

Rencontrer les enseignants