Everyone in tech has seen the word, repeated ad nauseum as the “silver bullet” for everything from go-to-market timing to quality to product discovery. But like many terms bandied about by those both within and on the periphery of Product Management, the term “iteration” often comes with connotations or meanings attached to it that aren’t really quite right — almost to the point where the word itself begins to lose its meaning and becomes a “cargo cult” phrase without any real “there” there. In this post, I want to explore what I think are five common myths about iteration that if busted will let us renew the meaning of the word and make it something worthwhile in our profession.
Many companies struggle with the challenges of reconciling the need for strategic planning and the desire to execute in an “agile” or Agile fashion. Generally speaking, this is because they’re stuck with the perspective that a “roadmap” must be a set of promises regarding what’s to be delivered, and not merely a strategy that will and must change over time. Being “agile” requires that we accept the unknowns in the world — and what’s more unknown than what the market is going to look like in 2 years? Therein lies the folly in trying to perform traditional roadmap planning and expecting to be able to be “agile” in your execution. But, there are some easy ways to change your perspective on roadmaps and maintain the balance between strategy and execution.
Product Managers sometimes have a bad reputation when it comes to Development teams — and we often unintentionally earn these reputations, by the way that we work with them. There are, however some things that Product Managers can do to build a strong relationship with their development teams — something that is, in fact, essential to the success of the product and your company as a whole. Here are five tips that you can use to ensure that you have the best relationship possible with your development teams:
Several times in my career, I’ve joked to someone or another that my next job title will be “Senior Cat Herder” rather than “Senior Product Manager” — and for good reason. Cats, for all of their cuddly cuteness, are independent problem solvers, much like most of the better developers that I’ve worked with.
Add to the problem the fact that as a Product Manager we typically don’t have any direct authority over our development teams — while we can prioritize the work that they’re charged with doing, and we can (sometimes) influence the way in which they build their solutions to the problems that we’ve stated, we lack the kind of direct management influence that lends itself to “control” over those teams. And, when a Product Manager who doesn’t have such authority oversteps his or her boundaries, and becomes a directive manager of those development and testing teams, it’s almost inevitable that it backfires, amidst charges of “micromanagement” and “you’re not my boss!”
And, ultimately, they’re right – you’re not their boss. You’re their colleague. Like it or not, you’re a fellow cat, not some pack leader of a wolf clan.