Operating Cycle

Product work is generative. You build something, put it out into the world, people use it. They give you feedback, find bugs, tell you how to make it better, and even spawn new ideas for what else to do. The work itself generates new work. Throw AI in the mix and you can convert feedback into work outputs faster than ever before. Then the cycle begins again, generating more work, more feedback, and even more work.

You’re stuck in a loop. And it’s an insidious loop because it fools you into thinking you’re making meaningful progress. But not all progress is created equal. Don’t mistake motion for movement. You create motion when you ride on a stationary bike, but you don’t actually go anywhere.

Movement is progress when it creates momentum in the right direction.

Otherwise, you’re just expending energy.

It’s like dopamine for your team.

Before AI, time was the natural constraint. It governed decisions and directed action.

Why? Because making the wrong decision cost time, money, and energy. You couldn’t afford to spend those resources doing something without a reasonably high certainty of success.

But what happens when execution collapses into an affordable outcome? You don’t have to wrestle with this vs. that when time is equal.

You can have both!

Time is no longer the governing constraint.

Coherence is the new limiting factor.

When a system no longer self-regulates, it overproduces by default. If everyone is equipped with a keyboard and coding agents, complexity compounds into incoherence.

I sensed this pattern emerging. Our team is cranking out lots of work. We have a system to move work through Linear (the Work Registry) while continuing to improve our review process to keep work moving with quality.

Just this week, some colleagues asked me about future projects. I told them I’m working on shaping them, but I’m also moving a lot of code through the pipeline. And a downstream effect is then having to work with sales, marketing, and customers to communicate the work, discuss the work, and capture feedback to inform the future work. Does this sound like the insidious loop we just discussed?

I keep a weekly note file. I write down everything I complete each day. It’s basically a “Done List.” I create a fresh one each week, using it to track wins, learnings, and takeaways for continuous improvement. I uploaded the last 8 weeks of notes to Claude and asked it to help me segment my work into three distinct categories. I gave some hints about what those categories might be, but I didn’t want to lead the witness (AI). After some back-and-forth conversation, we settled on three distinct categories:

1. Build: Hands on the tools. Writing code, designing, recording demos.
2. Shape: Hands on the strategy. Scoping, decomposing work, analyzing metrics.
3. Connect: Hands on the market. Sales calls, customer interviews, stakeholder updates.

The Maker, The Strategist, The Ambassador.

Claude noticed I’m spending a large amount of time on Build, opening and merging PRs, investigating bugs, creating outputs. It calculated about 60% of my time goes here. The other 40% is split between Shape (15%) and Connect (25%). I wasn’t surprised, but it quantified an internal drift I’ve felt: I’m not spending enough time in Shape.

Shape is the governing force. It’s what maintains coherence in the product. Build and Connect form a reinforcing loop creating new work, sharing it, and capturing more feedback to build more work. Without governance, the product loses coherence and makes it harder to communicate the value to the market.

These three modes are how I work, but they also apply to a team. This is the Operating Cycle within product work. It lives in the Clarity Current of the Claritorium and Strategic Momentum of Equilio.

Build

I like to get into the details. I’m a builder. I’m also obsessed with the creative process. I find endless joy in the messy work imbued in the act of bringing something into existence. Art is created from nothingness, messiness, and continual refinement of iterative building.

If you want to understand something, you need to take it apart, analyze it, and put it back together again.

Product work is about making things. You write documents, create presentations, record demo videos, design mockups, and write code to bring possibilities into reality. The art of a maker is through the process of building—to create something from nothing.

I’ve held roles as a designer, an engineer, a manager of designers, a manager of engineers, an executive, and now a VP of Product. But through every role, I’ve maintained one constant thread: I build things. Why? Well, beyond the fact that I love making things, it’s really about leading from within the work. It sets a real tone for the team when you possess an intrinsic understanding of the work. You can’t effectively lead others in their work without understanding it. Learn by doing.

Build turns possibilities into realities. It’s a translation of ideas into outcomes.

AI is making it easier than ever. The gap between idea and outcome is shrinking as the technology advances and people get better at working with it. It’s compounding.

When I’m done with a meeting, I can:

• Go to Claude.
• Ask it to review the Granola meeting notes using the Granola MCP.
• Draft a Linear issue with all of the context from the call using the Linear MCP.
• Start a Claude Code session in Conductor directly from the created Linear issue.
• Review the work myself, with an AI agent, and the team (design, eng, QA).

This is Intelligence Orchestration, Human Calibration, and Attention Allocation. I’m still directing and reviewing the work, but the pure execution work is done by a machine. All the messy parts of the process are still there—the discussion, the debate, the ideating, the sketching, the open brainstorming. AI is there to explore divergent ideas, converge on a mass of information, and execute with precision.

Unconstrained growth creates complexity. And complexity sows the seeds of incoherence. Without Shape to govern, Build will grow like an uncontrollable weed.

But before we get to Shape, let’s talk about the other side of the loop: Connect.

Connect

Just because you build something doesn’t mean people will use it. AI compounds this problem further with The Build Problem: more software, more options, more noise.

Connect exposes your work to reality. But the work really begins when someone starts using your product. To get there, you need the alignment of three forces:

1. Reach → Can people find it?
2. Trust → Will they engage with it?
3. Need → Do they even need it?

Reach is about visibility. A noisy market needs distribution so you place the work in the right context for the right people to find it.

Trust is about engagement. Human relationships are even more important. As noise increases and becomes more sterile, people will crave talking to real people who understand their problems.

Need is about relevance. Because you’re not just competing against other known software solutions; you’re also competing against someone’s bespoke software they built to match their own needs. Sometimes the “good enough” solution is a general-purpose tool or one they built themselves.

And feedback weaves them all together:

