Adapting to Agile with John Feeley – Masters of Product Management
Whether you’re on the road or away from your desk, you’ll want to stay connected with innovative ideas from Sequent. Our Masters of Product Management podcast provides listeners with engaging topics to help you think differently and about things you encounter daily, but often don’t have enough time to reflect and take action. Get your dose of insights, in just 15 quick minutes by tuning into the Masters of Product Management podcast.
All companies want to act with agility and compete more aggressively in the battle for the hearts and minds of customers. Yet, large companies that are shifting to rapid or agile development continue to struggle with complexity, role definition, and adaptation to agile methods. In this episode, Steven Haines speaks with John Feeley, a product director who has insights to share about agile transformation. Hosted by Steven Haines of Sequent Learning Networks
Key Points:
-
A lot of companies are struggling to implement Agile in a way that is productive and effective, since they are more accustomed to Waterfall.
-
Some people use the tongue-in-cheek term “Wagile,” implying Waterfall planning, but Agile development. This happens when they can complete parts of the development process more slowly; while needing to be more adaptive to changing requirements in other ways.
-
As companies adapt to using Agile methodology, we see shifts in roles and responsibilities, and fuzzy boundaries—product managers are doing product-owner jobs, and product-owner jobs are rudderless and being directed by the development team. Changing from Waterfall to Agile is a huge culture shift within a company.
Transcription:
[00:00:16] Steven: Welcome back, everybody. Today I want to talk about speed. For me, it’s a given that every company wants to do things faster; they have been wanting to do things faster for decades and decades. Recently, I did a podcast on the use of design sprints and it’s a technique used by companies to just rapidly vet product concepts.
I’m sure that you’re familiar with some of these. And, of course, more companies are evolving to, or are just using, iterative development techniques like Agiles and other techniques. And it’s to get full-blown products, or what I call “the bits of products,” out the door.
So, at my company, Sequent Learning Networks, we really know that large, complex firms have made a shift—or some of them are in the process of shifting their focus from more of a linear Waterfall development to Agile or some iterative development. Even some companies are using some hybrid approaches.
[00:01:14] Steven: Recently I’ve heard the term “Wagile,” where the business-end of things and the upfront design gets done upfront—maybe in a more linear or slightly iterative way, and then development and validation is done iteratively.
And in other companies—very fast-moving firms with especially large web presence and things like that—are using this continuous-integration, continuous-deployment technique: the CICD train, as I call it.
[00:01:41] Steven: So, regardless of method, a lot of companies are struggling to implement Agile in a way that is productive and effective for them–I guess, from a point of view of the process, and even from a staffing point of view. And this is really the point of this show. And I’d like to introduce you to my guest, John Feeley.
But before we say hello, John is currently Director of Product Management at a pretty good software company in California, and he’s got a new role. He’s about to stand up a new product management group in his company.
And he has come into that role as a strong leader and a visionary with probably more than fourteen years of experience in product management, with background across business function, sales marketing, software development— especially with an emphasis on Agile transformations—which is why I think it’s going to be a great show. So John, welcome to the show today.
[00:02:34] John: Thank you for having me on, Steven. Appreciate it.
[00:02:37] Steven: It’s great. So we had a really interesting and robust talk the other day, and we were talking about how companies are shifting to Agile. And you mentioned to me that some companies are struggling, and it’s something that I’ve seen as well. Could you describe, from your point of view, what you’re seeing?
[00:02:55] John: Yeah, it’s a tough shift because shifting to Agile, for any company, has been a culture shift in how you operate. You used the term “Wagile” before, and I’ve heard a lot of people use that as kind of a tongue-in-cheek, basically saying, “We’re going to do Waterfall planning, but Agile development.” And it’s very difficult, for typically senior leadership of a company, to wrap their brain around the concept that, just because you can turn on a dime with Agile development doesn’t necessarily mean you should always do that.
[00:03:37] John: In the difficulty for product management in particular, there is a lot that goes into the old Waterfall process of doing things, in terms of requirements, documents, and vetting all these things out. And having all that information upfront before development starts–it doesn’t make the product manager’s job any easier. The only benefit you gain is a potential shift in direction when you’re using Agile development. Sorry—
[00:04:13] Steven: I breathed. Sort of the sharp intake of breath before I went to say something, but I didn’t! [laughs]
[00:04:20] John: [laughs] So I mean, it just becomes difficult in terms of adopting a true Agile approach to a market place, for example, from the executive point of view. Some of the other things that I’ve seen is difficulty, in terms of Agile process in general. A lot of us are using offshore teams now.
And the whole point of Agile is to–they say, when you go through Agile bootcamps and training, face-to-face communication is best. Second best is voice-to-voice–you know, chatting over the phone or something like that. And the least effective form of communication is email. And when you’re working with offshore teams, there’s typically a huge time difference.
I’ve seen this in my current company—it’s really a struggle to adopt offshore effectively and still maintain that nimble Agile approach. We lose a lot of time in communications. And unless you have someone that’s willing to work those flex hours, whether that be on the offshore side or onshore, here, it’s a very difficult balance.
[00:05:33] Steven: You know, it‘s interesting—there are a couple of key points that I believe I heard you say. Number one: there is this leadership mindset, that they have this broad base of expectations, but they may not be seeing it all. And then there are these cultural dimensions, or even organizational design dimensions, where it’s almost standing in the way.
As I understand it, you want to develop something quickly and get it tested and validated with a real customer. If somebody is far away, or you’re in a time shift, how do you take advantage of that?
And I think that could be problematic. So, I understand that; but there’s something else: talking about getting some validation. We were talking–again, a week or two ago, about some things that are going on with product managers versus product owners. And we see shifts in roles and responsibilities, and fuzzy boundaries where product managers are doing product-owner jobs, and product-owner jobs are rudderless and being directed by the development team.
I see all this stuff is so variable, and I don’t know how anybody gets anything done with that degree of inconsistency. What are you seeing?
[00:06:48] John: I’m seeing that exact thing. Right now, I think, because Agile is “new” to a lot of leadership teams, they’re struggling to figure out what role the product owner really is. There is some overlap of product owner with what product managers typically do, at least in my experience. And there’s an ongoing—I don’t know if it’s an ongoing debate, necessarily; but it’s really an open question as to…are product owners and product managers interchangeable?
Is it the same role, or should it be two separate roles? And I think the answer is a little bit of a copout, but I think it depends on your organization. It also depends on the size of your company, obviously. If you’re a smaller company, I think you can definitely get away with the product owner and product manager being that same individual.
But as you grow into an enterprise-size company—several hundred employees—maybe you have a fairly mature product and product team. You really, I think, need two distinct roles.
[00:08:00] John: It depends on how your company is also organized. I can give you an example from my current life: our product owners are basically embedded with the development teams specifically—which sounds great on paper, because now you have this product owner that’s just lock-and-step with the development team through everything that they do; but that person is actually functioning more like a project manager, or even a BA—a business analyst, in that case. Their role basically becomes just managing the dev team day to day.
They’re down in the weeds. They’re writing requirements or answering very specific questions or making some decisions. They’re not one step above looking at it from a market point of view. And that’s where I see the product manager role being separate.
They need to be out of the weeds, and they need to be looking at market trends and doing the competitive analysis. And they can’t be embedded with that team day to day, doing stand-ups necessarily.
They certainly can participate, and they’re a valuable component of that sprint planning and product definition; but really, that product owner role becomes a very functional scheduling role because they are embedded directly with a specific team.
[00:09:23] Steven: You know, what’s interesting is that in some companies—this is what we’ve seen—when you have a product manager who gets so stuck into the product owner role, they don’t get a chance to get out of the weeds and they become extremely tactical.
They get very, very frustrated. And even though they’re called product managers, they’re literally doing that development team handholding.
Something else that we’ve started to see as well, where some companies, as they’re beginning to mature, are recognizing they can’t have two human beings associated with the same product. And they’re trying to find some hybridized approach where the product manager may not do a daily standup; and they may not be releasing things as rapidly because they just can’t. There’s a lot of integration, and things that have to go along.
So they’re doing some of these weekly meetings, either in person or even remotely, but maybe only doing a couple a week because they’ve got to be out and about and seeing customers and things like that. Can you comment on that?
[00:10:29] John: Yeah. I think you nailed it in the way I equate it–whether it’s right or wrong. That product owner, like I said, is aligned with the team.
Where I look at product managers being aligned with a marketplace or a customer–and that, to me, is the best place to start delineating: “OK. Here’s what the product manager is supposed to be responsible for. Here’s what I expect out of my product owners.”
And certainly, there’s going to be some overlap in there, in terms of specific requirements—generation and things like that—because obviously there has to be some collaboration there between those two. I think those two roles need to be connected at the hip, as it were, because I envision multiple product managers working with maybe a product owner.
If you have an organization like mine, we have siloed development teams. We have specific teams that are responsible for specific functions of the application, where a product owner, like I said, is assigned each one of those teams.
Me, as a product manager—if I have very specific requirements, or if I have a specific market need for an application, for example, I may require work from three of six teams, as an example. So, I’m going to go to three different product owners and say, “Okay, from your team, I need this.
From your team, I need this, and from your team, I need that.” Each of those product owners, being the experts with their team, specifically in that area, they can kind of figure out the down-in-the-weeds details. So, that’s where I start to separate the two.
[00:12:18] Steven: Sure, sure. So that’s one set of things I wanted to talk about. And I had another—of course we have an agenda here!
[00:12:28] John: [laughs].
[00:12:28] Steven: We have to, so we could be efficient, of course, right? Because the name of the game is speed. And we can’t do that many takes because we can’t iterate! So anyway, we were talking about product requirements, and I know you mentioned that just a little bit ago.
I’ve heard people say, especially in big companies that are trying to minimize documentation and these artifacts, are saying we don’t need a PRD; the PRD is dead. And I say, “Well, maybe the 3000-page PRD is dead; but we’ve got to have some baseline for non-functional requirements and things like that. What’s going on today, from your point of view, with respect to this PRD?
[00:13:12] John: I look at a PRD and—I do agree; I think the days of the 3000-page document that no one wants to read are dead.
[00:13:20] Steven: I wouldn’t read it. [laughs]
[00:13:24] John: I don’t. And I don’t want to write it, for that matter. I think with the Agile—in respect to Agile, there are certain levels of requirements. And so, the way my company looks at them is that they’re called Epics. So an Epic can be any size. And an Epic you can think of as a project.
An Epic is comprised of multiple features themselves. Say an Epic is a web application that’s supposed to collect someone’s information and add them to a mailing list, as an example. I would break that up into several features—say, “Okay I need a feature where it collects the form fields, and I need a feature for a submit button.” Each of those features are then made up of user stories.
[00:14:13] John: So you get that Waterfall effect of breaking down an application or requirement. That’s where I see Epic replacing PRD in that sense–where that’s where you would generate a lot of this detail and say, “Okay, I have this big Epic. I need a web application that collects all this information and so on and so forth.”
Now, does that mean you’re not going to write any sort of external document—whether it’s a Word doc, PowerPoint, or whatever? No, probably not. ‘Cause odds are, you’re going to have some sort of one-pager typed materials that you’re going to have to probably get—as a product manager, get buy-in from business, get buy-in from executive teams and marketing teams, and whoever your stakeholders are.
So you’re probably going to have a lot of artifacts that, I would argue, you can kind of combine together and call the PRD. But I think you’re right; the days of the 3000-page document are done.
[00:15:15] Steven: There are two dimensions that I want to comment on. One is, in one of our product management workshops, we came up with this notion to capture this thing called an Epic. We actually came up with the term “user storybook.” And what we did was, we said, “You know, you can create a user story, which is a depiction of one little journey, or mini-journey.
And when you write a book–which I have a little bit of experience in—you write a chapter, and then you write another chapter, and then you realize that there was something that you had to change in the previous chapter, so you go back and forth and back and forth.
So you’re in this continuous mode of editing. And that this idea is you still want to create a complete storybook, which really captures the entire journey. So that actually could be the Epic that you referred to. And I know that because used in the Agile world is just the idea that a story can be edited over time. And I think that’s important.
[00:16:15] Steven: But on the other side of the stick, I think that somebody—and I think somebody in product—needs to still own things like performance and capacity and safety and security and stuff like that, at the non-functional level, which may or may not be—I don’t think they’re captured necessarily in the user story. So do you have any sense of how that’s done in an Agile world?
[00:16:42] John: No. I agree with, yes, the notion that it does need to be owned; and in my current world, it’s just expected that the product managers all shoulder that responsibility themselves to make sure that security and all the performance is just inherent into the application. Part of it is also in going back to our initial discussion of speed.
We have a separate department set up for load-testing and things like that. And especially my current company—we are very peak-driven. We have holiday peaks drive our entire company.
And so there are eight months out of the year where we have much lower traffic; and then as we get closer to holidays—you know Christmas is coming up right now—we see a huge, huge spike on our system.
Same thing with Valentine’s Day and Mother’s Day. So performances of—we actually have a performance lab set up and making sure that our systems will still be standing under peak loads.
[00:17:57] Steven: And that’s important because it’s inherent in the business, which we’re not talking about, but maybe people can guess. I want to talk about something else, but also want to be cognizant of our time because we try to keep these casts at about 20 minutes or less, just because of the short attention span—people have things to do.
And so I’m going to skip over the thing related to continuous integration and continuous deployment; but I might want to take that up as another topic with you, possibly some other people as well, because I think that there are some companies who are operating in that model.
[00:18:36] Steven: It’s amazing and I think that we can have conversations like this, and I hope that people are continuing to have conversations like this because we have a lot of opportunities in front of us: the opportunities to go faster and to be more—I like to say the word fleet-of-foot, which is like the analogy of a sports team; and you encounter obstacles, and you’re pushing along, and then you pivot and you move.
That’s the kind of thing that we’re trying to do—that kind of blocking and tackling on the competitive playing field. And I think that iterative product development techniques allow us to do that.
But an organization has to adapt from a holistic perspective, and it can’t just be an edict from the top of the company that says, “Thou shalt go faster!” and not provide all the enabling tools, in terms of organizational design and that’s it.
[00:19:25] John: Exactly.
[00:19:25] Steven: That’s why we’re doing this, because I think that we were finding some equivalent thought on that. But I will leave this with our listeners and that is, do keep this conversation going.
I am hoping that others will want to join in on the conversation and reach out to me—either through LinkedIn, or through my company’s Contact Us page at Sequent Learning Networks, because what I really want to do is I want to expose some of these things. I want to almost take a therapeutic stance on this and say, “Listen. This is an imperfect world, and we have a lot of different challenges.” And if people have some tricks, or some techniques, or some things that they’ve learned that helped them adapt and move quickly and make their customers happy, and make great products, I’d love to hear from you.
And I really hope that this is the first in a line of broadcasts that we do that really focus on this. And with that, I thank John for joining us today, and hopefully we’ll hear from him—and perhaps other colleagues—and some of you out there, as we focus our effort on Agile transformation in Masters of Product Management. We’ll see you next time. Bye bye.