Positioning and launch enablement for an API observability product
Context
Postman Insights is a lightweight API observability layer. It installs at the container level, passively watches production traffic, and surfaces per-endpoint errors, latency, and volume. There are no SDKs to add and no code changes to make.
Insights worked differently from every other Postman product. The rest of the platform runs on Postman's infrastructure, so one change reaches 40M users. Insights runs alongside a customer's containers and inherits whatever environment they are running in. What we could promise depended on who was asking.
Because of this, 1.0 launched with a defined scope: Free, Basic, and Professional tiers, containerized environments only, fewer than five services, and up to 8,000 requests per minute per instance. Enterprise support would follow through a design partner program.
Challenge
If a rep sold the agent into an unsupported stack, the customer would end up with a failed install in their production environment. A failed install damages trust in the entire platform.
Product came to marketing with three requests. Message what we could and could not support. Help target the users we could actually serve. Send demand signal back so they could prioritize what to build next.
Approach
Positioning. Most observability tools are built for platform teams. Insights was built for developers, and it complemented an existing monitoring stack instead of replacing it. Every decision below came out of that statement.
Message house. I built the message house as the source of truth for how Insights was described on every external surface. It was organized around three pillars: visibility with zero setup, endpoint discoverability, and in-flow debugging. I wrote it for the full audience rather than the launch audience. Backend and platform engineers were the primary users. Hands-on CTOs, SVPs of engineering, and senior directors of infrastructure were the buyers. The enterprise story existed before the enterprise motion did.
Field enablement. Most launch enablement leads with capability. I led with scope. The document listed exactly what we did not support, with the actual thresholds, and explained why those limits existed.
Routing the no. Reps needed somewhere to put a disqualification. Any prospect outside the supported range was logged with their use case and flagged for the enterprise design partner program. A disqualified prospect became pipeline, and the log gave product the prioritization signal they had asked for.
Competitive positioning. Datadog, New Relic, and Honeycomb already owned the category. I positioned Insights as complementary to those tools. At our launch scope, coexistence was the position I could defend.
Trade-offs
Publishing our limits cost us deals. A rep who cannot promise serverless support loses the prospect running serverless.
What we gained was that every install we did make worked. Observability has a short window for this. A customer whose agent fails during setup does not come back and try again.
The approach also compounded. Clean signal from supported deployments told product what to build next, and disqualified prospects became a ready queue for the enterprise rollout.
Results
Insights launched to Free, Basic, and Professional plans in July 2025. The field was equipped, and the design partner program captured every prospect outside the supported range.
The positioning held on the product page, including the decision to publish the supported thresholds openly.
A customer made the coexistence argument better than we could. A VP of Engineering said they had Datadog and Honeycomb set up and still could not tell what was happening in their system.
Thirteen months later, the positioning was still in place. "No code, no custom dashboards, just answers" is on the page word for word. The in-flow debugging pillar still anchored the debugging section. The buyer personas I wrote ahead of the enterprise motion are the audience the page speaks to now, with enterprise logos and framing that has moved toward governance and compliance.
I wrote that positioning for an audience we weren’t selling to yet. It is the audience using it today.