8 ms·

It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. Just to quote one little bit from the piece regarding Google: "In o

It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. Just to quote one little bit from the piece regarding Google: "In other words, there have been numerous dead ends that they explored, invalidated, and moved on from. There's no knowing up front." Every time you change your mind or learn something new and you have to make a course correction, there's latency. That latency is just development velocity. The way to find the right answer isn't to think very hard and miraculously come up with the perfect answer. It's to try every goddamn thing that shows promise. The bottleneck for that is 100% development speed. If you can shrink your iteration time, then there are fewer meetings trying to determine prioritization. There are fewer discussions and bargaining sessions you need to do. Because just developing the variations would be faster than all of the debate. So the amount of time you waste in meetings and deliberation goes down as well. If you can shrink your iteration time between versions 2 and 3, between versions 3 and 4, etc. The advantage compounds over your competitors. You find promising solutions earlier, which lead to new promising solutions earlier. Over an extended period of time, this is how you build a moat.

trjordan 1y ago
This article is right insofar as "development velocity" has been redefined to be "typing speed." With LLMs, you can type so much faster! So we should be going faster! It feels faster! (We are not going faster.) But your definition, the right one, is spot on. The pace of learning and decisions is exactly what drives development velocity. My one quibble is that if you want to learn whether something is worth doing, implementing it isn't always the answer. Prototyping vs. production-quality implementation is different, even within that. But yeah, broadly, you need to test and validate as many _ideas_ as possible, in order take make as many correct _decisions_ as possible. That's one place I'm pretty bullish on AI: using it to explore/test ideas, which otherwise would have been too expensive. You can learn a ton by sending the AI off to research stuff (code, web search, your production logs, whatever), which lets you try more stuff. That genuinely tightens the feedback loop, and you go faster. I wrote a bit more about that here: https://tern.sh/blog/you-have-to-decide/ https://tern.sh/blog/you-have-to-decide/
- add-sub-mul-div 1y ago
  I think people are largely split on LLMs based on whether they've reached a point of mastery where they can work close to as fast as they think and the tech would therefore slow them down rather than accelerate them.
  - no_wizard 1y ago
    The verbose LLM approach that Cursor and some others have taken really annoys me. I would prefer if it simply gave me the results (written out to files, changes to files or whatever the appropriate medium is) and only let me introspect the verbose steps it took if I request to do so. That’s what slows me down with AI tools and why I ended up sticking with GitHub Copilot, which does not do any of that unless I prompt it to
    - cestith 1y ago
      I want a merge request with a short, meaningful comment and the diffs just like I’d get from a human. Then I want to be able to discuss the changes if they aren’t exactly what’s needed, just like with a human. I don’t want to have to hold its hand and I don’t want to have to pair program everything with a chatbot. It also needs to be able to show a logic diagram, a data flow diagram, and a dependency tree. If an agent can’t give me that, it’s not really ready to work as a developer for me.
    - DenisM 1y ago
      LLM might rely on their own verbosity to carry the conversation in a stable direction.
    - daliusd 1y ago
      So you want Aider, Claude Code or opencode.ai it seems. I use opencode.ai a lot nowadays and am really happy and productive.
      - tharkun__ 1y ago
        I really wanted to use Aider. But it's impossible. How do people actually use it? Like, I gave it access to our code base, wanted to try a very simple bug fix. I only told it to look at one service I knew needed changes, because it says it works better in smaller code bases. It wanted to send so many tokens to sonnet that I hit the limits before it even started actually doing any coding. Instant fail. Then I just ran Claude Code, gave it the same instructions and I had a mostly working fix in a few minutes (never mind the other fails with Claude I've had - see other comment), but Aider was a huge disappointment for me.
