“Big P” Product (1 of 2): 6 disciplines that build Enterprise Value, not just features
What scaled product teams get right beyond building. Alignment of Product with Business Outcomes, Market Differentiation, and GTM Execution
You’re mid-implementation when a Tier 1 customer asks for a use case your product doesn’t support. A Slack thread kicks off between Sales, Product, and Engineering. Because it’s a large account, what would normally be dismissed as a one-off gets prioritized.
The feature isn’t core to the product or key to the customer’s original goals—but it gets built anyway. The team celebrates the quick turnaround.
Then a bug shows up. Other priorities take over, and the fix is delayed. The issue escalates, eroding trust. Three months later, the customer churns.
The irony? The feature had nothing to do with why they bought—or the value you actually delivered. OR where you see your product’s differentiation in the market.
There are a lot of “unforced errors” in this story but it’s a real one I’ve lived and many others have in sub-scale B2B SaaS and tech-enabled services. It’s easy to blame the implementation manager for not pushing back, the sales rep for failing to reinforce the original business case, the product manager for saying yes, or the engineer for shipping something fragile. But a core issue is the absence of “Big P” Product Management.
In the first post of Sub-Scale SaaS Guy, “The Awkward Teenage Years of B2B SaaS”, I laid out the transitional pains SaaS companies face on the journey from sub-scale to scale. This post takes a deeper dive into one of the most crucial shifts: moving from “little p” to “BIG P” Product Management—and why making that shift is essential for building repeatable customer value and business outcomes.
Why “little p” alone doesn’t scale
The 0-to-1 phase is inherently scrappy. Teams chase product-market fit while reacting quickly to customer feedback. In many sub-$5M ARR companies I’ve seen, formal roadmaps are rare—often replaced by founder notes or makeshift slides. It’s not laziness; it’s survival.
“Little p” product management focuses on mechanics of feature development: collecting user stories, designing fast, sprint planning, basic QA, light analytics, and handling escalations.
What’s missing is proactive strategy: defining what will differentiate you in the market, aligning product priorities with measurable business outcomes, and building what matters most—not just building a lot of things fast.
Here are some telltale symptoms of a company stuck solely on “little p”:
Misaligned priorities: Resources go toward features that don’t move the needle on ARR bookings or retention.
Cross-functional finger-pointing: Sales blames Product for missed targets; CS blames Product for churn; Execs blame Product for a lack of innovation.
Surprise churn or bad-fit deals: No clear alignment between ICP needs and actual value delivery.
New features flop: Great demos, no revenue—because GTM and commercialization were an afterthought.
What’s required to build Enterprise Value isn’t just shipping well-built features, it’s snapping product development into alignment with business priorities, market differentiation, go-to-market motion, and the actual customer journey.
6 “BIG P” product disciplines from sub-scale to scale
Note: I’m intentionally skipping the important infrastructure required to scale “little p”—things like documentation, QA automation, analytics, and ticketing systems. This post focuses specifically on the strategic disciplines that define “Big P” Product Management.
1 | Goals: from product output to customer & business outcomes
Sub-scale: Speed rules. Founders and product teams prioritize output velocity over outcome clarity. This works in the early days when founders can directly connect dots between features and customer value.
Scale: Output velocity means nothing if it's not tied to outcomes. Roadmaps align with value drivers and business metrics. Release notes clearly articulate what customer or business problem is being solved. Those same metrics show up consistently in departmental goals and OKRs. They become a common language across the entire company to speak about customer value and business impact.
2 | Product vision: from disruption focused to broader viability
Sub-scale: Vision is fueled by founder pain or passion. You’re solving a niche problem for early adopters where being different can be enough to acquire enough customers to go from 0-to-1. A frequent claim is “We don’t really have competitors.”
Scale: You’re now selling to the Early and Late Majority (from Geoffrey Moore’s Crossing the Chasm) - where the bulk of your addressable market live. Vision must evolve beyond “different” to “better” and “complete.” You need to demonstrate commercial appeal and viability across a broader customer base in a defined category, often requiring platform thinking or deeper verticalization—built in close alignment with your GTM team.
3 | Product discovery & feedback - from sporadic one-offs to programmatic & predictable
Sub-scale: Discovery is sporadic and reactive. Feedback loops are driven by founder conversations or whoever yelled the loudest. Internal teams and customers don’t know when or how input will be received—or whether it matters.
Scale: Discovery is systematized. You have instrumentation (usage data, support tickets, CRM signals). Customer input is gathered through structured channels—interviews, surveys, advisory boards. Sales and CS know how to submit requests and what to expect. Releases and roadmap reviews are shared, documented, and predictable.
4 | Product roadmap - from reactive, incremental features to strategic, tethered to product vision & EV
Sub-scale: Roadmap lives in a founder’s head or a loose doc. Priorities shift frequently, driven by recency bias or anecdotal data. Engineering velocity suffers due to constant switching between priorities and support escalations. While the output is there, the buildout of the product is reactive and incremental resulting in a wide breadth of loosely connected feature & functionality.
Scale: Roadmap is built across the long term. Feature and functionality is tightly tethered to the vision and themes of what the product can be best in the world at for your target customers. Prioritization considers effort vs. impact and aligns with GTM, scalability, and market differentiation. Business cases are modeled and tradeoffs are debated cross-functionally. Tactically, capacity is planned ahead of time and protected for high-leverage work.
5 | Product scope - from shipping software to “Whole product”
Sub-scale: The job is to “get it working.” - functionality and usability of the software. Supportability, serviceability, and integrations are afterthoughts. Services are seen as necessary but non-strategic.
Scale: The job is to deliver an end-to-end solution. Product design includes customer support implications. Services are part of the differentiated offering—especially in a world where building software gets easier. Integrations aren’t just features; they’re strategic levers for partnerships and market expansion.
6 | Commercialization- from “shipped” to “adopted & monetized”
Sub-scale: Features ship, but revenue doesn’t follow. Revenue targets are unknown or too lofty built on gut feel. GTM enablement is a Zoom walkthrough. Betas are skipped, MVP is unclear, and sales feels unprepared. Driving demand is tossed over the fence to Sales, Marketing, Customer Success.
Scale: Commercialization is intentional. There are clear (and reasonable) success metrics tied to each launch. PMM and enablement leads orchestrate training across sales, CS, and support. Beta programs validate assumptions. Documentation is thorough. Certification paths exist for complex features. Orchestrated efforts between Product, Marketing, and Sales help drive demand.
Final Thoughts
“Big P” Product Management doesn’t mean losing your agility—it means directing it. Assuming you continue making improvements to the well-oiled product development machine (“little p”), it ensures you’re not just reacting but building what matters most—repeatedly and predictably.
That’s how you build Enterprise Value, not just product capabilities.