You Might Be Looking At Milestones All Wrong (with John Carter from TCGen)

Galen Low So there you are staring at your project plan again, dreading the very milestones that you helped create. They seem to creep closer every time you look at them, like diamond-shaped Space Invaders. They seem so innocuous at the beginning: they were just lines in the sand to help you plan in broader strokes. Now they’re a weight around your neck: heavy, immovable deadlines that cannot be reasoned with. They are the murmurs of doubt threatening to drag you into a dragons den of angry stakeholders when the fateful day arrives. If this sounds familiar, then I’m sorry to tell you that you’re one of those PMs who has been using project milestones completely wrong. Don’t worry, most of us are in the same boat. But if you want to transform your project milestones from a terror inspiring burden into a North Star for team and stakeholder collaboration, then keep listening.

Thanks for tuning in. My name is Galen Low with the Digital Project Manager. We are a community of digital professionals on a mission to help each other get skilled, get confident, and get connected so that we can deliver projects better. If you want to hear more about that, head over to thedigitalprojectmanager.com.

All right. Hey, everyone, thanks for hanging out with us on the DPM Podcast. My guest today is a widely respected expert on product development and also no stranger to project management. He is one of the key brains behind Bose’s noise-canceling headphones, as well as Apple’s process for developing new products. Today, his company, TCGen, advises heavyweight brands like Amazon, Apple, Cisco, Hewlett-Packard, IBM, Mozilla, Roche, and 3M. And he also just hired a tutor to help them learn music theory and is now composing music. So, folks, please welcome Mr. John Carter. Hello, John.

John Carter Hello Galen. Glad to be here.

Galen Low Great to have you on the show. Really appreciate it. John, your CV. When I looked at it, I was like, everyone is probably envious of the CV. We’re talking about product innovation for Bose, working with Apple, now running your own business, writing books. So I thought I’d just start off by asking, what did you want to be when you grew up?

John Carter That’s a funny question. And I actually still do it in my spare time, which is to be an engineer. I’ve always wanted to design things and make calculations and predict performance. And so that is something that’s always driven me to this day. Still drives me.

Galen Low I love that! Was it a big inspiration to get into the more innovation side of things? I imagine the engineering mindset lends itself to creating new things that are viable, feasible, and that people will actually use.

John Carter Well, I’m not sure it was that thoughtful when I first started, but I, I was the prototypical boy scientist. So I had the chemistry set, I had a microscope, telescope. I got a ham radio license. I just did all these geeky things. I just loved I loved what I did so much. And I think it relates to what I love to do now, which is I loved electronics and I loved the fact that you couldn’t see electricity or electrons, but yet you could measure it and do something with it. And today you can do the same with sound. You can’t see it, but it has tremendous impact on how you feel and think and so forth. And so I’ve always enjoyed trying to understand phenomena you can’t see.

Galen Low There you go. Was there an inspiring moment in time where you decided, you know what, let’s take this out of an engineering context and put it more towards technology and the digital world or products?

John Carter In a way, it really naturally arose from my work with Dr. Bose at the Bose Corporation where I started. He was phenomenal, both with marketing and engineering at the same time — it’s a very, very unusual capability. And he would ask basic questions about what people care, about what they’d like to do, what’s important to them. And through his approach to living and life, I really understood the importance of really trying to understand your customers needs and really make sure that you deliver on what really is important to them. And we’d learned that in so many ways, even being the inventor, we had no idea really what the customers would value until you put it in their hands. So I think it was a gradual introduction through Dr. Bose and his tremendous market insights that caused me to turn from just engineering to innovation.

Galen Low That’s awesome. I love that. And I mean, you’ve done so much in your career; these days, is there anything you’re just trying to get better at?

John Carter Always, always. There are a couple of things. One of the things that I think is really interesting is the intersection of Agile and project management. I think that’s fascinating. And the other is the ramifications of what I would call digital product development. What is it like to work on machine learning versus typical product development How do you innovate in that kind of digital environment and this whole new remote work? It’s just fascinating what’s going on. And so I really try and understand what’s pushing the wavefront of innovation.

