Skip to main content

14.5 Platforms

The term platform is thrown around a lot. But what is a platform, exactly? Turns out, you regularly engage with platforms of all kinds. Computers, cell phones, and video game systems are all platforms. Invisible structures and tools like databases, programming languages, and systems that power applications are also platforms.

Fundamentally, a platform is a foundation offering core services that encourage third parties to build complementary products that extend the platform's core functionality. You've already learned a bit about software platforms in the context of business models and how they're used to grow user bases. In this checkpoint, you'll dive deeper into the relationship between platforms, products, hardware, and software.

As a product manager, you'll make decisions that affect the visible and invisible parts of a product. Your team may also face specific constraints—and unique opportunities—when developing products for certain platforms. Understanding how platforms work will be essential as you move from product conception to launch.

By the end of this checkpoint, you should be able to do the following:

  • Explain the benefits and limitations of developing products for platforms
  • Discuss the differences between managing hardware and software technology products



What is a platform?​

Simply put, a platform enables growth through connection. A platform's value lies in its core features and its ability to connect external tools, teams, data, and processes.

A platform specifies where—and to some extent, how—software runs. The term platform refers to different types of technology. For instance, a platform can refer to an operating system, like iOS or Android, or it can refer to the combination of hardware and software, like in an Xbox or Playstation video game system. Even the web is a platform powered by browsers that are available on nearly every consumer tech device.

A platform can also be a software ecosystem that invites other companies to build on its core functionality. For instance, the Salesforce AppExchange platform encourages companies to build products that extend the functionality of the Salesforce tool. Similarly, Slack has expanded from a chat program to a platform that allows other applications to provide notifications or services via Slack.

How does this work? APIs and other integration methods play a key role here. These tools make it possible for platforms to successfully plant themselves at the center of an ever-expanding user network.

Why do platforms matter?​

In many ways, platforms power the world. Consumers and businesses rely heavily on platforms every day—when platforms go down, people notice. For instance, Salesforce made international headlines when the company had an outage in 2019. Perhaps not surprisingly, the biggest and most profitable technology products and companies in the world run platforms.

Platforms grow, and become absolutely indispensable, by doing two important things. First, they solve a key problem, which attracts a large audience. For example, Salesforce initially helped marketing and sales teams track customers and prospects, which is a priority for every business. Second, platforms allow other companies to add their services to the original product. For instance, the Salesforce platform now offers add-on services that address many different business needs. Likewise, Facebook started as a product for users to keep in touch with their friends, but it has since expanded significantly. The company offers diverse tools for advertising, and it provides access to companies that want to create products that leverage the Facebook platform.

As platforms integrate more features and data, they provide even more opportunities for developers to create new products for users. For example, many marketing tools now plug directly into Salesforce, which can provide a sales team with detailed information on who clicked on various ads, emails, and web pages. That data gives the team a huge advantage when they follow up with prospects—a sales associate can focus their pitch on what the prospect viewed or specifically searched for on the website. By providing easy access to diverse business information, Salesforce and its marketing tools provide a lot of value to Salesforce clients.

However, this comes at a price. Lock-in refers to the investment and effort that organizations put into adopting products. Consider Salesforce. As a company invests money and energy into its Salesforce environment—customizing it, adding additional products, training staff to use it daily—it becomes harder for the company to switch to a competing platform, like Microsoft Dynamics. This indispensability is fundamental to a platform's success. Not only would the company have to move all of its data from Salesforce to another platform, but it would also need to recustomize the new platform to meet the company's specific needs. For instance, the company would need to reintegrate add-on services, and that's assuming those services were even available on the alternative platform. Many organizations are reluctant to assume the risk and cost of switching, so they stay locked into Salesforce.

This success reinforces itself. Salesforce's dominance encourages companies to focus on developing new products for Salesforce's AppExchange because that's where the clients are. When a company is looking for a client relationship management (CRM) tool, it will gravitate toward Salesforce because Salesforce is flexible, able to be customized, and has the largest selection of add-on features. Furthermore, when that company needs to hire sales or administrative staff, training will be easier and faster—it's highly likely that new employees will have used the ubiquitous Salesforce at previous places of employment.

From a business perspective, this is great for Salesforce. The company's attrition rate—the percentage of customers who cancel their subscription—is less than 10%. As a result, Salesforce's stock price almost tripled between 2015 and 2020. This reflects the power of a platform. Customer lock-in leads to extremely high retention rates, which leads to stratospheric growth.

