Code is a representation of your program. Not-code is also a representation of your program. Both of these representations are fair and valuable. I don’t think that’s a problem. Peoples attitude towards which is more important is the problem - because you should be doing both.
“Talk is cheap, show me the code” is bullshit because it implies a superiority of the programmer/engineering class. “Talk is important, don’t write code till you know what you want and only then start.” is also flawed, since your expectations of what you want will almost definitely (or should almost definitely) be divergent of what you actually need.
What you want is to be able to show something sketchy but real to designers to explain that x doesn’t actually generate much value, show product managers the vibe of what you’re building so either they can pull the plug or push ahead, and other engineers the confidence that what you’re releasing is reliable and not a giant over engineered mess or pile of hacks.
I’ve found over the past two years of working that a few specific modern day practices can help you achieve a good middle ground between the two.
Fast build times and release tooling
The quicker you can get to prod and get something in the hands of testers and users, the faster your feedback cycle. The faster you can do this, the more confident you can be in being able to roll back, roll forward and remedy issues as they happen.
Feature flag your shit
Get together with your designer and your product manager (and maybe some other engineers) and start building that thing. As a prototype. But get it out as soon as you can - prove that it can actually exist in the flesh. You do this by hiding your not-quite-yet-built-or-valid-for-all-customers feature behind a feature flag, merging your work to master, and releasing it bit by bit to customers over time.
Even if you use feature flags at your company, you may benefit from reading Martin Fowler’s excellent longform on Feature Toggles (aka Feature Flags).
Please, for the love of god, pull out the feature flag afterwards though.
This one is mainly useful for the engineers. You’ve got an idea, so start coding and bash something out as soon as you can. It can be messy and arrogant and have some rough edges, but that’s okay. Once you’ve got something, you can iterate on that. And people can take a look at it and dissect it and work out what parts are gems and what parts can probably not survive the merge.
The other powerful thing is that you can totally roll it back, you can see what exactly are the changes made by your code, and you can iterate bit by bit on it over time. I can’t describe this iteratibility as eloquently as Kent Beck did in his article, Taming Complexity with Reversibility . Give it a read if you have a moment; it’s well worth your time.
Nothing is a panacea; you will get things wrong
A final note: No tools or practices in the world will save you from a lack of communication or a bad culture. These tools just make it more safe-to-fail and easier to communicate in constructive ways.