Galen Low Awesome. I love that.

And just wanted to ask, has there been anything else that you found recently that’s just making your life awesome?

John Carter Well, you know, I think one of the things that’s really renewed my faith in mankind is the ability to continuously innovate. If you look at the current set of problems in front of us and the fact that we is basically as the world has had to pivot on things like remote work, on education, on the drug development delivery. I mean, there’s positive transformations that are a result of this crisis that we’re now in that really is building my confidence in our ability to out innovate any situation that we confront. So that gives me a lot of hope.

Galen Low I love that silver lining on an otherwise perhaps suboptimal scenario for us this year. Awesome. So I thought maybe let’s talk about your recent post that you posted to the Thedigitalprojectmanager.com about project milestones. So firstly, it made me feel like I had been going about project milestones completely wrong. Secondly, it really got me thinking about the connection between project milestones and a product success or failure in the marketplace, which is a way I had never really looked at the problem before, but I thought maybe let’s rewind and start from the beginning, first of all. In your mind, what are project milestones and why should anyone care about them?

John Carter Right. It’s a great question, a great place to start, because I think people’s beliefs about milestones are wrong when it comes to digital project management and the way that they’re wrong as milestones are not a way to measure progress. There are many, many other better ways to measure progress that don’t wear down the team and produce volumes of irrelevant reports and then cause micromanagement because they now are aware of more things. So the common misperception is, is use milestones for tracking. But really, if you look at milestones, what they are as inflection points in the project, they’re critical periods or decision points in the life of a project where either you’re about to invest more or take on more risk or make arrangements and agreements with partners or what have you that probably do deserve the benefit of doing your homework. And the other thing is that in this complex, interconnected digital world that we live in, there’s a lot of dependencies between project attributes and milestones are a great way to synchronize on dependencies. You can have two teams that are both working at an agile fashion, but there’s some point at which the work of one team needs the output of another. And milestones are a great way to coordinate that kind of activity.

Galen Low I love that and thinking through that, I mean, you mentioned some of the common misconceptions of milestones, you know, fixating on tracking and reporting, what are some of the impact that that has to a project if you are approaching milestones that way instead of thinking about team dependencies?

John Carter Well, there’s so many things. First of all, it kind of erodes any belief in that the management trust the team. In other words, if the the projects are filled with lots of check-ins and management reviews, and milestone reviews, the team actually is constantly looking over their shoulder wondering what management is thinking.

This is a corrosive attitude because it really doesn’t bolster the team’s self-confidence and the ability to really deliver a project that’s excellent based on their own initiative, which they all believe they can do.

But furthermore, it’s a drag on the team because you’re constantly producing reports that are skimmed or not read or briefly overlooked and tedious graphics and updates. And what’s the point of it? Is it to make a decision? Is it to communicate? Well, if it’s to communicate, you can use project dashboards or backlogs or any number of different ways to communicate progress. If it’s decisions, you know what really needs to be relegated beyond the team? That’s when you need a big milestone. And those are few and far between. So the idea is to reduce the frequency and number of these reviews and make sure their value-added for the team.

And that’s really important. And how you might implement milestones that are effective.

Galen Low I like that.  It’s more about doing the work than pausing to evaluate it or report on it.

John Carter Exactly. Exactly. And then you have unfortunate courage is management to quote-unquote, add value and then add a bunch of empty calories onto the team that they have to then expend to produce the Seymour report so someone can see more. And it’s just an endless amount of management throwing chairs in the path of the team where really the management should basically eliminate obstacles and get out of the way.

And that’s another way in which milestones can cut two ways. Too many encourage micromanagement, meddling, right number encourages the right kind of decision-making.

Galen Low Awesome. And was there a point in time where you paused in the project that you were managing and said, OK, I’m going about this the wrong way? This should be actually more about team and teamwork than about reporting?

