Order of operations: Why can’t we have that yet?
Before making optimizations that require significant work or a system rewrite, do what you can to validate that the juice is worth the squeeze.
Autonomous Humanoid Robots in every home, flying cars, outer-space resorts, and that “simple” product feature you wanted to release last quarter. These things all have something in common: They have dependencies that must happen before they can become a reality.
Those dependencies could be architecturally related, or it could be you still need to validate the idea before engineering is comfortable spending the next 6 months on it.
Whether in a Technical Product Manager role or not, you will encounter large-scale engineering projects that need to be done. This is a near-daily occurrence in my Product Management life. I ran into this more than once just this past week.
Imagine wanting to introduce a new feature, only to realize that the entire system needs to be re-architected first. Even a seemingly simple task, like adding an icon to a button, can lead to a complete overhaul of the design system. And if you're thinking of adding a subdomain, be prepared to set up a new proxy or load balancer and rewrite the core routing handler. The dependencies in engineering projects can be pretty complex.
Does any of this sound familiar?
I’ve been on multi-year development projects and have had to support legacy versions alongside our new version for years. We want quick wins, but sometimes, we must tackle these long-term projects to make the most impact. If possible, it helps to set up a targeted team to tackle this while others can continue to make advancements elsewhere.
Sometimes, an entire rewrite seems the easiest way to go, but it’s rarely the answer. You could create a separate system, rewrite a portion of the code, or rewrite one section at a time.
At a previous company, we had two teams doing rewrites around the same time, and both took different approaches. One broke their monolithic system into chunks, re-writing a portion at a time and gaining improvements along the way. The other built an entirely new system. The new system seemed like a great approach, unencumbered by legacy issues.
However, few benefits were seen from that two-year project, and ultimately, they had to add all of those changes to their legacy system because they couldn’t convince their users to rewrite all of their systems to work with the new platform.
In contrast, the team that rebuilt in sections regularly made improvements for their users despite some challenges. At one point, a data model changed, and our users had to adapt to it, but at least it was a slight change they could handle and didn’t require 12 other teams to rewrite all of their logic all at once.
Those were large architectural projects, but what about something smaller? My latest challenge has been wanting to send discount codes to segmented groups of users, but before I can do that, some things need to be remedied:
We need to feed more data into our marketing CRM to have the correct data to segment our users for email targeting.
We must be able to generate and handle discount codes in large quantities and with minimal effort. This will significantly streamline our discount management process.
We need consistent tracking and attribution to know if our campaigns are successful.
We’ve had basic campaigns before, but we can’t offer more sophisticated discounts, like volume-based discounts; we can only offer a percentage—or dollar-based discount.
In this case, infrastructure changes are needed to get where we want to go (eventually), but I need to show the value before we can justify that. I need to find a way to test volume-based discounts with minimal effort.
Validating
What will be the value of this rebuild or long-term project?
Before making optimizations that require significant work or a system rewrite, do what you can to validate that the juice is worth the squeeze. The first step may be to have more data so you can analyze the performance of an existing system and set a baseline. System-level data and user interaction data can be super helpful here. Think about how you will test for success after you launch, and ensure you can measure that now.
In addition to existing data, opt-in forms, customer surveys, user interviews, and customer reviews are all great places to get quantitative and qualitative data to help show the value of a new idea. This might be the first stage before starting to plan your project.
Try to estimate the revenue impacts as well. Don’t just say, "If we convert even 5%, we’ll make millions!” Get real-world data as much as possible. Methods like a “fake door” test will take minimal effort and help you learn how your users would respond. An excellent resource for this is Alberto Savoia’s book, The Right It.
Where there’s a will
Can you do something now to prove the concept and deliver value? Is there a low-cost way to validate before you start building? In a previous company, we did this with a Looker Studio (Data Studio) Dashboard to validate a B2B-facing dashboard we wanted to create for our insurance Carriers and Brokers.
Plenty of no-code or low-code tools are out there to help with this. Retool, for example, is excellent for building internal dashboards and administrative systems.
Sometimes, you can’t avoid it
All the potential value in the world won’t get your feature out the door if it requires an entire rewrite, and there are other more valuable (or even less demanding) opportunities in front of you, especially if you haven’t done the work above to show the value.
But if you have, and you’re definitely going ahead with a large scale project, there are plenty of things to consider before you start on this journey.
In my next post, I’ll write about how to keep a long-term project on track. I’ve had some experience with this 😅 so I will share my learnings with you.