Product Current

We’ve run dozens of experiments in our product’s funnel from a new visitor to a trial user to a paying customer. We state a hypothesis, make the change, and track the results. Each iteration becomes a new probe sensing for signals, searching for a strong enough signal to inform direction. There’s a clear tension, but there’s not enough signal to justify a commitment to resources (time, money, people) on a project.

At least not yet.

Projects are fixed-time commitments with clear constraints: start date, end date, scope, team, deliverables, etc. In the typical approach to software development, you identify a problem through data—both quantitative usage data and qualitative feedback—and deliver the work against the fixed constraints. If you lean into the uncertainty of the work and provide levers to control scope, you can deliver a version of the work in the timeframe.

You have project-level work.

And then fixes and improvements.

Over the years, I’ve found most of the value in fixes and improvements. A product’s quality comes through refinement. You make small, focused, intentional changes.

And you do it over and over again.

The first release of a product or a feature in a product is just the beginning. You take your assumption, build it, and stress-test in real conditions. The more you limit the amount of changes, the more you concentrate your attention on the right outputs. Too many changes and you increase complexity.

Yet software development usually runs counter to this approach, like swimming upstream or working against the grain. Friction can often be a good thing, but not here. The natural flow of product work is like a river, moving continuously as it encounters new obstacles—shifting, bending, adapting.

When the funnel experiments didn’t resolve the tension, the choice became:

• Stick with it and keep experimenting.
• Commit to a larger bet with a project.

My intuition said it’s time to look at the entire onboarding flow. We changed enough, so if there isn’t a strong shift in the signal, then it’s time to commit to a larger effort.

The tension is still there, unresolved.

This work precedes projects. You don’t just shove something on the roadmap without a strong understanding of the problem. And in an AI world where execution is fast and cheap, you can spend more time probing.

You build continuous improvements until you either:

• Resolve the tension.
• Escalate to a larger bet.

If you resolve the tension this way, win.

If you have to escalate, you’ll do so with more confidence in the bet because of the iterative experimentation you completed.

Fixes and improvements, concentrated within focused effort, produce information as you make real changes in the product. You don’t sit around in the land of assumptions, Fake Figma, or indecision. You make small decisions to increase your certainty in the bigger decisions. You follow the current, organically shaping the work as you go.

The Old Way:

Identify → Scope → Build

The New Way:

Intention → Tension → Intervention

The Old Way has no space for tensions to incubate. Everything moves too quickly from “identified” to “scoped.” And all the work in scoping is an illusion of certainty. You can never remove the unknowns in the process.

The New Way is for “Streams,” a container of living tensions progressed with action, from delivering fixes and improvements to increase your fidelity of understanding. You learn by doing. You probe for signals.

Product work isn’t a sequence of projects. It’s the management of forces within a living current. And you need to follow it.

This idea is called the Product Current, which lives in the Clarity Current of the Claritorium and Value Creation of Equilio.

The three pillars are:

1. Strategic Direction for intentions.
2. Exploratory Resolution for tensions.
3. Committed Execution for interventions.

Strategic Direction

When I started my new role, I didn’t force a product strategy. Why? Because, given the right conditions, the best ideas emerge naturally from the work. If you focus on trying to make something happen, you often do the opposite. And you focus so much you lose your ability to sense when something is working; and when it isn’t.

Great product work is sense-making. Hell, any craft is about sense, feel, judgement.

So I waited. I learned the product, the customers, the team, the market. I wrote code, designed, talked to customers, worked with the sales team; I stayed in the work.

To develop a feel is to embody the work. You embrace the friction, the discomfort, the uncertainty. You know what you don’t know.

Eventually, you get to a point where the work feels natural. Rhythms coalesce into a symphony of creation. Tensions exist, but only to heighten your intuition and sharpen your senses. You become one with the craft.

To perform any craft well requires an intuition forged by experience, refined by intention, and fortified by discipline.

It doesn’t matter what you do. If you do something, do it well. And bring that same energy to all the somethings you do. There’s no requirement to have only one craft.

The reason a product strategy emerged from the work is because I knew what signals to expect. I felt the shifts, the tensions, the pressure. I knew when the strategy arrived, like an old friend you talk to after years and pick up right where you left off.

