How To Sound Smart (But Be Really Naive) About Dramatic Changes in Technology
Adam Bullied posted an apparently naïve question on his blog, inviting readers to take simplistic views of agile product management as identical to traditional product management, or as a completely different animal. Lots of folks piled on, creating a patchwork of comments and opinions that don’t address the interesting question of how product manage has evolved under Agile. I’d reframe his question (“Are agile PMs Baloney?”) into something meatier: “Do radically different ways of building software radically change how software product managers do their job, and how does this change our thinking about delivering value to the market?”
Let’s get warmed up. Suppose I was an industrial designer working in the early 1950’s. My job? Creating new tools for machine shops. My tools? Pencil and paper. Clay and wood prototypes. My development process? Relatively slow. Feedback loops? Long. To compensate, I work as much experimentation into my process as I could, but, let’s face it: there was only so much experimentation that I could try.
Fast forward to today. I’m still an industrial designer making tools for machine shops. Except now I’m not using pencil and paper, I’m using a sophisticated CAD-CAM system. I might be using wood and clay, but chances are good that I’m printing my prototypes. My development process? Fast. Feedback loops? Short. My ability to experiment with alternatives, and to use experiments with customers, is so easy that I find myself naturally collaborating throughout my process.
Now, ask yourself: Has the job of the industrial designer changed?
Think about this before reading further. Has the job changed?
Of course it has! Our “jobs” are inextricably tied to the tools and infrastructure that we use to complete the same. Dramatic changes to the technologies of our tools and infrastructure creates equally dramatic changes in our jobs. In every industry.
- Few developers program in assembly language anymore. We have better tools for that. And these tools, have, in turn, changed the job of the developer.
- The “job” of setting the price of items has changed dramatically since the advent of sophisticated pricing systems.
- Even cooking has changed, as high-tech methods enable the creation of dramatically different kinds of food. (Cryogenic Ice Cream, anyone?)
Which leads us to the main point of this blog. Adam asserted that there is no such thing as an Agile Product Manager, because, well, the job of the product manager is still the same. A good PM has to identify market problems and solve them. Agile is just a different technology for doing that, right? And because of that, there really is no such thing as an “Agile” PM – they’re just a PM using a different technology, right?
Wrong. Naively wrong, at best, but, wrong nonetheless.
However you choose to interpret the meaning of the word “job”, get clear on the following: It is a complex system. And complex systems have feedback loops. Which means…
- Your “job” influences and is influenced by the technologies that you use to do the same.
- Dramatic changes to these technologies will cause equally dramatic changes in your job.
- Your “job” lives inside a larger, even more complex system. So, changes in how you behave shape this even larger system. (Think how markets change when release cycles change from 9 months to 3 months to 3 weeks).
If you find someone telling you that an Agile PM is just a regular PM doing Agile, smile knowlingly, pat them on the head, and walk away, because trying to explain complex, non-linear systems thinking to people who don’t think in terms of systems is just too darn hard, unless, of course, you’re billing by the hour.
And if you’re NOT experiencing dramatic changes in your product management job since you’ve adopted Agile then give us a call – chances are pretty good you’re not doing Agile right.
February 18th, 2009 at 18 Feb 2009
Hmm, interesting.
I’m a little offended at being called naive – especially since I was asking, what I clearly pointed out as, a question meant to incite discussion. And it was quite a good discussion.
So am I naive and wrong because I don’t agree with Enthiosys point of view?
I’m not the only one that believes what I was saying. Some folks that agree with me have forgotten more about product management that I will ever know.
At the end of the day, agile is a set of tools and philosophies that help you do your job – whatever that may be. You can choose to either use them or not.
Trust me – if you ship winning products, no one will care (except purists) whether you are “agile” or something else.
And “complex non-linear systems?” C’mon, guys. Most of us aren’t building rocket ships – we’re shipping software.
February 18th, 2009 at 18 Feb 2009
Randomly stumbled into this blog, so writing this comment without complete context of your other posts. I disagree with the assumptions in this post or the industrial designer, assembly lang programmer, cook analogy.
The job of an industrial engineer hasnt changed. The tools have. An industrial engineer with good fundamental skills would be just as effective in the 1950’s as today. A good cook will be just as effective regardless of the tools, cause cooking is all about understand the fundamentals of how ingredients mix/blend/cook at various temperatures rather than the hi-tech gas range and ovens.
A good analogy might be an architect, has the job of an architect changed ever since man has been building wonderful structures? No, but the tools sure have.
Job skills are based on fundamentals and tools augment them. That’s why education is based mostly on fundamentals and add some applied perspective with tools.
I believe the skills and tools aspect of PM should not be mixed up. I’d take a PM with good fundamental skills any day and train them to use the latest and greatest tools/frameworks rather than have someone very fast on the tools/frameworks but weak in fundamentals.
So now to tie it back to your post, I think there are fundamental skills that a Product Manager should understand and possess and tools/frameworks like Agile/Scrum just augment them. Don’t get me wrong I’m not saying you don’t have to acquire additional newer skills to learn these new tools/frameworks to make your self more efficient/effective in what you do.
However to me it’s a layer that you put on top of the core skill set.
February 18th, 2009 at 18 Feb 2009
It’s alway interesting to me to watch these religious wars about this or that methodogy and who is right or wrong.
I’m one of the investors in the company where Adam is a PM. I also have about 30 years of battle scars working all of this stuff. First and foremost a product manager is, surprise, responsible for the product. As a board member, investor, etc, I’m interested in one thing and one thing only; the product. Are the dogs eating it. Are the dogs, more importantly paying for it, but that’s another story. As a Microsoft Alumni, I know the extreme value in Product/Program management.
I have a number of investments both in our fund (JLA) and the fund we co-manage (BBPF). Many use Agile, many do not. The org charts, interviews, and business cards, all say the same: Product Manager. The agile part? Philosophy of a company with practicing members. I do think in terms of systems and I do know Agile. When somebody tells me they are an “Agile PM”, I’ll grill them to make sure, to your point, they aren’t just tagging Agile to a title. But product management is way more than to do or not to do Agile as a company methodology.
But at the macro level, at the balance sheet level, at execution of the plan level, I want tier one players esp. tier one product (and program) managers making sure we get it over the finish line; titles notwithstanding.
Your meatier version of his question would have been a much different discussion and I also agree with your assesment on dramatic change.
But, at the high level, the ultimate objectives and end goals of a PM (agile or not) remain the same: Execution.
In that light and up here in the clouds so to speak, I’m not sure I’d dismiss Adam as either naive or wrong. A litle broad based perhaps, but I don’t think it rises to the cutesy smart/naive swipe or “wrong” moniker.
And guys, sign the blog entries, eh? Makes it easier to know which one of you wrote what.
February 20th, 2009 at 20 Feb 2009
[...] Shortly thereafter, the folks at Enthiosys posted an article on their blog entitled: How To Sound Smart (But Be Really Naive) About Dramatic Changes in Technology [...]
February 22nd, 2009 at 22 Feb 2009
I’m with Enthiosys on this one.
Granted, Adam’s right when he says that Agile is just a development framework. But the cross-functional nature of PM means that the shift to agile affects more than engineering. It impacts how PM works with customers, sales, support and executive management.
And true, the “what” of product management is unchanged: manage your product like a business, provide guidance to engineering on what to build, and to sales on how to sell. But in terms of the “how”, I’ve found the shift from waterfall to Agile to be profound. With Agile, product management’s work cycles are sped up, but their tasks are decomposed. The difference in the workflow is similar to the difference between Twitter and writing a term paper.
Here are some examples:
1) Agile PMs need to document fewer requirements, just enough so that the backlog and user stories are well-defined for the next couple of iterations. Planning further out than that is likely to be unproductive. Requirements are likely to change as the agile PM is getting a continual stream of new customer requirements and cost estimates from engineering. In contrast, with waterfall you need a large set of requirements to guide engineers for the span of an entire development cycle—typically 6-12 months.
2) Agile PMs have more frequent, and shorter, requirements gathering sessions with customers. One example: an Agile PM might ping a customer over IM, to ask a question that engineering asked moments ago. (IM is key for those situations where engineering is blocked waiting for PM input, and PM doesn’t have enough data to make a good decision.) These kinds of short customer interactions should be happening continually. With waterfall, customer interactions seem to take place only every few months, when PM is in the mode of writing an MRD/PRD—and when they do happen, the customer interviews typically last 1-2 hours.
This kind of direct, unmoderated access to customers means that the sales organization needs to give up a bit of account control to product management. It also means that an Agile PM needs to earn the trust of the sales team, have executive-level air cover to reach out to customers directly, and have agreement with sales and support on the appropriate scope of customer discussions. In contrast, waterfall’s long cycle times mean that PMs can work through the sales team to setup requirements gathering interviews.
3) Agile PMs work more closely with engineering than their waterfall counterparts. With waterfall, engineering appears as a “black box” to PM: deliver an MRD/PRD, wait some number of months, then get a chance to look at the product to provide feedback, build sales materials, prepare a beta program, etc. An Agile PM should demo at least some of newly built features (backlog items) after each iteration. This accelerates when PM can do a number of activities: provide feedback to engineering, demo to customers for feedback, start a beta program, and build sales materials.
4) Agile PMs have a greater ability to help the sales team close deals that hinge on product futures. For example, I’ve been in customer meetings where we’ve successfully demonstrated a product that was just two months into its development cycle. I could never have done such a demo if we were doing waterfall.
That’s my two cents. What do others think?
February 22nd, 2009 at 22 Feb 2009
I’m enjoying the ongoing dialog about this topic, both here, at Adam’s blog, and others. Unfortunately, though, the overall discussion is missing a few key points, which I’ll try to illuminate and clarify in this post. These points are related, so, while I’m presenting them linearly, be aware that your actual entry into this system may be different.
I’ll start by tackling one of the central challenges that we’re facing in this debate: how you frame the “job” of product management. When you define a job abstractly enough it is impossible to engage in thoughtful, meaty discussions about how process or technology changes affect that job. In this case, choosing to define the job of a product manager as shipping winning solutions is something that I cannot rationally argue against. Hey, I agree with so strongly with the idea that the primary job of a product manager is to ship winning solutions that I spent two years of my life writing a book about the same (Beyond Software Architecture: Creating and Sustaining Winning Solutions). But spending time at this level of abtraction doesn’t really help much in this debate. How you go about the “job” of shipping winning products changes dramatically based on the processes and tools used to build these products.
My first really profound experience of this happened when I started to deeply understand the distinctions behind different kinds of programming languages. I’ve been fortunate to work on large systems in a variety of paradigms, including functional, imperative, rule-based, and object-oriented programming. I’ve also studied linguists, and buy into the Whorfian-Sapir tradition that language (tools) structure thought.
These experiences were confirmed through the 5+ years I spent working for Elliot Soloway at the University of Michigan for more than 5 years. Under his guidance, I studied how expert developers solved problems and then built an IDE called the Goal-Plan-Code Editor (GPCeditor) that helped novices developers learning how to program Pascal solve problems based on these expert models of problem solving. The GPCeditor helped novices learn to program like an expert. We found that our students, when taught the expert methods supported by my IDE could develop programs an order of magnitude more complex that students who took traditional introductory programming courses using traditional tools, and significantly better than students taught our expert-inspired approaches using traditional tools.
Another is Michael Schrage. In his book Serious Play, Michael says:
Quantitative differences create qualitative differences. Make a commonplace material a dozen times stronger, and it becomes something else. Make a standard process a thousand times faster, and it becomes something else. Make a once-scarce resource a million times cheaper, and it becomes something else. As so do we. When we radically transform the cost and quality of the raw materials of innovation, we become something else.
I could go on referencing others, including Fred Brooks, John Seely Brown, or Donald Schon. The point is that most people do think of the relationships between our structures, processes, and the outcomes they produce as a complex system. Radical changes in one produce radical changes in the other. So, let’s stop discussing this at a level of abstraction that enables people to either avoid the very hard challenges that go from radical changes in the process or simply wash over them by claiming that Agile isn’t anything different to what was done in the past.
Consider how frequently you release your products. Many software offerings are released (roughly) once a year. With Agile methods, this can change to quarterly (or even more frequently). And no, this isn’t just a product management – development thing—you’re not going to get to this kind of radical improvement without the whole team working as a team to make this happen. But the demands of working with the whole team more frequently change the job of the product manager, to the point where many organizations have to shore up their understaffed PM function by splitting the role. Instead of a single product manager who is responsible for everything, we have a strategic or outbound product manager and a technical or inbound product manager (aka as a product owner).
What happens next is even more profound. Instead of focusing on how fast you can produce, you start focusing on how fast your customers can consume. You start to realize that real Agility isn’t about working software at the end of the Sprint. Instead, real Agility is being able to respond to your customers through powerful options that simply didn’t exist before. This is a profound change to the job of a traditionally defined product manager.
And it gets even better. You can start to change the entire market landscape because your customers (and your competitors!) know that you can meet their needs. I know that this change has occurred in the organizations I work with when their customers stop asking “Will this feature be in this release” and start asking “To what degree will this feature be in what release”, because these customers are safe and secure in the knowledge they the organization will ship their commitments.
Consider how you collaborate with your development team on such things as product requirements and acceptance criteria. If you’re stuffing a traditional MRD down the throats of an Agile dev team, they’ll likely throw it back at you so hard that you get pushed out the door. Similarly, if your a product manager who wants the benefit of working software delivered in time well-defined time boxes, you’re going to pull your hair out when developers tell you that the next stable integration of your system is 6 months in the future.
I could go on, but I don’t know if more examples of how Agile dramatically changes the job of a product manager will help. Instead, I’ll close by pointing out that those reading this blog should be very cautious about lines of argument based on successful sausage making. This line of argument goes something like this: “Hey, the most important job of a product manager is to create tasty sausages that people want to purchase. So, let’s not worry about how those sausages are made”.
Except how the sausages are made matters a lot. We can study the tastiness, and safety, and health, the best sausages, and then begin to ask powerful questions about how the best sausages were made, and in the process, create recommendations about best practices for those who seek to make new sausages.
To illustrate, consider the art of New Product Development. Dr. Robert Cooper has studied this extensively, and guess what? There are a number of stereotypic reasons that new products fail. And you can dramatically increase your chances for success by doing some pretty basic stuff, like being clear on the problem you’re solving, validating that enough people want to pay enough to have this problem solved, and prioritizing your work so that your meeting the needs of your market segments. And no, it isn’t guaranteed, and you will still have failures. But you have fewer failures with these approaches.
That’s how I feel about Agile, with the eventual outcome that Agile requires product managers who operate so differently that they deserve a unique and distinguishing label.
Luke Hohmann
March 2nd, 2009 at 02 Mar 2009
Luke, your last comment nicely addresses the arguments that seem to equate “the job of product managers doesn’t change” with “the end goal of product managers doesn’t change”. The end goal of product managers doesn’t change, but that isn’t really the issue. The issue is how product managers achieve this goal, the skills and mindset required to achieve it. All of these things change when a product manager adopts agile methods.
I have just written a blog entry debunking the notion that agile is merely a development methodology and doesn’t apply to product management.
March 5th, 2009 at 05 Mar 2009
Wow, what a bitchy title for a post. As Cranky as the Cranky Product Manager is, she has been clearly outdone by Luke’s crankiness.
Don’t think Adam deserved that kind of sarcasm and putting down of his intelligence all in one breath. He contributes a lot to the honest discussion of product management practices.
March 16th, 2009 at 16 Mar 2009
[...] best, the non-believer gets publicly berated as stupid/really naive by the principal of a product management [...]