It's been 9 months since I last called myself a product manager. Having faced my qualms with the profession as a whole, the transition to a more technical role felt like a natural choice. Keeping true to startup culture, that 'role' has proven not to be a role at all, but rather a collection of roles, from engineering, to software architecture, to systems administration, depending on which coworker you ask. If it sounds strange that a manager with a background in product could so quickly and violently fall into the most unapologetically technical aspects of software development, I’ve found first-hand that it is.

For what felt like the first time in weeks, I had just managed to pull myself away from a computer screen. I was becoming consciously aware that my isolation was threatening my own humanity... for a brief evening, 'team building' after hours became my highest priority.

Here's something that doesn't occur often in project management blogs: exploring the potential pitfalls of Agile.

Agile itself is not inherently a flawed methodology... that much should be consensus amongst self-respecting product and project managers alike. In fact, Agile's greatest drawback may be its own success. Because the benefits are (supposedly) painfully obvious, some organizations find themselves looking to adopt Agile with blind faith, perhaps while lacking the reasoning behind it.

While the intentions behind adopting Agile and Scrum methodologies may be admirable, a poor understanding of why these philosophies work can cause the unspeakable: death by Agile.

Circumstances for Failure

The success of any project is dependent on the balance of the big three. Of course, this is referring to the holy Triforce of project management:

As you already know: Scope covers what must be done, Cost refers to a budget and/or resources, and Time can be interpreted

If there is a single qualification in becoming a PM, it would probably be knowing the meaning of "As a ______, I would like to _______, so that I may ________." By now we're all painfully with familiar the standard issue types used in Trello and JIRA boards across the world.

User stories, tasks, and bugs. Boom, ship it. While the most common set of issues covers many needs, this industry standard set should really only be used as a guideline on how to define your product.

It's surprisingly common for PMs to stick to the norm when it comes to defining issue schemes... or worse yet, force issues schemes on projects where they are hardly applicable. As a problem solver, one of the first problems a product manager should solve is what the right way to tell your product's story.

Issues Types

Before jumping into schemes, here are the issues

Product managers love their jobs. There's nothing like powering through a project with a team of brilliant minds to come out and know you've all made a difference.

Most time spent being a PM isn't that moment. Much of our time goes in to thinking through complex problems, but the vast majority of our efforts are spent turning ideas into things that work. It's not so much our ideas that consume our time, rather the ability to explain those ideas to entire teams of people in excruciating detail.

The best way to learn is to teach, and the finest way to define a full product is by dictating it to others. Explanation is an art form.

These are some of the most common ways of putting prattle into practice:

Functional Specifications

Specs are the monoliths of documentation stemming back to the waterfall days. Functional specs routinely range from 100-300 pages

It is a thing of human nature to kill the meaning behind valuable phrases. While there may good intent behind phrases such as "SEO Optimization" and "Social Media Marketing," these terms become insignificant in substance. Boardroom buzzwords hold little merit to those in the trenches of building products from scratch, and "Agile Development" is no exception. The term 'agile' as it is currently used may as well be synonymous with 'development.'

The other day somebody asked me if I had any advice for an aspiring product manager. Without a moment of hesitation, I said the first thing to c ome to mind...

If a PM ever speaks to you in a way you don't understand, they're probably bullshitting you.

What I'd like to achieve is a separation of fluff from reality. It doesn't take much real-world experience to understand the extent to which