In yoga, you start the practice by setting an intention. It can be anything: staying in your body, focusing on your breath, embracing the discomfort. The intention serves as an anchor, bringing you back when things shift.

Strategic Direction is your intention. It’s the set of themes guiding your work like a gravitational pull to impactful outcomes.

As we discussed the work, the product’s direction, and what we’re doing, the language of the themes began to develop. The words became concepts of distillation driven by repetition. That’s why Human Calibration is so critical. When execution is cheap and fast, you need to be clear about the direction. If you don’t frame the work, you create incoherent products. So I created five strategic themes to anchor the work. And now they exist as entities to help direct the work as we keep refining them.

Once you have intentions anchoring your focus, you create a mechanism to compare and contrast this thing versus that thing.

Does this move us in the right direction?

Intentions govern what tensions matter.

Exploratory Resolution

Product work is the mapping and resolution of tensions. Feedback comes in many forms, but often it’s negatively tinged and laced with frustration. That’s fair, though. Users pay money for your product, establishing a contractual relationship with specific expectations. When I’m on the paying side, I like to remember there are human beings trying to do good work. Yes, there are a lot of SaaS products with malicious intentions, but that designation shouldn’t land on all (or most) of the software you use.

User express frustrations:

• “This didn’t work how I expected!”
• “I want to cancel my subscription!”
• “This is unusable!”

The capitalist exchange grants them supervisory powers; or so they believe.

But you still have control. They can choose to pay for your product, but you choose how and when to resolve tensions. The tensions fluctuate continuously. Instead of relying on stale backlogs, shift attention to emerging signals. What feels off? What are you hearing a lot about? Where is your energy going? Teams engaged in lively discussions naturally surface tensions just by talking about the state of the product. These discussions are rich with context, nuance, and signals. You just have to listen.

The Work Registry is where work lives, but it’s also where context develops. If it’s something you need to do, it belongs there. I focus a lot of my resources on tracking work in Linear, keeping it fresh with the latest context, and using the Linear MCP in Claude to organize and create what I call “streams.”

A Stream is a collection of work designed to resolve a tension. It sits between strategic themes and projects. They are mostly fixes and improvements (F&I) aggregated within a clear goal you’re trying to achieve. But it can also include research and design work. Anything designed to move you closer to understanding and resolving the tension belongs.

With Claude, I look through current issues and identify patterns. It helps me coalesce those patterns into Streams. I keep it limited to no more than three at a time. I track these in a spreadsheet, but also in Linear. Each one is a parent issue with the collection of experiments as sub-issues. Seeing them in aggregate helps understand how the work is moving. Are we resolving the tension?

Streams are precursors to projects, but sometimes they resolve on their own. If not, they escalate to an intervention. You make a bet with resources to intervene and address the tension more fully with a project. Work in a Stream is focused experiments. You’re probing, like checking the temperature of the water before you get in. You’re looking for signals before you make the commitment.

One of our Streams is focused on optimizing the funnel. The experiments create fast feedback loops. We pose the hypothesis, make the change, and learn from the results.

We determine if:

1. The tension is resolved.
2. More experimentation is needed.
3. It’s time to escalate to a bigger bet.

We’ve run 30 experiments. The results aren’t there, so intervention is required.

Using Intelligence Orchestration, we move quickly to release experiments. Action produces information. Issues don’t lay dormant in the backlog. A hypothesis can be tested quickly, so why expend energy on projects before you know it’s worth it?

That’s Exploratory Resolution. You don’t discover, scope the work, and hope for the best. You ship real changes, evaluate them, and find the signal in the noise to point you in the right direction. We can invest in a larger bet like onboarding only once the tensions are unresolved with Streams of focused experimentation. And if you leverage the Work Registry by building a wealth of rich context, you position yourself to execute on project work with precision.

Tension must mature before intervention.

Committed Execution

My kids have toys in the kitchen they play with every day. They frequently leave them out and don’t put them back. After years of cleaning up after them, we decided to do something about it. For a week, we gave them a simple reminder:

Whatever toys you leave out will be bagged up and donated.

So we did. Each night before going upstairs to get ready for bed, we reminded them the consequences and let them decide. After the week of reminders, we started bagging things up until they understood fully.

We had an intention to make sure they take care of their things and respect the house.