• Reach controls the volume of feedback.
• Trust controls the quality of feedback.
• Need controls the relevance of feedback.

We get a lot of feedback. With millions of users spread over the globe, individuals and large organizations, and a diverse group of internal stakeholders, I rarely have to seek out feedback. The volume is high.

When the volume is high, you need to focus on quality and relevance. Reach is powerful, but it brings noise with it. Tuning into the signals matters. Connect is where you make sure what you’re building resonates. To get something to resonate, it needs to solve a real problem.

I track every key product change. I post regular updates internally, talk to customers, and train our internal teams on the changes so they can share them (marketing), sell them (sales), and track their impact (finance). I translate ideas across disciplines.

Connect is a conversation. You share ideas, listen to what people think, watch how people interact with your product. Doing so generates feedback, but it shouldn’t be one-sided. Ask questions and use the opportunity to seek out more insights to fuel continued growth. I often find simpler solutions to what we’re building when I share works in progress. It’s like a metal detector sliding gently over the sand, searching for the hidden treasure.

Connect fuels Build; Build fuels Connect.

Without a governing force, output compounds, complexity grows, coherence drifts.

That’s where Shape comes in.

Shape

The glue and governance between Build and Connect is Shape.

Shaping isn’t writing specs. It’s defining the constraints and guardrails that make good building possible. Specs try to answer every question; Shaping tries to answer the right questions. Because you can’t answer all the unknowns before you do the work.

Shaping is the act of designing constraints that preserve coherence and allow fast iteration.

Shaping = Structured Intention

Shape should produce:

1. Boundaries: What’s in vs. out, scope edges, surface area control.
2. Direction: What problem matters, what success looks like, why it’s critical.
3. Constraints: Tradeoffs, limits, guardrails.

Think of shaping like a prompt. If you want high-quality outputs, you need high-quality inputs. Shaping is critical because it combines design, engineering, and strategy into a single artifact to define the intention of work. When I write detailed and extensive prompts for AI, I get much better results. Humans are the same.

Claude Code in Plan Mode can create an implementation plan. It details the files it will create or modify, what code it will add or remove, and can immediately execute on the work. A few minutes later, you have a working version. But here’s the thing: you shouldn’t do this unless you’re clear on the shape of the problem. AI is an expansive process by default. It takes orchestration and guidance to reduce. When you shape something, you narrow the slice of work to start an AI session from the right frame.

If you’re executing on narrow scopes, then that’s fine. But when you’re working on bigger projects, shaping is still important.

Phases of Shaping

There are three phases of shaping:

1. Ideate: Raw exploration to surface possibilities.
2. Frame: Turning raw inputs into a coherent shape.
3. Validate: Stress-testing the shape before execution.

In each phase, the three lenses of design, engineering, and strategy are present.

1. Design is how it works.
2. Engineering is how it’s built.
3. Strategy is why it matters.

Ideate

I still like sketching. I’ll sketch by hand or use a tool like tldraw or Excalidraw or FigJam. If I don’t need to visualize it yet, I’ll start with writing, discussing with someone, or using voice-to-text with AI. When you ideate, you start from words or visuals. Then you use them together to create the frame. I often ask Claude to interview me about the feature to find all the edges of the subject.

Ideate through each lens:

• Strategy → what problems are emerging?
• Design → what could this feel/look like?
• Engineering → is this even plausible?

Frame

You take all the inputs—the sketches, the transcripts, the words—and centralize them in a single conversation to create the frame. Work them into a cohesive narrative to define the intention of the work.

Frame through each lens:

• Strategy → what problem are we committing to?
• Design → what is the intended experience?
• Engineering → what constraints define the solution?

Validate

Use Claude Code to spike a prototype or to write the implementation plan. Review it with your team and with engineers. Set clear constraints on resources (time, money, energy) and what metrics you intend to achieve. Move forward when the bet is right.

Validate through each lens:

• Strategy → is this worth doing?
• Design → is this coherent and usable?
• Engineering → is this feasible and scalable?

The Practice

The Operating Cycle is not just how work flows. It’s how work is regulated. Build and Connect run on their own, but Shape is what keeps them from running away. The practice is how you apply control points to maintain coherence in the work. You leverage AI, but without the downside of coherence drift.

Build is controlled by constraints.

Connect is controlled by filters.

Build Constraints + Connect Filters

Build Constraints

Before you build, you shape. You constrain what you’re building. AI, like humans, operate better with clear constraints because a reduced surface area is easier to reason with.

Use Build Constraints to define what gets built and what doesn’t. Avoid the rabbit hole of building more than you need to. When each new change is only a prompt away, the value is in limitation and constraint. Less is more.

Connect Filters

Not all feedback is created equal. And just because you can do it doesn’t mean you should. AI makes this more important. You can add anything with a simple prompt. But adding increases surface area, complexity, and risks coherence drift. Feedback fuels progress, but you can’t (and shouldn’t) build everything you hear. And you need to use your intuition to translate raw feedback into real problems before you build anything.

Use Connect Filters to find the signal in the noise of feedback. Shape what you hear through conversation, debate, and the collective intelligence of your team.

The Throughline

AI lets you move at the speed of thought. You have an idea; AI turns it into reality. This power carries a responsibility. Sometimes the best way to move forward is to stop, slow down, and create a clear intention.

That’s what Shape is. You engage critical thinking before you Build and after you Connect. It acts as a regulator of the work.

Build and Connect drive one another forward while Shape governs their outputs. I learned the lesson by being mindful of my time. I sensed when the product needed more shaped work, more direction, more strategy. If you’re always reacting and not thinking, you build, get feedback, and build some more. You don’t sense the signals pointing you the right way.

The Operating Cycle drives the right progress.