In the first post, we established that digital products (i.e. connected devices) are an intricate part of our everyday life and yet pose significant challenges in development. At the end, I outlined three key learnings along the lines of prototyping, platforms and connectedness. In order to make digital product development more iterative, I elaborated on the first part of the framework in the previous post.
- Expand Prototyping – rethinking prototyping to speed up development while reducing risks
The second of the three-part framework is the following.
2) Choosing Platforms is Strategic
The first question to ask is ‘what is a platform?’ For an engineer working mechanical products, a chassis is a platform. A software developer considers an operating system as a platform to build applications. A web developer on the other considers a framework to be a platform to build micro-services. In essence, a platform is a ‘base to build on top of’. With digital products, there is a need to elevate the decision process around platform choices from a tactical level or operational choice to a strategic level.
Platforms choices need to be strategic, not operational or tactical
A Modular Starting Point
When making platform choices, focus on being modular and build in the ability to pull apart of put components together within a platform. This flexibility gives the wiggle room to adapt to new requirements over the next years. In light of constantly changing requirements, modularity saves the day. Yet another benefit is accelerated time to market on subsequent product generations. With the baseline for the product being established, there substantial drop in uncertainties and hence higher predictability on time to market. Tesla is a great example here. The drive-trains (or power trains) made by Tesla, had such a level of modularity, that Tesla could license this technology to other carmakers like Mercedes and BMW. Modularity gave an interesting twist to Tesla’s business model, adding an unconventional revenue source for a car maker.
Choices to persist longer than one generation
This is an almost obvious, yet underrated decision parameter. Platform choices should last longer than one generation of the product. Amortize platform investments over multiple years. Invest time, energy and thought into the decision process in choosing platforms, helping avoid technology obsolescence. Build enough juice in the platform to last for a few generations, else you are stuck with your choices. You will be forced to switch platforms if there’s not enough future-proof ability built in the platform. Even worse is having to add yet another platform in an existing fleet of platforms. It just adds complexity to the organization.
Beware of Platform Debt
Devices once shipped, are in the customer premises. Maintenance and support are a part of the brand promise. This eats into the capacity of teams developing and maintaining platforms in the organization. Constantly switching platforms causes engineering teams to keep reworking the same set of capabilities in the new platforms, leaving less room for addressing new evolving needs. With every new platform added, maintenance teams have more to support and maintain. Engineering teams are then struggling for capacity, trying to balance between new development and maintenance – thus accumulating ‘Platform Debt‘. A higher focus on maintenance adversely affects motivation levels of the teams working on them. Limiting the number of new platforms introduced for generations of the product lines helps reign in platform debt. Investing additional effort in platform choices and looking beyond the short terms substantially reduces maintenance efforts while allowing room for new development.
While these seem like obvious choices, organizations struggle with them as the underlying issues keep accumulating and aren’t visible before it’s too late. Typically it is the Product Manager’s responsibility to create visibility for all stakeholders across the organization. You need visionary product managers to look beyond the short term. Rethinking the platform choices on these lines gives the desired flexibility to build an iterative product development process for connected devices.
In the next post I will elaborate on the third and final part of this framework.