What is the hardest part of the Product Managers job?

What is the hardest part of the Product Managers job?

I often find myself being asked by junior product managers/product owners “What is the hardest part of the job?” My initial sarcastic response is always the same, getting people to understand the difference between a project manager and a product manager! However when it boils down to it the single hardest part of the job is the ability to say No. While saying no itself is a pretty easy and straightforward task it’s really the ability to justify why you’re saying now as well as having the confidence to say no to a request regardless of the seniority of the person asking. A Product Manager’s number 1 responsibility is to protect the product roadmap. This is done through careful prioritization. The product manager is the gatekeeper of the roadmap and should be able to explain in detail the business case for each item on the roadmap and why the roadmap is prioritized in the current order. Sure when the ole executive drive-by happens and you get a request to drop everything and shift focus it’s very easy to bow to the job title and just agree to it. The true importance of the product manager is to be able to push back on those requests, not necessarily just become a walking “no”, but be able to quickly have a discussion around the benefits associated with the current priority order and how the new request fits into those priorities. It’s also a critical task to explain the impacts of shifting priorities. It’s easy enough to go back to your dev team and explain the new feature to be worked on but that comes at a cost of not being able to deliver the current in-flight work, as well as a slow ramp up to get the new feature moving.


Being able to protect your backlog, explain the prioritization of your roadmap, and have the confidence to have a conversation with anyone at any level about the benefit of the priority order is far and away, in my opinion, the most challenging part of being a product manager

Product….Project….AAAAHHHHH Whats the difference?

Product….Project….AAAAHHHHH Whats the difference?

For the better part of my entire adult career, one common question/problem has always plagued me. As a seasoned Product Manager with over 10+ years experience it’s so common to get confused questions….are you a Project Manager? Can I get a Project plan? What’s your resource plan look like for this project? It goes on and on and on till I want to pull my hair out. Needless to say, this is a topic very near and dear to my heart….so let’s tackle the dreaded Product vs Project question once and for all! First up let’s take a trip down Product lane!


Product Definition

product is the value proposition you are delivering to a user. It can be anything: a physical product that you hold in your hands, a software application, or a service that you are delivering.

Product Manager role

What is a product manager? Product managers are often described as the Servant Leaders of their products setting strategy, prioritize releases, talk to customers, and clearly define features. A product manager’s goal is to deliver a product that delivers end-user value.

Product Manager’s responsibilities

The product manager is responsible for setting the product strategy. By having a “goal first” approach to managing and building the product, great product managers can create initiatives to help reach those goals. Product managers must answer these questions:

What problem does this solve?”

“What are you building?”

“What will the benefits be?”


Product managers own:






Organizational training

Profit and Loss


Now let’s take a look at the flip side and dive deep into the Project side of the house

Project Definition 

In contrast, project is a plan with a series of activities that have a defined outcome and a fixed start and end date. The project is completed when that outcome is accomplished.

Project Manager Role

What is a project manager? Project managers oversee a fixed project from beginning to end. It can be a single project or a group of projects. Their job is to execute the strategy set by the product manager or leadership team. A project manager’s goal is to work with a broader team with a diverse set of skills and to complete a project on time and under budget.

Project Manager’s responsibilities 

The project manager is often less concerned with specific product goals and focused on the project itself. A project manager takes product initiatives and features to develop a timeline based on any potential constraints related to resources, risks, or scope. Project managers must answer the questions, “What resources are needed?” And, “When will the project get delivered?” And, “Who is going to do what?”

Project managers own:





Cross-team organization

Problem resolution

Status updates


This is really just the tip of the iceberg but hopefully, this helps make things a bit more clear on the two very different roles, in a future blog I’ll touch on the role of product owner and how it fits in the above.


Don’t let your entrepreneurial spirit wither and die on the vine

Don’t let your entrepreneurial spirit wither and die on the vine

I was recently having a conversation with an entrepreneurial friend of mine about some of the struggles he was having and something hit me. He’s clearly not treating his entrepreneurial spirit like a cash crop. The spirit is just like something you would plant in your back yard, it has certain needs that must be met in order to grow and flourish.

