Product Strategy, Positioning, and Business Models

Product Vision

Product vision is the product team's guiding star (or North Star): a condensed, motivational and directional picture of the future the product is meant to create. It is not a description of the current release. It clarifies the product's future form, its customer value proposition—why customers need it rather than an alternative—and the resulting business value for the vendor, investors, employees, and other stakeholders.

What makes a strong product vision?

A useful vision helps a team make trade-offs: between markets, features, technologies, and priorities. It should be:

Company vision vs. product vision

Company vision describes the future the entire company wants to create; product vision describes the future created by one product or product suite. Both endure, but they operate at different breadths and levels of granularity.

Alignment examples

Exam tip: A vision that sounds attractive but does not resonate with what the company actually does signals a disconnect. Product and company visions should be traceable to each other, not merely aspirational slogans.

Key takeaways

• Product vision gives enduring purpose and direction, while describing future customer and business value.
• It must be clear, inspirational, customer-centric, strategic, long-term, differentiated, and feasible.
• A company vision is broader and more enduring; a product vision is product-specific and evolves more readily.
• A product vision should operationalise, rather than contradict, the company vision.

Product Definition and Positioning

Product definition answers what the product does; it is an internal statement that guides what to build, the roadmap, and partners' understanding. Product positioning answers why the product matters to customers; it frames the external impact, target user, value, alternatives, and differentiation.

Product-definition syntax

Frame the internal definition as:

The problem of [problem] affects [stakeholders]. Its impact is [consequences]. A successful solution would enable [desired outcome].

UPI example

• Problem: fragmented and inconvenient digital payments.
• Affected stakeholders: consumers, merchants, banks, and the digital economy overall.
• Impact: slow cash adoption/velocity, transaction friction (for example, lack of exact change or a card reader), and limited financial inclusion.
• Successful solution: instant, interoperable, secure, low-cost digital transactions across banks and applications.

HydraSmart example

• Problem: poor hydration awareness and inconsistent water-intake habits.
• Affected stakeholders: fitness enthusiasts, people working long hours, elderly individuals, and health-conscious consumers.
• Impact: reduced wellness and productivity, fatigue, dehydration-related health issues, and no personalised hydration monitoring.
• Successful solution: intelligent real-time tracking, personalised reminders, and behavioural insights that improve hydration behaviour.

Positioning-statement syntax

Frame the external statement as:

For [target customers] who [need / job], [product] is a [category] that [key capability / benefit]. Unlike [alternatives], it [differentiation and value].

From vision to GTM messaging

For HydraSmart, a vision may be to improve hydration habits; its definition specifies capabilities such as personalised alerts. The positioning then connects those capabilities to avoiding illness and improving wellness. A first release that only sends WhatsApp alerts must not claim sensing or wearable-data personalisation; later releases can make those version-specific claims when the capabilities exist.

Exam tip: Do not confuse features with value. “Tracks intake and sends alerts” is a definition; “helps prevent dehydration-related problems” is a positioning benefit.

Key takeaways

• Definition is internal and capability-focused; positioning is external and value-focused.
• A good definition states problem, affected people, impact, and the outcome a successful solution enables.
• A positioning statement identifies target users, their need, product/category, capability, alternatives, and differentiation.
• Vision → definition → positioning → GTM message creates traceability from aspiration to release-level communication.

GTM Practices

Go-to-market (GTM) is the integrated approach used to introduce, position, distribute, sell, and scale a product—from market introduction to market leadership. It matters especially in software because incremental growth cost is negligible relative to physical products: software does not require comparable extra physical components, assembly, and distribution for every additional user.

GTM questions and components

Other connected GTM elements are sales strategy (convert demand into new business), marketing communication (awareness and positioning), onboarding (reduce adoption friction), partnerships (extend reach), and metrics (measure growth). For example, Jio used many local SIM-card sellers as channel partners to reach customers broadly.

B2B vs. B2C GTM

ChatGPT illustrates a B2C-oriented GTM: positioned as an everyday AI assistant for work, learning, creativity, and problem-solving. Its drivers were a free-access tier, viral social sharing, a conversational interface, an API ecosystem, and a path for employees to upgrade into enterprise use. Low-friction onboarding and value within seconds supported massive adoption and billions of daily interactions.

Freshworks illustrates B2B GTM aimed at small and medium businesses: easy-to-use, easy-to-implement, easy-to-integrate, easy-to-maintain enterprise software, initially freemium and affordably priced. Its GTM emphasised lower complexity, fast onboarding in days, value pricing, and globally available usage templates.

GTM funnels

B2B funnel:

