Product vs. Project Managers: 12 Best Lessons for Product Team Work

This post lists the key insights from this article, from a senior product analyst at Paralecte, Tremis Skeete

“Product is hard. And for product managers who are trying to help companies transition from a traditional project delivery organization to a modern product culture; When working in certain types of organizations (like traditional banks or insurance companies), there are a lot of ways that a product team’s purpose can be misunderstood and work can go wrong.”

Marty Cagan, Founder & Partner, Silicon Valley Product Group

He also believes that when product and project leaders learn to distinguish between the roles and objectives of product management and project delivery teams, they will learn how to increase their effectiveness and become successful working together. Here are the 12 best product management career lessons the author learned from Marty.

1. Understand the Agile Method

Most of the benefits that product and project teams get from using agile techniques is learning to do product releases at least every two weeks (like at Zappos), as opposed to every three months. Some product teams (like at Amazon or Etsy) even release once or many times a day.

“We need consistent, frequent release vehicles.”

But to get there, Marty explains that product teams are expected to undergo a level of ‘test and release automation’ as he calls it, and that changes all of the company’s dynamics. The changes are never easy, but necessary.

2. Function Like a Lean Startup

“Innovation is function of iteration. It is a function of trying out ideas. And we need to learn fast in order to innovate.”

While a typical startup may only get three to four attempts at iteration within four to six months for example, Marty believes that in order to solve most worthy problems, startups should be pushing out 50–100 attempts.

“I tell founders that if you want to have any hope of solving problems and build the right products, you’re going to need to have at least 50 to 100 iteration attempts. And there is just no way to do that by using your engineers to build four-month MVPs. If you have your engineers build a four-month MVP and deploy it, and it doesn’t actually do what you want, you have just wasted four months out of an 18 month runway.”

3. Project-Led vs Product-Led Companies

“If your company doesn’t employ agile in a way that empowers your teams, then you don’t need product managers; you need business analysts or project managers.”

Product managers specialize in learning about areas where problems exist for the business via its customers; and use their skills to generate potential solutions with the use of prototypes, experiments and iteration. Business analysts specialize in learning about business problems, and use their skills to document requirements for designers, engineers and stakeholders.

While these roles may appear to be similar at first glance, the differences are clear: product managers generate value via customer advocacy, prototypes, experiments and insights, while business analysts generate value via understanding the business, generating documentation and deliverables.

“Let teams take ownership of solving problems.”

4. Product Discovery vs Product Delivery

According to Marty, the two essential problems in building products are:

What do we build (product discovery)

How do we build it (product delivery)

“Are we building the right product and are we building the product right?”

While speed to discovery and speed to implementation are important, conflating the two strategies ultimately creates avoidable amounts of technical and UX debt. Product and project teams need to understand the difference between discovering a solution and delivering a solution; because by doing so they can work together to formulate strategies that complement each other.

5. Validating Products vs Discovering Solutions

When discovering a solution, according to Marty, you are looking for something that is valuable, usable, feasible, and viable. In other words, the objectives are to build a product that is:

Valuable: something that people want

Usable: something people will understand how to use

Feasible: something the business can afford to build, while keeping in mind that designers and engineers can build it with the time, technology and resources available

Viable: The business has to be able to sell it and profit from it

“Prototypes are done in discovery. Products are done in delivery.”

Marty has noticed, in his experience, that teams at startups tend to build products that gravitate towards market validation, more so than truly innovative solutions (Apple is probably one of the exceptions, because they’ve built truly innovative products — like the personal computer, iPod, and iPhone). This is most likely because market validation tends to be more comfortable for startups, because you can get access to market feedback. However, the issue is rarely rooted in the market. This is evident especially when there are alternative products in the market that people are already using. As Marty explains:

“If your product fails, it isn’t because people don’t need their problem solved. It’s because your solution isn’t positioned to be better than the rest. In fact, in order to be successful, your product needs to be groundbreaking and be ten times better than the others.”

6. Minimum Viable Products vs Minimum Viable Prototypes

There are many different techniques and processes that can be used in discovery. One of Marty’s favorites is the design sprint. Similarly, there are lots of techniques and processes that can be used in delivery. “When doing discovery iterations, you aren’t building things that scale; you’re prototyping. Discovery is not delivery,” Marty says.

Marty believes that there are different kinds of prototypes that product teams need to be competent in. In his book “INSPIRED” he describes them as:

User prototypes

Feasibility prototypes

Live-data prototypes

Hybrid aka “Wizard of Oz” prototypes

