Today, I want to offer some insights into key differences between a Product, Portfolio and Solution in Product Management world. I have often observed companies and people struggle a tad bit on what exactly these are and how to evolve their Products and Solutions in a logical fashion. I will try to offer my simple, but effective way of looking at these terms. I will inherently use technology industry to describe these.
Firstly, before we talk about the Product world, let’s take a step back and take a look at the world without Products. The best word I could use to describe this world is ‘Projects.’ In this world, people would come together and solve a particular problem for a given amount of time, for certain budget and target certain functionality. After the end of project, they would usually disperse and move on to a different project. That subsequent project could be a continuation of the earlier project or could be a completely different one. In a big organization, there could be several Projects getting executed at the same time with specific and individual objectives, goals and problems to solve. Now, let’s pause for a moment. What’s not so good about this world? I would say it’s ‘waste.’ More often than not, organizations would not deliver goods to customers or end users, either internal or external, in a strategic fashion. There might be a lot of duplication across Projects and Projects could pull the organization in opposite directions.
Now, let’s talk about what a Product is? Picking up from the ‘Projects’ world, ‘Products’ could be described as ‘Strategic and Perennial – theoretically speaking because Products do die – Projects.’ Essentially organizations decide to evolve certain functionality in a strategic fashion without duplication and also by preserving the functionality know-how by keeping a structured code-base and keeping people together as much as possible and by building functionality on top of existing functionality. This is what Product Managers call ‘Roadmapping.’ Organizations could develop multiple Products each targeting same or different internal or external users. This is much better than Projects world, because there won’t be too much waste. However, one problem still remains. Products could collide, just like Projects, i.e. could pull the organization in opposite directions or related Products could have conflicts, at the least.
This is where ‘Portfolios’ come in. Organizations decided to bring together ‘related Products’ and started calling them ‘Portfolios.’ The key here is to evolve a group of Products that are related – let’s come to this relationship in a bit – in the same direction. This is often achieved by co-locations, same leadership, shared budget, shared code base, and shared Product Managers etc.. Essentially Portfolios have bigger roadmaps that are executed by the Products through their own individual roadmaps. Now, how should or how are the Products related? Usually organizations bundle Products together by market segment they are targeting or by personas they are targeting or by industries or by related functionality etc.. Actually all of these bundling ways are correct and so I wouldn’t lose sleep over this. Now, this Portfolios world is much better than Products world as there is lot more strategic roadmapping happening and so lot more number of Products going in the right or at least same direction. Sure there would still be a bit of opposite pulling that would happen, but organizations could effectively function at this level, to a certain degree.
In Portfolios world, however, there would still be one big problem. In big organizations having multiple Portfolios and Products, the functionality (features) would more often than not gets released sequentially. Let’s imagine a scenario where a customer is trying to solve a problem and that requires functionality from Product A in Portfolio 1, and another functionality from Product B from Portfolio 2. Let’s imagine that Product A hits the market at time X1 and Product B hits the market at time X2. What should the customer do? He would have to most likely wait for time X2. What if that is a considerably later in time? The customer would move on to a competitor. If it’s an internal customer, it’s even more dangerous, as the operations are impacted significantly and the organization could lose Millions of $. You see, ‘Solutions’ exist to attack this simple but the most important problem – ‘release timing.’ Not many Product, Portfolio or Solution Managers actually realize it. Sure, Solutions are created to solve customers’ business problems and they often look at certain Markets or Market Segments and are designed for such markets. And, they require functionality or feature set from multiple Products and Portfolios. But, more importantly, when the Solution offerings hit the market, they ensure that customers can leverage the Solutions from end-to-end i.e. Solutions effectively orchestrate the release management of dependent functionality across Products and Portfolios. In other words, Solutions were created to avoid dangling features.
Solution Execs may or may not have complete authority to execute Product roadmaps, but they would have to do extreme collaboration with Product and Portfolio Managers to ensure that Products and Portfolios work in rhythm to address business problems and market needs and release dependent features at the same time, not just release features strategically.