My friend was getting bogged down in the day to day grind and struggling to recharge his batteries. After listening to his problem I was able to quickly give him some advice on how to solve his problem. I simply told him “You need more Green time and less Screen time.” He looked at me like I was speaking a foreign language or had introduced some mind boggling concept so we dove into it.

Sometimes the easiest way to get a fresh perspective on things is to change your surroundings. I’m a huge fan of trying to get outside as much as possible. A little “Green Time” is a great way to recharge the batteries and take a moment to get away from the working grind.

One of the easiest ways to give your entrepreneurial spirit what it needs to thrive is get outside, change your perspective, get a little fresh air to help refocus yourself.

In today’s fully connected times no one is every really “out of the office” so its easy to get out on a walking meeting or get some green time and still be fully engaged in your work day.


Don’t let your entrepreneurial spirit wither and die on the vine, give it the Green time it needs

Failed business transformation through the eyes of an immunologist

Failed business transformation through the eyes of an immunologist

I was recently reading an exchange between Dr. Kristina Talbert-Slagle and retired Army General Stanley McChrystal comparing how a virus like HIV or AIDS works to how an insurgency like Al Qaeda in Iraq works and I was more then a little surprised at the similarities. I went on to make the same correlations that McChrystal himself makes in the fantastic book Team of Teams in comparing those same viruses to the struggles an Organization sees during a failed business transformation.

When someone contracts something like HIV or AIDS its never the actual virus itself that kills a person, the virus weakens the body’s immune system allowing it to fall victim to any number of otherwise non fatal infections. Organizations struggling with transformation often face the same problems. It’s extremely common for an organization under transformation to run into any number of expected non threatening challenges, however the true death of the transformation comes as a result of chasing down and trying to resolve all the “symptoms” of those normal non threatening challenges. When an organization shifts it’s focus away from the larger trans formative activities it falls victim to the death of a thousand cuts as it continues to chase down small out lying issues.

In business transformation, much like our own person health, its important to treat the symptom of the problem but the far more critical issue is getting to the bottom of the route cause and not losing sight of the larger transformation. It’s always easier to view each problem in a vacuum but the key is to take a step back and see how the current problem is interacting with the organizational echo system. Viewing the problem from this 10,000 foot level allows you to see the problem in its environment and better understand how the problem is interlinked with unexpected areas.

How failing fast dominated the Steel industry

How failing fast dominated the Steel industry

Was recently reading the story of Frederick Winslow Taylor‘s display at the 1900 Paris Exposition Universelle and was extremely amazed how Taylor was able to take a favorite agile mantra of mine, failing fast, and really revolutionize the steel industry. At the time it was common place for a steel mill to produce roughly 9 feet of steel per minute. The presentation which was a smaller replica of Taylor’s factory was able to product steel at a staggering 50 feet per minute. Taylor’s breakthrough was often compared to the creation of the electric light and was even refereed to as a major landmark in the history of mankind. But how was Taylor able to create such a mind boggling achievement? Magic? A pact with the devil? The answer lies in one of the great hallmarks of agile transformation….Taylor was largely able to accomplish this through trial and error, or as we like to call it, failing fast.

Through a series of experiments Taylor had determined the perfect conditions for creating steel, everything from the optimal temp to cut the steel, the optimal method to use water to cool the lathe, and the optimal speed to run the conveyor belts.


Taylor was able to revolutionize the steel industry by simply approaching his processes with a healthy curiosity for improvement and a willingness to fail fast. Sure in the early days his progress was very poor and unprofitable but by persevering through the difficult times and staying focused on the end game Taylor was able to rise to complete dominance in his industry



Agile transformation throughout Military History

As a huge military history buff I always find it interesting to stumble onto random waterfall vs agile snippets. Here are a few recent ones I wanted to share


