If you are a General Manager or Director of Product Management, you wrestle with decisions at the portfolio level – not just single products. This means allocating scarce resources (time, development teams, management attention, political clout) across a set of existing products/services and finding extra bits to explore new products. Hard trade-offs of short-term versus longer-term, growth versus harvesting, strategic investments versus tactical revenue, analytical purity versus concessions to executives.

This is a step up from product-level decisions, and worth its own discussion, especially since software/tech products have some underlying complexities that are worth considering. Abstractions are hard, though, so let’s invent a fictional product portfolio: a suite of financial applications (accounting, invoicing, payroll) for small business verticals (salons, dental offices, car washes, dog walking services) built on a shared technology platform. For example, the “music teacher” version is customized/skinned for SMBs who offer after-school piano or trombone lessons, and is marketed/sold through music-related channels.


This a product line already in the market. Resources are organized along product boundaries:

  • Larger vertical applications have a product manager and one (or two) agile development teams. We’re big in hair/nail salons, so that gets dedicated resources.
  • Small or emerging verticals share a product manager and development team. Car Washes and Lawn Care are supported by the same team.
  • Platform has four teams, one senior product manager and two product owners. They build common feature/function across verticals.
  • We want to expand into new markets, so have a quarterly rotation of product manager plus UX ace plus senior developer investigating new segments (house painting, accounting, florists, party rent-a-clowns).  Marty Cagan calls this continuous discovery.

You be shocked to hear that every product manager wants just one incremental development team, and has a business case to back that up. Every product’s backlog has a couple of absolutely-must-haves below the line. If only resources were infinite…

What to do? Your business unit has an obligation to the company to pay its own way and you don’t want to mortgage the future by only investing in current winners. So you (and your brilliant team) need to allocate limited resources toward

  1. Supporting and growing current vertical applications
  2. Growing and scaling up the platform
  3. Adding promising new verticals
  4. Adding a second platform or inviting outsiders to use the platform directly

[Hint: there’s no magical, perfect, general solution. In the real world, we’d need to do a heap of analysis, collaboration, market validation, modeling, and getting out of the building. For now, I’ll invent relevant facts.]

Where to Start?

We’re surely not being equally successful in every vertical, so let’s look at which applications are succeeding. That implies some strategy and quantitative goals (often missing or unstated) as our basis of comparison. For instance:

We should have top-three market share in each vertical and be at break-even within two years of launch, and
We should harvest in slow-growth verticals so that we can over-invest in new or growing verticals

With a nod to BCG, our market-weighted portfolio might look like this:

dog-cow-platform2Salons are overperforming our model, whereas dentists and pet food stores are (ahem) dogs.

The spreadsheet jockeys from Finance are already off to the races, recommending the demise of some applications and extra developers for others, but we can’t let one short-term metric drive the business. Market results are an opportunity for thinking and customer discovery and hard work.  A chance to ask why we are underperforming in some verticals and succeeding in others  Let’s:

  • Interview 4 channel partners and 10 veterinarian to find out that regional veterinary councils recommend software solutions. We’re missing the marketing/references/business development boat, which is not an engineering issue.
  • Follow a few house painters around, and notice that none of them have laptops. Early adopters have tablets, but are rarely near Wi-Fi, so we might need to refit our product for slow-cellular-to-iPad. Are there enough iPad-toting painters to make this a worthwhile investment?  Is this mirrored in other segments?
  • Salons are all about the personal touch, so logos (white labeling) and email campaign integration are hot buttons for them. But our logo customization better be as easy as picking the right nail color.

Etc. The numbers never tell the whole story. But they are useful in triaging our time and deciding which analytical rabbit holes to jump down.

Ultimately, some applications will be defunded or sunsetted to free up talent for more promising apps. But let’s wait before making that call…

Platform Thinking

Every platform business battles over what’s in the platform and what’s in the customer-facing applications.  Our app teams want to push down anything that smells of infrastructure, freeing up their cycles for new features. Our platform team wants to meet the broadest set of cross-application needs while also protecting our –ilities (scalability, availability, extensibility, security).

And simple voting doesn’t always get us to the right answer. We might notice that half of our app teams are demanding improved goods/inventory management… all for segments where we are failing. So let’s sort apps into winners and losers, apply a fresh analytical eye, and get out of the building to quickly test some theories.

It turns out that we’re mostly winning in pure service segments (salons, car washes, dog walking) that sell little or no physical goods and so don’t need to track much inventory. We’re mostly losing where inventory management is critical (pet foods, auto repair, fashion accessories) because they sell lots of physical stuff.  It’s time for some crucial collaboration among platform architects and product managers and UX leads to explore whether (a) inventory management is a trivial extension to the platform, or (b) tracking and accounting for physical stuff is a horrorshow 15x bigger than today’s entire platform, or (c) competitors who started from the inventory side already dominate these verticals. Notice that this is a strategic decision about the markets and customers we will serve, not simply doing what our internal customers ask of us. Where we spend our money implicitly defines our priorities.

Also, it’s worth looking at how much of a platform business we really have. We may be able to spin out new vertical applications in a few weeks each, just adding new “skins” and terminology. Alternately, we may be doing 80% of the work in the app teams, and our platform is really a handful of low-level modules. Which are we?

Small-big-platform2In the first case, we may have a fresh business opportunity letting development partners create their own apps on our platform. In the second case, it’s time for a serious come-to-Moses discussion about architecture and technical investments.

What About New Markets?

Finally, we have a small team searching for promising new applications. Since there are hundreds of possible SMB service segments, we want them to apply a combination of classical market analysis, customer validation, and strategic thinking. Our trio (product, UX, engineering) can start anywhere they choose, but I like the MBA-meets-Lean approach:

  • Quickly pull some (free) employment statistics or segment numbers. What are the 20 largest SMB categories?  Where can we start today?
  • Of those, which “feel” the most like our successful segments? Ones that don’t do a lot of inventory tracking or need HIPAA compliance?
  • Get our asses out of the building, and meet a half-dozen folks in that business. How are they doing financial management problem today? What gaps do they tell us about, and do we observe any that are less obvious? Should we dig deeper or throw this segment back?  What did we learn this afternoon that can shape our actions tomorrow morning?

With energy and focus, our small team should be able to tear through 3 or 4 categories a week, and form ever-better hypotheses about the intersection of what-we-have-today and what-they-say-they-want and how-we-could-improve-our-stuff.  Some of that filters back to the existing platform and application teams, while some informs our decisions about build new offerings.

Periodically, you (as the GM or Director of Product) have to pull the smart folks into a room, collaborate intensely, and make tough decisions about re-allocating the folks you have. In its simplest form, your investment model is a pie chart, which you can track and adjust.

portfolio-pie3Call it strategy, or portfolio review, or lean decision-making, or product management. But make sure you do it every quarter.

Sound Byte

Portfolio management is where strategy meets market demand meets product-level resources.  If you work at the portfolio level, don’t simply roll up decisions from your individual product teams and don’t blindly apply corporate mandates.