At evaluation and decision, enterprise buying requires buy-in beyond procurement. Land and expand means using an initial sale to cross-sell or upsell additional products—for example, moving from core banking to internet banking, mobile banking, or treasury.

B2C funnel: awareness/discovery → interest (freemium sign-ups or app installs) → engagement → conversion → retention → advocacy. Spotify illustrates conversion: after repeated use builds habit, users may pay ₹130 or ₹199 to remove ads. Retention combats churn through push notifications, gamification, and loyalty mechanics. Advocacy encourages users to share and spread word of mouth; early Netflix sharing supported reach before conversion to paid subscriptions.

Key takeaways

• GTM combines segmentation, positioning, pricing, distribution, sales, marketing, onboarding, partnerships, and growth metrics.
• B2B relies on trust, ROI, integration, multi-stakeholder selling, and long-term retention; B2C relies on ease, habit, emotion, and viral reach.
• B2B moves through account-based evaluation and land-and-expand; B2C moves through self-service engagement, conversion, retention, and advocacy.
• Software's low incremental cost makes an effective scaling strategy especially consequential.

Growth Strategy

Growth strategy selects the engines through which a software business acquires, retains, and expands customers. The four approaches—sales-led growth (SLG), marketing-led growth, product-led growth (PLG), and ecosystem-led growth (ELG)—are complementary, not mutually exclusive. The best mix depends on product and business context.

Four growth engines

For PLG, the first-use experience must minimise friction: a customer should get value quickly without substantial setup. For ELG, partners—not only end customers—must benefit; more integrated participants can establish a global standard.

Comparative choice criteria

Growth evolves over time

Growth approaches can evolve with a company. Microsoft demonstrates this combination across decades:

• Sales-led: enterprise Windows and MS Office licences, partners, and channels.
• Marketing-led: Xbox and Surface.
• Product-led: Teams and Copilot.
• Ecosystem-led: Azure cloud infrastructure and the developer ecosystem.

Key takeaways

• Choose and combine SLG, marketing-led, PLG, and ELG based on product context.
• SLG fits high-trust enterprise change; PLG wins through self-service and rapid value; ELG wins through partners and network effects.
• CAC is highest in sales-led and lowest in product-led; ecosystem costs are shared.
• Growth strategies evolve: one company can use different engines across products and stages.

Business Model Canvas

A business model articulates how a company intends to make money from a product. Alex Osterwalder defines it as the rationale for how an organisation creates, delivers, and captures value through interactions with suppliers, customers, and partners. It therefore covers the value chain, target segments, and cost and revenue streams.

The Business Model Canvas (BMC) captures this logic in nine boxes on one page.

The nine BMC blocks and how to fill them

Use this sequence: customer segments → value proposition → channels → relationships → revenue → key activities → key resources → key partners → cost structure. The first five clarify the customer/value logic before identifying what must be done and paid for.

$\text{Business viability} = \text{Revenue} - \text{Cost}$

The right side of the canvas tests desirability (do customers need it?); the left side tests feasibility (can we do it?); the lower revenue–cost view tests viability (should we do it?).

WhatsApp BMC example

WhatsApp was acquired in 2014 with roughly 60–70 employees at a value of about $18 billion, illustrating a lean team supported by powerful platform and network resources. Since value differs by segment, separate canvases can be useful for individuals versus enterprises/advertisers.

Exam tip: A BMC can model a future business as well as a current one. Its central test is whether the product, suite, or business line can become viable—not merely whether it earns revenue today.

Key takeaways

• The BMC is a one-page, nine-block model of how a business creates, delivers, and captures value.
• Start with segments and their value proposition; then define reach, relationships, revenue, delivery capability, and cost.
• Desirability, feasibility, and viability together determine whether the model makes business sense.
• Different customer segments may warrant different canvases because their value propositions differ.

Lean Canvas

The Lean Canvas, created by Ash Maurya, adapts Osterwalder's BMC for early-stage startups and MVPs. A startup is treated as an experiment/project to validate a business model; Lean Canvas therefore asks the more fundamental question: should this product exist?

Nine Lean Canvas blocks

The common blocks are customer segments, channels, value proposition (as a unique value proposition), cost structure, and revenue streams. Lean Canvas replaces or foregrounds other blocks to test startup risk.

The combination of UVP and unfair advantage creates competitive advantage. Unlike a BMC, Lean Canvas explicitly confronts competition because a startup challenges powerful incumbents. Early-stage metrics are necessary because top-line revenue, bottom-line profit, and NPS may not yet be meaningful.

Lean Canvas examples

