Necessary organizational processes for development, design, product management, or otherwise.

Culture Over Rules

Technology startups are often dominated by Caucasian males preaching the importance of culture. This irony should be lost on no one... in the boom of entrepreneurship and investing, the intangible concept of togetherness became an undeniable metric for success. As VCs have continued to emphasize the importance of employee happiness, it's been clear that we've undergone a fundamental shift away from the suit-and-tie offices which once dominated American professionalism.

The importance of company culture has no lack of advocates. Those in traditional work environments may associate tech culture with ball pits and ping pong tables, but the significance of company culture goes far beyond short-term relief and happiness. Companies such as Airbnb openly preach prioritizing culture, and in doing so these pioneers recognize core beliefs as a primary prerequisite for success.

In the context of the workplace, culture should be considered a counter-argument to strict rule enforcement. While both culture

Agile Suicide

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

Defining Your Project's Issue Schemes

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

The Art Of Technical Documentation

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

Functional Specification

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

Agile Development Without The Bullshit

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