Saturday, May 16, 2026

What Information Do You Actually Need Before Making a Solid Plan? (And Why Most Companies Never Really Get it Right)

By: Alon Cohen & AI Asist

I recently read a post by Amir Fish about an app that lets customers describe the features they need, and the app actually adds those features into the product. Brilliant, however, it made me think, how come it hardly feels like anyone is hearing the customer?

Picture this. You’re about to make a big call for your business, like rolling out a new feature, changing your pricing, or going after a different market.

What information would you really need to feel confident about that plan?

Go ahead and think about it for a second.  

Who is your audience, and what are they actually struggling with right now? What constraints or frustrations keep popping up? What would make them excited enough to say “yes” without hesitation?

And here’s the harder follow-up:  

How exactly would you get that information straight from your customers?  

Not the polished version that’s been filtered through support notes, team meetings, and executive summaries. The real, messy, unfiltered version in their own words.

Every company out there loves to say they “listen to the customer.” But in practice, most fall short. Here’s why the usual methods keep letting us down, and what can actually work better.


Broken Phone

The Broken Telephone Game

Your support team and sales reps hear the truth every single day. Customers vent about what’s broken, gush about what they love, and casually drop those golden “it would be great if…” ideas. That feedback travels up the chain, and somewhere along the way, it gets diluted. Details get lost. Tone disappears. By the time it reaches leadership, it’s no longer the customer’s voice. It’s someone else’s interpretation of it. Sometimes a ticket is opened and even kept, well, until PM decides to start fresh with a new board.

The Expensive Traps We Fall Into

Surveys sound scientific, but they’re slow, expensive, and heavily biased toward whoever has time to fill them out. Not to mention the bias of the person approving the questions.  

Bringing in consultants? You’re basically paying top dollar for smart outsiders to tell you what other managers in your industry think customers want. It’s filtered, second-hand insight at best.  

And don’t get me started on relying purely on numbers. They can be downright misleading. Back when touch-screen phones had almost zero search volume, plenty of people concluded: “No one wants that.” Look how that turned out. Or think about remote villages with no shoes. Does zero demand mean there’s no market, or does it mean there’s a massive opportunity waiting?

Raw numbers without real context often hide the truth rather than reveal it.

So What If You Could Cut Out the Middlemen?

What if every sales call, support conversation, and chat session were automatically turned into a clean, structured record? Complete with the full transcript, who the customer is, what they’ve bought, how the interaction went, and all the surrounding context?

That’s exactly what a vCon does. Think of it as a “conversation PDF”, a portable, complete package that keeps everything intact instead of letting bits and pieces slip away.

Now add modern AI on top of that. Suddenly, you can analyze hundreds or thousands of these conversations at once. The AI spots patterns humans would miss: recurring complaints no one’s reporting, unexpected excitement around certain features, hidden objections, and those offhand comments that signal real opportunities.

You stop guessing. You stop relying on summaries and averages. You start hearing your customers directly.

What Changes When You Finally Listen This Way

When you combine vCons with smart AI insights, those big planning questions from the beginning become a lot easier to answer:

  • You understand who your real customers are because you hear them describe their world. 
  • You see their actual constraints and pain points in their own language.  
  • You catch opportunities that surveys and reports completely miss.

Decisions start to feel obvious in hindsight rather than risky bets.

The beauty of this approach is you don’t have to preach it. Just ask your team the same questions I asked at the top of this post. Let them connect the dots themselves. Most people quickly realize the same thing: the best way to understand customers isn’t another survey, another slide deck, or another expensive consultant report.

It’s capturing real conversations as vCons and using AI to pull clear, honest insights straight from the source.

Your customers already have the answers you need.  

The only question left is whether you’re ready to actually listen.  

What information do you need before your next big move? Your next conversation might already contain it.

Please comment below..

### 


Monday, April 27, 2026

Why Your Best Engineers Can’t Ship Fast Enough

By: Alon Cohen & Ai freinds

Introduction

I recently saw a video about the need for speed that made me think about delivery speed, but outside the Tech Talent box. Every company claims its biggest risk is talent shortages. “If we just hire better engineers…”, "If we just had more development resources...". But is it really the only reason for slow deliveries?

Here is what I think I learned over the years.

The single point of failure in almost every development organization isn’t code, architecture, or even headcount. It’s the decision-making culture.

When smart, capable people at every level are afraid to decide, or feel they must escalate every meaningful choice to someone higher up, the entire machine grinds to a halt. The best engineers in the world cannot ship fast enough if their work has to survive endless review cycles from people who haven’t touched the product every day.

