What are the Risks for Product Managers When Taking Over Brownfield Projects?

Navigating the Challenges: Key Risks in Taking Over Brownfield Projects

As a 12+ years Product Manager who has guided numerous products through different lifecycle stages, I’ve learned that taking over brownfield projects comes with unique challenges. Unlike greenfield projects that start from scratch, brownfield projects carry historical decisions, established codebases, and existing user expectations. Let’s explore the key risks at each stage of a product’s lifecycle and how to navigate them effectively.

Disclamer: I usually do research when writing an article on my blog and I link all references at the bottom of the article. However, all the content of this article comes from my own knowledge I accumulated through my professional career. This isn’t an article I thought of writing one day when waking up. No, to put you into context, I’ve recently did a job interview and one of the questions was exactly this question “What are the key risks for a product manager when taking over a brownfield project?”. I felt quite inspired when answering and I thought I could share my answer with my fellow PMs. So the disclamer here is: this is my articulated answer and I might be completely wrong 😂

Understanding Brownfield Projects and Product life cycle

Before diving deep, let’s clarify what we mean by a “brownfield project.” It’s any existing system or product that has already started its journey - whether in ideation, development, deployment, or even serving millions of customers.

Taking over an existing project presents its own set of challenges that require careful navigation, depending at which stage of its life cycle the product is at.

There are 4 stages in the product life cycle:

  1. Introduction
  2. Growth
  3. Maturity
  4. Decline

Because we’re not here to talk about the life cycle of a product, let me summarise it for you with the graph below:

graph LR
	A[Introduction] -->|Growth Triggers| B[Growth]
	B -->|Market Saturation| C[Maturity]
	C -->|Market Changes| D[Decline]
	D -->|Revitalization| B

	style A fill:#e6f3ff,stroke:#0066cc
	style B fill:#ccebcc,stroke:#006600
	style C fill:#fff2cc,stroke:#996600
	style D fill:#ffe6e6,stroke:#cc000

	classDef default font-size:14px;

The Introduction Stage: Where Foundation Meets Reality

The introduction stage might seem the least risky for a brownfield project, but don’t be fooled. This is where crucial decisions have already been made, yet problems are still emerging. Here’s what to watch for:

Product-Market Fit Uncertainty

The planned solution might not actually solve the initial problem. This risk is amplified in brownfield projects because you’re inheriting decisions made by others. Always validate the fundamental assumptions behind the product strategy.

Resource Estimation Challenges

Teams often underestimate what they need for MVP delivery. When taking over, you might discover that budgets, team composition, and deadlines were set with incomplete information. Be prepared to reassess and adjust these elements.

Feature Creep in Disguise

It’s a classic scenario: stakeholders label their nice-to-have features as must-haves. This “feature bloat” can significantly extend development time. Your role is to identify and challenge these assumptions.

Introduction Stage Example: The Legacy Banking App

Imagine taking over a mobile banking app that’s been in development for 6 months but hasn’t launched yet. The previous team built extensive features like bill payments, transfers, and investment tracking, all before validating core user needs. Upon review, you discover that while the app is feature-rich, it lacks basic accessibility features required by a significant portion of the target market. User testing reveals that most customers primarily want quick balance checks and simple transfers - features buried under complex navigation.

Technical Foundation Issues

The initial technology choices might not scale well. Review the architecture and infrastructure decisions early to avoid painful migrations later.

The Growth Stage: Scaling Brings New Challenges

When a product finds its market fit and begins to scale, the risks shift dramatically. Here’s what to focus on:

Infrastructure Growing Pains

The MVP’s technology stack might buckle under increased load. Plan for infrastructure evolution before it becomes critical.

The Noise of Success

Growth brings feedback from everywhere - customers, stakeholders, investors, and team members. The real risk is losing focus amid this noise. Use data-driven decision-making to maintain clarity and direction.

Evolving Market Needs

Remember that product-market fit isn’t permanent. Markets evolve, and so should your product. Stay alert to changing user needs and market conditions.

Growth Stage Example: The Exploding E-commerce Platform

You inherit an e-commerce platform that’s grown from 100 to 10,000 daily users in three months. While this growth is exciting, the platform starts experiencing regular outages during peak hours. The monolithic architecture chosen for the MVP can’t handle the load. Meanwhile, you’re receiving feature requests from various stakeholders: the marketing team wants better analytics, the sales team needs bulk order processing, and customers are requesting a mobile app. The original PostgreSQL database is hitting its limits, and the team is spending more time firefighting than building new features.

The Maturity Stage: Fighting Complacency

Maturity brings its own set of challenges, often more subtle but equally critical:

Political Landscape

Success can breed complacency. You might face resistance to change when suggesting new directions. Build allies and use data to support your initiatives.

Technical Debt Accumulation

By this stage, technical debt often becomes a significant burden. Balance maintaining existing functionality with modernizing the codebase.

Maturity Stage Example: The Corporate Communication Tool

Consider a well-established internal communication tool used by 50,000 employees across a multinational corporation. It’s stable and reliable, but user engagement is plateauing. The technical team wants to modernize the codebase, while business stakeholders resist any changes that might disrupt existing workflows. The product generates steady revenue, but competition is increasing. You discover that 40% of the codebase is in a legacy framework, making each new feature implementation increasingly complex and time-consuming.

The Decline Stage: Finding New Growth

When taking over a declining product, you face some of the toughest challenges:

Team Morale

Declining metrics can demoralize even the strongest teams. Focus on small wins while working on larger turnaround strategies.

Documentation Overload

Ironically, successful products often have overwhelming documentation. You need to efficiently parse this history without getting lost in it.

Hidden Opportunities

Don’t overlook your super users. They’re still using the product for a reason - understanding why could reveal paths to revitalization.

Decline Stage Example: The Industry-Specific Project Management Tool

You take over a project management tool specifically designed for construction companies. Once a market leader with 30% market share, it’s now down to 8%. However, you notice something interesting: a small group of large construction firms still actively use and praise the product. Through investigation, you find that these loyal users value specific features that modern alternatives don’t offer. The challenge is modernizing the product while retaining these unique advantages, all with a demoralized team and shrinking budget.

Key Takeaways for Product Managers

When taking over a brownfield project:

  1. Assess the product lifecycle stage accurately
  2. Understand the historical context but don’t be bound by it
  3. Build strong relationships with existing team members
  4. Use data to guide decision-making
  5. Stay focused on user needs while managing stakeholder expectations

Metrics at each lifecycle stages

We love metrics, don’t we? Of course each project can have their own specific needs, success criteria, north star, etc. But I thought I’d give some guidance based on my experience to offer you some key metrics for each stage of the product life cycle:

Introduction User Adoption Time to MVP Feature Usage Growth User growth System Uptime Response Time Maturity Retention Rate Tech Debt Ratio Feature Usage Decline Churn Rate Support Tickets Active Users

Remember, every brownfield project is an opportunity to create value by building on existing foundations while introducing fresh perspectives. The key is recognizing where you are in the product lifecycle and adapting your strategy accordingly.

What’s your experience with brownfield projects? I’d love to hear your stories and strategies in the comments below.


Key Risks in Taking Over Brownfield Projects for a Product Manager
https://fry.pm/risks-in-taking-over-brownfield-projects/
Author
Fry
Licensed under