Picture a street with five houses on it, all of them yours. You bought them one at a time, each for a good reason. And every one of them drilled its own well.
Same street. Same ground. Same water underneath. Five pumps running at different hours, five bills for the pumping, and some mornings one house has water while the house next door swears the well is dry.
That's roughly what I walked into at Wiser. The street had more than five houses, honestly. Five is just how many you can picture.
What was on the street
Wiser was a retail-intelligence software company, and the portfolio had been built by acquisition. On the in-store side there were two applications for people to go out and collect pricing information in stores, plus retail execution management and retail intelligence, the tools for doing something with what they collected.
Online, there was market intelligence: how your product shows up on the web, its content, placement, pricing and images. There was MAP intelligence, short for minimum advertised price. Is your product being sold at the price it's supposed to be? Who broke the price first, when, and what stage of enforcement is each seller at? There were four products that did that job. Four. And there were two more for price intelligence and price optimization: given your competitive set, what's the best price for your spearmint gum in that store, in that area, next to the assortment you want?
Each had customers who'd picked it on purpose, and some customers bought several.
Every house had its own well
Here's the part that made no sense once you saw it. Several of those products depended on the same thing: knowing your price and your competitors' prices. And each product went out and pulled that information on its own.
It got stranger. Some of Wiser's customers competed with each other, so each one had us pulling the other's prices, plus everyone else's, at different times. Three companies meant pulling prices for the same three companies twice. A price pulled by one bot at nine in the morning might not match the price another bot pulled at noon. Depending on how and where a bot ran, one would get the price and another wouldn't. A site might let our bots through for one customer and block the same bots for another. The products were independent, so none of them knew.
There was no single place that held all of it. We were pulling millions of prices for multiple products and reusing none of them. That didn't make any sense whatsoever.
The water is the product
So we made the platform a product in its own right. The data itself has value. So how do we clean that up?
If the platform is plumbing, it's a cost center, and cost centers get squeezed. If the platform is the product, the clean, shared, trusted set of prices is what customers are actually paying for, and every application on top is a different way of using it.
The MAP products showed the whole range. One of the acquired MAP products just delivered the data as a feed, with its own name, its own packaging and its own sales motion. At the other end, customers were looking at the same MAP prices inside Wiser's own screens and preparing enforcement letters there. Same water. One house sold it by the bottle, the other ran it through the kitchen tap. They could be one product.
Three merges, all at once
People ask what order we merged in. There wasn't one. We were merging operations, merging products and merging brands, all together, and each one had a different tail.
Operations could move without customers noticing, because that work lived in the platform. But we had to be deliberate about it, product by product, so each one kept serving people the way they'd signed up, paid and contracted for.
Products and brands were different. Before bringing two together, we had to make sure there was real value in doing it. With MAP, we looked at the whole MAP roadmap and decided to build one MAP product.
Let the roadmap do the moving
This is the method I'd steal if I were you.
We built the new product's features in an order that let us pull the old products in as we went. The first set of features served everyone using product A. Then product A's customers moved over. The next set served everyone on product B, and then they moved. The roadmap itself did the consolidating, instead of us just cutting products off and telling people to pack.
Some products did get cut. But customers were given the opportunity to come across to something that already did what they needed. That's how we kept them from feeling the merge.
The two common alternatives both fail. Build one big new product and announce a moving day, and every customer you force to pack boxes will look at what else is for sale. Leave every house alone and call it a "house of brands," and nothing gets cheaper, nothing gets shared, and the reason you bought these companies stays a slide in a deal memo.
One login opens more doors
We also put single sign-on across the portfolio, in the areas where it fit. That also made cross-selling easier. When a customer already has a login that works, giving them another product to test, use or experiment with is a small step instead of a new account and a procurement conversation.
I'd learned that one at Meta. One of my projects there was unifying settings and admin across several products. It's part of why you can now cross-post to Facebook and Instagram at the same time: there's one universal profile underneath. I brought that thinking to Wiser. (At Meta I also worked on bringing many checkouts together, and that's where I worked out how much should be shared and how much shouldn't. "Sixty, twenty, twenty" has that story. "Let them change how they pay" is the billing side.)
What it added up to
More than ten products ended up on one shared platform. Enterprise operating cost came down 20% within a year. Delivery got 40% faster. That's what a shared layer is for: a fix or a new capability gets built once and shows up everywhere.
Where the metaphor breaks
Houses on a street don't share residents. Acquired products do. Customers bought several of them, which is exactly why the shared data and the single login paid off. It also means two of your products may be doing the same job for the same buyer. Four MAP products is three too many. Some houses should be emptied. Just build the new rooms first, and move people when their rooms are ready.
On a real street, the city owns the water main. Here you do. If the platform is the product, it needs its own team, its own roadmap and someone who wakes up thinking about it. Treat it as everybody's side project and it gets nobody's attention.
And wells don't have contracts. Your products do. Merge the operations underneath them all you like, as long as every promise customers signed up for survives the trip.
Try this
- Make one row for every product in the portfolio.
- Add a column for the data each one depends on, and where it gets it. Circle every place two products fetch the same thing separately.
- Add a column for how customers log in. Count the duplicates.
- Pick the two products that do the most similar job. Sketch the features a combined product would need, in the order that would let product A's customers move first.
- Write one sentence about what the shared data is worth on its own, to a customer, with no screens on top. If you can't, you don't have a platform product yet.
Where do you land?
