Product Scaling
At some point in the lifecycle of our product the challenge of scaling arrises, and with it a whole boatload of complexity. In this blog we’ll explore why that is happening and what you can do about it.
What is scaling anyway?
It seems such an obvious question, isn’t a scaled product just a bigger version of previous iteration? When Robbin Schuurman and I explored this topic in last weeks ValueStream we made some interesting discoveries.
One of the first things that you may notice when talking about scaling that not everyone has the same perception of what scaling is. When we asked for analogies with road traffic we got very different answers.
Some people compared scaling to a busstation in downtown New Delhi: hundreds of smaller and larger teams in a spaghetti chaos trying to move their own goal forward but jamming others in the process.
Others made an analogy to a large intersection of highways that you can find in many US cities and we all know from the movies. Flyovers, bypasses, 6 lanes of traffic etc. Lots of infrastructure and a very complex solution that is impossible to oversee from the perspective of the individual driver.
A third analogy was that of a straight empty normal road through a quiet forrest. Scaling is descaling. The objective is not to accept the complexity, or fight complexity with more complexity but rather getting back to what is really important.
Three perspectives on scaling
It dawned on us that when people talk about scaling they are often using different perspectives.
Often when people talk about scaling it is about team scaling, capacity scaling. Especially when working with agile coaches this seems to be top of mind. It focusses on the human and process side of scaling. How do we grow motivated team? how do we deal with scarce skills? what becomes the cadance? How do they integrate the work into a single product?
When managers talk about scaling, it is often about alignment. How do we know that everybody is working on the right thing? Sure, they are busy but is it effective? what kind of forecasts can we make? What goals aren’t we meeting and why not? What dependencies need to be managed?
Rarely we talk about the one we as Product Managers should actually be talking about: scaling the product itself? How can we increase revenue or impact on customers, increase our efficiency without adding complexity or cost. For example, SaaS based products tend to scale very well, when they are built in the right way.
So first make sure you are talking about the same thing, and if Product Scaling is what we as Product Managers should care most about, then why are we spending so much time talking about things like LeSS, SAFe, Spotify, Nexus etc.?
Eight ways to scale Products as a Product Manager
The year is 1992 and Microsoft releases the first version of Microsoft Office. Why? It is not because the customer expressed a need for it. No, where Excel was obliterating the competition (Lotus123) was Word struggling to compete against Word Perfect. By creating a bundle of products they created a new product that didn’t require much additional work but offered a unique value proposition, if you already had Excel, why buy an additional Wordprocessor. A technique they would repeat many times.
Fast forward 3 years and Easy Jet does the exact opposite. It takes a luxury commodity and strips it down to the bare essentials, leaning out the product in the process. You can still get the additional services and amenities but they are now products in their own right. You can easily outsource the catering to a third party if you want to.
The big black thing on that magnificent frigate of the Royal Dutch Navy is a SMART-L long range ballistic missile detector. Basically you can put the frigate in a convenient spot and defend a region against the threat of things raining down on you, if if they come from space. Great Product right? well it turns out that you can’t put a frigate everywhere, there is this thing called “land”. This is why in the Thales group you can also find a land based L-band radar, but it is considered a seperate product. This allows the teams to optimise for weather and other mission parameters whilst sharing technology. Simplifying a very complex product.
You can also do this depending on technology. You can argue that there are advantages to maintaining a single codebase of, for example a game, for any platform you are deploying it on. But as the company Electronic Arts demonstrated with their popular game “the Sims” there is great value in creating unique experiences on different platforms. Again allowing you to focus.
TomTom started out with a single product, the iconic navigation “box” on your dashboard. Within several years the had may different variants of the device each targeting a specific nice market. Internally there were even more, since some types used different hardware to make use of multiple suppliers. Yes, it creates complexity in keeping track of your portfolio, but it also creates an opportunity for teams to come up with unique solutions.
The other way around would be to leverage platforms. Product Managers do not ask themselves often enough the question: “what can we remove from the product?” Many things have become platformed over the last decade and it pays off to remove complexity of your product. Eg. how, where and when to serve adds, infrastructure etc.
A Canadian robot company switched from industrial robotics to autonomous automated workers. By targeting a new market: warehouse robots and combining the relative dumb industrial robots to smart warehousing “employees” that never tire and learn what products will be ordered next week based on learning algorithms. Oh and they also automatically make way for humans too.
Picknick has become incredibly successful as a “on-your-door” grocery delivery service because they integrated the entire supply chain and went directly to the consumer. It scales the product in a sense that the risks and margins of the chain now absorbed in the PnL of the product itself.
Why don’t we talk about Product Scaling?
Well maybe it’s because we are part of a large organisation. An enterprise organisation and therefor it feels like we need a framework to structure how employees will collaborate. Or perhaps, because we are trying to deal with a lot of complexity in the processes, tools, products, and other structures in our organizations?
Anyway, it seems like we are often trying to solve complex problems, by creating complex solutions and your organization would not be the first one to struggle with problems like:too many dependencies within and across teams, dependencies on knowledge and experience of the Product Managers ….slow decision-making, perhaps?
Some things that you can do (thanks Robbin Schuurman):
- Share your Business, Customer, User, Market and Domain knowledge with the Developers;
- Ensure there is direct communication and feedback between customers/users and teams;
- Ensure the Product Vision and Strategy are clear to everybody. Share your vision often;
- Ensure there is a clear, measurable and motivating Product Goal to work on;
- Ensure there is a clear, goal-driven Roadmap which is known to the stakeholders and teams;
- Ensure the Product Backlog is clear, ordered, visible, transparent and accessible to all;
- Spend the right amount of time with the various stakeholders and Developers;
- Get a Scrum Master on board, who can coach, train, mentor and facilitate the team, stakeholders, and organization;
- Do proper, Professional Scrum, with the support of a great Scrum Master;
Now what?
There are times when size matters, and rather thinking about managing the complexity of Product Management at scale, would it not be more useful to reduce the complexity by making things simple?
