Business Model is a skill published by agensi that converts an unformed product concept, client brief, or research data into a structured business-model.md file intended to serve as a reference document throughout the development lifecycle. It follows an 11-step process to define a product in plain English, establish a core problem-and-solution fit, and produce a monetization hypothesis before any code is written or UI is designed.

A key output of the skill is the explicit separation of the buyer from the user. Rather than treating both roles as identical, the skill maps out why a buyer purchases the product versus what a user needs from it day-to-day. It also surfaces user objections and maps specific go-to-market channels, so the resulting document covers commercial viability alongside product definition.

The skill enforces a set of documented anti-patterns to avoid common pitfalls: it resists scope creep, rejects generic startup language, and demands specific and measurable success metrics rather than vague goals. It also defines explicit non-goals, which limits the risk of engineering effort being spent on features that do not serve the stated business objective.

The output file is intended to feed directly into downstream tasks such as design documents, UX flows, and implementation planning. This skill is appropriate when a team needs alignment on strategy before committing to technical decisions. It is not a code-generation tool and produces no executable output.

Use cases

Turn a startup pitch or client brief into a structured business-model.md before sprint planning begins

Identify and document the distinction between buyer motivations and end-user needs for a new product

Define a monetization hypothesis and go-to-market channels before committing to a tech stack

Establish measurable success metrics and explicit non-goals to scope an MVP

Map user objections during early discovery to inform product positioning

Feed a finished business-model.md into downstream design doc or UX flow generation tasks

When to use it

A product or feature idea exists but the team lacks a shared written definition of the problem and solution

Buyer and user roles differ and need to be documented separately before development begins

A client brief or research data needs to be translated into actionable strategic requirements

The team wants to define non-goals explicitly to prevent scope creep during implementation

A structured input document is needed before generating design docs or UX flows

When not to use it

The project needs executable code, database schemas, or deployable artifacts — this skill produces only a markdown strategy document

The product is already past the strategy phase and implementation is underway

A technical architecture document or API specification is required rather than a business logic overview

No product concept, client brief, or research input is available to work from