The Death Of The Project Manager: A New Era For Product Management Arises

Paul Savage at UXDX EMEA. Video: https://youtu.be/05POo4Ll1zk

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Job titles that don't exist anymore

[00:00:02] First of all, I didn't get here earlier so I'm not sure who I'm talking to. Who's a designer? Hands up there. Okay, those are designers, great. Who's a developer? Excellent. Any project managers? Yes, so just to be clear, this is not like insight and chart[?] like that. This is a Halloween themed thing. So the coffins and everything else, there's no connection there at all.

[00:00:40] First of all, one of the themes that are coming through in all the presentations today: we've got a massive change around the industry. There's loads of job titles that don't exist anymore. First of all, we have the guys who used to copy the code from staging to production, those guys. Well, they're DevOps, that makes that a programmatic thing. And you've got all those lovely test engineers that we can try and get rid of. There's loads of these jobs that don't exist anymore. And having a dedicated project manager is one of them. Which is actually pretty bad news for me, right? I was hired into nearForm as a project manager. So, interesting. Going from a developer, where I started, into kind of managing things and being a product manager and being in control.

What project management actually is, and where it goes wrong

[00:01:36] First of all, just to understand very, very clearly what project management actually is. Project managers are magic. At the start of a project, they are responsible for understanding the scope, the feature set that has to be done. And then they need to figure out kind of what resources they need, what kind of developers, designers, what kind of time they need to actually make this happen. And then they get in their business analyst to convert the ideas into a structured set of requirements. And then they get the requirements, they give it to the dev team, they give it to the test team. They've got a lovely Gantt chart that shows them clearly how all these different functions will work along the way. And the project maintains, and software is built, and software is tested, and software goes live. And everything they've got live exactly matches what the business owner at the start fed into the process. And that's where it all starts to go wrong.

[00:02:39] And the reason is that the project manager is one step removed from all the things. They're supposed to identify risks and manage them. Which makes perfect sense when you're in the real world and you're building a building. You know the risks. It might rain. It might be an earthquake. I don't know, it depends on where you are. In software, we're in an n-dimensional space. There is an incredible number of risks that can hit you. It tends to vary significantly project to project. Every project should be considered a new build, with a heap of new parameters kicking in. So this magical project manager who is trying to have his lovely risk matrix and manage all the project's risks and get this lovely mitigation going and make sure everything is delivered on time, it's set up for failure. There's absolutely no chance of success.

[00:03:34] What I like to think of is this lovely concept of an inland lighthouse. It doesn't matter how bright this lighthouse is. This lighthouse is useful... it's 400 miles from the coast, it's useless. Did I say useful? Anyway, it's useless. So what you have is you've got a project manager who is looking at a set of requirements that are based on assumptions that the person, the business person that's asking for something to be done, that product to be built, can actually tell you what they want. That's rubbish. And then there's the idea that you can identify risks in advance from knowing about project management, when every project is so different.

MVPs, fixed everything, and the sketch artist

[00:04:19] So if you map it back to the way an MVP starts, it starts to get very, very interesting. And that's where you say, right, MVP, the business wants to deliver an application process. Let's just say an application process. There's a new product in the business. There's a new product that's usually been a paper form or an Excel thing. We want to create a nice product that will do this. It's a simple thing to explain. The project manager then comes in and figures out exactly who needs to get involved and gets everything kicked off.

[00:04:57] And in all the projects that kick off like that, there's loads of assumptions made and all the mistakes are made day one. And it's lovely, you hear it very, very simply. Typically you'll have a fixed feature set. You'll have a fixed delivery period and a fixed cost. But we're going to deliver it using an agile process. Absolutely. Because that doesn't break agile at all. There's no problem.

[00:05:24] There's loads and loads of these things that start. And when you actually reduce it to a very true example, you start to understand why they don't make sense. Because the project manager is becoming a middle man. So think about a murder scene. You have an eyewitness that sees somebody running away from the murder scene. So you grab them and you bring them to the police station. And then you appoint a project manager who explains that this person now needs to sit down and describe in detail that suspect that was running away from the murder scene.

[00:05:54] So you get a lovely detailed requirements spec. And then you get that requirements spec and you bring it over to the sketch artist, who then starts working away with the sketch. And they finish the sketch, and then they bring it back. And lo and behold, it doesn't come close to matching what the suspect looks like. So that middle man is why the project manager is a problem. And it's very, very obvious to see with the sketch artist.

