I'm not too crazy about marketing people. It's not that I dislike marketing as a concept... on the contrary, I have nothing but respect for the concept of subtly manipulating the human mind. Thus it is naturally frustrating to watch the concept of marketing move away from calculated campaigns, and more into the realm of Mailchimp and Social Media junkies. If the ability to use Facebook tops your list of tangible skills, chances are I wouldn't trust you to define my company's voice.

I'm assuming that undergrad marketing programs consist of more than introductory Instagram classes. Where then, are these concepts being applied? From the outside looking in, a case can be made that marketing is the discipline of deploying microsites and unapologetic sales messaging.

I can only imagine how CMOs who meticulously shaped brands feel about a workforce striving for a bare-minimum understanding of their field. Yet I can

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

Articles covering product management remain a scare breed. We're familiar with the cliché “qualities of a good PM" articles which recycle themselves on the front page of HackerNews once every few weeks. These seem to provide great advice at first glance, mostly because they closely mimic much of our society's golden rules.

Consensus amongst vocal product managers is that being a good PM isn't too far off from simply being a good person. The mantra of leading by example and turning the other cheek has somehow made its way into my own professional psyche for the last 8 years.

After thoroughly testing this mindset in the field, I'd argue that this mindset under the following circumstances:

1. You're a PM at Google
2. Your company would rather keep you happy than extracting maximum work for minimal cost

Those odds don't feel great.

After nearly a decade, I've stuck to my guns

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