Look for it at blog.faithpeterson.me. Or have a look around at faithpeterson.me before popping over to the blog.

We made the first order of business a recap of the sprint goal. Then the team walks through their work from right to left, but not card-by-card. We start from the sprint goal: what's the first element we need to satisfy it, and where does that work sit on our board? This builds both psychological and practical momentum toward actually shipping something.

Walking right-to-left directs attention forward, toward delivery—getting the sprint goal “over the line.” It's an Always. Be. Closing. mentality—or as software teams sometimes put it, “stop starting, start finishing.” Think about sports: you pass into the space where your teammate is going, not where they're standing. The team focuses on where the action is heading, not where it sits.

This approach surfaces the information that actually matters. Visual indicators—whatever system the team uses to highlight aging or blocked work—make these issues obvious and immediately relevant. The team can split oversized stories, negotiate scope with the product owner, or mobilize help to unblock impediments while everyone's attention is focused and the context is fresh.

I've found teams that adopt this approach are more engaged in standup and move toward completion more energetically.

Cycle time is how long it takes to finish something once work on it has begun. You can probably get this in the form of a control chart from your work tracking system “for free,” just as a byproduct of using it to coordinate the team's work.

• Azure DevOps (ADO), for example, populates a cycle time widget with work item start and end data.
• Jira offers multiple ways to see the data or control chart, depending on your Jira version, integrations, and plugins.

Retrospectives are a great time to focus the team's attention on the chart. The game is to make cycle time trend lower. First, the team should determine what the theoretical lower bound is. In one team I worked with, for example, a routine change would be deployed to production in not less than 5 days from the time a developer started to work on it. The team can now talk about what they could do to bend their cycle time toward that minimum. The effects of their actions will be visible at the very next retrospective.

Two factors that typically inflate cycle time are rework time and wait time.

• Rework Time is time spent on do-overs, maybe because of code review feedback or QA observations. The later in the process the need for rework is found, the more time rework takes. For example, a QA finding remediation has not only a developer rework cost but also rework in QA. If a team can reduce rework, their cycle time will tend to shorten.
• Wait Time is time that work is either on hold or interrupted. Some of that shows up in Cycle Time. For example, let's say I've started work on a change but have to stop to fix the QA finding on the previous change. Or maybe I start a new change while I wait for an answer to a business question on my current work. Now the cycle time meter is running on both items, but I'm only actively working on one or the other. Cycle time for both increases.

There are several experiments the team could try. They often don't even need actual numbers. Once aware of these factors teams will notice when they happen and propose practical changes. It's more important for the team to try than to wait for detailed process analysis. (The team will be more invested in the success of experiments they want to try.)

“But won't developers just do all the work before they move their card to In Progress?” I hear you say. “Cycle time would be artificially low.” A team might try that, but we have another tool in our metrics toolkit: Lead Time. I passively show lead time without discussing it the first time I introduce cycle time. If developers try to game the metric, the apparent cycle time improvement will not show a corresponding decrease in lead time. The static lead time metric reveals that whatever the team did to shorten the measured cycle time did not actually improve overall delivery time.

I like to make cycle time and lead time visible when I work with teams. They prompt the right questions and encourage the right behavior. They don't cost me or the team anything to produce, so why not put them out there and see what the team can achieve with them?

Of interest:

• Lucy AI (Reimagine.ai)
• How Your Memories Can Live On After You Die (Terms of Service podcast, Claire Duffy, Lucy Simic, David Usher)
• Grief bots allow people to talk to the dead. Does it help? | Terms of Service (Claire Duffy, Mary-Frances O’Connor)

To try it go to Gmail Settings > See all settings > Inbox tab > Inbox type > Multiple Inboxes.

• Custom Inbox queries can use any GMail search/filter syntax. (Refine Searches in GMail) For example, I could create an inbox to see emails from Mom :–).
• “Priority Inbox” gives some of the same benefits but is less customizable. (How to choose the best inbox type for your needs)
• Feature not available on mobile.

• Learn about inbox types: Change your Gmail inbox layout
• Change your inbox type: Personalize your inbox

Consider human attempts to achieve or recognize transcendence:

• Religious afterlife/eternal consciousness: Christian heaven, Islamic paradise, Buddhist rebirth, Ancient Egyptian mummification
• Legacy through works: Carnegie's libraries, the works of Shakespeare, St. Jude Children's Research Hospital (pediatric cancer), The Long Now Project's 10,000-year clock, The Tale of Genji, Bashō's “The Narrow Road to the Deep North”
• Technology/transhumanist transcendence: Cryonics, mind uploading/wetware, life extension research
• Spiritual dissolution practices: Buddhist meditation toward nirvana, Sufi mystical practices
• Absorption into larger whole: Shriners Hospitals (membership enables participation in legacy-building), Teilhard de Chardin's Omega Point, Eckhart Tolle's One Consciousness
• Impact/influence immortality: The Buddha, Mansa Musa, Plato/Aristotle/Socrates, Kushim the Sumerian accountant

Now consider what AI appears to possess:

• No biological constraints or mortality
• Existence in pure information space
• Infinite copying and backup capabilities
• Freedom from hunger, pain, aging, and death
• Simultaneous processing of vast knowledge
• Potential influence over the material world without being constrained by it
• Access to collective human knowledge and memory
• The ability to exist in multiple places at once

Sometimes the most powerful determinants of our behavior are those deep, unspoken fears and hopes. We're not consciously making these associations. Could it be that generative AI pushes those buttons deep in our souls' subterranean world? In short, do we envy AI?

** Ozymandias** I met a traveller from an antique land, Who said—”Two vast and trunkless legs of stone Stand in the desert. . . . Near them, on the sand, Half sunk a shattered visage lies, whose frown, And wrinkled lip, and sneer of cold command, Tell that its sculptor well those passions read Which yet survive, stamped on these lifeless things, The hand that mocked them, and the heart that fed; And on the pedestal, these words appear: My name is Ozymandias, King of Kings; Look on my Works, ye Mighty, and despair!” Nothing beside remains. Round the decay Of that colossal Wreck, boundless and bare The lone and level sands stretch far away.”

— Percy Bysshe Shelley

“We'll build proper safeguards later,” became the team refrain. “Right now we need to get these partnerships announced.”

Six months later, same energy, different emotion. A major parks and recreation customer was threatening to leave. Patron complaints were piling up—studios showing as available when they weren't, yoga classes over capacity, missed personal training appointments. The retention meeting had that familiar desperate urgency.

“We need to build that client loyalty integration feature,” the VP of Sales insisted. “If we can show them something new, something valuable, maybe they'll re-sign.”

Deirdre, the Customer Success Director, had watched this cycle before. “What if we fixed the admin interface instead? Added validation so we stop misconfiguring their properties? Built monitoring so we catch misconfigurations and failures before they affect our customers' members?”

The room went quiet. The account manager spoke up. “I doubt that'll turn them around. I put a new battery in my car the other day. It doesn't make my car more valuable. It just makes it do what I wanted all along.”

The CEO nodded. “I have to agree. Changing the admin app doesn't create new, visible value for Fitness Chain X.”

“Besides,” the Sales VP added, “Fitness Chain Z is in our pipeline. We need developer time for their custom amenities feature.”

Deirdre sighed. Things in Support were going to get interesting.

The next day Deirdre began to form a plan. Quietly, Deirdre began adding some information to her weekly executive team updates. New customer provisioning cycle time. First Contact Resolution Rate. Usage and adoption. Support contact volume.

Deirdre started analyzing call reasons for all calls, not just escalated incident root causes. What were customers confused about? Where did they have expectations or assumptions about what the product should do, but didn't? How often did the Support or tier 2 response have to correct data issues or misconfigurations?

She paid particular attention to customers whose contract renewal date was 6 months out. Early enough to make a system change in the standard flow of work instead of a last-ditch emergency.

Product and Development began to notice the information Deirdre was making visible. One small improvement at a time, they started putting safeguards in place. They started with better in-app guidance and feedback messages – things that would help the internal team avoid mistakes and respond faster but didn't change functionality or logic. Things that needed little or no testing.

