Archive
1290 posts · Page 99 of 108. ← Blog
How do you know if your product is actually working? Not "did we ship the feature" but "did it make the difference we hoped?" Answering that requires metrics — and product management lives in a productive tension here: data is essential for knowing whether you're succeeding, yet the most metric-obsessed teams often build worse products by optimizing the measurable at the expense of the meaningful. Using data well means measuring what matters, letting it inform judgment, and resisting the traps that catch data-driven teams.
How do you know if your product is actually working? Answering that requires metrics — and PM lives in a productive tension: data is essential, yet the most metric-obsessed teams often build worse products by optimizing the measurable at the expense of the meaningful.
How to teach an agent to load and persist conversation memory in your own store via a custom history provider.
Implement a custom agent.HistoryProvider with Provide and Store hooks so the agent loads and persists history in your store; DisableStoreOutput keeps it the single source of truth.
The Picnic social platform served 1M+ users across a graph of Go microservices behind a GraphQL gateway. The latency win came from a counter-intuitive move: fewer services, tighter contracts.
A product is built by a collaboration, not a handoff. The most productive product teams run on a tight partnership between three roles — product, engineering, and design — each owning a distinct concern and none simply taking orders from another. When that collaboration works, products get built that are valuable, usable, and feasible; when it breaks down into a handoff or a hierarchy, everyone is frustrated and the product suffers. For engineers, understanding this collaboration is understanding how to work well with PMs and designers.
A product is built by a collaboration, not a handoff. The most productive product teams run on a tight partnership between three roles — product, engineering, and design — each owning a distinct concern and none simply taking orders from another. For engineers, understanding this is understanding how to work well with PMs.
How to serialize an agent.Session to storage and resume the same conversation later, even from a new process.
Serialize an agent.Session with encoding/json, store the bytes, and reload them into a fresh Session in another process to resume the exact same conversation.
Test coverage and observability are the boring infrastructure that makes the interesting changes safe. Notes on how the Picnic team built both, and the on-call experience they enabled.
Prioritization answers "what should we build next?" — but that question is unanswerable without a prior one: "what are we trying to achieve, and why?" That's strategy and vision. Without them, prioritization becomes a directionless scramble of locally-sensible choices that don't add up to anything. Vision provides the destination; strategy provides the path; and together they turn a stream of features into a coherent product going somewhere. For engineers, understanding strategy explains the "why" behind everything the team does.
Prioritization answers 'what should we build next?' — but that's unanswerable without a prior question: 'what are we trying to achieve, and why?' That's strategy and vision. Without them, prioritization becomes a directionless scramble of locally-sensible choices that don't add up to anything.
How to make the agent return a typed Go struct instead of free-form prose, via a JSON schema derived from your type.
Two ways to get typed output from an agent: per-run agent.WithStructuredOutput, or agent.WithResponseFormat with jsonformat.MustFor baked into Config.RunOptions.
The transaction engine had to absorb 30K+ TPS across partner integrations, never lose a transaction, and survive partial failures. The architecture: Go, Kafka, Pub/Sub, Redis, K8s, with idempotency at every layer.
If product management had a single defining skill, it would be prioritization — and its essence is a word most people find hard to say: no. There are always more things to build than time to build them, every one championed by someone, and the PM's job is to choose the vital few and decline the rest. Done well, prioritization focuses a team's finite energy on what matters most. Done poorly — or avoided — it spreads the team thin across everything and accomplishes little.
If product management had a single defining skill, it would be prioritization — and its essence is a word most people find hard to say: no. There are always more things to build than time to build them, and the PM's job is to choose the vital few and decline the rest.
How to pause a run for human approval before the framework is allowed to execute a tool.
Wrap a tool with tool.ApprovalRequiredFunc so the run pauses and returns a ToolApprovalRequestContent; approve or decline, then resume with RunMessage on the same session.
A single layer of idempotency will eventually fail. Three independent layers gives you a margin. Here is the pattern that worked across ingest, worker, and emit boundaries.