> My impression has always been it's more important the build the correct thing (what the customer needs/wants) rather than more stuff faster.
The process of learning what the customer needs/wants is a heavily iterative one, often involving throwing prototypes at them or betting at a solution, then course-correcting based on their reaction. Similarly, the process of building the correct thing is almost always an iterative approximation - correctness is something you discover and arrive at after research and prototypes and trying and getting it wrong.
All of that benefits from any of its steps being done faster - but it's up to the org/team whether they translate this speedup to quality or velocity. For example, if AI lets you knock out prototypes and hypothesis-testing scripts much faster, you can choose whether to finish earlier (and start work on next thing sooner), or do more thorough research, test more hypothesis, and finish as normally, but with better result.
(Well, at least theoretically. If you're under competitive pressure, the usual market dynamics will take the choice away, but that's another topic.)
You have a specific idea of customer in mind. Likely different than the gp’s. Many types of customers are quite happy to have prototypes thrown at them. Sometimes it’s even contractually required in agency work.
Is it just me or is this whole mania exposing those people who thought they were great ‘thinkers’? The takes I see are so utterly flawed it’s ironic - people refer to llm’s as hallucinating when the real halluncinations are from people cosplaying the role of management/investors when they have never done said role professionally in their life.
For sure, but these days product management mistakes can be more easily rectified. Before that, if we invested 4 months in building something that did not land, we'd be quite reluctant to jettison this and start fresh. Egos, career considerations, sunk cost, etc. I think I will soon be able to say "not any more", since doing a U turn can be cheaper than pretending the bad choice is the best choice. "Oops, lets redo this" vs. 6 months of executive squabbling about whose fault it is that we wasted $3M in development costs on something that clearly does not perform.
Also, give it time. Real adoption in boring companies started Q1. Q2 is, I think, this settling in and people learning how to do their work and manage their responsibilities. Q3/Q4 will be the time when I expect to start seeing higher velocities across all IT-adjacent products I use.
Iteration speed is far more important than the volume of features delivered, though we are tackling aspirational features that would previously have been considered too complex or niche, too.
This with the ability to research, iterate on prototypes, in my opinion allows to determine the right thing quicker as well. Of course right now the value is largely intuition based, there may be some immediate revenue/profit, but revenue/profit will take time to follow, so in a way it is a speculative intuition based bet. Financial gains will take time to follow, so for a period of time it will be "trust me bro" for at least some cases, but I suppose future will show, since the intuition seems so strong about it. You can't have good data about an emerging tech like that.
Isn't that trivially true? Scenario 1) Spend $10,000 to make one prototype. You get one shot, so you prepare and do as much pre-work as humanly possible, but because you only get one shot, you forgot the ask the question that in Hobbs sight was obvious. Scenario 2) prototypes cost $1,000 so you get multiple shots. So you don't do as much pre-work, throw a half dozen things at the wall. One of them sticks! It really resonates with customers. You iterate a few more times, and when it's finally on the market, you have a successful business.
The difference is all that pre-work. The problem with that is some things are only obvious after you've built one and it doesn't fit just right for some reason. That reason is impossibly harder to just reason about and figure out vs iterating where possible. For software things that's easier. For hardware, we have stories like the palm pilot engineer having a wooden block with them for a week before deciding on the form factor for it. Such pre-work is valuable, but if the cost of prototypes is way down, you can afford to iterate instead of trying to psychically predict everything up front. Of course that doesn't work for eg trips to the Moon, but most busineeses aren't doing that.
The problem is in validating the prototype. Whether the users are consumers or enterprises or internal stakeholders, they aren’t going to try 10 different prototypes. They will try one or two.
Most business software isn’t complicated to implement (i.e. it doesn’t require multiple prototypes to determine which technical approach is best). Usually for most apps you approximately know the technical implementation. What requires taste, experience, or whatever you want to call it, is the user experience and if your software actually solves a real problem. You can’t really just churn on prototypes to solve that. You will lose the patience of your user base.
Even so-called UX and product experts get stuff wrong all the time. Going from idea to prototype to feedback in hours or days rather than days or weeks feels like a superpower, at least in the very customer facing parts of what we do.
Did CAD make engineers better? certain products are only possible because of CAD but the pen and paper guys weren’t obviously less efficient, and I personally think they were very efficient.
When prototypes are harder to build you focus on answering the biggest questions. I feel like you spend more time iterating on details in CAD, even when the larger idea is invalid.
It’s no more exhausting than the alternative. It feels good being able to build more and experiment more.
The biggest downside is the feeling that people sometimes turn their brain off and aren’t even doing basic checks on some of the slop their LLMs produce.