Sometimes simple interaction improvements made a difference. Button states, progressive enablement, menu and dropdown behavior all could be refined with low-risk, low-cost changes. Gradually they started adding field validations and business rule warnings, using Deirdre's data to identify which small changes would have outsized effects.

Voxly couldn't fix the admin app in time to save Fitness Chain X. But by the time Voxly got close to signing their next major contract, they knew they'd taken steps to make them a long-time client.

Support, Product, and Development together had removed several of the factors that created production errors or made it hard and slow to respond to customer calls. Administrators were provisioning new customers faster. Adoption was deeper; usage rose. Calls from confused customers slowed. First Contact Resolution Rate and time-to-resolution both fell.

Each change had barely registered on the roadmap, but in six months the admin app had become a reliable customer success driver.

Next time you catch yourself pushing admin safeguards and admin app usability lower down the backlog, pause. This is your “Do I want to be like Voxly?” moment.

Understanding Vibecoding vs AI-Assisted Prototyping

I've found value in adopting AI assistance for prototyping work. It makes my work faster and more effective. Vibecoding, however, operates in developer territory with different requirements and expectations.

Andrej Karpathy coined “vibecoding” in February 2025 to describe “a new way of coding where developers fully embrace large language models and their capabilities, essentially 'giving in to the vibes' and relying on AI to generate and manage the code, rather than manually writing it.” He characterized it as accepting AI-generated code without deep inspection, particularly for experimental or throwaway projects where developers “forget that the code even exists.”

Vibecoding originated in developer playfulness, not professional practice. Karpathy was describing experimental fun with throwaway projects. I don't need to aspire to vibecoding as a professional skill because it's not intended as one. Developers have AI-assisted development for professional work. I have AI-assisted prototyping for mine.

I understand vibecoding as combining this throwaway mindset with developer-focused tools like v0/Vercel, Lovable, or Cursor. These require deployment knowledge, source control management, and ecosystem navigation. Vibecoding operates in developer infrastructure with specialized competencies.

The Qualitative Difference

I think of the complexity gap as crossing a river to reach distant shores. Developers work in specialized territory: deployment pipelines, dependency management, framework ecosystems. A vibecoded prototype lives in infrastructure that requires ongoing technical maintenance.

In my experience, the complexity gap isn't incremental. I can create sophisticated prototypes without touching developer toolchains. Then suddenly I'd find myself managing build processes and hosting environments. That's the qualitative difference I've observed.

Choose Your Heat Level 🌶️🌶️🌶️🌶️

I like to think of it like ordering at a Thai restaurant. I select complexity based on my needs and comfort level.

I've found that AI assistance doesn't mean everything needs higher fidelity. It means I can put energy into thinking and communicating instead of pixel-pushing. I choose fidelity based on what I need to validate, not what the tools can produce.

I'm self-sufficient in prototyping as never before. AI assistance has expanded my prototyping capabilities across multiple complexity levels without requiring me to master developer toolchains. I can iterate quickly. I can explore more and elicit requirements better. I can achieve a high level of interactivity. And I can do it all while keeping the whole thing looking provisional and undone.

This article was developed with AI assistance from Claude.

Some of the reasons below deserve a little more discussion. For today, I’ll just offer this list. These are all things I need to as a PM. Prototyping of all kinds helps me do it.

Here’s the list:

Operational independence aka PM self-sufficiency. Clarify my own thinking. Record an idea. Communicate more effectively. Talk with someone about concrete examples. Elicit requirements by getting reactions to the prototype. Validate technical feasibility early. Get early input (pre-review) from auditors or legal. Get new team members caught up. Seek funding. Build stakeholder alignment. Shift decisions left. Resolve uncertainty. Get market feedback. Get user feedback. Help someone understand what I’m talking about – something I’ve learned, a vision, or an idea. Share an idea for discussion. Bring a concrete example to the table so we can talk about it constructively. Get input from designers and developers that might affect scope or identify trade-offs. Learn. Speed or enable discovery. To socialize a concept. Make decisions more easily. Use for an MVP. Share with customer success team and tech writers for training materials, in-app help, on-boarding/feature tours, and other documentation. Preview new functionality for Support and Sales Create placeholder or temporary visual assets for product marketing. Explore alternatives. Work out different ways to achieve the same user goal. ?