Lock-in applies to consumer products, too. For instance, you probably use either an iPhone or an Android device. You've bought apps, configured your account, and become familiar with the interface. Of course, switching mobile devices isn't as consequential as switching a company's CRM system. But it's probably something you want to avoid. Overcoming lock-in—and abandoning a tool you're comfortable with—involves significant user frustration and requires a highly attractive alternative.




Software and platform constraints​

When developing software, a development team must consider where the product will function. This means identifying a platform and understanding what it can and can't do.

Typically, software is built for the web, mobile devices, or computer systems. Each of these platforms is rooted in collections of computing standards and commercial products. Those standards and products create both opportunities and constraints for developing products.

Web​

First, what's the difference between the web and the internet? The internet is all of it—the physical infrastructure and everything. The web refers to the services built on the internet. Products that run on the web typically operate in a web browser and are accessed via a web address. There are also web products that are installed on a desktop or mobile device but that can't function without the internet (Slack, for example). These apps use wrappers to accelerate processing that is specific to the device or OS.

Web products have a couple of key benefits:

  • They're accessible on nearly every device. Web products are easy for users to access. Although designers and developers will have to consider certain details—like how a product will look on a mobile or desktop device or how it will render on Chrome or Safari. But these are familiar issues that development teams have learned how to manage.
  • Deployment is really, really fast. A small update to a web product can be deployed to the web server in minutes with no interruptions to the users. Consider edits made to a home page or the addition of new menu options. A team can make these changes and distribute them globally in mere moments. Large-scale updates, such as new product releases, do take longer to deploy. However, much of that time is spent developing and testing the changes, not actually launching the update. By comparison, mobile and desktop apps require users to accept updates or reinstall the upgraded version of the product in order to see any changes.

The most significant constraint of web-based development is that every browser and device affects how a product appears. A web page will not appear or behave the same way on Safari on an iPhone as it does on Edge on Windows 10. However, attempting to account for these variations—even just among the most popular browsers and devices—will add significant time and effort to product testing. And depending on your target audience, your team may decide to forgo fringe browsers and operating systems, like Internet Explorer 11 on Windows 7. It's hard to justify investing in development for outdated technology because older browsers and operating systems have fewer users.

Mobile​

The mobile platform ecosystem is dominated by Android and iOS. (Windows had a lesser competitor until 2014.) It's fairly easy to develop products for iPhones and iPads because they run on a single Apple operating system and the devices have standardized sizes and resolutions. Android devices, on the other hand, vary in size, hardware, resolution, and even the specifications of their operating system. This adds more complexity to Android testing and development—ensuring an Android app works consistently across Android devices takes time.

What are the benefits of developing for mobile? Well, consider this: there are billions of mobile devices in use worldwide. The ubiquity of mobile devices is perhaps the best reason to develop for the mobile platform. Applications are easy to discover and download. The cost to publish apps is modest—a single, flat fee from Google or an annual fee for Apple.

But getting an app published can be challenging. The Google Play Store and Apple App Store have specific rules about what is and isn't allowed in apps they publish. The review process for each version or update often includes a few iterations, each of which takes days or weeks. Then, the app developer must deploy the app in the marketplace and wait for users to download. The marketplace will take 30% of every purchase. If an app costs $1.99, then the developer will earn $1.39 for every purchase.

Users must also download the updated versions of apps; updates aren't automatically pushed to their device. As a product manager, you'll need to introduce new features and improvements to motivate users to update.

