the first clock to break

how to disrupt time to decision with ai

I used to think the big unlock with AI was time to production.

Generate some code, share it with engineers, ship faster.

The reality is that pushing generated code to production still requires code review, rewrites, connecting real data, testing. That work doesn't disappear.

What does change immediately is how fast you can explore ideas. AI turns prototyping from a multi-day process into a conversation.

You get something real in minutes.

Real enough to click through, react to, decide on.

Not just a static mockup, but something you can feel.

The same fidelity that used to take hours in Figma or weeks in code now happens at the speed of thought.

Time to decision is the first clock to break with AI.

the three clocks

This is the mental model I use to think about shipping velocity.

Time to Decision: how fast we go from "what should we do" to "we're doing this" or “we’re not doing this”

Time to Learning: how fast we learn if we're building the right thing

Time to Production: how fast we ship once the direction is validated

Faster decisions lead to faster learning. Learning improves your next decision.

AI compresses the double diamond.

Shipping becomes follow-through when you know you're solving the right problems.

what "decision" means here

A decision can be small or large.

A pattern decision, a feature decision, a product decision. A prompt decision, a model decision, an architectural decision.

They all count.

Decisions compound. Killing five animation options before lunch. Cutting entire feature paths in an afternoon. These add up to massive velocity gains.

The goal is to make better decisions, faster.

the clock is already breaking

Shopify's CEO Tobi Lütke told teams that the prototype phase of all internal projects "should be dominated by AI exploration."

His reason: Prototypes are meant for learning and creating information, and AI dramatically accelerates this process.

Teams at Shopify can now "produce something that other teammates can look at, use, and reason about in a fraction of the time it used to take."

They're exploring multiple directions in hours instead of weeks.

---

Zapier took a different approach. They paused all work for a week to run company-wide AI hackathons. Everyone built something real, from engineers to support staff.

Their support team built "Sidekick," an AI ticket summarizer that cut average handle time in half. Teams started tackling work that was previously too tedious or expensive to prioritize.

They tolerated messy experiments and duplication.

Some failed, like their early OpenAI plugin. But that learning compounded.

When new opportunities emerged, they could move fast.

89% of Zapier employees now use AI in their day-to-day. More importantly, teams are reimagining entire workflows, not just doing the same work faster.

what i'm seeing

On our team, we've moved from multi-day design sprints to same-day decision sessions. We prototype live, cut options in real time, and leave with clear direction.

The prototypes aren't production-ready. They're decision-ready.

They're the new PRDs.

When killing ideas becomes cheap, you explore more freely. You're no longer attached to ideas when the next one is minutes away.

Different product teams, different industries, same pattern.

Speed to fidelity goes up, time to decision goes down, and learning is unlocked sooner.

a decision sprint you can run tomorrow

Andrew Ng's AI transformation playbook recommends starting with lightweight pilots that build momentum.

This sprint framework is exactly that. A lightweight way to build momentum around faster decisions.

1. identify a problem

Make it specific.

Modal or full page?

Stream tokens or only show the final output?

Claude Sonnet or Opus?

Pick one question that actually moves the experience.

2. prototype at the speed of thought

Open v0 and prompt a rough version of the flow.

Click around. Iterate. Apply your taste and product sense.

If it has legs, bring the idea into Cursor or Claude Code to push it further.

Fork two or three directions.

Aim for speed to fidelity, not polish.

3. decide in the room

Do not end conversations with "I'll mock that up later so we can decide next time we meet."

Prototype it now. Get to the decision.

Ask the model for a short summary of what you tried, what you chose, why, and what risks should be considered with each option.

(Later, I’ll share a prompt you can use to generate this decision log following a prototype session)

4. share fast

Default to user feedback.

Send a recording or staging link within 24 to 48 hours and put it in front of real users if you can.

If users are unavailable, share with the most informed stakeholders, but get to users as soon as possible.

Move from assumption to a signal quickly.

5. move together

Once the direction is clear, everyone can move together.

There’s no need for traditional hand-off if you’re able to achieve shared understanding early.

This results in way less back-and-forth.

a tiny decision-log template

Try this prompt with your coding agent after a session:

Create a brief decision log of this session (not too verbose, formatted nicely):
- Problem we were solving
- Options explored (2-3 bullets, mark with ✅ shipped or ❌ killed)
- Kill rate (% of options killed)
- What we decided and why
- Main risks to consider
- Next steps

what you can actually track

Decision Lead Time: From the first written question to the decision timestamp

Time to First Signal: From the decision to the first useful insight, whether from users, stakeholders, or test cases

Kill Rate: How often we decide not to build, because saying no fast is a feature

targets that work for me

I try to create motion within 24 hours of a question being raised.

I usually create and share a tangible artifact (prototype, landing page, recording) with someone within 24 hours of deciding.

Users, stakeholders, whoever.

I seek feedback and iterate like hell, averaging about 60-80% of options killed for each version of an early prototype.

If you're not killing enough ideas, you're probably not exploring enough options. When prototyping is this fast, ideas are cheap. Killing ideas should be your default.

anti-patterns to avoid

1. endless forking without deciding

You can explore forever if you let yourself. Timebox it. When you've got enough signal to make a call, make it. Analysis paralysis kills momentum.

2. demos that are too far from reality

That sick demo might not make sense at all to build.

Are you solving the right problem?

Get a second opinion early if something feels too good to be true.

3. decision logs that become another burden

Don't let process kill the momentum you’re trying to build. Document only what's useful.

A simple list of what you killed and why is enough to spot patterns.

4. delegating critical thinking to a model

Don’t do this. Use your brain.

AI is a partner in doing hard work, not a replacement for it.

closing thoughts

Today, a team will debate something for an hour that could be prototyped in ten minutes. And a decision still won’t be made by the end of the meeting.

That's the gap. That's the opportunity.

Instead, try this:

When someone says "What if we..."

Take a stab at building it right there. All you need is ten minutes.

Show it to them. Discuss. Make a call.

Now you are the catalyst in creating shared understanding to accelerate shipping velocity.

The tools are ready. The question is whether or not you are.