One of the most frustrating things I’ve heard over my career is that “agile is something that software developers do.” It is said dismissively by those who are happy with how things are today and see no reason for changing how they operate. It ignores all the success agile teams have had in software the past decade and in other industries including architecture, marketing, video production and even the auto industry.
I’ve had the pain and pleasure of running both software-development and product-management teams for well over two decades—sometimes both at the same time. After being involved in the agile transformation of almost a hundred teams during this time, I can attest that agile truly works and I can’t imagine ever going back to traditional waterfall. But for agile to work, product management must focus on these two key C’s: courage and customers.
C is for Courage
You have to have the courage to make hard decisions, especially when prioritizing the features within a release and defining the minimum viable product.
Before agile, this was very difficult. We had our list of features, and we made them fit perfectly into the appropriate swim lanes of our PowerPoint presentations. It took quite a large chunk of our time to lay it out in a way that was compelling and showed the promise of a coherent strategy.
After creating a product roadmap, which clearly showed the priority and features for each major release, why would research and development (R&D) need product management to waste time on the prioritization of the features within a release? The list is the list, right?
The ugly truth, and we all know it, is that R&D under waterfall was rarely able to complete a release as defined by the roadmap.
I once took over an organization where every release was a battle, with tons of infighting. Why? There were always serious tradeoffs that had to be made once the software-development teams came nearer to the scheduled ship date. R&D managers became the captains of “we can’t.” And that forced their product-management partners to ruthlessly decide which partially completed or not-even-started features to cut to meet even some of the major commitments that had been made. It was always at the end of the release, and product management often felt as though they had a proverbial gun held to their heads by R&D. At the end of the day, product management believed it was settling and that R&D was driving what features made it into the release. In this organization, product management had courage, but it was courage in battle and in finger pointing versus courage in planning and execution.
To attempt an armistice, the R&D teams held out an olive branch: Prioritize your features, and we’ll ensure they are completed in that order—sparing you those last-minute hard decisions of which features to keep or jettison as we rush to complete the release. But product management simply refused to prioritize their features. They dug their heels in, sending their software-development manager a spreadsheet that had everything marked as “high” or, my personal favorite, “must have” in the priority column. The response from the software-development organization to their unprioritized list came across as Draconian:
“Spreadsheets have rows and, unless you explicitly state the priorities without any ties, we are using the row numbers as the priority. When capacity runs out, that is the cut-off line. If you want to change your mind and add a new requirement to the release midstream, it will insert a new row in to the list and all those rows below it get pushed down on the list. This will cause one or more items you thought you might get below the cut line as the team runs out of capacity. It is what it is. Deal [with it].”
R&D saw product management as lacking the courage to prioritize and absconding responsibility. And R&D, lacking courage to work with product management in true partnership, chose instead to let the rows of a spreadsheet step in as the proxy priority. As with most dysfunctional teams, each side continued to play the victim and with less than spectacular results. There were incremental improvements, but only in that it became much more visible what capabilities would be delivered in what order.
After introducing agile into the organization, things took a great turn for the better, albeit after a very rocky start. Agile forced the priority discussion with each and every sprint or iteration versus only at the beginning or end of a traditional release cycle. As part of sprint planning, the product owner and scrum master work in partnership to prioritize which user stories are to be worked on in the next iteration. The goal of this new approach is that the highest priority items are worked on first. And at the end of every iteration, one can ask, “Do we have a shippable or demonstrable product? Have we reached minimum viable product?”
This organization, as I mentioned, had a rocky start. Product management initially viewed agile as “a development thing” and refused to play the role of product owner on all the teams but one. “We’ve handed the development team the list of features we need to include in the release, why would we spend time prioritizing not only the features within a release, but now for each and every 3-4 week iteration? Scheduling how they do work should be their job.”
The unfortunate result was that for those teams, R&D invoked their own C—the C found in “cherry picking.” Without real guidance as to the priorities, the individual R&D teams simply picked and chose what user stories they worked on and why. Some were selected because they were the easiest, while others were chosen because they contained the most interesting work.
Unfortunately, the end result for these first agile teams was a cacophony of capabilities, spread like a wide shotgun pattern across the feature list. When schedule pressures forced product management to become involved to triage, the mess they found seemed worse off with agile than it had been with waterfall. At least in waterfall they had a glimmer of what R&D was working on as there was a schedule that showed tasks. With agile, they had what appeared to be random tasks completed without care as to how everything fit together. How were they going to tell a story to customers or management about the major themes and value behind the releases, when what they had now looked like a patchwork quilt? “Down with agile” was being shouted from the rooftops; all that was missing were the pitchforks and spires.
One team, however, had gotten agile right and it showed the others the best path. On this team, a technical product manager had shown the courage to embrace this new methodology and became the product owner. She quit writing market requirements documents (MRDs) that resembled tomes and manifestos, choosing instead to embrace the much easier user stories. She also became an active participant in iteration planning, prioritizing user stories in the backlog and partnering with the scrum master to assign them to the next iteration.
With each iteration, she was able to demonstrate to management a product that was evolving during its development cycle. And she was able to get feedback early and often from her customers and even incorporate that feedback into future iterations—sometimes even in the very next one. She discovered that the R&D team still never made it through the entire list that was initially planned for the release, but there were no more last-minute hard decisions about which partially completed features to rush to completion or to mothball. She knew with confidence when she had a minimum viable product and it was easy for her to tell the R&D team: “Halt the presses, lock this thing down and clean up the rough edges I’ve laid out in user stories in the next iteration—and let’s get it out to our customers.”
Other product-management teams saw this as an anomaly vs. a true testimonial to how great agile could be. After all, a single data point doesn’t make a trend.
The good news is the product manager of this newly successful team became quite vocal in terms of how her R&D teams were no better or worse than the other teams. She openly shared that the key difference was that she had the courage to jump in with both feet and to follow the best practices of hundreds of other software development agile teams across many industries. She surveyed where the practices had worked and where they hadn’t, went to agile user groups and then had courage to take the plunge. The other product managers eventually came around, albeit slowly at first.
As each team started to kick in and make the transition to what management considered to be high-performing teams, it became harder and harder for the laggers to hold on to their old ways since their teams were not getting any better while the others’ clearly were.
In a nutshell, having the courage to fully embrace agile allows you to:
- Force prioritization at every sprint to avoid last-minute difficult decisions
- Get feedback early and often from customers—and incorporate that feedback into future iterations
- Be vocal and lead by example to get the whole organization on board
C is for Customer
One of the best aspects of being in product management is bringing the voice of the customer to your product delivery teams. Although we have a plethora of boxes to cover in the Pragmatic Institute Framework, being that customer voice is one of the keystones to ensuring success at any and all of them. And as a proxy for the customer, we are expected to travel at least 25 percent to 50 percent of the time in order to stay in contact with all customer contingencies (sales, marketing, professional services, partners, customer support—and yes, customers, both current and future). Some people I’ve met along the way have never understood this and they can be the death of their agile teams.
Being agile helps facilitate incorporating the voice of the customer by eliminating MRDs as thick as a New York phone book. You know the documents I’m talking about: Those that describe everything a product was to do in excruciating detail, but are rarely read, understood or executed on.
Instead, agile allows teams to focus on “user stories,” requirements that are “fit for purpose” and scaled down into bite-sized chunks. These stories follow a format that looks something akin to:
I, as a <user role>
Want to <goal or outcome user is to accomplish>
Because <the reasons why a user in that role would want to do that>
Acceptance criteria: <list of criteria by which a product owner would call that story done or completed>
A process called “backlog grooming” takes place next. When a user story is too big for an R&D team to accomplish during an iteration, it is broken down into smaller stories that point to its parent story (often called an epic or a feature in agile-speak). Where the story isn’t clear or lacks acceptance criteria, the product owner uses the voice of the customer to make it even clearer. Here is a golden opportunity for the product owner to express everything that R&D is to work on and to clearly tell them both the “what” and the “why” for each and every requirement. Because the product owner is supposed to be the proxy for customers and their voice in all product discussions and decisions, product management often plays this role.
That leads me to what I believe are two poor choices for product owners:
Proxy product owners. While it’s true we no longer need huge MRDs, for some this has morphed into writing no documentation at all for the R&D team. In these organizations, the R&D team has no choice but to play the role of product owner, which further helps perpetuate the “agile is a development thing” belief. In those organizations, I call the folks who step up “proxy product owners.” It isn’t out of disrespect for what they are doing. In fact, it is the exact opposite: It is acknowledging that they are playing a role outside of their organization and taking on extra work that is very important to the success of the product. It is also an acknowledgement that they are indeed acting as a fully empowered proxy.
Some view this as software-development organizations not focusing on the “how” and wandering dangerously into the “what” and “why” that product management is supposed to own. My answer is simple: Have the courage to play that role and be that voice of the customer; R&D shouldn’t do it, nor does it want to.
Those who don’t believe in visiting customers. This is an even worse type of product owner on an agile team. All too often they are subject matter experts (SMEs) who believe that they know all of the answers based on their vast years of experience—that they, due to their personal previous work experience, know much more than the customers they are supposed to serve. Now don’t get me wrong, not all SMEs are this way. But in my career, I’ve run into a number of them, especially in specialized industries such as healthcare where subject matter expertise is held out as being more important than actual product-management expertise.
One product-management organization I had the pleasure of taking over after an acquisition was loaded with SMEs who served as product owners, but never spent any time on the road talking with customers. They did so only at yearly user conferences or when there was an escalation and they were forced to deal with an angry customer. When I drilled down and probed on why each of them didn’t visit customers, the answers that I received were:
- I’ve worked in this industry for years before becoming a product manager.
- I know this industry like the back of my hand, and I know what is best for our customers.
- Our customers don’t know what is best for them, and as an expert in this field, it is my job to come up with those things that make life easier for them.
Wow! Really? If a product owner on an agile team is supposed to be the proxy for the actual customer, wouldn’t actually talking with customers be a critical part of the job? I would contend that if they are basing everything they do on their own personal experiences, being hunkered in their bunkers versus out there in the real world, then their agile teams are simply building solutions for one and only one set of customers: themselves.
In this organization, I had no choice: I put SMEs on the road to actually meet and talk with customers. In their requirements and user stories, I had to advocate that the voice of the customer always be incorporated. Those who couldn’t get beyond their own greatness as SMEs and still refused to talk with customers were given other assignments where their knowledge could be tapped and leveraged. These holdouts, however, no longer had the role of making everyday decisions regarding the course of what had once been their products.
Incorporating the customer in agile allows you to:
- Drill down to the basics in short user stories versus long MRDs
- Communicate both the “what” and the “why” for each requirement
- Have customer conversations before it escalates into angry confrontations at yearly conferences
Take Agile Action
Over the years, I’ve seen two types of product-management organizations:
- Those who embrace agile and cherish the glory of how much they can accomplish in partnership with development.
- Those who do not embrace agile and sit on the sidelines, sniping at the teams that can never give them what they want, when they need it.
To create the first type of organization, you need to have the courage to jump in and be that voice of the customer in a way that helps your development teams deliver great products that delight those who are the most important in your world: your customers.