Each kind of prototype is designed for specific objectives, which also comes with their own flaws and risks. And some prototypes are meant to be tested qualitatively, while others are meant to be tested quantitatively.

Quantitative testing: Testing that tells us what’s happening or not

Qualitative testing: Testing that tells us why things happen, and if there is a problem, we can test to figure out a solution

Prototyping in the discovery stage is important for the delivery stage, because engineers get the opportunity to optimize their work based what they learned from the prototypes, then deploy their work with confidence.

Since discovery is not delivery, it’s a reason product managers and business analysts need to be clear about the purpose of releasing MVPs. Marty suggests a way to mitigate this by articulating what ‘MVP’ means in different contexts:

“The easiest way to fix the confusion when it comes to building a ‘Minimum Viable Product’ is if you just communicate in situations when you’re doing discovery that you’re building a ‘Minimum Viable Prototype,’ many problems are solved. Prototypes are done in discovery. Products are done in delivery.”

7. Product At Scale: Build Products You Can Sell

Product managers tend to think about the fastest and cheapest ways to test ideas, which among other things, drives their need to talk to customers in order to learn about the pain points. It’s within conversations and pain points product managers can discover the best ideas successfully.

Business analysts and project managers tend to think about the fastest and best ways to deliver solutions for the customer. It’s what drives their need to satisfy the business. It’s also in their ideas and deliverables they find success.

While product teams focus on the customer component, project teams focus on the business component. And when insights or tradeoffs are discovered that impact respective components, information is exchanged, agreements are made, prototypes are refined, and products ultimately are built, sold, and delivered.

Here’s a trick that Marty suggests can help sell your product at scale. Product and project teams can identify pilot users or ‘reference customers’ as Marty calls them to use the prototypes and products. If they like it, they will tell others, which leads to greater adoption.

8. Create Two Roadmaps: Feature-Driven & Outcome-Driven

I’ve grown to accept in my career that it’s impossible to stop project teams and stakeholders from thinking in terms of timelines and feature lists. So as a product person, it’s up to you to not only be the advocate for understanding situations before discovering solutions; you’re also responsible for raising the question, “What do we want to see happen as a result of adding this feature?” In other words, “What is the desired outcome?”

A way to address this challenge is to create a compromise, and create two roadmaps from two contexts:

Feature-Driven: A list of desired content areas and features, arranged on a projected timeline

Outcome-Driven: A list of desired business, customer or user activities and scenarios, also arranged on a projected timeline

Now, with two roadmaps we have another tag team strategy. Product teams focus on the outcome-driven component, project teams focus on the feature-driven component. And ensure that both teams have access to both roadmaps to ensure that at least the timelines are in sync. When insights, tradeoffs and redundancies are discovered, coordinate with each other accordingly.

9. There Are Two Kinds of A-B Testing

A-B testing is somewhat of a gold standard of techniques for product development. However, some people can get confused because there are actually two different kinds of A-B testing, as Marty explains:

“There is discovery A-B testing and delivery A-B testing. They are both the same concept, but they are used differently and for different reasons. Discovery A-B testing is much more limited and geared towards finding evidence. The bar for results is lowered, but the test is completed much faster. Some discovery A-B tests will even be invite-only, especially if it is B2B, rather than B2C. Delivery A-B testing, on the other hand, is usually done for statistical significance.”

Another issue that Marty often sees is when companies only optimize and run A-B tests, and then call that product management. Granted, every product company should be doing this, but it isn’t the only thing they should be doing. “Product managers are supposed to be creating value, not just optimizing and capturing it,” He says.

10. Managing Ethical Risks

Two great product companies, Ebay and Facebook, had very different approaches to ethical risks. When Marty worked at Ebay in its early days, he recalls the reputation system being one of the most important features to them.

While leaders are usually to blame for ethical issues, the product managers and designers are often the ones that realize these issues first. Leaders present goals to the team with little or no thought of ethical risks, and it’s when those goals play out that ethical issues arise.

When they arise, it’s important that product managers handle them correctly and effectively. Rather than just bringing up the issue to the leaders, they should be coming to them with solutions.

11. Competent Product Managers

Marty defines the competent product manager as having four things:

a deep knowledge of the users and customers

a deep knowledge of the data that customers generate

a deep knowledge of the business

a deep knowledge of the industry and its competitive landscape

12. Product and Project Leaders Can Work Together

Project delivery teams determine the best ways to allocate resources to build and deliver products on time to stakeholders and users.

Product management teams determine the best ways to build products while solving problems for stakeholders and users.