How To Course Correct When The Roadmap Is Chronically Derailed

Read The Transcript:

 

We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.

 

Hannah Clark: Product roadmaps, like real roadmaps, are bound to run into delays. Some you can forecast and plan around, and some kind of just come out of nowhere, but most of the time you can figure out a detour and get back on track. But what if you notice a troubling pattern; objectives are getting missed, timelines are chronically dragged out, and just seems like the whole roadmap is constantly getting derailed?

On today's episode, you'll hear from Michael Pierce, Director of Product Management at Public Consulting Group, who argues that a chronically behind roadmap could be a symptom of misalignment between the business structure and the structure of the product team. So if you're struggling to figure out why your goals and initiatives never seem to pan out the way you forecasted, this might be the course correction you need. Let's jump in.

Hello, listeners. Welcome back to the Product Manager podcast. I'm here with Michael Pierce. He's the Director of Product Management at Public Consulting Group. Michael, thank you so much for joining us today.

Michael Pierce: Yeah. Thank you, Hannah. Looking forward to being here.

Hannah Clark: So Michael, can you kick us off with a little bit about your background and how you ended up where you are?

Michael Pierce: Yeah, absolutely. Yeah. So started off with a degree in economics, like many product folks, right? We have a variety of backgrounds. I was working in a insurance brokerage and at that time, a buddy had given me a copy of the Lane Startup and I started reading it and thinking about the various processes at work that were inefficient, kind of in that maybe really immature product mindset.

And I actually ended up creating like a kind of sophisticated VBA program, taught myself some visual basic code, started to automate things. And that was kind of like the start of me being interested in, at that time it wasn't heavily popularized as it is today, but I've like product management, right?

Like talking to users, figure out what they need, try to build a solution and checking in on them and kind of throughout that process. So shortly after that, I actually created my first startup. It was in the aquatic space. So we worked with a lot of like pools city of Denver, right here where I'm from Denver, Colorado was one of our customers, which was super exciting for us, but that was really the start of my product journey, right?

Cause we talked to users, we built like kind of a roadmap. Almost like a now next later type style, right? Cause I was still very early on in my product journey, but it was kind of a great entry into that. And fast forward years later, I had an acquihire situation, moved to work at enterprise in Boston. And that was a wonderful experience. And shortly after that, I ended up in my current company, Public Consulting Group as a Director of Product Management.

Hannah Clark: Amazing. So over the length of your career, you've worked with several teams, sometimes on the team, but often leading them. So what are some of the challenges that you found somewhat endemic to product teams in general?

Michael Pierce: Yeah, so I think a really big challenge that a lot of product folks don't always recognize is like, you need to look at the company that you're currently working at and try to define, I'd say two big buckets. So one is, are they sales led, right? Are they finance led, marketing led? And we've all seen great examples of this.

Like if you look at HubSpot, have you on the marketing front, they're definitely a marketing led company. You look at a company like Zoom or Slack. They're classic examples of really strong product led growth and product led leadership. And so where it's really important, I think, for product teams to look at their company and think to themselves, Hey, is this CEO often meeting with the sales department and do they have a very tight relationship?

Or did some of the company leadership come up through operations or through sales or whatever function and that often can be a clue to how does the company operate? And I'd say the other important thing that product teams should do to really look at or understand the culture of the company is think about how big decisions are being made.

Is it completely top down? Is it maybe some of the top leadership and they socialize with some of the other managers and executives? Is it very democratic, right? So kind of understanding the structure of how companies make major decisions is something else that's really important. And I think if you know those two things, like if you're sales or finance led and the kind of structure of decision making that could really help like a product department know, like, okay, how do we fit into the overall picture and how are the dynamics set up in a way that we can navigate?

Because if you just ignore all that information and just go about your day as a product department, you might find yourself straight with a lot of blockades and challenges because you're not, I guess, positioning yourself the right way to influence others in the organization.

Hannah Clark: So, like, let's maybe frame this with an anecdote. What are some examples of ways that misalignment where the product team sees themselves versus how the business actually functions can kind of cause some issues later down the road?

Michael Pierce: Absolutely. I think if I understand the question correctly, I think one example of that would be, you know, right now there's a lot of energy around product led growth, right?

And I personally love product led growth. I'm biased a little bit, but I think if the product department is operating in a way that's maybe very heavy on the product led growth front but the actual company, let's say, is very sales led growth, that's going to cause a really big misalignment in terms of initiatives getting funded, in terms of getting buy in across different departments.

