Change is Pulling Us into the Cloud
Product management is an interesting career. We don’t code; we’re not necessarily engineers. And yet, we must communicate with and understand our development team. Our products are built under the guiding hand of technology experts. Imagine their work as a cloud—they take input from our companies, do something, and we get new product to sell. Product managers hover really close to that development cloud, and sometimes we feel like we’re actually in it!
There seems to be a constant stream of new terms, new “paradigms,” new methods and tools and languages. The seemingly high rate of change, as evidenced by a steady stream of new buzzwords, can make our heads spin!
My favorite college professor was an engineer at heart, and in practice —he taught college courses in programming, and wrote custom software in his spare time. He was amazing—he had started coding in the 1960s,worked in a variety of industries, and seen dozens of major shifts in technology and capabilities. I spent many hours listening to his wisdom and philosophy on QBasic, COBOL, C programming, and life!
At one point, he taught a class, Data Structures in C,where I was the only student. Having taken my customary winding path through post-graduate education, my course schedule was out of the normal rotation. I needed to complete the course during that semester in order to graduate, and I was the only student. Well, Neale taught the course anyway—it was just the two of us, and neither of us missed a class the entire semester. I learned a great deal about sailing—it was one of his favorite topics, and provided all sorts of programming challenges. He shared two secrets with me, which have been remarkably helpful in dealing with the buzzword of the day.
Focus on the problem
A program is just a solution to a problem. Don’t get caught up in the language of the day—the important part is the logic. Focus on building a flowchart showing logic that makes sense and efficiently calculates a precise and accurate answer. After that, you can think about the language you’ll use to code it. First, focus on the problem.
Focus on concepts
Second, learn how to effectively interpret buzzwords. Every few months, you’re going to hear a new buzzword.When you boil it all down, most of the ideas aren’t entirely new. Think about the technology adoption curve, for example. Most of us were introduced to this concept in Geoffrey Moore’s book, Crossing the Chasm.Did you know that the concept was first introduced in the 1960s, in the book The Diffusions of Innovation by Everett Rodgers? The ideas come back around again and again—usually with a new word attached. Sometimes, the idea comes back with a whole new set of terminology.
We need to focus on the concepts, then draw associations between sets of buzzwords and the basic concepts they represent. Think time sharing, then Software as a Service.
These two basic pieces of advice have come in handy a number of times since then, and I find myself coming back to them as I consider the impact of Agile development methodologies on the world of product management.
When I refer to Development, I’m talking about that entire team. I’ll assume that includes people who play the roles of product designer, development manager, project manager, and quality assurance.
If we were building custom software—projects that serve done specific customer—we would sit down with that customer and find out what they needed. Our product designer would study the users and create a solution that was perfect in all ways (ok, maybe not perfect —but really good, and tailored for their specific situation).
Now, when we can sell that one product multiple times, a very cool thing happens to our financials. See, the first piece of technology costs a lot—sometimes millions. We have to research it, prototype, design, code, and test. After that, the overhead drops a considerable amount. If the product is software, every copy after the first one costs us a blank CD and a box, maybe some paper if it still needs a user’s guide. The cost might be $15,if we’re still clinging to shipping physical media.
As vendors, we want to build a product that sells multiple times, to get us past the initial cost and into a serious profit zone.Our company needs us to build a “resonator”—a breakthrough product or service that buyers immediately understand has value to them, even if they have never heard of our company or its products before.
Targeting a Market Segment
That’s where product managers jump in. In order to sell our product multiple times, we have to make it appealing to a group of buyers that’s large enough to support us. Let’s call that a market segment.
Market segments share problems and they are a design target for Development.
Unfortunately, market segments are also a little ethereal.It’s hard to wrap your brain around the idea of creating a product for a group, because we’re human, and we all realize that each member of that group will have unique problems that no one else experiences. How will we decide which problems to focus on?
Someone has to analyze that market segment and articulate who “they” are and what problems they have. That’s the product manager’s primary role—to be the messenger of the market and to articulate the market’s pains and pleasures. For the development team, the product manager must provide adequate context to allow them to design an appropriate solution.
Development Needs Product Managers to Tell Them:
Who are the players in the target market segment? What do they look like, and what are their jobs like? Who provides the funding to purchase? Who influences their decision? Who will eventually use the product?
What problems does the target market segment share? How frequently does each problem occur, and what’s the situation when the problem does happen?
What is the relative importance of each problem? What is the impact level for each, and how many times has it been seen in the target market segment? When I say “relative importance,” I truly mean that we have a prioritized list, numbered 1, 2, 3, 4, 5, 6, etc.This numerical priority is much more useful to Development than the traditional high/medium/low ranking. This prioritized list of problems and their associated personas is called a requirements list.
It may be tempting to refer to this list as a backlog.Please be aware that in Scrum, the backlog is the same type of list, but it contains detailed features rather than personas and problems. The backlog is what Development creates to show how they will solve the problems they’re focusing on from the Requirements List.
The answers to these questions are the product manager’s deliverables to Development, regardless of the development method in use.
The good news is that these requirements can be written on index cards, which we can sort to show priority. There is something satisfying about physically sorting that stack and, later, seeing the “to do” stack get smaller, while the “things accomplished” stack grows.
Scrum and Sprint
If you’re dealing with a sudden move to agile development in your organization, it can be a little unnerving. You start hearing about the “scrum master” (which sounds a little scary, doesn’t it?), and wonder where the “bullpen” can be found. You try to figure out what exactly a “sprint” is, and where we’re running to (or what we’re running from)!
In all seriousness, there are a lot of new terms thrown around, and you might start seeing some new behaviors. We’ll explore some challenges product managers might encounter when their teams “go Agile.”
Prioritizing the List
Depending on the development method the team uses, the requirements may be packaged in a different way. If the team is agile, they receive one chapter at a time. If they’re waterfall, we give them the whole book. Regardless of what Development is doing this week, or how they’re organizing their work, the product manager needs to keep a list of prioritized requirements—and, for each one, they need to communicate the personas and how they’re impacted, along with a description of how the problem occurs and how frequently it happens.
When teams operate in the more traditional Waterfall method, the product manager takes a large section from the top of the Requirements List and wraps it into whatever document is appropriate for his or her organization. The team reviews the whole thing, and the entire set of requirements for a release is approved all at once. Then, Development retreats to the cloud and starts the design work, researching and estimating the cost and time to build.
When teams use an iterative method—XP or Agile or Scrum,you get the picture—the product manager takes a few items from the top of the Requirements List, maybe even a single line item (depending on the size of your team and the complexity of the problem to be solved). Development goes through design, and they build and test a solution, “sprinting” through the highest priority items in the Requirements List. When they finish, we give them the items that reached the top of our list—after they took stuff for the last iteration. Eventually, we decide it’s time to release—so we do the final testing, and release whatever we’ve completed so far.
Whether our development team is using waterfall or agile, we provide requirements that show the persona, problem, and frequency. We provide the impact of each problem and market evidence to support it. We also provide that sequential prioritization, whether it’s stacked index cards or a spreadsheet sorted by priority.
Tuned in to Agile
The tuned in product manager maintains the prioritized market requirements list, so he or she is ready when Development needs more work. Your top priorities—the top cards in the stack or the top rows in the Requirements List spreadsheet—consistently represent the most urgent and pervasive problems discovered. Furthermore, this market-driven product manager has validated that companies are willing to pay money to solve the problems that show up on the list.
If your development team switches to an agile development method, and you’ve been using the Pragmatic Framework to build market-driven products, you may not even notice it. That was my experience the first time I worked with a team who went Agile. I delivered a prioritized market requirements document to them, just like always. Later, I learned that they had broken my requirements into sprints.
In fact, I made this discovery when we found a bug in the field and needed to deliver a fix. I remember going to the Development manager’s office to talk about it, after I heard the problem from Customer Support. I can still see the smile on her face when she told me that (she’d have to double-check with the team, but she was pretty sure) we could release next week, and we could include the highest priority things from the current Requirements Document. Seems they were doing this “Agile” thing, and they had already finished and tested the top items. That was a sweet day that stands out in memory.
I’m sure that I had been told about that change before “the bug day,” but until I saw that smile and heard the great news, I had not truly realized the positive power that Agile brought to the table. The game had changed, and I felt like I had gotten free dessert—a big yummy dish of ice cream with marshmallow cream and peaches and whip cream and a cherry on top—without even asking for it. We delivered the bug fix and the enhancements, and sat back reminiscing about how the world is truly a fine and wonderful place.
Unfortunately, my story seems to be rather unique among product managers who are being swept into the Agile wave. Alas, many are not prepared for Agile. Instead, you’ve been writing long, prose-heavy Market Requirement Documents. You’ve used a stepped priority (high/medium/low), rather than sequential (1 to N). Guess what? Your development team is going to have to figure out how to break that stuff into sprints. Chances are, even if they look only at the “high” items, it will be way too much work for a sprint. That’s when your office starts filling up with questioners. They want to know, what should we work on in the first sprint? Can we save the purple widget for iteration three? Will you break down requirement 2.4 into tasks small enough to fit one sprint? Oh, you’re not sure right now? That’s fine—just come to the daily stand-up each morning, and tell us what to work on that day. See, that way, you can think about just a little bit each evening, rather than prioritizing the whole bunch.
If product managers don’t maintain a sequentially prioritized requirements list, they will be sucked into the Development cloud if their team goes Agile.
Get Out of the Cloud and Get Back to Basics
If you’re feeling out of control—if you’re spending all of your time spoon-feeding information to your Agile team—you have to ask yourself: Are you doing everything you canto lead your development team effectively? After all, they are the cloud. They take our input, work their magic, and “POOF!”—out of the cloud comes cool technology that never existed before.
Are you researching the target market segment to find problems that are urgent and pervasive, and that people are willing to pay to have solved? Are you articulating those problems for Development? Are you describing the personas and which persona is having each problem? Are you providing them the information they need to build an effective iteration strategy?
Build and maintain a prioritized market requirements list. Link the problems to the market evidence you found to support it. Get back to the basics of product management, and your Agile team might surprise you with their power.
Want to learn more from Stacey? Attend Pragmatic Institute's Build.
Looking for the latest in product and data science? Get our articles, webinars and podcasts.