For HydraSmart, the product may begin with a minimal alert-only MVP or expand to a full bottle-and-app solution. The full Lean Canvas above tests the latter. The critical validation questions remain: is the problem sharply defined, is the UVP truly unique, and is there a defensible moat? Inadequate validation of the underlying problem and business model can lead to products that customers do not need.

Key takeaways

• Lean Canvas is a startup/MVP validation tool; BMC is better suited to describing and improving operating/scaling businesses.
• Fill Lean Canvas from problem through segments, UVP, solution, moat, economics, metrics, and channels.
• UVP + unfair advantage = competitive advantage; both are critical when confronting incumbents.
• Early-stage startups need in-process metrics because revenue, profit, and NPS may not yet exist.

Delivery Model

A delivery model is how a software vendor makes a product available to customers. Modern products are defined not only by features but by delivery. The choice affects revenue model, scalability/concurrency, customer adoption across segments, partner ecosystem, and long-term profitability.

Three delivery models

SaaS means software as a service: rather than purchasing and running the software themselves, customers consume it as a vendor-run service. Hosting and licensing are conceptually separate: software can be period-licensed even without vendor hosting, but this SaaS discussion focuses on vendor-hosted delivery. Multi-tenancy means one software instance serves many customers; in managed services, infrastructure is dedicated per customer.

On-premise vs. SaaS implications

SaaS is strategic because its architecture must support multi-tenancy: one instance must serve customers with different currencies, time zones, business rules, and access controls while logically configuring each customer separately. It also enables continuous deployment, because the vendor controls development and production support rather than waiting for discrete customer release windows.

Delivery-model examples and strategic outcomes

• Salesforce pioneered SaaS delivery.
• SAP historically dominated on-premise enterprise software before moving toward cloud options.
• Zoho launched globally as cloud-native from the beginning; remote activation/support enabled global expansion, lower delivery cost, and SMB penetration.
• Tally became popular as downloadable on-premise accounting software.
• Adobe shifted from boxed/shrink-wrapped licences to Creative Cloud subscriptions, gaining scalable recurring revenue, retention, and business value.

Exam tip: SaaS is not simply “software on the cloud.” It entails vendor-operated delivery, recurring service economics, multi-tenant/scalable architecture, and centrally managed updates.

Key takeaways

• Select delivery based on revenue, scalability, adoption, ecosystem, and long-term profitability—not features alone.
• On-premise maximises control/customisation but requires upfront infrastructure and customer-managed operations.
• SaaS offers subscription revenue, automatic updates, scalability, and faster deployment, but needs multi-tenancy and robust architecture.
• Managed services use dedicated customer infrastructure operated by the vendor.

Tailorability

Tailorability is the ability to adapt a product to a customer's or market's precise needs without losing the scale advantages of a product. It matters in B2B and B2C, but the required degree differs sharply.

Why products need to be tailored

Tailoring may be required for:

• Regulation: Finacle operates in more than 100 countries and must meet local regulations.
• Workflows: banks differ by institution type and product/business processes; ERP products must fit industries from oil and gas to healthcare and retail.
• Integrations: a core product must connect to the customer's own and third-party systems.
• Business rules: for example, interest-computation/application rules can vary by bank.
• Differentiation and local usability: customers need distinct customer experiences even when sharing an underlying platform; local contexts may require rupees/metres rather than dollars/feet.

Too little flexibility makes customers look like undifferentiated cousins and invites competitors. Too much tailoring turns a product into a cumbersome, bespoke implementation: teams may start from scratch instead of assembling the $80\%$–$90\%$ of capability already built into the product.

Tailoring strategies

Invasive customisation changes the main product code. With thousands of B2B customers, placing every customer variation in core code creates complexity, makes maintenance difficult, and does not scale. Early products may lack non-invasive infrastructure, but building it is the scalable direction.

Tailorability–simplicity trade-off and delivery implications

Enterprise products serving diverse markets, time zones, currencies, regulations, and business rules—ERP, CRM, banking—need higher tailorability. B2C mobile apps, consumer SaaS, and games usually need less, often only configuration/composition. SAP is highly customisable; Netflix offers minimal explicit customisation. Netflix's data-driven recommendations are personalisation: algorithms use consumption data to make choices for the user, rather than the user explicitly customising business rules.

On-premise deployments can support deep integration and customisation across many surrounding systems. SaaS can usually support configuration, APIs, and extensions, but deep localisation/customisation is harder because a multi-tenant instance serves many organisations.

Layering core product, locale, customer customisation, composition, and configuration keeps global features out of the core. For example, Portuguese regulatory/language capability can sit in a Brazil locale layer rather than bloating every installation. Optional components such as a local stereo system or dashcam similarly reduce base cost while preserving customer choice.

Key takeaways

