Monkeynoodle.Org

Often your first product manager job is for a module on a platform, a single feature of a complex product, or a simple standalone product. This is because, while of course difficult, those are a lot simpler than managing a platform. When you product manage a platform, you lose a lot of the simple answers to important questions:

• Who are your customers?
• How do you measure success?
• How do you capture value?
• What are you even shipping?
• How do you do marketing?

Luckily all the old problems are still there, but now super-sized:

• What about capacity planning?
• How do you prioritize?

Plus a special new one:

• Increased delay from action to feedback

Let’s get started!

Who are your customers?

In a more “classical” product manager position, the customer is the person who gives your company money. A platform product manager is often at least one step removed from that… they make a product which enables the use case that the customer wants to buy. In some cases, the platform PM might be supporting a system which isn’t even connected to customers buying things at all: internal infrastructure projects can be run like products for instance, or maybe your product is a package of tools that field engineers use to produce customer success on a T&M (Time and Materials) basis.

The definition of “customer” in these cases should be the people who directly work with your results; if there are folks who exchange money for the product that’s great, but by definition a platform also supports “customers” who choose to or are forced to use it. If you have internal teams or partners who are building products to sell on your product, they’re your customers also. If you make an infrastructure as a service system for your company to use, then the teams in your company who use it are the customers, even if they only pay in internal funny money.

These customers might not consider themselves customers; it can be difficult to get them to give you the time to research their needs and understand their priorities. Culture matters, but perseverance can often carry the day. As people discover that you’re professional and diligent and sincerely want to help, they’ll warm up fast.

How do you measure success?

The easy mode answer for measuring product success is Money! Whether your organization counts that as GAR (Gross Annual Revenue), NAP (Net Annual Profit), ACV (Annual Contract Value), ARR (Annual Recurring Revenue), or something else entirely, it’s nice to be able to point at your product and say “We made money”. What if your product is a platform that all products, successful or otherwise, are sharing? The sensible answer is of course to share the good and bad outcomes alike, but somehow that starts to get really difficult if the successful products claim success is theirs alone and the less awesome products blame platform shortcomings. Even without that, the reality of bundled contracts and enterprise sales mean it’s difficult to say which SKUs (Stock Keeping Units) in the price-book “deserve” credit for which dollars in the contract. SKUs are thrown in for free to push the overall contract to signature, SKUs are inflated in value to fit a customer’s budgetary windfall, and the ASP (Average Sales Price) of a given product can wander around like a drunken sailor, usually very far from the MSRP (manufacturer’s suggested retail price) that was suggested at product launch. Here’s a common pattern for a new product on an enterprise platform: it’s thrown into a deal for free at 100% coverage to land that customer in year one; year two the customer has found some utility for the product and buys at nearly full price for 10% coverage; year three they want the product at 80% coverage, but pay half price. Is that product successful? Profitable? It can be tough to get anyone to even sit down and do the math, or do anything with the results of that math.

Faced with this complexity, the platform product manager often needs to find other ways to measure success. Money is great if you can get it, so you should totally wade into the stuff discussed in that last paragraph; just be aware of all the salt that those numbers will need. In addition, I like looking at delivery and stability metrics. As a platform, you need to be dependable and functional, so count up features delivered, nines supported, and critical issues squashed. That’s a slippery slope to measuring quality, but just because it’s hard is no reason not to try. You’re aiming for an executive dashboard, and possibly need to make some proposals.

How do you capture value?

Speaking of money… where does your platform product sit in the value chain? Would anyone buy it on its own? It’s not uncommon for a platform product to be quite attractive to early adopters and technologists, but need product modules to land and expand in mid-market customers. That produces an interesting pricing challenge. Another way to think about it is the famous AWS story, an internal platform that turned out to be useful for the larger world. That said, not all platforms are right for going to market with, just as not all cool feature ideas are standalone products. The only way to find an answer to that question is to talk with the people you think might be buyers of the platform and get feedback.

What are you even shipping?

A platform product often has little to no visibility for the buyer or user; it’s just a thing that needs to go into the upgrade awareness matrix when they want to do something with a new feature that it enabled. Often its updates pass invisibly, just making the mid market product use cases work better. That means the product managers of those products don’t have to know much about the platform either… so they’re going to pull you into calls by surprise. You’ll need to be able to speak authoritatively at a high level about the technology of that platform. What it does, why, and why new technology alternatives are or aren’t being considered. This can produce something of an existential crisis for the platform PM working in a feature-driven company. In fact, you might even find yourself in some trouble if it’s not apparent what you’re doing to make things better, so communicating the plan and progress is important. I’ve never had so many standing one-on-ones as the times when I’ve been a platform PM; it’s definitely easier as a product PM, but I’ve greatly enjoyed each of my stints running platform or parts of platform.