I bet you heard the phrase “a camel is a horse designed by committee.” It means that when too many people have a say or try to shape a design, the result often becomes awkward or compromised instead of elegant.

However, this isn’t a “process” problem. It’s a cultural one. And it quietly kills more companies than bad technology ever will.

How Decision Fear Creates Bottlenecks

It starts innocently enough:

  • A mid-level engineering manager sees a feature that needs a small scope change.
  • Instead of deciding, they schedule a sync with the director.
  • The director, wanting to be “aligned,” loops in the VP.
  • The VP, now three layers removed from the actual users and code, asks for more data, more options, market research, different vendors, a presentation, animated graphics design, etc., adding more and more stakeholders.

Each escalation adds days or weeks. Requirements drift. Context is lost. By the time the decision finally comes back down, the original problem has changed, and the team is already working on the next sprint, or even worse, the next shiny project.

In many cases, the "hierarchy" (if they understand what was asked) decides that the feature might be needed, but the developers are so busy that, as gatekeepers, they must say no (or he/she cannot ask for more people). By that time, that feature could have been done, tested, deployed, and made a few customers happy.

The people closest to the product, the ones who actually ship it, are no longer empowered to own it. The result? More iterations, more meetings, more “let me check with leadership” Slack threads.

Even elite development teams become order-takers and ticket hoarders instead of owners.

Why Upper Management Is the Worst Place for Most Decisions

The higher you go in most organizations, the further you are from the customer, the code, and the day-to-day reality of building the product. Yet many cultures treat senior sign-off as the gold standard for “good governance,” or a CYA methodology. 

This creates two toxic outcomes:

  1. Decision latency explodes. A two-way-door decision (reversible, low-cost) gets treated like a one-way door (high-stakes, irreversible).

  2. Accountability evaporates. When everyone is “aligned,” no one is truly responsible. Mistakes get blamed on “the process” instead of being owned and fixed fast.

  3. Legal eliminates. When it comes to the point where legal get involved, an innovative product is as good as dead. No one wants to take a risk because no one in legal can provide a straight answer, certainly not a corporate lawyer, and certainly not on any innovative technology. (examples are AI, AI Voice Agents, Transcription Agents, and so on).

Real Competitive Advantage Is Talent AND Speed of Decision

You can have the most talented developers on the planet. If your culture punishes mistakes more than it punishes stagnation, you will lose.

Companies that win treat fast, decentralized decision-making as a feature, not a bug.

Real-World Proof: When Decision Culture Wins (or Loses)

NASA vs. SpaceX

For decades, NASA operated with a classic bureaucratic, risk-averse model: heavy documentation, multi-layer approvals, and waterfall-style development. Decisions that should have taken days dragged on for years.

“[At SpaceX] we would make a decision in a single meeting that would take years to reach the same decision point at NASA.”
Garrett Reisman, former NASA astronaut and SpaceX Dragon program lead

An Oxford University study of 203 space missions found that SpaceX projects took an average of about 4 years from decision to build, while comparable NASA projects took nearly twice as long.

SpaceX vs. Blue Origin

SpaceX sprints with transparent, rapid iteration and a bias toward action. Blue Origin has historically emphasized methodical, consensus-driven progress.

In February 2025, Blue Origin CEO Dave Limp openly cited the problem in an all-hands meeting while announcing a 10% workforce reduction:

“We grew and hired incredibly fast in the last few years, and with that growth came more bureaucracy and less focus than we needed.”

The Boeing Cautionary Tale

Once legendary for engineering excellence, Boeing moved decision-making power toward finance and short-term profit metrics. Engineers, the people closest to the product, were increasingly sidelined. The result: the 737 MAX tragedies and ongoing safety issues, widely linked to this exact cultural failure. Read the Harvard Business School analysis

What a Healthy Decision Culture Actually Looks Like

A culture that prefers some mistakes over stagnation has these traits:

  • Empowerment at the edge: The people writing the code (or bolting on the heat shield) make the majority of product decisions, exactly what lets SpaceX outpace NASA and Blue Origin.

  • Clear decision rights: Everyone knows who owns what and when escalation is truly necessary.

  • Psychological safety around reversibility: “We can fix this in the next release” (or next flight) is treated as a feature, not a failure.

  • Leadership that stays out of the weeds: Senior leaders set strategy, context, and guardrails, then get out of the way.

  • Metrics that reward speed and learning, not just zero defects.

  • Small teams, with minimal overhead that value cross-collaboration, meaning they can introduce small projects to other teams with specialized knowledge as quick interruptions, and receive fast unblocking without reprioritization red tape. In other words, operating with a true “we’re on the same team” mindset.