tristor 1y ago
This, so much. As an engineer turned PM, I am usually sympathetic to the idea that doing more discovery up front leads to better outcomes, but the simple reality is that it's hard to try anything, make any bets, or even do sure wins when the average development lifecycle is 12-18 months to get something released in a large organization and they're allergic to automation, hiring higher quality engineers, and hiring more engineers to improve velocities. Development velocity basically trumps everything, after basic sanity checks on the cost/benefit tradeoffs, because you can just try things and if it doesn't work you try something else. This is /especially/ true in software in 2025, because most products are SaaS or subscription based, so you have a consistent revenue stream that can cover ongoing development costs which gives you the necessary runway to iterate repeatedly. Development costs then become relatively stable for a given team size and the velocity of that team entirely determines how often you can iterate, which determines how quickly you find an optimal solution and derive more value.
- esseph 1y ago
  > it's hard to try anything, make any bets, or even do sure wins when the average development lifecycle is 12-18 months to get something released in a large organization and they're allergic to automation, hiring higher quality engineers, and hiring more engineers to improve velocities. This has been my experience as well :/
- didibus 1y ago
  > and they're allergic to automation, hiring higher quality engineers, and hiring more engineers to improve velocities I think there's another issue, but it could relate to your first two statement here. Even to try ideas, to explore the space of solutions, you need to have ideas to try. When entering development, you need clarity on what you're trying. It's very hard to make decisions on even a single attempt. I see engineers working task the entire time simply not sure what really the task is about. And in a way, the coding agents need even more clarity in what you ask of them to deliver good result. So even inside of what we consider "development" or "coding", the bottleneck is often: "what am I supposed to do here?" and not so much "I don't know how to do this" or "I have so much to implement". This is obvious as well, once you throw more engineers, and you can't break up the work, because you have no clue what so many people could even all do. Knowing what all the needed tasks even are is hard and a big bottleneck.
jayd16 1y ago
When they say dev speed they mean the coding the AI can do. It's agreed that testing, evaluating, learning and course correcting are what takes the time. That's the entire point being made.
- thenanyu 1y ago
  Sure, but the actual lag from "I have an idea worth trying" to "here's a working version people can interact with" is one of the larger pieces of latency in that entire process. You can't test or evaluate something that doesn't work yet.
