Key Activity

Origin & evolution

The block comes from Business Model Generation (2010) by Alexander Osterwalder and Yves Pigneur, on the efficiency side of the canvas alongside Key Resources🏭Key ResourceBusiness ModelA key resource required by the businessView reference → and Key Partnerships. The three blocks describe the back of the house: what a business does, what it holds, and what it buys in from others. Key Activities is the verb among them.

Osterwalder and Pigneur sorted these activities into three types. Production activities dominate manufacturing models, where designing, making, and delivering a product in quantity is the core work. Problem-solving activities dominate consultancies, hospitals, and other service models, where the work is generating bespoke solutions🔧SolutionDiscoveryA proposed approach to address an opportunityView reference → to individual client problems. Platform and network activities dominate businesses whose value comes from a network they run, such as a marketplace or a payment network, where the core work is platform management, matchmaking, and keeping the network healthy. A software business often runs all three at once, which is precisely why naming the few that matter takes discipline.

The block's intellectual ancestor is the value-chain analysis Michael Porter set out in Competitive Advantage (1985), which broke a firm into the discrete activities that create value and asked which ones drive cost and differentiation. The canvas compresses that analysis to a single block and aims it at one question: which activities does this specific model truly depend on. Activities that any competent firm could perform are not key. The ones that produce the value proposition are.

How it works in practice

A food-delivery marketplace lists its activities and finds the discipline hard. It does marketing, it does customer support, it runs a kitchen-partnerships team, it builds an app, it operates a courier dispatch system. Pressed to name the key activities, the founders cut the list to two: matching demand to supply in real time, which is the platform activity that makes the marketplace function, and maintaining courier liquidity in each city, which is the operational activity that keeps delivery times under thirty minutes.

Everything else is real work, and most of it can be outsourced, automated, or run by a junior team. The two key activities cannot. They consume the senior engineering and operations talent, they justify the largest cost lines, and they decide whether the value proposition of fast, reliable delivery survives contact with a Friday-night demand spike. When the company expands to a new city, it does not ask whether it can do marketing there. It asks whether it can stand up courier liquidity and real-time matching, because those are the activities the model is built on.

Key Activity vs. its neighbours

• Key Resource is what the business holds; Key Activity is what it does with it. The dispatch algorithm is a resource; running real-time matching is the activity that resource enables. The canvas links them because an activity without the resource to perform it is a wish, and a resource no activity uses is dead weight.
• Value Proposition is the value the customer receives; Key Activity is the work that produces it. The test of whether an activity is key is whether the proposition would survive its removal. If not, it belongs in the block.
• Capability💪CapabilityStrategyAn ability that enables value deliveryView reference → is a durable organisational ability, a standing competence the firm can deploy across many activities. A Key Activity is a specific operation the model performs. Capabilities accumulate; activities run. A firm builds the capability of logistics optimisation, then spends it on the activity of courier dispatch.

In the graph

In the Unified Product Graph, Key Activity sits in the business-model region and links to its model through business_model_performs_key_activityBusiness ModelperformsKey Activityhierarchy. Its purpose is fixed by key_activity_delivers_value_propositionKey ActivitydeliversValue Propositioncausal, which encodes the test that an activity earns the word "key" by being load-bearing for what the customer gets. Its mechanics are wired through key_activity_uses_key_resourceKey ActivityusesKey Resourcecross-domain, the dependency⛓️DependencyTeam & OrganisationA cross-team or system dependencyView reference → on the assets it consumes, and partnership_performs_key_activityPartnershipperformsKey Activitycross-domain, which captures the activities a model hands to partners rather than running itself. The structure matters because it makes the discipline queryable: an activity that delivers no value proposition is, by the canvas's own definition, not key, and the graph can surface it for demotion so the list of "things we do" never passes for strategy.