John Carter Yeah, it was soon after as I was promoted to chief engineer at Bose and then in that situation, I had the tendency to micromanage the call more reviews and do more project milestones and sprinkle them in. And I suddenly realized I was dying because I couldn’t find the all the time and the week to schedule all these minutiae, these reviews filled with minutiae. And the second thing is that it didn’t help the teams either. So I was drowning, the teams were drowning. And then I realized and this was so boring that some of these team leaders and tech elites knew a lot more than I did. A lot more. And I should just get out of the way. I don’t know what I’m talking about. And that realization that one engineer said that in the dev organization said I was just creating distortion, delay, and noise. That was probably the point at which I stopped doing so many milestone reviews.

Galen Low And when you stop, did you notice like an overnight difference in the way that team was operating?

John Carter No, not really. I think it became incrementally more productive and I became a lot happier in my job. I found out the team actually executed just as well, if not better, without my meddling. So I think what it does is just lift the veil off the team, make them more productive, happier, more content and deliver better products.

Galen Low Well, that yeah, it’s amazing the weight of mistrust. And when things are coming from a place of mistrust, it’s a heavy burden for the team versus the trust. That’s the job is going to get done. And everyone’s collaborating effectively and managing themselves effectively.

John Carter Yeah, it’s like an ever-present caustic atmosphere, I agree.

Galen Low Awesome. Let’s talk a bit more about how to go about doing it the right way and also what it looks like when you’re doing it right in terms of project milestones. So you mentioned that milestones are more for the team than for project managers or for management. Like how do you groom a team to see it that way if that’s not how you’re seeing it already?

John Carter Well, this, in fact, gets back to this mistrust environment that you talked about. And what’s really critical is for the team to have a competent product owner, a competent scrum master digital project manager, and a competent tech lead. If you have those three things, then management should trust you and they should trust the system. And if you have competence in your team, there’s no need for constant micromanagement. And then what you can do is you can really work with the team so that they understand. Well, here are the key milestones and this is why they’re important. And I think that’s the most important thing. And also, milestones should never be on a fixed interval.

So you shouldn’t have weekly standing meetings or monthly review meetings or calling late reviews. I mean, some are necessary, but not at the detailed level in general. And the notion is milestones should be event-driven.

They’re project-driven. They’re based on the speed, maturity, size, risk, et cetera, of the team, as well as obviously the challenge and the task. But that’s it’s a clear indicator if your milestones are on calendar dates that are regular, there’s a problem.

Galen Low Almost speaks to mistrust. It’s like I’m going to check in on you every two weeks.

John Carter Exactly. Exactly.

Galen Low Make sure it’s on the rails versus. Listen at this point. We need to look at where we’re at because there’s other things that depend on it. And how are we going to plan or collaborate on those next steps?

John Carter Exactly. Or we’re going to write, you know, the seven-figure Check. Are we sure we’re doing the right thing? Absolutely.

Galen Low When you put it like that, yeah, it’s very important.

John Carter They can be big checks.

Galen Low Yeah, well, absolutely. And in terms of sort of knowing when a team is ready, I like having those roles and knowing that they are strong at the role that they’re playing in the team.

What kinds of behaviors do you expect from a team who is really ready to own their own milestones and understand what they’re all about?

John Carter Oh Galen. This is terrific question and I think it can be answered very simply. Excuse me. And that is history. In other words, has this team been predictable in the past? Does their history, does the their success and achievement in the past, does it indicate a positive outcome? And I think this you know, this whole thing of trust is built over time. And certainly the best gauge of any project team is, is their past history and success in program. So I think that’s the first and foremost thing I think, you know, you need. And they each one of the those key positions, for example, in product, you really need someone who understands, you know, the why and the what. They really have to know that stuff and team has to believe them. And same on the tech, the tech lead, and Dev and QA, you have to believe in their ability to make the right architectural decisions and trade-offs to achieve the project goals. And then the case of the digital project manager, you’ve got to have confidence that they will be transparent. And so when there’s a problem, they basically make it known quickly and don’t hide things.

And I think these kind of behaviors in these three key roles will signify readiness besides history.