So, again, it's really important to recognize your place as a department, as a function, relative to all the other functions as a way to calculate your moves as a team.

Hannah Clark: So let's talk a little bit about prioritization and the challenges that come with. And I think that this is something that every product team struggles with to some extent, regardless of what your growth model is. What are some of the challenges that you've seen in terms of prioritization through the companies that you've worked for?

Michael Pierce: Yeah, I think two things come to mind. So one of the big things that come to mind is often there's a gap between, I'd say the ideal state or the wishlist kind of mentality about what we're building compared to the reality of it.

And so I think one challenge of prioritization is, when you're dealing with boards, when you're dealing with public companies, investors, I've worked for some companies done by PE firms. They could be a lot of pressure to have this huge roadmap that has all this fun, sexy stuff, right?

And so I think the challenge there is really bringing everyone back down to earth, but in a way that makes them feel good about it. So really, when you talk about prioritization, a level setting on, I'd say the higher level pieces of that. So prioritization comes once you know, Hey, like this is our vision, this is our North star.

You have to have those upper level things to find to have that effective prioritization, which is maybe the other pitfall rate. And I'd say like, once you align stakeholders and executives around, Hey, this is our vision. This is how we're going to measure success, with our North star, with our KPIs, you know, OKRs, et cetera.

It's a lot easier to have a healthy prioritization process and shift away from that kind of bloated wishlist mentality and shift towards something that's a lot more crisp, right? Maybe there's lots of items, but they're very well defined. We know as an organization, Hey, like these four major epics or initiatives are heavily tied to these two OKRs that we know the CEO and the organization really cares about. So I'd say like, that's the way I at least think about like the prioritization problem.

Hannah Clark: So in a prior conversation, you shared with me an anecdote about doing an analysis of a company. We won't say which company, but there was some issues with misadjectives that you were asked to identify the reasoning for. Can you tell me a little bit about that and kind of recap what that anecdote was?

Michael Pierce: Yeah, absolutely. This was a case where the company was missing a large portion of the roadmap items and they wanted to know why, which is a totally innocent and good question. And as a product person, I kind of see the roadmap is like it often or like the work getting down on the ground is often a result of a lot of other processes, right?

It's the output of a large box of complex interactions and inputs going into that box. So one of the first things I did is I started peeling back the layers to understand, okay, well, if we're missing 50% of the roadmap items, what are the root causes of that? Right? So one of them before I got further into my exploration was around, all right, well, do we just have too many roadmap items?

Because if you have a roadmap that say, let's say it takes 2000 hours, but you only have 1000 dev hours of capacity, clearly you're going to miss half those items. But as far as I could tell, there was enough engineers and QA folks and all the supporting staff to execute on that roadmap.

So then I dug deeper to really understand, okay, well, why as a company are we still missing a lot of those items, right? And as I did my analysis, I discovered a couple things. So one of them was dev teams were set up in a way where they're shared across multiple products. And so as a product person, the challenge of creating a good roadmap is you need to have confidence that, Hey, we have these five fixed resources.

These five engineers work on this product and they're working, let's say 40 hours a week. Maybe they have 30 hours a week of efficiency cause there's distractions, right? Slack messages, emails, whatever. So you can kind of look at that time and project it or forecast forward and figure out, Hey, what's the likelihood, like 80%, 90% that we're going to hit this roadmap?

But the big challenge with shared development is if there's one fire on another product, or if you land a massive contract, let's say on one of your products in your portfolio, that can derail the broader company's roadmap and that specific product's roadmap heavily. So that was kind of one root cause I found was that shared development. The other big root cause that I found was there was a high volume of unplanned work and defects. And so those were things that the roadmap was created, there's a high rate confidence that it could be followed through.

But as teams encounter issues, like maybe there's a big dependency that needs to be upgraded, right? Or maybe there's a big contract one and you had to pull resources or some code went to production and a bug was found, right? Like all those things are things that can derail a roadmap completing. And as product folks, we know there's so many variables out there, so you always try your best to figure out which variables are fixed, which variables are dynamic, and then back into a production.

But as you increase the number of different variables, you're decreasing your probability of successfully completing that quarter or that fiscal year.

Hannah Clark: And that's just talking about what's on the roadmap. We're not even talking about the issues that that can cause with regards to innovation or anything that's coming next.

Michael Pierce: That's right.