Aurornis 1y ago
> It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. The current trend in anti-vibe-coding articles is to take whatever the vibe coding maximalists are saying and then stake out the polar opposite position. In this case, vibe coding maximalists are claiming that LLM coding will dramatically accelerate time to market, so the anti-vibe-coding people feel like they need to claim that development speed has no impact at all. Add a dash of clickbait (putting "development speed" in the headline when they mean typing speed) and you get the standard LLM war clickbait article. Both extremes are wrong, of course. Accelerating development speed is helpful, but it's not the only factor that goes into launching a successful product. If something can accelerate development speed, it will accelerate time to market and turnaround on feature requests. I also think this mentality appeals to people who have been stuck in slow moving companies where you spend more time in meetings, waiting for blockers from third parties, writing documents, and appeasing stakeholders than you do shipping code. In some companies, you really could reduce development time to 0 and it wouldn't change anything because every feature must go through a gauntlet of meetings, approvals, and waiting for stakeholders to have open slots in their calendars to make progress. For anyone stuck in this environment, coding speed barely matters because the rest of the company moves so slow. For those of us familiar with faster moving environments that prioritize shipping and discourage excessive process and meetings, development speed is absolutely a bottleneck.
- flail 1y ago
  Since I haven't mentioned the context in the article, it is a small agency with a customer target of early-stage (ideally earliest-stage) product startups. We have literally one half-hour-long sync meeting a week. The rest is as lightweight as possible, typically averaging below 10 minutes daily with clients (when all the decisions happen on the fly). I've worked in the corpo world, too, and it is anything but. We do use vibe coding a lot in prototyping. Depending on the context, we sometimes have a lot of AI-agent-generated code, too. What's more, because of working on multiple projects, we have a fairly decent pool of data points. And we don't see much of speed improvement from a perspective of a project (I wrote more on it here: https://brodzinski.com/2025/08/most-underestimated-factor-estimation.html https://brodzinski.com/2025/08/most-underestimated-factor-es...). However, developers sure report their perception of being more productive. We do discuss how much these perceptions are grounded in reality, though. See this: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o... and this: https://substack.com/home/post/p-172538377 https://substack.com/home/post/p-172538377 So, I don't think I'm biased toward bureaucratic environments, where developers code in MS Word rather than VS Code. But these are all just one dimension of the discussion. The other is a simple question: are there ways of validating ideas before we turn them into implemented features/products? The answer has always been a wholehearted "yes". If development pace were all that counted, Googles and Amazons of this world would be beating the crap out of every aspiring startup in any niche the big tech cared about, even remotely. And that simply is not happening. Incumbents are known to be losing ground, and old-school behemoths that still kick butts (such as IBM) do so because they continuously reinvent their businesses.
franktankbank 1y ago
Feedback from customers is the longest time.
- thenanyu 1y ago
  Get it sooner then! By getting to market faster
  - franktankbank 1y ago
    Its one variable in the sum of all the times. You are asserting without much evidence that the bottleneck is the dev turnaround time. I think for a lot of people there's evidence that its dev is about 10% or less of the back and forth. I've sat on my hands for months while requirements have got sorted and no this wasn't something I could just jump into which I'm sure you'd (wrongly) suggest is the right approach. Have you ever been involved in a profitable project?
    - thenanyu 1y ago
      The only reason requirements need to be sorted out is because development effort is perceived to be expensive. If you reduce the development effort significantly, then you can just build it instead of talking about building it.
      - franktankbank 1y ago
        Sounds like you need a trillion monkeys on typewriters. Easy!
seneca 1y ago
Exactly the comment I came to make after reading this article. The article is basically claiming that "trying different things until something works" is what takes time, but the actual act of "trying things" requires development time. I can't see how someone can think about this topic this long, which the author clearly has, and come to this conclusion. Perhaps I've just misunderstood the point, but it seems like a nonsensical argument.
- flail 1y ago
  If only "trying things" always equaled "developing things". There's a whole body of knowledge (under the Lean Startup umbrella) that argues otherwise. Do we always have to build it before we know that it will work (or, in 9 cases out of 10, that it will not work)? Even more so, do we have to build a fully-fledged version of it to know? If yes, then I agree, development is the bottleneck.
  - thenanyu 1y ago
    The lean startup offers a lot of lossy proxies for building and releasing things because it presupposes that building things takes a long time
    - flail 1y ago
      I would actually challenge you to read/reread Lean Startup with the following filter: Disregard parts that explicitly assume that they are relevant only because, in 2013, development was expensive. There are very few parts that you would throw out.
- croes 1y ago
  > trying different things until something works That sounds like an awful way of software design. Trial and error isn’t engineering but explains the current state of software security.
  - seneca 1y ago
flail 1y ago
I would agree if the only way to achieve (digital product) success were to implement as many versions of software as possible. That's not true. The whole Lean Startup was about figuring out how to validate ideas without actually developing them. And it is as relevant as ever, even with AI (maybe, especially with AI). In fact, it's enough to look at the appalling rate of product success. We commonly agree that 90% of startups fail. The majority of that cohort have built things that shouldn't have been built at all in the first place. That's utter waste. If only, instead of focusing on building more, they stopped and reevaluated whether they were building the right thing in the first place. Yet, most startups are completely immersed in the "development as a bottleneck" principle. And I tell that part from our own experience of 20+ years of helping such companies to build their early-stage products. The biggest challenge? Convince them to build less, validate, learn, and only then go back to further development. When it comes to existing products, it gets even more complex. The quote from Leah Tharin explicitly mentions waiting weeks/months of wait till they were able to get statistically significant data. What follows is that within that part of experimentation, they were blocked. Another angle to take a look at it is the fundamental difference in innovation between Edison/Dyson and Tesla. The first duo was known for "I have not failed. I found 10,000 ways that don't work." They were flailing around with ideas till something eventually clicked. Tesla, in contrast, would be at the Einstein's end of the spectrum with "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about [or in Tesla's case, making] solutions." While most of the product companies would be somewhere in between, I'd argue that development is a bottleneck only if we are very close to Edison/Dyson's approach.
- thenanyu 1y ago
  The whole point of lean startup was to route around the bottleneck of development velocity.
  - flail 1y ago
    I heard that before. No, Lean Startup is not about working around the cost of software development. It is about designing good experiments, validating, and learning, so that when we're down to development, we build something that's way more likely to succeed. The fact that we were advised to build non-technical experiments is but a small part. And with the current AI capabilities, we actually have a new power tool for prototyping that falls neatly into the whole puzzle. Here's a bit more elaborate argument (sorry for a LinkedIn link): https://www.linkedin.com/posts/pawelbrodzinski_weve-already-had-the-agile-is-dead-wave-activity-7321157459484520448-onV_/ https://www.linkedin.com/posts/pawelbrodzinski_weve-already-...