If You Are in a Position to Fix It in Your Own Company

Start small and be brutally honest:

  1. Audit your last five major features. How many decisions were escalated unnecessarily?

  2. Introduce the Type 1 vs. Type 2 framework in your next leadership offsite.

  3. Give teams explicit decision-making authority and protect them when they exercise it (even if the decision proves imperfect).

  4. Kill the phrase “Let me run this up the flagpole.” Replace it with “You own this, ship it.” As a lead back your team decisions as if they are yours. 

  5. Measure decision speed the same way you measure velocity or quality.

Conclusion

Talent is the bare minimum.

The companies that dominate the next decade won’t necessarily have the smartest engineers; they’ll have the ones who are allowed (and expected) to make decisions without waiting for permission from someone three layers removed from the product.

NASA, Blue Origin, and Boeing all had (or still have) extraordinary talent. What separated the winners from the laggards was the decision-making culture.

Fix the culture.
Empower the team.
Prefer motion over perfection.

Because in the end, the market doesn’t reward the most careful companies.
It rewards the ones who ship.

###

Drop it in the comments below. The more specific, the better. I read most comments and will try to respond.

Thanks
Alon



Wednesday, April 8, 2026

The Box That Changed Everything

 Standards That Move the World

The Box That Changed Everything

How a steel rectangle reshaped global trade, and why a JSON object is about to do the same thing to conversations.

Here's a story you already know, even if you've never really thought about it.

In 1956, a trucking entrepreneur from North Carolina named Malcom McLean loaded 58 steel boxes onto a refitted oil tanker in Newark, New Jersey. The ship sailed to Houston. Nobody threw a parade. But that voyage did something extraordinary: it proved that you could skip the misery of break-bulk shipping the sacks, the barrels, the longshoremen wrestling odd-shaped cargo on and off boats for days at a stretch—and just move the box.

The same box. Truck to crane to ship to crane to train. Never opened. Never repacked. Just… moved.

That one idea is not a breakthrough in materials science, not a revolutionary engine, just a standard-sized steel rectangle that dropped the cost of loading cargo from almost six dollars a ton to about sixteen cents. And then it quietly rewired the entire global economy.

I keep thinking about this story because I believe we're watching it happen again. Not with steel and ships, but with conversations and data. And the box this time is called a vCon.

Let's talk about what the shipping container actually did

People tend to remember the container as a logistics improvement. That undersells it by about three orders of magnitude.

Before containerization, a cargo ship could sit in port for weeks. Longshoremen worked in gangs of twenty or more, hauling goods out of the hold with pulleys and muscle. Stuff got stolen. Stuff got broken. Stuff got rained on. The port was, frankly, a mess—a tremendously expensive, accident-prone, unreliable mess. And because it was so expensive and unreliable, trade was mostly regional. You made things near where you'd sell them, because shipping was a nightmare.

The container changed all of that. Not overnight, it took decades of fights with dock workers' unions, arguments over standard sizes, massive port rebuilds, and new ship designs before the thing really took hold. But once it did, the impact was staggering. World exports went from $384 billion to over $25 trillion. The fraction of goods and services traded internationally doubled. Manufacturing moved to wherever it made the most economic sense, not wherever it was closest to the customer.

The container didn't just make shipping cheaper. It made an entirely different kind of economy possible.

China went from producing about 2% of the world's manufactured goods in the early 1980s to more than 30%. Just-in-time manufacturing, the backbone of companies like Toyota, and later every major manufacturer on earth, became viable because you could rely on a container showing up when it was supposed to. Walmart, Amazon, and IKEA, none of these business models work without containerization. The $5 Tshirt at Target? That's a container story.

And here's the part that always gets me: the container itself isn't impressive. It's corrugated steel. It has twist-lock fittings on the corners. It comes in two standard sizes (20 feet and 40 feet). A child could explain it. Its genius is not in what it is, but in what it standardizes.

Now let's talk about conversations

Think about every meaningful business conversation happening right now. Phone calls in call centers. Zoom meetings with clients. Slack threads about support tickets. Email chains negotiating deals. SMS messages confirming appointments. WhatsApp groups coordinating field teams.

