Managing large-scale projects as a Product Manager

You should know that if you take on something of this magnitude, you will be fighting an uphill battle

Product Management often involves breaking ideas down into smaller steps. Still, there are times when you can't avoid the necessity of building out a significant amount of infrastructure or rewriting your legacy system in one fell swoop. Eventually, you will be required to dive into one of these large-scale projects.

All of the general product wisdom still applies here, and you should know that if you take on something of this magnitude, you will be fighting an uphill battle. It’s not going to be easy. It will be hard to keep the focus, not burn out, and see this through. I’ve been involved in multi-year projects and seen the struggles firsthand.

As with any advice, its usefulness will vary depending on your unique circumstances. This is not a definitive guide but a collection of considerations that I hope will steer you in the right direction with your large-scale project.

Before you build

• Stay focused on the long-term goal: When you have a large job, it’s easy for the project to keep growing in scope. Stay focused on the long-term goal and ruthlessly cut anything that doesn’t help you achieve it. This project is large enough already.

• Find value creation and alignment: The more aligned your project is with other initiatives, the more likely it is to get the backing and support it needs. Support and enthusiasm for long-term projects wean over time, so it’s essential to have a strong value proposition to keep referring to.

• Assess risk and develop mitigation strategies: A large-scale project can present many challenges, including technical risks, resource constraints, or market changes. Having a clear risk management plan can save a lot of headaches down the line.

• Set clear, measurable milestones and key performance indicators (KPIs): Tracking progress is part of showing results. This will help you maintain focus and provide a sense of achievement as you hit each milestone.

• Technical Feasibility and Proof of Concept: Before embarking on full-scale development, conduct a feasibility study or build a proof of concept (PoC). This will help the team identify potential technical challenges and refine your approach.

While you’re building

• Build and test in increments: If you spend six months building in isolation before testing, no one will want to touch that. It’s far better to test and get feedback as you go. Think about the work as an evolutionary process.

• Use it in production as soon as possible: As mentioned above, you want to get some real-world usage (if possible) of your feature. This will help tell you if you’re on the right track.

• Run in parallel: Sometimes, this can be a helpful strategy. It can help you test and give others time to onboard. Essentially, it means running both the old and new versions of your software, API, or feature in parallel. Especially helpful in an API dealing with data, you can do dual entry and compare the results from the two systems to ensure your new one matches expectations.

• Release in slices: Much like testing in increments, you want to get real-world usage out of the various components early on. I discuss this in another post, The smallest functional slice.

• Deliver value early: Even if it’s not visible to your end user, it’s a massive win for the team to demonstrate progress and see The value of value delivery.

• Versioning: Maintaining two versions may be unavoidable when rewriting systems others rely on. This is especially true for API rewrites.

• Timing: You may be required to work with many other teams, external customers and integrators. It’s essential to start talking to them early on about timing. When will the new API be available to integrate with? When will the old system no longer be accessible?

• Documentation: As you build, especially as people start using your product, it’s important to document how it works. This is especially critical if others will need to integrate with your system.

• Legacy read-only: If your system was responsible for writing data, you can take a multi-step approach to retiring it. Having the old system available as read-only can be helpful for other teams that still rely on the historical data and can give you, or them more time to migrate data to the new system.

• Early adopters: Find some early adopters with a limited-scope use case for your new API, software, or app.

• Trim the fat: There are almost always things we’ve built in the past version that don’t need to be migrated to the new version. Don’t make the mistake of trying to clone and copy everything. Now’s the chance to trim the fat and make it better and more straightforward than before. Respect the 80/20 rule.

• Support from above: If you can get it, projects that require adoption across the company benefit from the support above. The closer this is to a proclamation from on high, the better.

• Be vocal: keep the rest of your company up to date on the progress, blockers, etc. This will help eliminate surprises. Believe me, six months into the work, there will still be people who had no idea it was happening.

Hopefully, this will get you thinking about some of the challenges of a large-scale, multi-month (or year) project. I’d love for you to avoid some of the challenges I’ve had in the past.

If you’re going through something like this and want a second set of eyes or sounding board, reach out. I offer coaching sessions and would love to discuss these challenges with you in a more in-depth discussion tailored to your circumstances.