[00:06:19] The right way, of course, is the eyewitness comes in and you sit them with the sketch artist. And then you get a nice little process going. The sketch artist says, well, is this the shape of the head? And the guy goes, no, no, it's a bit square. And the sketch artist iterates and iterates and iterates and converges on a picture that's a very, very good likeness of the suspect. All good, right?

Design driven development, and its unicorn problem

[00:06:41] And that's design driven development. Brilliant. That can solve all our problems. It depends on how long you've been in software. Waterfall was around. That was going to solve all our problems. Then agile came in. That was going to solve all our problems. Extreme agile. And we now have radical agility. David[?], it's very clear. And again, these things solve all our problems.

[00:06:58] So design driven development is wonderful. You get a business owner. They know exactly what they want. And you get them together with a designer, and the designer builds a picture of what happens, and they work iteratively together and they get something that they're really, really happy with. And then the designer brings that to the development team and works with the development team.

[00:07:26] And what you've done there is you've made your designer, your beautiful unicorn designer, that unicorn designer that's really hard to find, you've made them a project manager. And the best designers are generally not good project managers. So what you need to do is to get more integrated.

[00:07:45] And this will come through in all the talks. It's obvious when you actually break it back. The whole thing that's wrong is to think about a controlling point, like a project manager that knows everything and controls everything and changes all the parameters and gets everything over the line on time. What you need to think about is an intelligent, talented team that will deliver.

[00:08:13] When you actually do that, then it's not just design driven development and it's not agile. It's really, really simple. It's these few points of confidence[?] working together. So you've got a customer. If the customer doesn't know what they want, it's very difficult to do a good job. So if the customer is wrong, you're dead anyway. But let's assume we get the customer right, they know what they want, they can express it. You've got a designer that can interpret that into a kind of a look and feel in an airplane[?]. You've got developers that can actually build it. And you get them all working together as a team.

Ballistic missiles versus heat seeking missiles

[00:08:48] And the difference between the old way of doing it and the new way of doing it is much like building missiles. Missiles used to be military missiles. So you want to take a satellite out. You key in your components at the very, very start. It's like the requirements in the waterfall process. And your missile shoots off and it's going to take out your satellite. And that works if you know exactly where your satellite is going to be and everything else, and you get your maths right and everything works really, really well.

[00:09:20] That's the reason that software development projects regularly fail: because the assumptions are wrong, the maths is wrong, where the satellite is supposed to be is wrong. People misunderstood what is important, and very often people ask for things that they think they want, not what they need, and you have to tease that out.

[00:09:37] So what you need to do is you need to build a heat seeking missile. Way more effective. All you need to do at the start is make sure it's pointing up. And it takes off, and then it slowly but surely turns itself, and as it goes up you get it closer and closer and you get your target more often than not. So that's the aim: to build a heat seeking missile. But how do you actually do it?

Setting a project up: the team, the customer, expectations

[00:10:00] In nearForm we build quite a few MVPs every year. That's where we take things from scratch and we put the team together, and we do a few things at the start of the process to get things set up the right way. Projects are very, very much like planting an orchard. You can make so many mistakes day one that your orchard will never produce fruit. I have a lovely orchard at home, by the way. It's fantastic. It never produces anything, but it's beautiful to look at, trees are very healthy. But I got a few things wrong day one.

[00:10:34] So the first thing is get the right team set up. And this is really interesting. This is where culture comes in and all sorts of things. If the customer is quiet and polite and you put in a really shouting team, you've messed it up already. So you've got to get things like that right. You've got to actually get things set up for success.

[00:10:54] You also need to choose the right skill set in the teams. So if it's a very highly visual project where the UI is critical, you need to get a designer and a UX expert, and hopefully that'll be the same person if you're lucky, onto the team as early as possible. You need to get the actual developers right on the team. If it's all going to be highly performing visualizations, you need somebody who really knows their front end. If it's something that's going to be around performance and back end, you might have a different type of engineering team.

[00:11:29] Get the right team set up, and then get them connected with the customer. And what that means is that they actually have to understand the business goals. And that's great if you're someone like Zalando or Ryanair. That's a really important thing that you can do, and that's one of the successes of those stories: they get everybody to actually understand what the business goals are.