Every one of those conversations generates data. Recordings, transcripts, metadata, who talked to whom, when, for how long, about what. And almost all of that data is trapped. It's locked in whatever platform hosted the conversation, stored in proprietary formats, and siloed away from everything else.

Sound familiar? It should. This is the fragmented shipping problem all over again.

Before the container, cargo existed in a thousand different shapes and packages, and getting it from point A to point B meant repacking it at every step. Before vCon, conversational data exists in a thousand different formats, and getting insights from it means building custom integrations for every platform, every analytics tool, every compliance system.

A vCon, short for "virtualized conversation," is a standardized container for conversational data. It's a JSON-based format being developed as an open standard through the IETF (the same body that gave us the protocols that run the internet). A single vCon packages up everything about a conversation: the participants, the actual dialogue (audio, video, or text), metadata like timestamps and call detail records, any analysis that's been performed (transcription, sentiment, summaries), attachments, consent records, and identity verification—all in one portable, signable, encryptable object.

It's a box. For conversations.

Why this matters right now

The timing is not accidental. We're living through an explosion in AI capabilities that can do remarkable things with conversational data if that data is clean, structured, and accessible. Large language models can analyze customer calls for sentiment. They can pull out action items from meetings. They can identify patterns across thousands of support interactions. They can flag compliance risks in real time.

But here's the catch: AI is only as good as its inputs. And right now, feeding conversational data into AI tools is a bespoke, fragile, expensive process. Every company builds its own pipelines. Every integration is custom. Every time you switch vendors, you start over.

This is the pre-container world. It "works," in the sense that break-bulk shipping "worked." Goods got moved. But it was slow, costly, and limited what was possible.

The parallels run deeper than you'd think

Here's what keeps striking me as I dig into the topic. The similarities aren't surface-level; they follow the same structural pattern.

Standardization unlocks interoperability. The shipping container didn't succeed because it was the best possible box. It succeeded because everyone agreed on the same dimensions. Once ISO standardized the sizes in the late 1960s, every port, every crane, every truck chassis, every railcar could handle the same unit. The ecosystem is aligned. vCon is doing the same thing for conversations. When every communication platform can output a vCon, and every analytics tool can ingest one, you get an ecosystem. You get a marketplace. You get competition on quality, not lock-in.

The "boring" standard enables the exciting stuff. Nobody gets excited about the twist-lock fitting on the corner of a container. But without it, you don't get global supply chains. Nobody is going to get excited about the JSON schema of a vCon. But without it, you don't get frictionless AI-powered conversation intelligence across every communication channel. The boring part is the important part.

Proprietary silos lose to open interchange. Before the container, every port, every shipping line, every railroad had its own way of doing things. That fragmentation was a moat for incumbents but a tax on everyone else. Sound like the communications industry today? Every platform locks in your data. Switching costs are enormous. vCon, like the ISO container, breaks those silos by making the cargo (conversation data) portable.

The most transformative standards don't create new capabilities. They make existing capabilities interchangeable.

The second-order effects dwarf the first. McLean was trying to save money on trucking. He did not set out to enable the rise of China as a manufacturing superpower or create the conditions for fast fashion. The container's consequences went wildly beyond anyone's imagination. I'd bet the same happens with vCon. Yes, it will simplify contact center analytics and ease compliance. Those are the obvious first-order effects. But what happens when every conversation a business has is structured, portable, and analyzable? When can AI work across all of your communications without custom plumbing? Can you easily move your entire conversation history from one vendor to another, like moving a contact list? The second-order effects could be enormous, and I don't think we can fully predict them yet.

The economic angle

The cargo container didn't just change logistics. It changed economics. It restructured labor markets (for better and worse). It shifted manufacturing geography. It made some ports obsolete and turned others into boomtowns. It made consumer goods radically cheaper. It was, in the words of economists, a general-purpose enabler, a thing that doesn't just improve one process but transforms the conditions under which many processes operate.

vCon has the same structural potential for the conversation economy as the conversation economy itself, which is bigger than most people realize. Think about every contact center, every sales team, every support desk, every healthcare provider documenting patient interactions, every financial services firm recording advisory calls, every legal team preserving conversations of record. Conversations are the raw material of the service economy, and the service economy is most of the economy.

Right now, working with that raw material is expensive and clunky, like loading cargo by hand. vCon is the standard that could make it cheap and fluid. And when you make a fundamental input to economic activity cheap and fluid, you tend to get a lot more of the activity that depends on it.

The container analogy in one sentence: Shipping containers standardized the movement of physical goods, unlocking globalization. vCons standardize the movement of conversational data and could unlock the next generation of AI-powered business intelligence.

