Introduction
Welcome to this video from SPK and Associates. My name is Michael Roberts, VP of Sales and Marketing for SPK and Associates.
Hi, I’m Chris McHale. I am co-founder and CEO of SPK and Associates, and we are an IT services company that focuses on accelerating product and software development and delivery. I’m here with Chris to talk about the domino effect of late-stage product changes. None of those domino effects are good.
Minimizing the Impacts of Late-Stage Product Changes
No, but hopefully we’ll be able to provide some general guidance and best practices around helping address those things. So, Chris, let’s start off with your experience. What strategies or methodologies can companies implement to effectively manage and minimize the impact of those late-stage changes to product timelines?
Lean Startup
Sure, this is a loaded question. There’s a lot more involved, probably a lot more than meets the eye. But first and foremost, I would say that adopting an agile, almost a Lean Startup project mentality, even if you’re in a larger company when doing product development, is absolutely key.
A person I like to follow and read a lot about is Steve Blank, who basically started the whole Lean Startup movement. One of the key things is to make sure that you’re going to your customer, your potential customer, super early and understanding what they need and want before you get going on anything. So, in the spirit of agile project management, instead of more of a waterfall methodology, make sure you’re going quickly, frequently, and often to the client or prospective client to find out what they really want. We often think we know what they want, but we don’t. If we’re doing that early, we’re going to have a lot fewer of these late-stage changes. So, that’s first and foremost.
Adapting to Clients
But the world is not perfect, and we often find out things later that we didn’t know early on. Sometimes we have a couple of prospective clients or customers we’re working with, and they’re giving us guidance, we’re following that guidance, and then we find out later they’re outliers—they’re not really what everybody else wants. Then we do need to make a change.
But if we’re following something like an agile project management methodology, we’re going to be much more able to make quick changes to our requirements. Since we’re doing everything incrementally and trying to provide product and software updates incrementally, we’re going to be able to pivot much more easily if we’ve approached it in a specific fashion where we’ve boxed up and are incrementally trying to do development, as opposed to some big, enormous waterfall-type project. When we do have to make those pivots, we’re going to be better able to actually make them.
And then just a few other things: ongoing communication, constant communication within the product development team, between the product development team and the stakeholders and the potential customers, is absolutely key and critical. So when things do happen later on and we do need to communicate those changes, and sometimes those mean delays or cost overruns, we’re going to have that relationship with these various people in the team as well as the prospective clients and stakeholders. That message is a little bit easier to deliver. So those would be some things I would say.
Preventing Late-Stage Product Changes
Awesome. And I think in the process of that answer, you actually answered my next question, but I’ll ask it anyway because I think it’s a really good point to overemphasize. So you talked about the communication loop and making sure that the stakeholders, the product teams, and the engineers are all communicating on a regular basis. Is that your top recommendation for how to handle the passing of the baton and hopefully not having that late-stage problem?
Communication
Yeah, I would say how you do that is actually pretty important. We can all say, “Okay, we should have ongoing communications, and here’s our cadence for communication,” and all of that. I think everybody tries to do that, but I think how you do that ends up being really important. First of all, frequent communication, so the whole effort to have stand-ups on some ongoing, pretty frequent cadence, is really, really important. A lot of times, engineers don’t really want to do that because they just want to work. But it turns out that taking that time, you find things out in those conversations that you have—not the email exchanges or even updating JIRA tickets. But having those conversations, something comes up that alerts somebody to a potential problem.
We’ve so far been talking about customer-related changes, but they could be supply chain-related changes and things like that, having to do with what’s going on in the product development cycle. But having those really frequent stand-up communication channels is, I think, really important. Making sure that they’re cross-functional. So if it’s a development team, it’s typically just a development team that’s working together and having the stand-ups. But make sure that you’re having the once, you know, like post-sprint, for example, retrospective, or you’re having a once-a-month cross-functional meeting where you’re pulling in people from marketing and sales and support and finance or whatever else is required. That’s really important.
Creating Relationships
And the thing that happens here is not just talking—it’s that you actually have relationships with these people. These are people that you’re used to talking to. You have a relationship with them. They understand that you mean well, and they mean well, and that can get away from finger-pointing and things like that that might happen when the crisis happens.
We are all human at the end of the day.
Yes, exactly. And then that sort of thing tends to lead to a lack of trust and then a lack of a good opportunity and methodology for solving the problem.
Yeah, humans first, right?
Yeah.
That always helps a lot. And as you said, when you’re communicating on a regular basis, it makes the bigger problems seem a little bit smaller because you know each other as a group, and it’s not a one-off, weird meeting with people you haven’t met before. Awesome, thanks for that.
Yeah, where you’re actually trying to figure out what your relationship is even going to be before you can get on to solving the problem. But if you have that framework already…
Right.
Resolving the Domino Effect of Late Stage Product Changes
Okay, Chris, so last question here. As we solve this domino effect of late-stage product changes—we’re going to solve it in this video—how do we better integrate flexibility and the agility that you mentioned into project planning and the execution phases to help accommodate those late-stage issues without really impacting the product itself? Any insight there?
I would say that incremental approach that I mentioned before is really key. The more incremental you can be, and the more you can modularize—if that’s a word—the way you’re approaching a product or software development effort, the more likely you are to be able to make adjustments and pivots without there being a huge redo of a bunch of work. I think empowering the teams, making sure that the people who are doing the work are really empowered to make suggestions as to how the changes should get addressed, that they are listened to, that their voice is really honored, is absolutely key.
Everybody says that, but egos and pride get involved. I think a lot of times people who are managing and leading a team suddenly feel like they have to solve this problem and don’t know if Joe is going to be able to give good insight. Listen to Joe. Listen to the person that’s on the front line, if you want to call it that. They have the best ideas because they’re doing it every day, and if you really give them the permission to step back and look at what they’re doing and make appropriate changes, they will give you gifts that will help immensely.
Agreed. Giving the people that are closest to the work the opportunity to solve those problems is one of the biggest impacts. Definitely agree with that.
Yeah, absolutely.
Conclusion
Thank you, Chris, for joining us today. Appreciate your time. And thank you for watching this video. If you like this video, please hit like and subscribe for more great content around accelerating your product development life cycle. Until next time, thank you. My name is Michael Roberts. Look forward to seeing you again.
Hi, thanks a lot. I’m Chris McHale, and thanks for watching.
