Product management is one thing. But what if you have an entire portfolio of products to manage? Multiple products, which may or may not be functionally related, possibly aiming at different audiences, all launched at different times.
Obviously, portfolio management brings more complexity and more raw workload, because there’s more to manage. Hopefully your team has grown to accommodate this complexity. Even if the team is appropriately sized and skilled, you’ll still run into some challenges that don’t usually come up in managing a single product.
Challenges
Most product portfolios aren’t pre-planned. A company starts with one product, then builds more over time to accommodate newly-identified needs and opportunities. This results in a set of products that don't always work together as well as the business or customers like. The products often have differing design standards, may be built on different technologies, using different databases, etc.
From a customer perspective, the experience is disjointed and possibly even confusing. Things work slightly differently in different places, everything looks just a little bit different in an uncanny valley type of way, and hey - why do I have to log in with a different account over here?! The overall effect, even if it’s not entirely off putting, is usually a vague “sloppy” feel. It’s not great for brand value, and probably not great for retention either.
On the delivery side, everything has to be built and tested separately in every product. Is there a new password policy? Implement it across each product. Change to some brand elements? That’s multiple update projects. A tweak to a feature that happens to be duplicated a few times? Well, now you have to make that change - you guessed it - a few times. And test it a few times.
All this duplicated effort is not only costly, it increases time to market. And of course, the likelihood of introducing bugs goes way up. And honestly, it’s not interesting work for delivery teams!
Adding to the overall cost is storage and computing, which is more expensive with every new product. This is especially true if they’re all on different platforms and hosted separately.
Finally, from a product management perspective, portfolio management requires tradeoffs. A change to one product may impact or be dependent on others. Assuming you have one budget with which to manage the portfolio, work on one product necessarily lessens resources for the other products. Prioritization becomes far more complicated and stressful.
Wrangling the portfolio
Clearly, to manage the entire portfolio, your role as product manager needs to shift from day-to-day management to a more strategic, “big picture” view.
The way I personally approach portfolios is to see how the individual products might work together as a single platform or portal. That doesn’t mean you need to replace everything with one single, gargantuan product - in fact that’s often not the right move. But it helps to view the portfolio as a whole entity, rather than several separate wholes.
I’m a big fan of standardization and modularity.
Look for opportunities to standardize around a single technology stack, a single design system, and a single set of processes or experience flows. Experience, effort, and cost all benefit from every shared element.
Map out current state and desired customer journeys. You may find that certain audiences are jumping around among products. That’s a clear opportunity to streamline the journey by streamlining the portfolio.
For example, if a company offers a set of training courses, and their local offices host a different set of training courses, the course directories and registration apps might be completely separate - found in different places, looking different, and requiring different information to sign up. There are organizational reasons why that happens, but the customer doesn’t care - they just want to take some training!
You may also find during this exercise that some products naturally work well together, feature-wise, and could be combined. But because they were built four years apart, they are completely separate.
Easier said than done
Updating multiple products to make them more standardized, more streamlined, and possibly in some cases combined - that’s a lot easier to type out than it is to do. This is obviously not a one- or two-sprint effort. This is a long-term, multi-year vision.
You run the risk of alienating customers if there are too many changes too quickly. Or if change management and communications aren’t on point. Or if you make interim changes that make things not work as expected. And you also run the risk of making the experience even more confusing in the short term.
It might be tempting to try to build an entire new platform in the background, and then launch it with a big, flashy bang. That is incredibly difficult and risky. For one thing, it’s an outsized amount of work that will consume your delivery team, meaning you won’t be able to roll out updates or new products in the meantime. And customers only wait so long.
For another thing, project managers know that as projects increase in scope, they increase exponentially in duration, cost, and risk. That kind of undertaking really isn’t advisable in nearly any circumstance.
Getting from here to there
So the real challenge here is in roadmapping a path from current to future state. In a way that’s achievable by the team and enjoyable for customers.
As an aside - and I promise this is relevant - I used to do a lot of word games and puzzles. There’s a little word game that assigns you a five-letter word, and you have to morph it into a completely different word, one letter at a time. The catch is that each change must result in a real world. So you can do PLATE > PLANE > PLANT but you can’t do PLATE > PLATT > PLANT, because “platt” isn’t a word.
Your job in roadmapping is the same: make one change at a time (or realistically, a few changes), and each change must result in a viable, usable portfolio. Plan out where you want to end up, in broad strokes, and establish a game plan that makes smaller, discrete changes until you’ve reached your destination.
Maybe you institute a single design system for all products and migrate all products to it, THEN work on bringing them together. Maybe you can architect a unified back end and start moving certain pieces over behind the scenes. Maybe you go the “whole big platform” route, but launch that platform as just a single product, and only you know you'll be integrating other product functionality over time :)
So much to consider
The best approach depends on lots of factors, including team capability, customer needs, the current application architecture, and more. And communication - with your team and with customers - will be critical during the process.
This is not unlike rebuilding an engine while the car is driving, and it won't be easy. An experienced product or portfolio manager can sort through all the factors and work with the technical team to devise the best plan - and adapt to the inevitable challenges that pop up along the way.