Product Management in the Age of Agile: Challenges and Rewards

This short paper is an overview of what I consider important to the changing world of Product Management.

Product Management was once a set of well-defined functions that reflected a concise waterfall process. There was power, elegance, and clarity to the process.

Agile methodologies—Lean, Scrum, and Kanban—are radically changing the world of engineering development. In my opinion Agile is changing all aspects of Tech business, becoming more of a guiding philosophy that impacts the entire company in how business decisions are evaluated and made.

Product Management may be the area most impacted by Agile (excepting Development). Agile processes change fundamental aspects of product management, including how product features are defined, how customer input is sought and evaluated, how product development is planned and scheduled, even how version updates are created and rolled out. Being an effective product manager in an Agile/Lean environment is a constantly dynamic process—nothing is hard and fast.

Market evaluation

• Old-school: We'd evaluate a market segment based on current documented sales, market research using Gartner and other consultants, talks and meetings with current or prospective customers, and sometimes just a hunch we'd have: “This market obviously needs this product. Gartner says it's this big. We found a customer who'd be willing to pay this much. The competition are these companies, and our compelling differential is this set of features.” It often worked, but there's a LOT of guesswork, hunches, and third-party analysis going on here.
• Agile and Lean processes are based on Customer Development, the direct interaction with customers actually using our product—probably a stripped-down, basic version, but the idea is to get out of the building and into the customer's application and test the product concept. There's far more, such as:
  • Defining the customer (market) segment, where we identify our solution to a specific problem that creates specific value using real-world input directly from customers.
  • Identifying our early adopter, the customer segment most likely to be our early market success.
  • Defining the customer's problem, specifically from talking to them, and (best case) experiencing their problems; get a clear, in-the-field understanding of exactly what they need resolved.
• Product managers must be willing to suspend their belief systems regarding markets and products, and live in our customer's world. In order to “get it right” we must become the mediator between our executives and developers on one side, and our real-world customers on the other.
  • This also changes our artifacts (deliverables); our document set may be less dense and voluminous, but must also accurately present what we've learned and how we are approaching the market.

Product Specifications and Features

• Old-school: Based on our input from market analysis, customer analysis, competitive analysis, and our professional knowledge of the industry, we'd create a total picture of the product, defining all features and aspects of the product. The product manager would create the product feature list to the deepest level possible. I've had developers refuse to estimate scope of work because the feature set wasn't detailed enough, and I've had execs refuse to authorize a development program because the product definition wasn't complete enough. That's not to say these responses were wrong; rather that the process of defining the product was completely top-down, based on a once-removed (or more) analysis process. And sometimes we'd miss our target completely.
• Agile has product management do the above, but product management then gets out of the building and tests the product—live—at customer sites, as many as possible. We want to learn the most Real-World information possible, with specific customers, in specific markets, doing specific tasks.
  • We want to have real customers with real problems to test real products.
  • Of course the feature set of these early products will be far more limited than a completely set product definition—but this will allow us to know from the first what's really needed.
• Product managers must be willing to use product backlogs that are detailed and dynamic—and incomplete. Backlog items are nested in categories, details and priorities; a product manager becomes the Product Owner of the backlog feature set. We must be flexible, willing to listen and change on a dime. It means hearing all input: customer to developer. And it means being creative.

Changes in Product Direction

• Old-school: if our huge product development program turns out to have produced a product that few of our target market wants, we are stuck. I've completed 18 month-long programs, resulting in sales far below projection. The response was nearly always to blame the sales and marketing effort; change the marketing, change the channel approach, slash prices, anything that might boost sales. We have a huge investment in our analysis, our development process, our marketing efforts. Changing means another long development process and if the last one didn't sell, what makes us think the next will?
• Agile methodologies set us up to test, constantly, every aspect of our product. We'll know within a couple of weeks what works and what doesn't.
  • If our approach doesn't work, we get out of the building and find out what didn't work: was it the feature set, didn't we solve the problem, was it the interface, was it the time-cost of learning the product; we don't know until we get out there and experience the customer's logic and reasoning.
  • But we don't have a huge chunk of resources invested in this version of the product, so we can:
  • PIVOT to a new direction. We aren't locked down to a set product, so we can shift in whatever direction is required to address our customer's needs.
