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? Whats 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 lets tackle the dreaded Product vs Project question once and for all! First up lets 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:

Strategy

Releases

Ideation

Features

Go-to-Market

Organizational training

Profit and Loss

 

Now lets 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 has 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:

Budget

Delivery

Resources

Capacity

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.

 

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!