What's different this time

The analogy jumps over two worlds.

The shipping container operated in the physical world, where the benefits were visible and measurable: fewer broken crates, faster turnaround, and lower costs per ton. 

vCon operates in the digital world, where the benefits are more abstract: better data portability, easier compliance, richer AI training inputs. It's harder to photograph a JSON object on a flatbed truck.

The container also had a more straightforward adoption incentive. Ship owners could see the cost savings immediately. With vCon, the value proposition requires a bit more imagination; it's about what becomes possible when your conversation data is structured and portable, not just about what gets cheaper.

And there's the privacy dimension, which has a parallel also in the container world. Conversations contain personal information. They contain things people said under an expectation of confidentiality. The vCon standard has to navigate consent management, data governance, and regulatory compliance in the same way that steel boxes handle chain of custody in the physical world, with locks, breakable seals, and passive temperature & humidity trackers. Yet privacy may seem to some people a slightly harder design problem in the digital world.

But these differences don't weaken the analogy. They strengthen it. The fact that vCon is tackling harder problems like privacy, trust, consent, security, while still aiming for the same radical simplification, suggests that the people building it understand the stakes.

We've seen this movie before

There's a pattern in the history of technology and commerce. A fragmented, expensive, friction-heavy system persists because nobody can agree on a standard. Then someone proposes a standard. It's resisted by incumbents who benefit from the fragmentation. Slowly, a few adopters prove it works. A critical mass forms. And then, suddenly, the old way looks insane. Who would go back to loading cargo by hand?

We're somewhere in the early chapters of that story with vCon. The IETF working group is active. Companies like VCONIC are building real products on the standard. Service providers are starting to see the commercial opportunity. Jeff Pulver, who knows a thing or two about what happens when you standardize communications infrastructure, having been around with Alon Cohen and Lior Haramaty at the birth of VoIP, is calling it a new industry in formation.

Maybe it takes off. Maybe it doesn't. Malcom McLean didn't know in 1956 that his steel boxes would reshape the world. He just knew that the current way of doing things was dumb and that a standard box was obviously better.

In my opinion, the people building vCon are in the same position. The current way of handling conversational data is dumb. A standard container is obviously better. The rest is a matter of time, adoption, and the kind of second-order effects that nobody can predict until they're already happening.

If history repeats, and it usually does, this box is worth paying attention to.

Wednesday, June 25, 2025

AI Ideas to fix development inefficiency problems

Date: June 25th, 2025

By: Alon Cohen + Grok


Now that we have AI to help us make things more efficient, I asked Grok the following question:


  • I am sure you are familiar with Fibonacci, Sprints, Kanban, Scrum, and prioritization. I noticed that when organizations work this way, development takes longer, and bugs take longer to fix (on the next sprint). Time buffers between tasks are out of control, as developers do not want to look bad for not finishing on time. Teams tend to get stuck when they depend on another team from time to time because the other team does not want to spend its own time helping others, which can lead to a deadlock. Can you suggest a better, more efficient methodology to manage development tasks?


Here is the summary of the answer I got from Grok.


Agile methodologies like Scrum (with sprints and Fibonacci estimation) and Kanban are widely used, but the issues you describe—slow development, delayed bug fixes, excessive time buffers, and inter-team dependencies—point to common pitfalls in their implementation.

These often stem from rigid adherence to frameworks, misaligned incentives, or poor coordination. Below, I propose a hybrid system to manage development tasks that addresses these pain points while maintaining flexibility and fostering collaboration. The system draws from Lean, DevOps principles, and modern workflow practices, tailored to reduce delays and improve responsiveness.




Proposed System: Flow-Based Collaborative Development

This system emphasizes continuous flow, cross-functional collaboration, and dynamic prioritization to minimize bottlenecks, reduce delays, and improve responsiveness to bugs and dependencies. It blends the strengths of Kanban, Lean, and team autonomy while avoiding the rigidity of sprints or over-reliance on estimation.