Hannah Clark: Yeah. So what do you think are some of the ways that we can protect the roadmap? Now we've accounted for all the time that we need to execute on the roadmap, but then there's also this time that we know that we're going to need in the future to innovate, to create new features and to respond to features that the sales team wants done for a certain client. What are some ways that we can protect the roadmap in that way and protect time?

Michael Pierce: Yeah, I think that's a great question. So I think the first step I would suggest to a product person is to say, Hey, look at the historical quarters and kind of get a good baseline in your mind around the classic term, like yesterday's weather. So if last quarter there was 20% bugs, 20%new sales feature request, 10% rate innovated bets, then you can kind of use the sum of that to forecast your future roadmaps.

But I'd say a good way to align on the roadmap as an organization is to socialize the idea that a roadmap should be a well balanced diet, right? So like you have, let's say 40% new features you have based on that historical data, right? You have 10% or 15% time on defects. You have maybe a 20% flux around a big sales request that might come in.

And you can kind of back into a nice ratio of what tickets should be worked on in what kind of proportions, just like a diet. So I think that's a really good first step for product folks is to just make sure that there's like the right ratio and that you communicate that to stakeholders.

So they're not caught off guard if 10% of the engineer's time is spent to some kind of interesting bet or, more blue sky feature because it's already been pre-socialized. And that allows teams, I think, to have a lot more empowerment to respectfully say no to say, Hey, like, we would love to do that one extra tweak to this feature, but we're committed to 10% this quarter of our capacity to explore a new function that might really help sales next year. So I think, again, everything goes back to expectations. I think for teams and product folks with upper management or different stakeholders.

Hannah Clark: Speaking of teams, what's the relationship between the way that teams are designed and the impact of what gets prioritized and shipped?

Michael Pierce: Yeah, so I think that kind of goes back to what we originally were talking about with like product led or sales led. I think often you can look at the way teams are designed based on the culture of the organization.

So if the organization has very aggressive sales culture, I mean aggressive in a good way, right? Like they're trying to win tons of new business, you know, there's a lot of energy around it. That's going to impact how teams are designed, though to some degree, because maybe you're going to have a lot more feature development work, right?

And you're going to have to have some dedicated teams that just do customizations for clients, let's say. So I think a lot of the team structure will inherently come from what the organization or the company values, whether it's sales or finance or product kind of first thinking. And what their kind of thoughts and values are around net new work, or greenfield functionality.

All those things can kind of impact how a team is designed. Also, it may be a good topic to talk about here is what structure do you have in place to execute work? So we're always hearing about Agile, right? And in the past, we had more Waterfall companies and there's a variety of other ways that firms to get organized.

And so I think that's another big thing with team design, is understanding that landscape of, you know, are we a very Agile first culture? Are we somewhat Waterfall? All those things will kind of impact the makeup of a team. But again, once you understand that, I think as a product person, you can now kind of be an advocate for where you do see gaps being able to say, Hey, I understand that we're heavily Waterfall in the past.

There's this new product that we're going to go to market with. Like let's experiment with using an Agile process here, or switching to a dedicated engineering team versus shared engineering team. So just having that contextual information, I think is really empowering for product teams.

Hannah Clark: Have you had that kind of an experience before where you've had to experiment with restructuring a team to match the way that the company needed to function?

Michael Pierce: Yeah, absolutely. So last company I worked at was a private equity company out of Boston. They recruited me to build a product department from the ground up.

And part of that was I looked and analyzed how all the teams were doing work and how they're organized. And we had a couple of different products that I company and effectively there was, I would say it was a little bit Waterfall and a little bit messy. And when we really analyzed everything and I talked to the owners and the CEO, I said, Hey, like, kind of appears that there's an opportunity here to restructure how our teams are operating in what little groups right there functioning toward the value of the overall kind of portfolio of products.

And it was a great experience because we've got the opportunity to roll out Agile across all the teams. We got the opportunity to cluster different groups together in terms of platform teams versus teams that work directly on the products. And empower some folks to be more like technical PMs rather than a classic PM on a standardized kind of SaaS offering.

So that was a fantastic opportunity, I think, as a product person to look at holistically how things are structured and be able to suggest and recommend folks around the best way to structure teams and to measure the before and after was really cool, right? I've seen the improved efficiency of having daily standups, of having sprint demos, all these things had a really positive, meaningful impact on the organization. And at least that's the best thing we can ask for as product people, is to be able to make an impact and to measure that impact.