Many mobile apps must also explicitly request users' permission to access information on the device, such as the user's photos or location. The app must include a clear explanation of the services it will provide using the information requested. And contingency options (even if they're a little awkward) should be put in place in case a user doesn't grant the app permission to access that information.

Limited battery life is another significant challenge for mobile product development. Intense graphics or complex processing can quickly drain a battery, and mobile users hate apps that drain their batteries. It's important to consider battery consumption during the phases of product design and testing. The goal of any mobile product should be to use only as much power as needed.

Desktop​

Finally, there are products that are built for desktops and laptops. Despite their wider use, these products are often called desktop apps—a naming convention that dates back to the era before highly portable computers. Desktop computers and laptops are much more powerful than mobile devices, have larger displays, and support different inputs (like a full keyboard and a mouse). In many ways, these characteristics put desktop apps at a distinct advantage.

For example, graphics programs like Adobe Photoshop and Premiere use desktops' larger screens and keyboard shortcuts to help users accomplish tasks faster. Likewise, tasks like inputting data and crunching numbers in Excel or Tableau would be poorly suited to mobile devices. Desktops also connect with other hardware easily; they can process data from a linked medical imaging device or a video monitoring system. Although these types of products may also offer mobile versions, the mobile functionality is usually significantly limited due to the device constraints.

The platform for desktop applications is the operating system—usually Windows or macOS (other operating systems, such as Linux, have devoted, but highly niche, user communities). The hardware, screens, memory, and other specifications vary widely among different computers. But for most desktop products, the operating system abstracts away those details, making it relatively easy to create apps that work well on a variety of devices.

Desktop applications usually have to be updated manually—the user must approve the download of an update and run it on that computer. Some users are wary of downloading updates because they aren't tech savvy or they're worried that a new version will break their existing application. They might also be worried about losing features and functions they know and like. The consequence? A desktop app product may never get updated.

Outdated software will cause user frustration because the user is missing out on bug fixes and enhancements. Likewise, if a product depends on upgrades to generate revenue, users avoiding updates will impact the company's bottom line. This combination of challenges is a significant reason why many desktop products have moved to a web/desktop hybrid model that requires users to subscribe for a monthly fee. Adobe's Creative Cloud Suite—which includes both Photoshop and Premiere mentioned earlier—is one example of this.

Software updates can also pose a challenge if your product is aimed at business users. It's unlikely that users in a large company will have permission to install new versions of software. In professional settings, computers are often centrally managed by an information technology (IT) team. This team tests updates before releasing them across the company in order to protect the business against malicious software getting installed. However, it can be frustrating for employees if an update is significantly delayed relative to when it was made available.




Hardware products​

Hardware products are physical devices, like cell phones, laptops, televisions, and other devices used every day to access online technology. These products are built out of physical components—keyboards, speakers, screens, and many more—that are optimized based on their function or characteristics, such as size, power consumption, and reliability.

Hardware products are often built to run certain software products. For example, all Dell computers use an operating system provided by Microsoft, and Dell works with their suppliers to ensure that their hardware components are compatible with Windows 10. Similarly, Amazon's virtual assistant Alexa runs software that allows it to capture microphone input from a smart speaker; it then communicates with Amazon's backend servers and returns results for the speaker to output. Even smart TVs run software to allow the user to easily switch between broadcast TV and online streaming services.

Some hardware products have software that's extremely hard—or impossible—to update. This is called embedded software, and it can be found in devices like a cable modem, remote control, or microwave. This software has to be tested rigorously for reliability and accuracy. Because embedded software is hard to update, bugs can have huge consequences. For example, hundreds of thousands of home routers have been compromised by malware and the inability to update the routers' software.

Hardware products can be designed for specific tasks and built at a lower cost than other types of products. For example, consider an alarm clock. A digital alarm clock can be manufactured for just a few dollars. Or someone can choose to use their $800 cell phone as a clock. While someone with an iPhone may decide not to buy an alarm clock, there are cases when it's simpler to use a dedicated hardware product for a specific purpose. Hardware for complex graphic processing and chips built to mine bitcoin fall into this category. These products can be built at a lower cost and perform far more efficiently than other products, such as a nonspecialized computer CPU. The flip side is that hyper-specialized hardware is inflexible. It's difficult to repurpose or repair these types of devices.

Manufacturing hardware also involves a complex process of designing, building, testing, and eventually distributing a physical product. The iPhone X, released in 2017, began development five years earlier. Techniques like 3D printing and creating circuit boards in-house make the prototyping process faster and cheaper. But even after a product design is final, the team or company may need custom manufacturing machines and processes to bring the product to life. Manufacturing and distribution can take months, and it may be years before a product is available to consumers.

Hardware products are usually built to last for years, and they're tested thoroughly for flaws or defects. But even if a company extensively tests its prototypes, it might miss something. If an issue is not found, it may be reproduced in manufacturing. This could affect only a limited number of items, or it could affect millions of copies of a product. If the issue is severe, it can prompt a product recall. This is an extremely expensive mistake to make. Samsung's 2017 ordeal involving Galaxy Note 7 phones exploding on airplanes due to a battery issue is thought to have cost the company 5.3 billion dollars—on top of the significant damage it caused to Samsung's reputation.

Picking a platform for your product​

As a product manager, you may be faced with making a decision about the best platform(s) for your product. To make that decision, you and your team will need to discuss and answer several questions:

  • What platforms do our users rely on? What does our audience already use?
  • How are users using the platforms?
  • If our target audience is primarily mobile users, what is the breakdown of iOS and Android users?
  • What devices are users already using to do most of their tasks: mobile, desktop, or something else? Which of these tasks connect with the purpose or function of our product?
  • Does the product require a specific technology or piece of hardware? If so, which platforms support that?
  • When will users need to use the product? Which platform is easiest or most convenient to use at those times?
  • Is the user base of our target audience growing, shrinking, or plateauing on any specific platform?
  • What does the future look like for the platform? Will it be replaced, abandoned, or supported several years from now?
  • Does our team have the expertise and resources we need to develop for that platform?

Addressing these strategic and tactical questions will help you make an educated decision when considering the best platforms for your products. And remember: if your product is successful and your user base grows, you'll likely want to expand to other platforms.

When considering which platform to build on, you and your team may also want to analyze the cold, hard data. Some information is available on platforms, devices, and market shares on websites like StatCounter (Global Stats).

As of January 2020, StatCounter and other resources cite the following:

So, consider these hypotheticals. If you're selling a mobile app, should you launch on Apple or Google? You're more likely to make money on the Apple App Store than on Google Play, even though there are far fewer iOS users than Android users. But if you're releasing a free app, you'll probably want to launch on Android because you will have access to more users.

Keep in mind that your specific audience's device and browser usage may not match the general trends. Google Play may have less of a market share, but your research may suggest that Android users are more likely than iPhone users to purchase your particular app. In making platform decisions, you'll need to consider how your target audience's behavior aligns with, or deviates from, that of the general population.

Stacks​

When developing applications for the web or backend services for apps, the combination of the platform's software, hardware, and services is called a stack. A stack consists of these components:

  • The operating system that the software runs on
  • The web server that handles the HTTP requests
  • The programming language that runs the application your team creates
  • Frameworks built using programming languages that provide APIs and features for your developers to connect the systems
  • The database to store information and settings for the product

The developers on your team will navigate the complexities of working within the stack. But as a product manager, you should be familiar with these concepts and structures. For example, one of the most common stacks that you may hear about is LAMP:

  • Linux is the operating system.
  • Apache is the web server that handles incoming and outgoing HTTP requests.
  • MySQL is the database for storing data.
  • PHP is the programming language that the team uses for development.

All the parts of the LAMP stack above are open source—in other words, they're available for public use and have no licensing fees. Open source projects encourage product development because these tools and the programming involved have become widely adopted standards within the developer community. When working with a familiar platform stack, developers are able to focus on developing the products that will use the stack components. The development team can easily modify and add to the stack if necessary.

Here are variations of stack components that are widely used:

  • Operating systems: Linux, Windows
  • Web servers: Apache, Nginx (pronounced "engine X")
  • Databases: MySQL, MongoDB, MariaDB
  • Programming languages: PHP, Ruby on Rails (often called Rails), Java, JavaScript (often called JS), Python
  • Frameworks: Redis (for temporary storage), Node.js (a JS framework for creating services), Express.js (another JS framework), Angular.js (a JS framework for frontend applications)

A stack runs on computer servers that a company owns or rents in the cloud, and a company's engineering or operations team manages all these components. This is how cloud-computing services like AWS fit into stacks.

As a product manager, you don't need to know every kind of stack and how each works. But you should have a fundamental understanding of what each stack component does, how your product works with the stack, and how to discuss functionality issues with your team.

For example, imagine your product's version of PHP is out-of-date. As a result, the developers don't have access to a specific feature available in a more recent version—a feature that would speed up the development process. At this point, you may have to make a choice: accommodate the outdated PHP at the price of slower development (knowing that it will eventually require an update) or delay development to give the development and operations teams time to upgrade the PHP version. In this case, you don't need to understand all the nitty-gritty details. But you must be able to discuss the possible trade-offs with your team and effectively communicate your decision to your supervisor and company leadership.