deleted 1y ago
[deleted]
epolanski 1y ago
I don't buy it. Prototyping was never the issue. The lessons you're talking about come from stressing applications and their design, which requires users to stress it.
- thenanyu 1y ago
  So give it to users?
  - bob1029 1y ago
    There is often a severe opportunity cost associated with experimenting on your customer base.
    - thenanyu 1y ago
      Do it responsibly then?
    - estimator7292 1y ago
      We've been doing this for fifty years, please catch up with the times.
chrisweekly 1y ago
Yes - and tightening the OODA (Observe, Orient, Decide, Act) loop is essential for organizational velocity.
wyum 1y ago
I think you and the article actually agree and you are arguing only with their use of the word "development." The article uses "development" to refer only to the part where code is generated, while you are saying "development" is the process as a whole. You both agree that latency in the real-world validation feedback loop leads to longer cycles and fewer promising solutions and that is the bottleneck.
jiggawatts 1y ago
> Because just developing the variations would be faster than all of the debate. So the amount of time you waste in meetings and deliberation goes down as well. Thank you for articulating something I knew but haven't been able to express as eloquently. It frustrates me to no end to watch half a dozen non-technical bureaucrats argue for days about something that can be tried (and discarded) in a few hours with zero consequences. "Let's write a position paper so that everyone involved can agree before we do anything." Noooo! Just do it! See if it works in practice! Validate the marketing! Kick the tyres! Go for a test drive. Just. Get. Behind. The. Wheel.
j2kun 1y ago
> The way to find the right answer isn't to think very hard and miraculously come up with the perfect answer. It's to try every goddamn thing that shows promise. I have found that spending more time thinking generally reduces the amount of failed attempts. It's amazing what "thinking hard" beforehand can do to eliminate reprioritization scrambling.

trjordan 1y ago

This article is right insofar as "development velocity" has been redefined to be "typing speed." With LLMs, you can type so much faster! So we should be going faster! It feels faster! (We are not going faster.) But your definition, the right one, is spot on. The pace of learning and decisions is exactly what drives development velocity. My one quibble is that if you want to learn whether something is worth doing, implementing it isn't always the answer. Prototyping vs. production-quality implementation is different, even within that. But yeah, broadly, you need to test and validate as many _ideas_ as possible, in order take make as many correct _decisions_ as possible. That's one place I'm pretty bullish on AI: using it to explore/test ideas, which otherwise would have been too expensive. You can learn a ton by sending the AI off to research stuff (code, web search, your production logs, whatever), which lets you try more stuff. That genuinely tightens the feedback loop, and you go faster. I wrote a bit more about that here: https://tern.sh/blog/you-have-to-decide/ https://tern.sh/blog/you-have-to-decide/