Galen Low I love that, I love that the whole concept of, you know, team makeup and team-building strategy and, you know, you do want experienced folks who are approaching it from a mature lens and understanding the context of what they’re doing. And, yes, maybe supported by more junior folks. There’s definitely room for them still. But in terms of having the right folks, you mean having experienced team members who can look at the project and the product that they’re creating in the right way to then understand what the milestone means and to help plan those milestones for the project?

John Carter Absolutely, and the fact that junior roles may outnumber the senior roles by quite a bit, but you need and I’m not talking about age, you just need cycles of experience, so-called learning cycles. And so if they’ve got several under their belt, they’ve been good experiences. I think you can certainly trust the team. Absolutely.

Galen Low Learning cycles.

John Carter Yeah.

Galen Low That’s great. And then I guess my other question would be on the other side. So if you’re dealing with a management team that is used to having monthly milestone check-ins or what’s there to be a dozen milestones in a very brief period of time because they’re so used to and maybe they do trust the team, but they’re just hard-wired to want to check-in and micromanage.

How do you get a team like that, a leadership team or a management team to adopt a different way of thinking about milestones so that they’re fewer and further between and they’re not a regular cadence?

John Carter Right. Well, that’s a really great question. And the answer is, Galen, it depends. So if in the organization there is a mechanism for providing some kind of measure of progress, whether it’s backlog’s or story points or deliverables that have been completed, there are all sorts of simple metrics which are gauges of progress that are objective. And I think that’s the degree to which they’re lightweight and objective is really important. They can be supplied as a proxy. I think the challenge with managers is they confuse transparency and monitoring project progress with decision making. And those two are totally different communication forms. And in terms of progress tracking, that can be done with dashboards or all sorts of transparent indicators or worst case, it can be done in the meeting.

But just with one individual on a frequency that is driven by need. But there is a confusion with managers. And so what we need to do is we need to assure them that they can transparently see progress and also be assured that they are notified if something goes wrong. And although we didn’t really talk about boundary conditions in this article, there’s a notion of a team having limits to what’s within, let’s say, the threshold of what they’ve agreed to on their digital project development. And if they’re not going to achieve those, it’s incumbent upon the team to, in fact, inform management. So if management, therefore, has a way of transparently saying the team’s progress and also is confident that there’s a mechanism so that they’ll get bad news quickly, then in fact that should be adequate. And they trust the team because they’ve seen their history with those three factors. I think we can make a compelling case to management for the need for less milestones.

Does that make sense, Galen?

Galen Low Absolutely. And I love that sort of separation and disambiguation between like reporting and tracking versus decision making, which really is what milestones are about a moment in time to say, how are we doing?

Not progress wise, but that point where we were going to enter into this next phase or add this other team to collaborate with us. Are we ready for that? Is that still the right thing to do?

John Carter Exactly. Exactly. Are they ready for us?

You know, it’s a great point and a value-added check in.

Galen Low Which I mean, I guess brings me to my next question just in terms of, OK, well, when we’re planning milestones, does this perspective does your perspective on milestones change the way that we actually create them in the first place or developing our project plan? Or have it may have been to say, OK, well, we do a check-in quarterly or we’re doing a check-in because we need to update the steering committee. Does it change the way you plan projects if you’re thinking of it as milestones for the project and for the team?

John Carter Yeah, for sure. So all those other status reports and steering committee updates and so forth, those would be diminished or eliminated. And what we’re talking about is a light work framework to do digital product development. And this framework should have a set of standard inflection points that are appropriate for your business. So different organizations have different constraints. You know, if you’re I don’t know if you’re making widgets, you’ve got to order inventory and parts and so forth. Well, that’s a big expenditure. You probably want to make sure you’ve got the right parts specified. It’s really important. And similarly, if you’re trying to ramp a digital project, you want to make sure that the right kind of instrumentation is included in the product. So you want to make sure that you can get the kind of analytics that your team wants. Well, it’s important to make sure that that instrumentation is ready to go when you lots of product. So it really depends on what your business is. But those milestones, in general, should be standardized. There should be few. And I like to say there should be as little process as possible and not any less. So the idea is to really make it lightweight and put in standard milestones where your business typically makes the big decisions. And it should be a small handful, I’d say three, three to five.