We identified a tension when they weren’t cleaning up. So we experimented with a new approach to resolve the tension.

When the experiments didn’t resolve the tension alone, we performed the intervention to fully solve the problem.

We didn’t jump right to the intervention until we were certain it was necessary. The experiments pointed us in the direction. This is no different in product work.

Committed Execution is when you bet resources against solving the problem. You use the Project Engine to apply focused energy, leveraging the knowledge you acquired through experimentation. Once you commit to a project, it’s still an experiment; but one focused on optimization instead of exploration. The effort is surgical.

This also avoids the problem where you work on a project, release the work, and then miss the opportunity to refine. Every project I’ve worked on would have been much better if we were on it for 2-3 weeks after release, continuously shipping fixes and improvements based on user feedback. You can build this into your project timeline, but it’s even better when there’s work done through a Stream before the project. And then the same thing happens after the project; and through regular F&I work.

Intervention is concentrated pressure.

The Practice

The Product Current is expressed through a simple practice, moving through direction, exploration, and execution. AI is highly leveraged throughout the process, informed by human judgement and experience. I represent the Product Current in a spreadsheet I call the roadmap to avoid confusion and align to common norms. This is an evolution of the original format I created and used in the Product Forge.

There are five tabs in the spreadsheet:

1. Themes
2. Streams
3. Bets
4. Experiments
5. Ledger

Themes (Intention)

Themes establish intention. You should keep them limited to no more than five.

Attributes:

• Streams you’re tracking.
• Bets you’ve committed to.
• Health of the work.

Themes live in their own tab within the spreadsheet. I also share them as simple designed visuals to illustrate their value.

Streams (Tension)

Streams establish tensions. You should keep them limited to no more than three.

Attributes:

• Tension to describe the issue.
• Resolution Criteria to describe what needs to be true to resolve it.
• Escalation Trigger to describe what conditions require intervention.
• Experiments to track completed and active experiments you’ve run.
• Theme it connects to.
• Status of the tension, like open, converging, or closed.

Streams live in their own tab within the spreadsheet. I also track them in Linear as parent issues containing sub-issues.

Bets (Intervention)

Bets establish intervention. Keep them limited to your team’s capacity, bearing in mind your active Streams. A maximum of three is generally a good number to follow.

Attributes come from the Project Engine.

Bets live in their own tab within the spreadsheet. They’re also tracked in Linear, starting as an issue and converted to a project when we commit to it; or not.

Experiments (Probes)

Experiments are probes. They’re framed as a hypothesis, tested with real metrics, and evaluated against real success criteria.

Experiments live in their own tab within the spreadsheet. There’s an internal dashboard I built with Claude Code to show the experiments in the Weekly Update. It’s important to promote experimental work so everyone can objectively view the progress.

Ledger (Memory)

The Ledger is your memory. Log key releases, updates, and decisions. Anything that’s relevant to future decisions and knowledge-building belongs here.

The Ledger lives in its own tab within the spreadsheet.

The Throughline

I was catching up with two friends recently. They’re both software engineers. One of them talked about feeling reenergized by work now that he’s using AI for programming. Why? Because he doesn’t have to fight configuration problems, build issues, or any of the other periphery problems that sit on top of software development. He can focus on the strategic execution where his knowledge, skills, and experience are most needed. He can direct AI agents through intentional direction and tasteful review. When you’re first starting out as a junior developer, struggling through those same build problems is important. The friction forces you to understand how the system works. The discomfort is part of the process. But later in your career, it’s your taste, judgement, and intuition to architect solutions that matters the most. That’s why Intelligence Orchestration and Human Calibration are so important in a world of AI and agentic coding. Where do you, the human, fit in that process?

AI is a disruptor. If you’re not actively thinking about how it’s changing your work, you will be in a poor position as it evolves. There’s still space for craft. But how that craft is expressed changes. All the experience you acquired comes through new workflows. Surrounding your individual efforts is the system the work exists within.

The Product Current is a new way to move through the work.

You start with clear intentions through established themes with strategic direction.

You seek tensions in the work, experiment, and resolve or escalate to the next phase.

When tensions are unresolved through experimentation, you step in with interventions through clear commitments as bets.

Work is like a river. Are you going with or against the current?