add-sub-mul-div 1y ago
I think people are largely split on LLMs based on whether they've reached a point of mastery where they can work close to as fast as they think and the tech would therefore slow them down rather than accelerate them.
- no_wizard 1y ago
  The verbose LLM approach that Cursor and some others have taken really annoys me. I would prefer if it simply gave me the results (written out to files, changes to files or whatever the appropriate medium is) and only let me introspect the verbose steps it took if I request to do so. That’s what slows me down with AI tools and why I ended up sticking with GitHub Copilot, which does not do any of that unless I prompt it to
  - cestith 1y ago
    I want a merge request with a short, meaningful comment and the diffs just like I’d get from a human. Then I want to be able to discuss the changes if they aren’t exactly what’s needed, just like with a human. I don’t want to have to hold its hand and I don’t want to have to pair program everything with a chatbot. It also needs to be able to show a logic diagram, a data flow diagram, and a dependency tree. If an agent can’t give me that, it’s not really ready to work as a developer for me.
  - DenisM 1y ago
    LLM might rely on their own verbosity to carry the conversation in a stable direction.
  - daliusd 1y ago
    So you want Aider, Claude Code or opencode.ai it seems. I use opencode.ai a lot nowadays and am really happy and productive.
    - tharkun__ 1y ago
      I really wanted to use Aider. But it's impossible. How do people actually use it? Like, I gave it access to our code base, wanted to try a very simple bug fix. I only told it to look at one service I knew needed changes, because it says it works better in smaller code bases. It wanted to send so many tokens to sonnet that I hit the limits before it even started actually doing any coding. Instant fail. Then I just ran Claude Code, gave it the same instructions and I had a mostly working fix in a few minutes (never mind the other fails with Claude I've had - see other comment), but Aider was a huge disappointment for me.

tristor 1y ago

This, so much. As an engineer turned PM, I am usually sympathetic to the idea that doing more discovery up front leads to better outcomes, but the simple reality is that it's hard to try anything, make any bets, or even do sure wins when the average development lifecycle is 12-18 months to get something released in a large organization and they're allergic to automation, hiring higher quality engineers, and hiring more engineers to improve velocities. Development velocity basically trumps everything, after basic sanity checks on the cost/benefit tradeoffs, because you can just try things and if it doesn't work you try something else. This is /especially/ true in software in 2025, because most products are SaaS or subscription based, so you have a consistent revenue stream that can cover ongoing development costs which gives you the necessary runway to iterate repeatedly. Development costs then become relatively stable for a given team size and the velocity of that team entirely determines how often you can iterate, which determines how quickly you find an optimal solution and derive more value.

esseph 1y ago
> it's hard to try anything, make any bets, or even do sure wins when the average development lifecycle is 12-18 months to get something released in a large organization and they're allergic to automation, hiring higher quality engineers, and hiring more engineers to improve velocities. This has been my experience as well :/
didibus 1y ago
> and they're allergic to automation, hiring higher quality engineers, and hiring more engineers to improve velocities I think there's another issue, but it could relate to your first two statement here. Even to try ideas, to explore the space of solutions, you need to have ideas to try. When entering development, you need clarity on what you're trying. It's very hard to make decisions on even a single attempt. I see engineers working task the entire time simply not sure what really the task is about. And in a way, the coding agents need even more clarity in what you ask of them to deliver good result. So even inside of what we consider "development" or "coding", the bottleneck is often: "what am I supposed to do here?" and not so much "I don't know how to do this" or "I have so much to implement". This is obvious as well, once you throw more engineers, and you can't break up the work, because you have no clue what so many people could even all do. Knowing what all the needed tasks even are is hard and a big bottleneck.

jayd16 1y ago

When they say dev speed they mean the coding the AI can do. It's agreed that testing, evaluating, learning and course correcting are what takes the time. That's the entire point being made.

thenanyu 1y ago
Sure, but the actual lag from "I have an idea worth trying" to "here's a working version people can interact with" is one of the larger pieces of latency in that entire process. You can't test or evaluate something that doesn't work yet.

Aurornis 1y ago

> It's completely absurd how wrong this article is. Development speed is 100% the bottleneck. The current trend in anti-vibe-coding articles is to take whatever the vibe coding maximalists are saying and then stake out the polar opposite position. In this case, vibe coding maximalists are claiming that LLM coding will dramatically accelerate time to market, so the anti-vibe-coding people feel like they need to claim that development speed has no impact at all. Add a dash of clickbait (putting "development speed" in the headline when they mean typing speed) and you get the standard LLM war clickbait article. Both extremes are wrong, of course. Accelerating development speed is helpful, but it's not the only factor that goes into launching a successful product. If something can accelerate development speed, it will accelerate time to market and turnaround on feature requests. I also think this mentality appeals to people who have been stuck in slow moving companies where you spend more time in meetings, waiting for blockers from third parties, writing documents, and appeasing stakeholders than you do shipping code. In some companies, you really could reduce development time to 0 and it wouldn't change anything because every feature must go through a gauntlet of meetings, approvals, and waiting for stakeholders to have open slots in their calendars to make progress. For anyone stuck in this environment, coding speed barely matters because the rest of the company moves so slow. For those of us familiar with faster moving environments that prioritize shipping and discourage excessive process and meetings, development speed is absolutely a bottleneck.