In 197 BC at the Battle of Cynoscephalae a Roman army met the forces of Macedon. Looking back on the battle its hard to imagine how the traditional legionnaire tactics of the Roman military could deal with the mighty Macedonian Phalanx but the answer is much more surprising when viewed in the context of Waterfall vs Agile development.

At the time the Macedonian Phalanx was very much the unmovable object, very similar to waterfall development. From a command and control standpoint there wasnt much finesse to an army based around the Phalanx. Much like waterfall development once the battle started the Phalanx was a large unwieldy freight train that lacked the ability to pivot regardless of the environment around it. Macedonian Generals were often faced with new intel once a battle started very similar to how a Project Manager might field changing requirements while being powerless to make changes to the current project

The Roman army on the other hand organized itself into much smaller and more Agile manipular formations, with each commander afforded some battlefield flexibility to pivot and adjust as the battle unfolded. The hallmark of the Roman army as well as its greatest asset was the ability for a General to relay an overall strategy to each cohort commander and then once the battle begin each commander had the flexibility to pivot as needed as conditions changed, this very similar to how a product owner might deal with the churn and flux of requirements, directing the dev team on how to react to the changing landscape


Another great example of this can be found during the Battle of Trafalgar. Here Nelson took a smaller fleet up against a superior Franco-Spanish fleet. Again as in our previous example its very easy to draw some waterfall vs agile parallels

The Franco-Spanish Fleet under the command of Admiral Villeneuve looked to use its numbers advantage and relied on well established naval battle traditions. Information was very silo’d with only Villeneuve knowing the full battle plan . A plan he couldn’t share with his other captains ahead of time. As the battle begun to play out Villeneuve used a flag and smoke system to attempt to send his orders to fellow captains. A system that in the fog of battle proved impossible to follow

Lord Admiral Nelson on the other hand used a bit of an outside the box strategy in this battle. Not just in the way he deployed his ships but in how he communicated and shared his battle plan with his other captains. In the days leading up to the battle Nelson spent time with each captain addresses all concerns raised while placing great trust in each commander’s ability to ultimately make the right choice. When a captain challenged Nelson on the play Nelson famously told the captain “No Captain can do very wrong if he places his ship alongside that of the enemy” Nelson had patiently installed the idea in his own commanders that he allowed and, indeed, expected his subordinates to use their own initiative. The trust Nelson placed in his commanders to execute his overall strategy by whatever method they deemed best would become known as “The Nelson’s Touch”


It really does amaze me how often you can be researching something completely unrelated to business transformation and stumbled into some truly historic examples of just how long the age old battle of waterfall vs agile has been raging on!


The story of Proteus and Menelaus

I’m often asked how I ended up going into an Agile / Business transformation career, the answer is pretty simple, I just sort of fell into it and quickly found out it was something I was pretty good at. The story of Proteus and Menelaus always appealed to me and to this day is still a story I like to tell at the start of a new Agile or Business transformation.


Returning home after the Trojan war Menelaus’s ship was becalmed on the isle of Pharos, after spending 20 days waiting for favorable winds a Nymph named Eidothea explains that only Proteus can help Menelaus get home and that only by capturing Proteus will Menelaus ever get favorable winds to return home. Eidothea explains the only way to capture Proteus is by surprise and helps Menelaus hatch a plan to capture Proteus after he falls asleep. She told him there is a certain cave where seals sleep that Proteus goes to at dawn. Menelaus and two chosen men were to go there and hide among the seals and grab Proteus by surprise. They were to hold on no matter what form he changed into. When he stopped changing, then Menelaus could ask him which god was angry with them, then they could sacrifice to that god. Menelaus and his men snuck into the cave before dawn and grabbed Proteus when he came to look over the seals. He changed into animals and trees and tried to frighten them, but they did not let go.


This story always struck me as extremely interesting as Menelaus had to push past constant change while keeping a single goal in mind. This has always been a powerful story in helping drive home the perseverance needed to successfully transform a business.  During the transformation you might has to go through several stages each trying to throw you off course but the critical part is to always keep your end goal in mind and try to hold on for the ride!