Hannah Clark: Absolutely. So having had that experience, could you recommend any, or do you think of any red flags that product people, especially leaders, should be looking out for that might indicate that it might be a good idea to start restructuring or thinking about restructuring the team?

Michael Pierce: Yes, absolutely. So I'd say one of the red flags is you have to get data around these things. So, one of the flags would be looking at the total time it takes to get from idea to production. If that is very heavily delayed compared to the norm, and it is tough because there's not necessarily a lot of published norms around these things. But let's say there's some new feature development work on something that's a bit smaller and it takes two weeks to get to production.

That's pretty good, right? Like the average sprint cycle is like two or three weeks. As a product person, not necessarily see that as a red flag, right? But if you're looking at a small piece of functionality, and again, let's say it takes 40 dev hours, right? But to actually get to in production, you're looking at five, six, seven, eight weeks. To me, that'd be a red flag that, Hey, the way things are structured, maybe there's a bottleneck in QA, or maybe there's a bottleneck with getting the right stakeholders inputting into that epic or the FRD.

Those to me would be kind of indicators when you think again of the whole system as like a box with inputs and outputs, it would be indicators that the outputs don't match what you would expect in terms of a normal baseline.

Hannah Clark: So how would you measure the success of restructuring teams?

Michael Pierce: Yeah, so I think there's a variety of ways you could do this. So, the classic ones are looking at the team's output. Are they outputting more increments of value to the end customers in a shorter period of time? Another classic one would be, are we reducing our time from idea to production?

Are we getting quicker and more Agile, for the pun, at getting the work from point A to point B? And I think maybe another way that's often overlooked is to do a combination of one-on-one conversations, checking in on folks and kind of reporting those findings back up to the executives, as well as just a classic survey of measuring the before and after the restructure of, how did team members feel?

Do they feel like they're less pulled in different directions, so contact switching? Do they feel more empowered to make the decision with the right folks to get work out the door? These are all great indicators around that restructure and whether or not it took, and whether or not there's positive results from it.

Hannah Clark: Awesome. If we can kind of put a bow on that, what were the results of your experience having to restructure the team?

Michael Pierce: Yeah, it's great question. So one thing that was apparent from the get go, when I talked to folks was the gap in having a shared understanding about questions and about ambiguity in the work that the team was doing was heavily reduced because they were meeting once a week before I came to the company.

And as we restructured, we're doing daily standups. So, the team was really able to get their questions answered every single morning from the right folks. And that really increased the output of work, but also decreased, I'd say, the anxiety that the developers had because they weren't sitting on questions for a week.

If they weren't sure about something, it was just that next day that they could hopefully get an answer to it. Not in all cases, but in most cases, and I think that made the team feel a lot more supported overall in the organization.

Hannah Clark: So just to finish off, let's talk a little bit about getting buy in from higher stakeholders. So what are some of the ways that you've been successful in kind of proving or giving some indication of proof that restructuring is going to be worth that initial runway?

Michael Pierce: Yeah, so I think a big part of restructuring is when you think of the, I know I hate to call it a black box, right? But when you think of all the complexities that happen to get from point A to point B when you're doing software development, because software is messy, right?

It's complex. There's all kinds of twists and turns. And so I think when you think of restructuring, it's important to talk to the execs and higher up stakeholders about like, well, what is the actual outcome? What are the OKRs? What are the key results you're trying to drive for the organization?

And then you can use that as a benchmark or a baseline for the effectiveness of organizing work. And same is true just for measuring work altogether, it's all about knowing where the baselines are and measuring against something so you can see how closely you achieved that goal.

Hannah Clark: Awesome. Well Michael, thank you so much for joining us. I know that you're a contributor at The CPO Club. People can read your work on TheProductManager.com, but what are some other ways that people can find you online?

Michael Pierce: That's right. I would say the best way to find me online is through LinkedIn. I'm a digital minimalist, so I only have LinkedIn. But if you message me there, I would love to have a virtual chat with any listeners of the podcast.

Hannah Clark: Awesome. Well, thank you so much for your time and I really appreciate your insights.

Michael Pierce: Absolutely. Thanks, Hannah.

Hannah Clark: Thanks for listening in. For more great insights, how-to guides, and tool reviews, subscribe to our newsletter at theproductmanager.com/subscribe. You can hear more conversations like this by subscribing to The CPO Club, wherever you get your podcasts.