Galen Low And I love that example of widgets. Or if you had to order parts, it just makes sense. You have these dependencies that sensibly before you go and do that, you want to make sure that you are at a point where it makes sense to do that.

John Carter Absolutely. Absolutely. You know, and in the case of typical digital developments where you’ve got cloud activities, you’ve got what’s going on in the client, and then you may have desktop, you’ve got a lot of different systems that need to be integrated and DevOps that needs to be coordinated. So each business is different.

Galen Low For sure, one of the things that was I found really fascinating about your article was you talked about having three major milestones or inflection points during a project that would correlate with major business goals. Can you explain a bit about what those are and why they’re important?

John Carter Yeah, well, the first I think is so important, especially when you’re talking about innovation and this notion. Galen, we talked about capital I innovation. In other words, the innovations that are our game-changing. What you want to do at the very beginning of your digital project is think about is this concept really aligned with our strategy? Does this fit who we are as a brand? Is this a sort of product or idea that we want to bring to the marketplace? Will this move the needle in terms of revenue or margin? In other words, we’re going to be committing to this activity for the next three, six, nine, 18 months, potentially a large team. Is this going to be aligned with our strategy and move the needle? So the first thing you do is you Check there’s a concept that second most important thing given there’s a concept that it’s aligned with strategy. You want to make sure you’ve got product-market fit. In other words, do you, in fact, have something that consumers will choose? Do you have unique selling propositions that are meaningful to consumers? Do you have some vitality in terms of the marketplace? Can you, in fact, encourage other users or are larger shopping cart experiences or whatever the goal is? Do you have proof points of your acquisition cost? All these things now are in the era of digital projects and products are measurable. And so this next phase is really important, especially before you really scale the team as make sure you have product-market fit. And then the last is, is this development and market launch. So this is basically all right. The organization says the concepts aligned the product and the market fit. In other words, consumers really like what we’re doing here now. Now, in order to make this a feature, complete release MVP and then feature complete, what are we going to need to develop to get this onboard? What kind of partners are we’re going to need on the Plowden infrastructure side? What kind of development partners are we going to need for the different mobile platforms? You know, we’ll do the desktop and tablet work. And here, how are we going to partition this? We’ve got to invest in UI, graphic design, and so forth. And so we’re going to need to spend big. Are we going to commit to that? And that is really the commitment to go for development and market launch. So these kind of are the three key inflection points that really govern most digital project the product development and obviously can be tailored. You know what’s important to you? Maybe there’s another stage, ideation stage you put on the front. Maybe you have a more explicit validation phase at the end. Maybe there’s DevOps going on. There’s all sorts of Rinkel that you can add to this. But having a common framework so that executives, when you’re dealing with and this is what we work at Apple developing their Apple new product process is you want to have when a company’s scaling, you want to have a few standard milestones so you can compare where projects are, because that allows executives then to manage the spend over time BI, you know, essentially managing the flight pattern and the standard milestones, these inflections that are important tell you where the project truly is with regard to customer access and investment.

Galen Low I love that idea of just, yeah, benchmarking across projects, and especially if you’re a company that is developing multiple projects at once or products at once, rather, you need to kind of look at this pipeline and see where things are at in terms of not the health of the project, in terms of progress, per say, but the health of the actual concept for the product and how the product is evolving in terms of when that’s going to launch and when it’s going to require certain resources.

John Carter Right. And in fact, if you look at these three milestones that we talked about, Galen, none of them were really hinged to a time.

Galen Low Mm-hmm.

John Carter There were all about, hey, is this aligned with strategy? Good. Hey, is there product-market fit? Good. Hey, do we want to really invest and spend to launch this sucker? Good. And those are, you know, three very important Non-time-specific elements in the program. And certainly managing the three of those can’t be too onerous for any organization.