• Product managers must be willing and able to scrap a product definition and backlog feature set and start all over. This means not “getting religion” about a product held dear, and it means being willing to live in a reality-based world. It can mean more work as well, while being able to see the value of the process.

Launch and Rollout

• Old-school: Everything hinges on our launch. Since big development projects typically slip, this usually means we have to short-circuit our QA period, leading to potential bugs that should have been ironed out before development ended. We don't address our customers—even Early Adopters—until we have launched our completed product, which further delays market acceptance.
• Agile process leads us to be consistently and constantly working with groups of customers on versions of our products, even if they are minimally-viable (stripped-down) releases.
  • We can insure that each release of a product is tested in real-world conditions (our customer's environment) and fix what's needed, as well as change features as we learn.
  • We also are able to “build a buzz” in our target market, by increasing the number of customers working with (testing) our product, so that by the time we launch the total product, we've acquired a healthy set of Early Adopters within a viable—and valuable—market segment.
• Product managers create the early stages of launch materials, and being Agile can mean a constantly shifting set of features and release details. A product manager needs to stay on top of the product's evolution through the develop-and-verification process, keeping aware of WHY we are moving in a particular direction with the product; as well as staying in contact with our key customers so we can use their experiences to guide our launch marketing materials.

Updates and Revisions

• Old-school product management did product updates in the same way the first-cut products were done: using large-scale waterfall methodologies. Often it took almost as long to develop version 2.0 as it took to build our first 1.0 release. That means that problems took long to solve, new features were not reacting to market or competitive pressures, and our developers lived in a cave.
• Agile processes allow us to release updates as often as we want or need; daily if that works best.
  • A well-run Agile process means most code is developed to be changed in every sprint, leading to building products that are more tightly integrated but more capable of being revised without breaking. I see this as the product equivalent of object-oriented programming: the product tech is built in a way that allows us to get inside and change it with less chance of breaking the thing.
  • This process also allows us to make testing an integral and essential part of every development sprint, giving us the advantage of knowing if we've broken something before updating the production code. This is a huge advantage. There's not “test department” as such, since engineers are testing each new development in the contextual framework of the entire product.
• Product managers (product owners) are tasked with the job of keeping all bug fixes and enhancements properly prioritized in the product backlog, and acting as the advocate for these items. Again, real-world, reality-based input is used to set priorities for development.

Finally, I'd like to note how vital a product manager / product owner can be to leading the team and keeping them on-task and harmoniously working together toward an often changing set of goals. People are very different: I've worked with engineers for many years and I've seen every personality described in a psychology textbook. The product manager/owner, especially in an Agile environment, must lead a team so that each member of the small group is able and willing to work together with maximum efficiency.

I once had a senior engineer on my team (an IEEE member who authored early TCP/IP code) who was unwilling to respond to my product direction. I stumbled on the answer when I took him to lunch and, instead of telling him what to build, asking him “what CAN you do, given these fundamental limitations?” He wanted to have his input and knowledge respected and valued, and from there on he developed a breakthrough product. Again, finding how his personality needed to be approached—respectfully—was the key to his cooperation.

Yet the product manager also needs to keep things light, fostering an environment where work is fun and our common goal is invested in by all team members. One key is respecting all members, no matter their background or expertise level. It is important as well to see where mentoring or private discussions of an individual's challenges are needed. A product manager has very little actual power, but must lead the team toward success. That takes a unique personality, one that understands the difficulties and challenges faced by all stakeholders, yet is committed to product and company success to meet our customers real-world needs.

There is far more to a product manager's duties in an Agile environment, and we are still learning. My goal here is to summarize how this valuable role has significantly changed our responsibilities. I hope this short paper can stimulate conversation and reflection on how to further develop product management in an Agile world.

Thanks for reading.