[brettcooke]

Andrew Ng made another point about AI product management in a previous piece [1] that I found both thought-provoking and a bit contrarian, and I’m surprised he didn’t mention it here. In that earlier piece, he went beyond just advocating for concrete specs and explicitly challenged the traditional design-thinking approach, arguing that teams should pick a fully formed idea and run with it rather than spending too long on broad problem exploration and multiple potential solutions. It’s a stance that favors speed and specificity over the more open-ended, iterative nature of design thinking.

Curious what others think about forgoing design thinking in AI product development in favor of this more direct, concrete approach.

[1] https://www.deeplearning.ai/the-batch/concrete-ideas-make-st...

[dartos]

Advocating for waterfall?

Not every product can be totally designed and spec’d out from the outset. Especially when time to market is important.

Maybe this works at the individual feature scale, but at any reasonably large product, designing _everything_ from the outset would result in brittle design.

[contrast]

Andrew Ng isn't proposing anything more than starting with a product idea rather than a market definition. "I've got an idea for a product so let's build a prototype to test it" isn't waterfall.

His argument is pointlessly contrarian, too. He says his proposal is counter to design thinking, but design thinking would encourage you to build the exact same prototype he is proposing. As his own piece acknowledges, if you're at an early stage where you don't have any specific product ideas, design thinking could be a good starting point.

In practice, this is all the same core idea. The end result is better if you investigate real ideas rather than rely on abstractions and assumptions. Test your ideas with prototypes. Be ready to discover your favourite idea doesn't work and change direction.

I wonder if he's really arguing against something that is independent of the method chosen: handing your money and control over to teams whose incentives are to spend as much time as possible on consultative exercises.

[dartos]

The comment I was replying to has this quote in it

> he went beyond just advocating for concrete specs and explicitly challenged the traditional design-thinking approach, arguing that teams should pick a fully formed idea and run with it rather than spending too long on broad problem exploration and multiple potential solutions

[ivanmontillam]

> Not every product can be totally designed and spec’d out from the outset

I'd argue that no product can be spec'd 100% from the outset. Not even something like the regular Notepad.exe.

You'll always find some hidden complexity overlooked that results in the revision of the spec at the middle of development.

Embrace the change.

[eichi]

There is common misconception among engineers about agile.

Agile is for reducing bunch of implementation docs. Your heavily crafted implementation docs will be gabage since implementation can be changed easily. However, we still need to define requirements and specs so that we won't create things no one want.

[n4r9]

> Your heavily crafted implementation docs will be gabage since implementation can be changed easily.

I've heard this before but I'm not convinced. I'm sure lots of product teams use Agile and still manage to have thorough, up to date docs. You just need to factor doc updates into your issues.

[peterlada]

Yes. This is intuitively true. Solid specs can be built with high % of AI assist and can be executed fast. Vague specs and exploration would take forever compared to the prior. One can build 10 concrete ideas in a span of a single exploration