Galen Low And would you say that if you have let’s say you have these three set up in your project plan, are they immoveable? A lot of folks, kind of. The way we conceive of project planning milestones are the things that can’t move. What are your feelings on on on milestones in that regard?

John Carter Well, there’s a you know, there’s the difference between a hope and reality. In the case of pure, agile software development, it is theoretically possible to not, quote-unquote, miss a milestone. But really what you’re doing is missing, not missing or moving a sprint as opposed to a milestone. And even in an agile development, there’s a notion such as feature complete, as you know, being really important. So I think that these milestones are absolutely generic and apply to any situation and really will help speed innovation.

Galen Low I love that.

I wonder if maybe you could talk about some examples just to kind of make it real for our listeners of, you know, what might a concept fit milestone be? And then what would its subsequent product-market fit be? If you have any real-world examples are for wanted to. Sure. Use a hypothetical example.

John Carter No, no. I’ve got recently set up the system. We called it the venture board. So it was a venture capital set up within a large technology organization. And we went through this basic framework. And out of it came some really interesting and concrete lessons that are specific.

One of the things that we think is really important for concept fit and a tangible example of that kind of milestone is first is aligned with the true north of the company. And so what we would do is we’d often look, create a strategic map of project ideas. And your idea might be on the map and there’d be other candidates for digital development on the map as well. The map contains two dimensions. One dimension is the alignment with strategy, the true north. The other dimension is financial impact. How much will it move the needle? And so, first and foremost, you look at concept fit is we’ve got this we’ve got this market basket of ideas. Is your idea that you’d like to develop? Is it going to move the needle and is it truly aligned with our brand? And there’s a checklist you can use for that.

And there’s a strategic map that can help you with this kind of decision with regard to product-market fit. That’s different in that that involves external parameters. You know, and I think cost of acquisition is probably the most important metric that one would be looking at in terms of product-market fit. But it also could be key understanding of the unique selling proposition. What do consumers want? You know, this, for example, goes back to my headphone experience. So I was the inventor and along with Dr. Bose, we were the first two on the patent. And when we were developing that, we were developing it for better sound. It would actually be better base, more uniform over different people’s heads and wearing situation, etc.

We put it into people’s hands. They didn’t care about that. They wanted noise reduction. And so, believe it or not, we didn’t really have product-market fit, even though we were the inventors. And so what we did is we pivoted and we thought then to maximize noise reduction, not the total balance and frequency response, all that stuff. So this product-market fit. Is really, really important, and the only way it can be truly measured is contact with customers in some form. And then the last milestone and I think the real example there is do you have a business case? In other words, does this really map out, you know, the cost of acquisition now? You know, the product-market fit, it’s aligned with strategy. Now there’s a math out. In other words, is your cost of does the margin you make from the product greatly exceed the cost of acquisition? Where are you going to need to launch the product, et cetera? And so if you can convince yourself on the math that you can do this math and you end up with a profitable high volume digital product, then it’s worth going for. And so those are the three inflection points is kind of strategic fit map. And second is acquisition cost and customer market, customer market fit. And then finally, does it pencil out? Those are three key milestones in ways that I’ve seen companies use them effectively and they’re added value. I mean, you you want to go through those any team in the scale and goes back to your point about milestones not being like schedule driven. It’s like what’s going to make this product successful?

Galen Low And what I like is that as a decision point in the headphone example, it wasn’t like, OK, well, you know, we need to start a or this is a failure or, you know, we missed this milestone. You use that as a point to evaluate the product you’re making, realized you need to pivot and then use the rest of the runway to make it something that’s actually is the right fit.

John Carter Right. And we did it early. I mean, that’s the key. That’s the key.

Galen Low I like that. I like that.

I have to ask and you brought up earlier, just with the focus on Agile, why do you still need milestones? Should have project manager planning a project using an agile methodology, still care about milestones? What do they look like there?