Core Principles

  • Continuous Flow Over Fixed Sprints:

    • Replace time-boxed sprints with a continuous flow model (inspired by Kanban) to allow tasks to move as soon as they’re ready, reducing delays caused by waiting for the next sprint.

    • Use Work-in-Progress (WIP) limits to prevent overloading teams and ensure focus on completing tasks before starting new ones.

  • Dynamic Prioritization:

    • Implement a weighted prioritization framework (e.g., Weighted Shortest Job First, WSJF) to rank tasks based on business value, urgency, and effort.

    • Bugs, especially critical ones, can be prioritized immediately rather than deferred to future sprints.

  • Cross-Functional Swarming:

    • Encourage teams to “swarm” on high-priority tasks or blockers, including bugs or dependency issues. This means temporarily pulling in expertise from other teams to resolve issues quickly, rather than waiting for knowledge transfer.

    • Foster a culture of shared ownership, where developers from different teams can contribute to critical fixes or features without bureaucratic handoffs.

  • Minimized Estimation, Maximized Predictability:

    • Move away from Fibonacci or story-point estimation, which can lead to inflated buffers as developers pad estimates to avoid looking bad. Instead, use cycle time metrics (time from start to completion) to forecast delivery based on historical data.

  • Dependency Mapping and Proactive Coordination:

    • Hold short, daily sync meetings (not full standups) for teams with dependencies to align on blockers and share knowledge in real-time.

  • Fast Feedback Loops:

    • Integrate automated testing and continuous integration/continuous deployment (CI/CD) to catch bugs early and deploy fixes rapidly.

    • Use real-time monitoring and alerting to prioritize production issues, ensuring critical bugs are addressed immediately rather than queued.

  • Team Autonomy with Guardrails:

    • Grant teams autonomy to decide how to tackle tasks, but enforce lightweight guardrails like WIP limits, clear acceptance criteria, and standardized tooling to maintain alignment.

    • Rotate team members periodically across squads to spread domain knowledge and reduce dependency on specific individuals or teams.

Key Practices

  • Visual Workflow Management:

    • Example: A critical bug is tagged and moved to the top of the “In Progress” column, with a WIP limit ensuring it gets immediate attention.

  • Daily Prioritization and Swarming:

    • Start each day with a 10-minute prioritization huddle (not a status update) to review the backlog, reprioritize tasks, and assign swarming resources for blockers.

    • Example: If Team A is stuck on a database issue, a database expert from Team B joins for a few hours to unblock them.

  • Dependency Resolution Framework:

    • Create a “Dependency Coordinator” role (rotating or dedicated) to facilitate knowledge sharing and unblock teams. This person ensures that dependent teams align quickly.

    • Example: If Team C needs an API from Team D, the coordinator arranges a 30-minute pairing session to clarify requirements and kickstart work.

  • Bug Triage and Response:

    • Critical bugs bypass the backlog and are assigned immediately.

    • Maintain a small “emergency lane” in the workflow for urgent fixes, with a strict WIP limit to prevent overloading.

Cultural Shifts

  • Incentivize Collaboration: Reward teams for unblocking others or contributing to shared goals, not just completing their own tasks.

  • Normalize Fast Failure: Encourage rapid iteration and small releases to catch issues early, reducing the impact of bugs.


How This Addresses Your Pain Points

  • Slow Development:

    • Continuous flow and WIP limits ensure tasks move quickly without waiting for sprint boundaries. Smaller task sizes reduce complexity and make progress predictable.

  • Delayed Bug Fixes:

    • The emergency lane prioritizes critical bugs for immediate resolution. 


Potential Challenges and Mitigations

  • Resistance to Change: Developers accustomed to sprints may resist continuous flow. Mitigate by starting with a pilot and showcasing early wins (e.g., faster bug fixes).

  • Stakeholder Pushback: Stakeholders may demand estimates. Educate them on cycle time metrics and provide regular updates to build trust.


Why This Is Better Than Scrum or Kanban Alone

  • Scrum: Fixed sprints cause delays for bugs and dependencies, and planning overhead slows teams down. The proposed system eliminates sprints for faster flow and responsiveness.

  • Kanban: While Kanban supports flow, it often lacks structure for prioritization and dependency management. This system adds dynamic prioritization, swarming, and dependency coordination.

  • Lean Influence: By focusing on waste reduction (e.g., waiting, overestimation), the system ensures value is delivered quickly.


Real-World Examples

  • Spotify’s Squad Model: Spotify uses autonomous squads with loose alignment, similar to the proposed team autonomy with guardrails. They emphasize cross-squad collaboration for dependencies, akin to swarming.

  • Toyota’s Lean Flow: Toyota’s production system inspired the continuous flow and WIP limits, ensuring work moves smoothly without bottlenecks.



On one hand, I was surprised because AI tends to agree with the status quo more than with potentially controversial or visionary ideas. However, the answer accurately verifies my past ideas and postings on the topic, as well as verifies my actual experience in the field.

What do you think?