[00:11:47] And the other thing is customers' expectations. Very often we work with people who've never built software before. People who are not involved in that process regularly assume things that are incredibly difficult are easy, and they assume that things that are very, very easy are difficult. So you've got to get that right. That's very, very important, to open that communication and make sure that you manage your expectations.

Success criteria and the heartbeat of a project

[00:12:20] You also need to define success criteria. One of the questions asked was about the metrics we track on our projects. Each one is different. And it used to be that project managers had success criteria, because they have a list of features, and as you implement the features, well then that's success. And if you match that to your lovely Gantt chart, you're on track, everything is good. So we've got half the features built and we're half the way through the project, everything is great.

[00:12:44] And the answer is, very often that is not the case. And strangely enough, when projects go wrong and you ask the development team, the development team knew it was going wrong already. They knew that actually there were two or three things at the end that needed much more time. So what you need to do is you need to figure out how to track success. What are the success criteria? Work that out in advance and then track against that in a way that makes sense.

[00:13:11] And the other thing is you need to build a heartbeat of your project from day one. There's no point in that heat seeking missile being left alone. It goes too far off track. If you leave that heat seeking missile alone, it just disappears off and it's off pointing at the wrong part of the sky, and you can never pull it back. So what you need is a heartbeat, so that you get developers together every day, you get people doing demos every week, you get feedback loops. You build those feedback loops so you can actually take a look at the milestones and you can make sure you're hitting them as you go through your project. And those feedback loops are the critical thing about everything.

Common sense over process, and staying lean

[00:13:49] So the number one thing is common sense over process. If you're a developer that's been around a while, you might remember patterns in coding. Ways of writing code were split into a number of different patterns, and everybody embraced these patterns at the start, and it was a bit mad. You'd have a requirements discussion and the next thing was, which pattern are you going to use to implement this? Which is completely the wrong way to do it. So don't try and embrace agile. Look at what works for agile, why agile works in certain contexts, and then do what's the ladder[?] did: take your own version of agile that will work in your company and make it work for you.

[00:14:32] And more than anything else, we talk about being lean. This is one of the big things about that missile. When you're actually starting, you don't need to be too finicky about what part of the sky it's pointing at. Just make sure it's pointing up. If you think about the very big success stories, the guys in Stripe, they didn't build a massive system to automatically validate everything about your application to be a credit card merchant on day one. They built a simple web form that allowed them to get the information so they could do it manually, just to see if anybody actually wanted to do this.

[00:15:05] So if you actually approach all your projects this way, you can validate those assumptions instead of those assumptions tripping you up later in your project. You start validating from day one. You're validating, and every time you validate, that's just tuning that missile's path a little bit better.

Autonomy, and turning everyone into project managers

[00:15:28] Which means my second last slide. The thing about this is you have to trust your missile from the start. That means you have to give your team autonomy. And this is the one difference. This is why project managers are really fading away: because they're this controlling point in a world where it's almost impossible to control enough to generate success.

[00:15:52] The developers very often will encounter a problem or a risk with the system as they go. They need to be responsible for calling that out. They need to work with other people to actually mitigate those risks as they go. The customer will regularly see something as they go and go, hang on a second, you know what, I never said it, but we need the whole thing to do this as well, that's a higher priority than the other stuff I was asking them to do. So when we're talking about managing scope, there is a responsibility to manage scope. The designers regularly will come up with snags and problems like, well, you want to do it that way, but you know what, that's going to be an awful user experience, that's going to be really difficult for a user to grasp. We're all very familiar with this now and we can kind of do it.

[00:16:36] And each of those points is an intelligent decision making point with autonomy to direct the project and impact the project, when you actually let them do that and you let go. And I'm a complete control freak, so you can ask anybody in nearForm, what we do is just control everything that's needed. But actually just letting go and just letting teams create success has worked really, really well.

[00:16:59] Which brings me to the absolutely horrifying conclusion that we can't actually kill the project managers. We actually have to turn everybody else into project managers, like zombies. Because what the project managers were responsible for, now that responsibility is shared across all of us. So we all have to be project managers. We all have to do the things that project managers did. That project management book of knowledge, everybody needs to go back and read that now, because developers, designers, everybody needs to do that. Thank you very much.