• Tailorability is essential for regulatory, workflow, integration, business-rule, and differentiation needs.
• Configuration selects known parameters; composition adds plugins/extensions; customisation adds code.
• Prefer non-invasive customisation; invasive changes to core code create fragmentation and maintenance risk.
• High tailorability supports enterprise diversity but conflicts with SaaS multi-tenancy and product simplicity; use layers to manage the trade-off.

Service Strategy

A service strategy defines which product-related services are needed, who supplies them, and how they enable customer success. Customers buy outcomes, not merely software: if they cannot achieve the outcome, the product alone has not delivered value. Services are therefore part of the whole product, a single continuum with the software rather than a separate add-on.

Service can mean useful labour that does not create a tangible commodity (such as implementation or support), provision for maintenance/repair, or technical functionality delivered through software components (such as web/API services). The focus here is primarily product-related human service.

When service matters and what it includes

Service intensity differs by context. In B2B, it can be mission-critical; in B2C, it is typically lighter support/onboarding. For example, SAP's services ecosystem is stated to be about 4–5 times its licence economy; Salesforce accelerated adoption through onboarding, training, and partners; Finacle supported global success across 100+ countries through strong implementation and tailoring.

System-integrator (SI) partners coordinate hardware, third-party tools, and related components. In large implementations, SI and service costs may comprise roughly 30–40% of the customer budget, with licences around 30% and the remainder internal cost.

Vendor, partner, and self-service choices

Product companies can combine models. For example, Finacle might retain global help desk and bug-fix maintenance while partners provide local help desks and language expertise; the vendor may lead critical new-country implementations while SI partners implement elsewhere.

Zerodha exemplifies deliberate self-service: instead of a large call-support team, it designed diagnosis/configuration/help content and a learning “university.” Atlassian similarly scales with self-service.

Common service-strategy failures

At early stages, determine customer pain points and the minimum level of self-service versus assisted support. Build APIs and documentation, create a partner ecosystem for rapid onboarding, and at scale default to self-service with the minimum necessary direct service.

Key takeaways

• Services are part of the whole product because they turn software into customer outcomes.
• B2B often needs implementation, integration, training, support, and partner ecosystems; B2C should bias toward intuitive self-service.
• Mix vendor and partner delivery according to customer intimacy, quality, local scale, and cost.
• Balance product scalability, customer success, service efficiency, and ecosystem leverage; do not become a bespoke consulting business by accident.

Sourcing Strategy

A sourcing strategy determines what a startup builds and controls itself versus what it obtains externally. It is a strategic—not merely operational—choice shaped by speed to market, internal cost, scalability, quality, and competitive advantage.

What can be sourced, and why?

Potentially sourced elements include talent (engineers, architects, UX designers), software components (speech libraries, QR code), infrastructure/cloud hosting, data sources (for example, maps), cloud platforms, and external services.

Examples show the boundary: Apple designs chips internally but manufactures them externally; Netflix retains its recommendation engine while using AWS infrastructure; Flipkart used external cloud and logistics to scale; Zoho preferred deep in-house capability.

Build vs. buy and open source

Exam tip: Build what differentiates you; source common infrastructure. A critical differentiator held by a third party weakens competitive advantage.

Payment gateways are a typical commodity: startups can use Razorpay or Paytm payment APIs instead of rebuilding payment/regulatory capability. Netflix keeps recommendations and streaming algorithms as core product capabilities while outsourcing hosting to AWS.

Open source is software developed and shared by a community. Common examples are Unix/Linux, Android, Kubernetes, Postgres, React, and TensorFlow.

Red Hat illustrates a business built around supporting and maintaining a widely used open-source Linux variant. Zoho uses internal engineering to leverage open source strategically.

Risks and mistakes

Sourcing best practices

• Build and retain core IP, differentiating algorithms, architectural ownership, product knowledge, and control of customer relationships. Investors may view outsourced core IP as funding risk.
• Source commodity features, generic services, standard tools, payment gateways, speech engines, QR codes, and vernacular-language interfaces where available at reasonable cost.
• Protect service quality and customer relationships; outsourcing support/maintenance can be damaging if it weakens the customer experience.
• Reassess boundaries as the company scales: early external choices may later need to be brought in-house.

Key takeaways

• Sourcing choices span talent, components, infrastructure, data, and services.
• Build core differentiation; buy/source commoditised capabilities for speed and efficiency.
• Outsourcing brings specialised skill and flexibility, but introduces communication, quality, dependency, knowledge-leak, legal, and security risk.
• Keep strategic control of architecture, IP, product knowledge, and customer relationships while revisiting the make–buy boundary over time.