Don't Rename Your Way to Product Transformation

Don't Rename Your Way to Product Transformation

"We don't have product managers. Can we just rename our BAs and project managers?"

I hear this question at least once a month from tech leaders starting their product transformation. And I get it. You need product managers. You have smart people in Business Analyst (BA) and Project Manager (PM) roles. A title change costs nothing. Problem solved, right? Think again.

The Renaming Shortcut

Here's what usually happens when companies take the renaming shortcut: Six months later, you have people with "Product Manager" on their business cards doing the exact same work they did before. They're still gathering requirements from stakeholders. They're still writing detailed specs. They're still tracking project timelines. The only difference is now they are frustrated because their job has not actually changed, and leadership is confused about why the product transformation isn't working. You changed the title. You didn't change the work. And that gap is the difference between a real transformation and expensive theater.

Why Renaming Fails

The skills that make someone an excellent Business Analyst or Project Manager are valuable. But they're fundamentally different from what Product Management requires. Business Analysts typically excel at understanding the current state. They gather data. They document requirements. They translate stakeholder needs into specifications. They create clarity from complexity. That's critical work. But it starts with the assumption that someone else has already decided what to build.

Project Managers excel at execution. They manage dependencies. They track timelines. They remove blockers. They keep teams moving and deliver on commitments. That's also critical work. But again, it assumes the decision about what to build has already been made.

Product Managers need to decide what to build in the first place. They discover which problems are worth solving. They validate assumptions before committing resources. They make strategic bets about customer value, not just tactical plans for delivery.

"BAs and PMs typically operate downstream of the build decision. Product managers operate upstream."

Neither BAs nor PMs typically spend their days interviewing customers to understand unmet needs. Neither runs experiments to test whether a solution will work before building it. Neither challenge stakeholder requests by asking if the requested feature actually solves a real problem. Those aren't criticisms. Those activities just aren't part of the BA or PM role as traditionally defined.

Identifying Product Candidates

Here's the reality: some of your BAs and PMs will make excellent product managers. Others won't. The determining factor isn't the title they hold today. It's the mindset they bring to the work. I've seen this pattern play out dozens of times. The people who successfully transition to product roles aren't necessarily the ones with the most experience or the highest performance ratings in their current role. They're the ones who are already operating like product managers, even when their job description doesn't call for it.

The BA Who Won't Stop Asking Why

I worked with a company that promoted their senior BA to a product role. On paper, she seemed like a safe bet. Ten years of experience. Deep domain knowledge. Excellent stakeholder relationships. But she struggled. She kept waiting for someone to tell her what to build. She documented requirements beautifully but rarely questioned whether those requirements addressed the real problem.

Meanwhile, a junior BA on another team was driving everyone crazy. She kept pushing back on feature requests. She'd respond to stakeholder asks with questions: "What problem are we solving? Have we talked to customers about this? What if we tested this assumption first?"

Guess which one became a strong product manager? The junior BA already had the product mindset. She just needed training on discovery methods and strategic frameworks. The senior BA was excellent at her job, but that job wasn't product management.

The Project Manager Who Wants More Influence

Another client had a project manager who was frustrated. She was great at delivery. Her projects came in on time and on budget. But she kept asking to be involved earlier in the process. "By the time I see these projects, all the decisions have been made," she told me. "Half the time, I can already see problems with what we're building. But it's too late to change direction." She wanted to influence what got built, not just how it got delivered. That's a product manager waiting to happen. She had the strategic thinking. She just needed the tools and permission to apply it upstream.

How to Grow Product Leaders

If you're serious about building product management capability, don't just rename people. Invest in their transformation. Here are some practical tips:

Assess for mindset, not just skills. Look for people who already ask "why" when gathering requirements. Who pushes back on stakeholder requests? Who wants to understand customer problems, not just document features? Those are your initial candidates.

Provide real training, not just a title. Discovery methods. Assumption mapping. Customer interview techniques. Outcome-based roadmapping. These are learnable skills, but someone needs to teach them.

Pair them with experienced product people. If you don't have product managers internally, bring in consultants or advisors. Let your transitioning team members shadow real discovery work. Learning by doing beats learning by reading.

Change the work, not just the title. Redefine what success looks like. If you're still measuring your people on requirements documentation or project delivery, they'll keep doing that work. Measure them on customer insights gathered, assumptions tested, and outcomes achieved.

Give them permission to say no. Product managers need to be able to push back on stakeholder requests. If your culture doesn't support that, the role change won't stick. Create space for strategic thinking, not just tactical execution.

The Hidden Candidates

Some of your best future product managers might not be in BA or PM roles at all. I've seen excellent product managers come from engineering. For example, the developers who always want to understand customer context before they code, who question requirements that don't make sense, who care about solving problems, not just shipping features.

Customer success teams often have future product managers, too. These are the people who talk to customers every day and see patterns in their pain points. Who understand the gap between what you built and what customers actually need.

Even sales and account management can be fertile ground. Look for the ones who listen more than they pitch. Who understand customer problems deeply and can articulate value in outcome terms, not feature terms.

"Many of your people are already thinking like product managers. They just need the skills and the opportunity."

Real Product Transformation

Changing titles is easy. Changing how work gets done is hard. A real product transformation isn't about renaming roles. It's about shifting how you decide what to build. That means investing in people, training them, and giving them new tools. It means creating space for discovery work that doesn't exist today, and changing how you measure success. It means accepting that some excellent people in their current roles won't make the transition. And that's okay. Excellent BAs and project managers are valuable. Not everyone needs to become a product manager.

But for the people who do have the mindset, the investment pays off. I've watched junior BAs become strategic product leaders. I've seen project managers transform into discovery experts. I've seen engineers move into product roles and thrive because they finally get to focus on the "why" behind the code. The difference between those success stories and the expensive failures? The companies that succeeded didn't just change the org chart. They changed the work.

Ready to Get Started? Start with Honesty

If you're considering this transition, start by being honest about what you're really asking people to do. Are you renaming them to fill boxes on an org chart? Or are you investing in a genuine capability shift? Are you giving them the training, support, and permission to work differently? Or are you just adding "Product" to their title and expecting magic? The title change is the easy part. The mindset shift takes longer. But if you're willing to make the real investment, some of your business analysts and project managers will surprise you. They'll become the product leaders your transformation needs.

You just have to give them more than a new business card.

--------------------------------------------------------------------------------------------------

I write about product transformations and building real product capability every week. If you're navigating the shift from projects to products, follow along for frameworks and strategies that actually work.