 There are two broad business models: pipes and platforms. You could be running your business the wrong way if you’re building a platform, but using pipe strategies. First a few definitions. Pipes Pipes have been the dominant business model for as long as we’ve had industries: firms create stuff, push them out and sell them to customers. Value is produced upstream and consumed downstream. There is linear flow. Examples of pipes: essentially every consumer good – all of manufacturing runs on a pipe model, broadcast television is a continuous content pipe and prior to the internet, much of the services industry ran on a pipe model as well. This model was brought over to the internet as well. Ecommerce stores work as a pipe, and so do single-user SaaS. Platforms Unlike pipes, platforms do not just create and push stuff out – they allow users to create and consume value. At the technology layer, external developers can extend platform functionality using APIs. At the business layer, users (“producers”) can create value on the platform for other users (“consumers”) to … consume. Broadcast tv channels work on a pipe model but YouTube works on a platform model. This is a massive shift from any form of business. Business Model Failures Why is the distinction important? Because platforms are a fundamentally different business model. This means that platforms can’t be built the way pipes are built: traditional retail is a pipe. And it’s being disrupted by the rise of marketplaces and in-store technology, which work on the platform model. Pipe Thinking vs. Platform Thinking So how do we avoid this pitfall? Here’s a quick summary of the ways that these two models of building businesses are different from each other. User acquisition: for pipes it’s straightforward – get users in and convert them to transact. Online stores for example focus on getting users and converting them. And that’s where the first pitfall for platforms is – don’t try to get users in and make them perform some actions – because platforms have no value when the first users come in. Indeed, users (as producers) produce value for other users (consumers). Hence, without producers there is no value for consumers and without consumers, there is no value for producers. Platforms have two key challenges: 1. Solving the chicken and egg problem to get both producers and consumers on board. 2. Ensuring that producers produce, and create value Without solving for these two challenges, driving site traffic or app downloads will not help with user acquisition. As a matter of fact, companies, especially during a digital transformation, often fail when they are actually building platforms but use Pipe Thinking for user acquisition.
Product Design and Management: Creating a pipe is very different from creating a platform. Pipes require to be built with the consumer (only) in mind. (Expedia is a pipe: all features are built with a view to enable consumers to find and consume travel tickets). In contrast, a platform requires the curator to build tools for producers (for example, video hosting for YouTube) and do the same for consumers (for example, video viewing for YouTube). The most important thing to consider is that for pipes, the use cases are well defined from the get-go. But for platforms, the use cases emerge through usage (example twitter started as a tool to express yourself in less than 140 characters but today is a platform for sharing and consuming news and content – creating an entirely new model for consuming trending topics) – as user uses often take platforms in entirely new directions.
Monetization. For a pipe, it’s pretty straightforward – Calculate all the costs of running a unit though a pipe all the way to the end consumer and make sure that price = cost + wanted margin. On a platform business, monetization isn’t quite as straightforward. When producers and consumers transact (Airbnb, Etsy), one or both sides pays the platform a transaction cut. When producers create content to engage consumers (YouTube), the platform may monetize consumer attention (through advertising). In some cases, platforms may license API usage (Trello, Stripe). Platform economics isn’t quite as straightforward either. At least one side is usually subsidized to participate on the platform. Producers may even be incentivized to participate. For pipes, a simple formula helps understand monetization: Customer Acquisition Cost (CAC) < Lifetime Value (LTV) This formula works extremely well for ecommerce shops or subscription plays. On platforms, more of a systems view is needed to balance out subsidies and prices, and determine the traction needed on either side for the business model to work.
The End of Pipes In the future, every company will be a tech company. We already see that in all the digital transformations occurring in every industry as companies move to restructure their business models in a way that uses data to create value. As we are moving from linear to networked business models, from pipes to platforms, all businesses will need to move to this new model at some point, or risk being disrupted by platforms that do. (To be continued!) Let me know what you think!
DM me @philippemora on IG and Twitter My name's phil mora and I blog about the things I love: fitness, hacking work, tech and anything holistic. Head of Digital Product thinker, doer, designer, coder, leader
0 Comments
 Part 2: Team Superstructures and alternative organizations Staffing the teams Determining which person goes on which team — can be extremely tricky. If we have teams that stay stable for a longer time, we don’t have to make these decisions very often, but they will impact the team performance for a long time. Conversely, with flexible teams, a lot of staffing decisions will have to be made, but each one won’t matter as much. In other words, with stable teams, your staffing process requires more diligence, and with flexible teams, more speed. Here are few points to consider:
The role of formal reporting lines While most of the work gets done in cross-functional product teams, there is also the functional element. In many product organizations, the formal reporting line is functional. In other words, engineers report to engineering managers, designers to design manager, and product managers to product directors or similar roles. It’s important to understand that this formal reporting line does not mean that the functional managers engage in a command-and-control style management with their reports —the cross-functional teams are empowered and autonomous, and these teams are at the heart of the product development lifecycle. However, that doesn’t mean there is no role for functional leadership and management. To the contrary: autonomous and empowered teams don’t need less managing: Empowering means creating an environment where people can own outcomes and not just tasks. This doesn’t mean less management; it means better management. It’s important for leaders to step back to create this space, while stepping in to remove impediments, clarify context, and provide guidance. Functional coaching and development Instead of telling their reports what to do, the key responsibility of the functional managers is developing their reports, for example through development plans, feedback, and coaching. This functional aspect complements the natural learning and development that happens in the cross-functional team. Of course, product teams should practice continuous improvement, for example, by conducting regular retrospectives. However, there is a limit to the functional learning that can come from this kind of continuous improvement. For example, a designer is unlikely to “level up” in terms of information architecture or trends in UI design from retrospectives with their engineers and product manager. Coaching from a line manager who’s a more experienced designer is much more effective here. Context and direction The product direction needs to be as cross-functionally aligned as the implementation of it in product teams. In other words, at leadership level, alignment has to happen between the various functions (e.g., product management, engineering, design) before the direction is cascaded down to the product teams. Functional line management still plays a role in the direction-setting though, in highlighting the specific aspects to the function to their reports and providing guidance and coaching on how to make the direction actionable. Organization size and reporting structure In smaller teams, there is also the model of the “player coach”, in which the team is led by one team member who splits their time between individual contributor work and team leadership. These player coaches are sometimes called “lead” (e.g., Design Lead or Engineering Lead) or specifically for product managers, Group Product Manager (GPM). While the player coach model means not having to hire a dedicated manager (who is not “delivering” anything), it can also place a high workload on the player coach, since they are expected to deliver 100% in their product team and then also develop and lead the rest of the team. It might be better to have a dedicated manager who can pick up some small tasks to help out the product teams, but who isn’t part of a product team themselves. Let me know what you think!
DM me @philippemora on IG and Twitter My name's phil mora and I blog about the things I love: fitness, hacking work, tech and anything holistic. Head of Digital Product thinker, doer, designer, coder, leader |
Product Builder in Colorado. travel 🚀 work 🌵 weights 🍔 music 💪🏻 rocky mountains, tech and dogs 🐾
Categories
All
Archives
March 2025
|