A platform product can have huge blast radius; if it breaks, everything on it does too. There’s a couple of paths you can take to mitigate that; one is CI/CD (continuous integration and continuous deployment) with feature flags or roll backs, and the other is tick-tock release cadence. In the first, each change is small, change is continual, and big changes are hidden behind feature flags until they can be safely used. This can work great, especially for a SaaS with clearly defined API borders presented to the world. Alternatively, a team might elect to roll-back the changes… this is a lot more difficult than it sounds in enterprise software though, and to be honest I haven’t ever seen it done. Instead, those shops usually restore from backup and then deal with a different set of problems.

The other way to ship a platform is establishing a quarterly or even bi-yearly cadence of releases, then following a tick-tock development pattern. Tick, new features. Tock, optimizations and maintenance. This is easy for platform consumers and sales teams to plan around; where CI/CD’s goal is to avoid requiring anyone to plan, the tick-tock development pattern is designed for teams that do make plans and work to them. There will still be complaining about the plan, but at least the plan exists.

In either case, if you ship to on-prem then the bane of your existence will be customers that refuse to upgrade the platform but want the products built on it to become better. Of course, some SaaS’s have found ways to live this hell as well: allowing some customers to stay on old platforms for years and years while others move forward with updated technology.

How do you do marketing?

As a platform PM, I’ve had this experience all too often: a freshly hired PMM (product marketing manager) shows up in my calendar and has been assigned to fill the empty spot of platform marketing.

• “Which quadrant are we targeting?” Well, all of them… eventually. This platform currently enables products that compete in Retro-encabulation, Fromulators, Kaiju Brain Emulation, X of course, and Giant Robot Interfacing. We’re also struggling in the Y market, and about to launch some VR goggles.
• “VR Goggles, can I market that?” No, that’s Alice’s job. Someone’s already writing marketing for each of those products. You’re supposed to market the platform that makes everything work.

Sadly, I’ve found a lot of marketing people unable to get past this hurdle. The good ones are amazing, so be appreciative if you’ve got one who can do it. Success patterns might look like this (assuming the CMO (chief marketing officer) agrees with these being valuable outputs for your fresh PMM to produce):

• Understand the early adopters who love the platform for what it is and market to them. A quirky grass-roots campaign that finds people who solve technology problems where they work and play. If you’re still small, this is easier… it’s well, just marketing, all of it, and a PMM who’s focusing on the product quadrants instead of the platform is actually a problem. But if you’re big enough that the products on the platform are respectable businesses in their own right, it can be challenging for a platform marketing voice to be heard.
• Enable the other product marketing people with content pieces that make their jobs easier. Prebuilt materials that ensure consistent and punchy value pitches across many markets so your platform and company are recognized as a coherent mission instead of a conglomerate of unrelated things. Maybe these materials are built around such high clarity, high value use cases that they can even be used to drive testing.
  A good platform marketer can pitch the story of a platform as an engine. The products on the platform? They’re cars, and you market the cross-overs and the sports cars to their separate target audiences. The platform? You might market that to everyone (Mazda’s Zoom Zoom campaign), and you might even spare some thoughts to the wild ones. In enterprise software… that’s the customer who rebuilds a production system on your platform not because you think it’s an addressable market, but because they want to do it. The right thing to do is support them as a community, and marketing can help with that.

What about capacity planning?

As a product manager for a single product, you’ve got a team… it’s not as big as you want, maybe it’s just one person or maybe you’re really unlucky and there’s nothing at all… but the effort of capacity planning is pretty direct: You’ve got X things you want to do, and you’ve got Y resources to do those things with. Ah, but if you’re building a product that’s on a platform… rising tide lifts all boats. Maybe some of your problems can be solved from the platform?

When you’re responsible for the platform, you’re the recipient of all of those hopes and dreams. Every product has needs, and looks to you as a potential pool of resources. Sometimes they’re right, and the best way to solve a problem is to move it into platform… and sometimes you’ll need to tell them to build what they can now and wait a while for that best solution.

Platform PM capacity planning can be tough, because the pace of delivery is always more constrained than the desire for throughput. Some PMs respond to this pressure by using a prioritization process and giving their most accurate estimate of when something might get done, then updating the queue regularly. Others just tell everyone “no” at first and wait to see which projects can’t find alternate success paths and come back to try again. Personally, I prefer the over communication route, but I’ll admit that I’ve been accused of being confusing when I give other PMs “I’d like to do that, and will add it to the stretch list for next quarter” answer instead of a “yes, we’re dropping everything to do that now” or “no, it will never happen, kindly go away”.

I’ve found the most successful pattern for delivery of a platform to be Agile sprinting. There’s a lot of ideas wrapped under that phrase, and some are bogus; the three most useful components are thin steel thread, locked scope sprints, and definition of done:

• The thin steel thread is a minimal implementation of the needed capability, which goes from top to bottom. Instead of fully fleshing out all possible features across the whole domain, you work with the consuming product managers and engineers and the platform engineers to determine the minimal set of changes from platform APIs down to platform internals to support the most important use case that the product needs to solve. You then make sure that’s upgrade safe, scalable, secure, and can be disabled if it goes wrong. The ideal deliverable is complete, minimal, and could possibly be expanded later.
• Locked scope sprints are the most critical tool for success. A sprint is a time period and a prioritized set of tasks that the team commits will be completed at the end. Once the sprint has started, you must complete the things that were committed before starting new things. There are two exceptions: a Customer Down situation stops development while that customer issue is resolved, and a high priority task can take the place of a lower priority task that hasn’t been started yet. Although to be honest, if you’ve got un-started tasks in the sprint, your sprints are probably too big. I have left companies over failure to keep the in-flight scope locked. It’s disruptive to development teams to change projects and shelve unfinished stuff, which almost certainly doesn’t get returned to and almost certainly cannot be picked back up cleanly because the surrounding interfaces have changed. More importantly, every committed priority has expectant consumers, and a long tail of disrupted promises when it is delayed (and therefore most likely not delivered). An executive who breaks sprint is voting no confidence in product management; if this happens, you have a fundamental conflict and must either work to fix the relationship or leave.
• Definition of done is a concept that I love, but can be more flexible on. In the most strict implementation I’ve seen, this concept was implemented as automatic tickets. For every use case generated and brought into sprint, the system would generate tickets for testing, documentation, integration review, and demo review. A new platform feature might not cause ripple effects all through the products that sit on it… or it might. A ticket as a reminder to make sure isn’t a bad thing. That said, most of the organizations I’ve worked at haven’t had the resources to be this rigorous, and it’s been the responsibility of my PM team or their EM partners to look for those side-effects and address them. The important part is a checklist, mental or formal or other, which helps the team to answer if the feature is ready to face customers. If you haven’t done all the things to ensure delivery is complete and no loose ends are dangling, then you’re not done and can’t go on to the next feature.
  A shorter sprint makes it easier to be flexible to context changes. A long sprint means you can solve bigger problems. A week is the minimum. A quarter is the maximum. A month is pretty good for a platform.

How do you prioritize?

Capacity planning means prioritization… which means making choices between the products depending on your platform. Rest assured that no one will be happy with your choices. Maybe you can make everyone equally unhappy, or maybe you can make the biggest impact product happy and leave everyone else very sad.

I like to allocate resources based on the CPO’s strategy. If that says 30% to Retro-encabulators, 30% to Frobulators, 30% to Kaiju Brain Emulation, 10% to new projects… then that’s how I allocate bandwidth to products. I ask the product PMs to prioritize their asks to platform, and we knock them down in order. You give me the three things you want, I align them to a team, delivery pops out in due time.

To be clear, that can still fail in lots of ways; maybe the product PM’s ask is insufficient to capture product-market fit, maybe the ask isn’t feasible but no one knows until they try, maybe the engineers try a radical new approach that just doesn’t work. Still, it limits the scope of such failures and keeps your gambles in line with the organization’s plan. Maybe you want to gamble bigger, though. Maybe you believe that the Retro-encabulation and Frobulation markets can go on a minimal KTLO (keep the lights on) budget and platform should focus 80% of its effort on Kaiju Brains. Make that argument to the CPO and CEO before you act to allocate, or else it’s your head on the line if the Frobulator product line craters and the Kaiju market fails to materialize.

Increased delay from action to feedback

The last gotcha in today’s discussion of platforms and products… delayed feedback loops! The risk in a product-platform relationship is that there’s naturally some amount of delay as a result of the platform product relationship. A tractor-trailer full of cars has a wider turning radius and slower acceleration profile than any of the cars on that trailer. But the worst case scenario is driven by each step on a journey moving in serial.

• The customers ask product teams for features, the product teams prioritize and evaluate.
• The product teams decide to ask platform for features, the platform queues those features up.
• The platform delivers the features, and the product team queues adoption up.
• The product team delivers the features to the customers, where context has changed and the features are no longer impactful.
  There’s a few PM tools to deal with this. Saying no to most feature requests and filtering to the really impactful problems is a good one. It also helps to focus on shortening feedback loops. As platform, the earlier you can get product working with your stuff the better. The sooner you’ve got a prototype API for product to build on, the better. The easier it is for product to feature-flag and test your new capability, the better. The easier it is for customers to access new features, the better. The sooner that customers see designs, hear ideas, and discuss what’s feasible, the better. These activities drive, if not parallel execution and delivery, at least parallel planning.

Conclusion

Platform is a great way to deliver products, and a wonderful opportunity for a product manager. It’s not without challenges, but I hope this has been a useful guide to addressing those challenges.