flail 1y ago
Since I haven't mentioned the context in the article, it is a small agency with a customer target of early-stage (ideally earliest-stage) product startups. We have literally one half-hour-long sync meeting a week. The rest is as lightweight as possible, typically averaging below 10 minutes daily with clients (when all the decisions happen on the fly). I've worked in the corpo world, too, and it is anything but. We do use vibe coding a lot in prototyping. Depending on the context, we sometimes have a lot of AI-agent-generated code, too. What's more, because of working on multiple projects, we have a fairly decent pool of data points. And we don't see much of speed improvement from a perspective of a project (I wrote more on it here: https://brodzinski.com/2025/08/most-underestimated-factor-estimation.html https://brodzinski.com/2025/08/most-underestimated-factor-es...). However, developers sure report their perception of being more productive. We do discuss how much these perceptions are grounded in reality, though. See this: https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ https://metr.org/blog/2025-07-10-early-2025-ai-experienced-o... and this: https://substack.com/home/post/p-172538377 https://substack.com/home/post/p-172538377 So, I don't think I'm biased toward bureaucratic environments, where developers code in MS Word rather than VS Code. But these are all just one dimension of the discussion. The other is a simple question: are there ways of validating ideas before we turn them into implemented features/products? The answer has always been a wholehearted "yes". If development pace were all that counted, Googles and Amazons of this world would be beating the crap out of every aspiring startup in any niche the big tech cared about, even remotely. And that simply is not happening. Incumbents are known to be losing ground, and old-school behemoths that still kick butts (such as IBM) do so because they continuously reinvent their businesses.

franktankbank 1y ago

Feedback from customers is the longest time.

thenanyu 1y ago
Get it sooner then! By getting to market faster
- franktankbank 1y ago
  Its one variable in the sum of all the times. You are asserting without much evidence that the bottleneck is the dev turnaround time. I think for a lot of people there's evidence that its dev is about 10% or less of the back and forth. I've sat on my hands for months while requirements have got sorted and no this wasn't something I could just jump into which I'm sure you'd (wrongly) suggest is the right approach. Have you ever been involved in a profitable project?
  - thenanyu 1y ago
    The only reason requirements need to be sorted out is because development effort is perceived to be expensive. If you reduce the development effort significantly, then you can just build it instead of talking about building it.
    - franktankbank 1y ago
      Sounds like you need a trillion monkeys on typewriters. Easy!

seneca 1y ago

Exactly the comment I came to make after reading this article. The article is basically claiming that "trying different things until something works" is what takes time, but the actual act of "trying things" requires development time. I can't see how someone can think about this topic this long, which the author clearly has, and come to this conclusion. Perhaps I've just misunderstood the point, but it seems like a nonsensical argument.

flail 1y ago
If only "trying things" always equaled "developing things". There's a whole body of knowledge (under the Lean Startup umbrella) that argues otherwise. Do we always have to build it before we know that it will work (or, in 9 cases out of 10, that it will not work)? Even more so, do we have to build a fully-fledged version of it to know? If yes, then I agree, development is the bottleneck.
- thenanyu 1y ago
  The lean startup offers a lot of lossy proxies for building and releasing things because it presupposes that building things takes a long time
  - flail 1y ago
    I would actually challenge you to read/reread Lean Startup with the following filter: Disregard parts that explicitly assume that they are relevant only because, in 2013, development was expensive. There are very few parts that you would throw out.
croes 1y ago
> trying different things until something works That sounds like an awful way of software design. Trial and error isn’t engineering but explains the current state of software security.
- seneca 1y ago

flail 1y ago

I would agree if the only way to achieve (digital product) success were to implement as many versions of software as possible. That's not true. The whole Lean Startup was about figuring out how to validate ideas without actually developing them. And it is as relevant as ever, even with AI (maybe, especially with AI). In fact, it's enough to look at the appalling rate of product success. We commonly agree that 90% of startups fail. The majority of that cohort have built things that shouldn't have been built at all in the first place. That's utter waste. If only, instead of focusing on building more, they stopped and reevaluated whether they were building the right thing in the first place. Yet, most startups are completely immersed in the "development as a bottleneck" principle. And I tell that part from our own experience of 20+ years of helping such companies to build their early-stage products. The biggest challenge? Convince them to build less, validate, learn, and only then go back to further development. When it comes to existing products, it gets even more complex. The quote from Leah Tharin explicitly mentions waiting weeks/months of wait till they were able to get statistically significant data. What follows is that within that part of experimentation, they were blocked. Another angle to take a look at it is the fundamental difference in innovation between Edison/Dyson and Tesla. The first duo was known for "I have not failed. I found 10,000 ways that don't work." They were flailing around with ideas till something eventually clicked. Tesla, in contrast, would be at the Einstein's end of the spectrum with "If I had an hour to solve a problem, I'd spend 55 minutes thinking about the problem and 5 minutes thinking about [or in Tesla's case, making] solutions." While most of the product companies would be somewhere in between, I'd argue that development is a bottleneck only if we are very close to Edison/Dyson's approach.

thenanyu 1y ago
The whole point of lean startup was to route around the bottleneck of development velocity.
- flail 1y ago
  I heard that before. No, Lean Startup is not about working around the cost of software development. It is about designing good experiments, validating, and learning, so that when we're down to development, we build something that's way more likely to succeed. The fact that we were advised to build non-technical experiments is but a small part. And with the current AI capabilities, we actually have a new power tool for prototyping that falls neatly into the whole puzzle. Here's a bit more elaborate argument (sorry for a LinkedIn link): https://www.linkedin.com/posts/pawelbrodzinski_weve-already-had-the-agile-is-dead-wave-activity-7321157459484520448-onV_/ https://www.linkedin.com/posts/pawelbrodzinski_weve-already-...

deleted 1y ago

[deleted]

epolanski 1y ago

I don't buy it. Prototyping was never the issue. The lessons you're talking about come from stressing applications and their design, which requires users to stress it.

thenanyu 1y ago
So give it to users?
- bob1029 1y ago
  There is often a severe opportunity cost associated with experimenting on your customer base.
  - thenanyu 1y ago
    Do it responsibly then?
  - estimator7292 1y ago
    We've been doing this for fifty years, please catch up with the times.

chrisweekly 1y ago

Yes - and tightening the OODA (Observe, Orient, Decide, Act) loop is essential for organizational velocity.

wyum 1y ago

I think you and the article actually agree and you are arguing only with their use of the word "development." The article uses "development" to refer only to the part where code is generated, while you are saying "development" is the process as a whole. You both agree that latency in the real-world validation feedback loop leads to longer cycles and fewer promising solutions and that is the bottleneck.

jiggawatts 1y ago

> Because just developing the variations would be faster than all of the debate. So the amount of time you waste in meetings and deliberation goes down as well. Thank you for articulating something I knew but haven't been able to express as eloquently. It frustrates me to no end to watch half a dozen non-technical bureaucrats argue for days about something that can be tried (and discarded) in a few hours with zero consequences. "Let's write a position paper so that everyone involved can agree before we do anything." Noooo! Just do it! See if it works in practice! Validate the marketing! Kick the tyres! Go for a test drive. Just. Get. Behind. The. Wheel.

j2kun 1y ago

> The way to find the right answer isn't to think very hard and miraculously come up with the perfect answer. It's to try every goddamn thing that shows promise. I have found that spending more time thinking generally reduces the amount of failed attempts. It's amazing what "thinking hard" beforehand can do to eliminate reprioritization scrambling.