Product development is tricky stuff. We are in the business of creating something from nothing, embedded within complex, global, collaborative enterprises. Conflict is endemic to that process. Indeed, there are those who believe that conflict is a critical attribute to the creation of great products. Count me among them.
Conflict pushes us to maximize performance
Conflict keeps our focus on the needs of our customers
Conflict forces us to examine multiple options, cut away the fat, and secure high ground
Conflict helps leadership to understand where we are, what is challenging our progress, and how they can best engage to…
The concepts we will be discussing in this post are complex and particular. Lots of theoretical mappings. I’ll be utilizing a library of terms and diagrams to help keep us on the same page along the way. For an overview of the broader concepts, however, please give a quick skim to: https://drewharteveld.medium.com/progressive-elaboration-or-a-box-full-of-bees-ec4cdead2b0e
I manage scope in at least two tiers: Business Functions, and Functionality Attributes
Business Functions are requirements defined within the context of the business, itself. The Big Ideas, not the details that enable those in the real world.
We in the technology program management business are expected to have broadly transferrable skills. This week may be focused on new product development, next month might be all about integrating an acquired portfolio, and next quarter gets gobbled-up with re-org of an existing business unit.
Each of these program types brings a unique mix of excitement, opportunity, and challenge. One of the most fraught program types- and often overlooked for its embedded risks — is enterprise platform integration.
For the uninitiated, enterprise platform integration consists of installing a prefabricated platform, whether it be vended or open-source, into a running business…
I always begin the recurring seminars I teach at New York University’s School of Professional Studies with a model I describe as “ground zero” for projects. I draw two capital “P”s on the whiteboard, and define one as “Product” and the other as “Project”. Together, the class defines, from a shared perspective, what each of these terms means and the interplay between the two. The point of this exercise is to establish two key truths:
I have been lucky to engage in a bunch of Agile/ Digital Transformation work during recent years, and it is among the most gratifying work that I do. There is nothing quite like seeing stakeholders on both the business and technology sides tear a path straight through the labyrinth of process they have been dutifully navigating for years in order come together and pound-out solutions as one team. The term “liberating” doesn’t even capture the elation when the pistons begin firing at speed.
But Digital Transformation can also be fraught since legacy attitudes and expectations can run so deeply and…
There is a dirty secret that we in the product development business don’t often discuss: our careers will be riddled with failure. The simple truth is that creating new things in the world, and having them adopted at a scale that moves the needle, is incredibly difficult. Success demands positive outcomes of dozens of variables, many of which are outside of our own sphere of control.
The daily toil of product development surrounds identifying these variables and acting upon them to increase the chances of positive results. …
I was indoctrinated early in the Agile movement, during a time that the methodology was not yet so universally adopted and today’s many tools didn’t yet exist. This was a time of index cards tacked to bulletin boards, around which teams actually stood for daily Stand-Ups. Our Agile was highly practical, but more provincial than the mature iterations utilized by globally distributed teams today.
In that early form of Agile, grooming played a comparably minor role. Our Agility revolved around a backlog with functionality defined in only the most skeletal fashion. While we all knew there were unknown challenges and…
The factors that limit your ability to deliver aren’t endemic to the delivery itself, but rather the negative space that surrounds that delivery. They are the attributes of your product development environment: the connective tissue between the assorted functions that work together to execute on great ideas.
You can’t innovate because your product development environment simply isn’t healthy enough to support further growth and optimization. It doesn’t engender teamwork, creativity, dedication, introspection, and risk-taking. Your environment lacks adequate Operational Governance.
I say “Operational Governance” and everybody does an eye roll, like I’m one more jerk from Internal Audit here to…
Despite the rise of iterative product development methodologies over the past decade+, there are still many large IT organizations that operate in a completely waterfall mode. Stated reasons for this are many, including:
During the initial phases of a large, complex, enterprise capital project, the work effort consists mostly of research, analysis and planning — the “Detailed Design” phase in a classic waterfall SDLC. In this phase, a chosen group…
A recurring theme in this space is the interplay of strategy and tactics within a business context. Leap-frogging over the platitude that “one man’s strategy is another man’s tactics” let’s agree that success in business demands effective execution of both modes of operation. As Sun Tzu tells us, “Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat”
“Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat”
But how to bridge the gap?
I’m a born tactician, so the hands-on, git-r-done part of…
BUSINESS PROCESS & OPERATIONAL LEADERSHIP; I organize people, process, and tools to create scalable delivery to the market.