John Carter Yeah, so this is a common misperception and I think a really bad one, which is that agile and milestones aren’t compatible. Well, the fact is that this is a dirty secret.

Just about every company that I know, quote-unquote is doing agile has milestone. Not one but I know a dozen. So it’s this myth that’s propagated by religious fanatics, I say that with both humor and with some truth, I once gave a presentation at a Scrum Masters Group, and it was the first time ever in maybe five years that the word waterfall was mentioned in the presentations. It’s like, wow, OK, but I get the importance of agile. But it’s not in conflict with milestones. As as we talked about Galen, the fact is you need milestones to manage dependencies and any agile program of any complexity has dependencies. And as part of the Sprint zero, you do a release plan and you determine and map out what sprint these dependencies are going to come into. And those are milestones. You can call them something else. But the fact of the matter is those are milestones. And the second is any organization that’s about to invest big in any kind of digital project is going to ask the team, are you ready to spend? Is this a good investment? And that’s a milestone. So, you know, I think that it’s really a false choice. Agile versus milestones. They coexist very well. And I think the best systems are both. Use both.

Galen Low Awesome. Yeah. I know it.

John Carter And I would also add, I believe in small ‘a’ agile, which are what are the agile practices that you value that really move the business forward in ways that you think are important?

I think Sprint planning, for example, might be one demos, and customer feedback might be another. But, you know, figure out what’s important for Agile and apply that.

Galen Low I really like that. You know, John, these tips on product milestones are all really, really valuable. And I think the one that really resonated with me and I think will change how I do things moving forward is this notion of standard milestones. I had never really thought of it as a way to measure across projects as well, and also to set expectations with stakeholders and senior management about what types of things we’re measuring across all of our projects and really driving that decision making, especially when you’re about to sign that seven, eight-figure check to fund that Next piece or to, you know, order all the widgets.

So I think that’s yeah, that’s my big takeaway from this. And I think.

John Carter Great. And it’s where.

Galen Low I think for folks for folks who want to start changing the way they’re using milestones and adopt this. What is the first step that you’d recommend that they take?

John Carter Well, I think the most important thing is for them to understand as a business what are those key decisions that they need to make. You know, where are those few important points that every project really has to go through? What are the knotholes?  What are those key areas? And then agree on those and then call them the same thing. It’s pretty simple, but agree on them, call them the same thing, have every team use them. It’s a great way to start. That’s the way we scaled the Apple product. New product process was we simply agreed on what are a few milestones, what are we going to call them? What needs to be done by them? And let’s now start using that language. It’s it actually sounds very simple, but the first step is actually to adapt.

Galen Low That makes a lot of sense and makes a lot of sense, and then I guess once you’re going on this and you’re using milestones this way, what’s the most important thing to remember along the way?

John Carter Well, I think this whole notion that what we started the conversation, Galen, was this loop around trust, decision making, and monitoring. And I think if we can really engender a system of trust based on, you know, capable people running their projects and we can separate out the milestones which are simply for decision making, then we can leave the monitoring to something that’s really, really low friction and provides the executives the information they need without weighing down the team.

Galen Low I love that, I love that.

John, thank you so much for coming on the show today. I really appreciate all your insights that you’ve given us. And I think it’s it’s been life-changing for me and hopefully quite significant in terms of life-changing for some of our listeners.

John Carter Thanks for an opportunity to talk about this. You clearly know something about it. And I think you’ve synthesized the key points. So thanks for this opportunity, Galen.

Galen Low So what do you think? What are your hack’s tips and tricks for project milestones? What works? What doesn’t? Tell us a story. Where have your project milestones failed you? What best practices have led to your big wins. Tell us in the comments below. And if you want to learn more and get ahead in your work, come and join our tribe with DPM Membership head over to thedigitalprojectmanager.com/membership to get access to our experts forum master, my mentorship groups, workshops, live mentorship sessions, ask me anything, sessions, ebooks, templates and more. And if you like what you heard today, please subscribe and stay in touch on thedigitalprojectmanager.com until next time. Thanks for listening.