This is unfortunately not an experience I am unfamiliar with. I have to pretend to eat a big plate of humble pie on the first technical call with a lot of our clients.

Once you learn their first reaction is going to be to reject your proposal on arbitrary grounds (i.e. a new security theater show), you start to present simpler proposals purely for the sake of tripping their initial response. Once you get them to fire their objections across the way, it is really easy to review the impact and build the real proposal that meticulously deals with each point that was raised.

I think you are missing the general idea and being stuck on the details which I highly simplified. The step after identifying the difference in logic is to work back from there and establish a full chain of reasoning we both agree upon, but I cut that out in my half sentence description.

>Of course people stop to be engaged the moment they realize what is going on

So the people who have an interest in convincing me (as I'm the one building the application) have no desire to do convincing when they realize I'm trying to understand their rationale? Why? I have learned to document it well when it happens, so when the project does fail I can show their manager exactly where I built what was asked for, noted my concerns with the design, and showed where they disengaged from addressing those concerns and desired for me to just do as they asked.

> Not when it really is a good idea

If you do IT at a company that isn't a tech company, you're usually going to be stuck in a situation where you have to convince a non-tech-head to make a technical decision that seems right to you. Since you don't have four years to teach them everything that got you to that point, you're going to need to give them high-level details.

In my experience that isn't true at all. I have often found that new ideas are often met with a lack of care but sometimes contempt or even disgust. People being emotionally threatened by new ideas is actually a thing and there is nothing you can do about it except fast forward to the future when those people have gotten past their inner conservatism.

It is so incredibly rare that something screamingly original is met with a positive reaction, likely because there is no positive frame of reference on which to build enthusiasm. The only time I have any luck in this area is when I pitch my original ideas to people who are extreme experts around in that area such that the idea isn't a creative stretch for them.

Even when I build the new thing the positive reactions are, at first, exceedingly rare. A new idea doesn't become popular until it is endorsed by popular people or by early adopters who enjoy experimenting with wild unknowns. People generally need to be told something new is good before they can reach that conclusion themselves, but when it does happen it happens like a flood.

Based upon these experiences I don't dick around with pitches. Unless you really REALLY need a favor from somebody you are just wasting your time, time that could be better spent just building the new thing.

I think that it requires acknowledgment that there are two sides to such issues; as someone who is on the side that typically ends up having to handle the majority of the busy work to get many proposal through in my company I absolutely want the proposer to make the effort to figure out the stakeholders/costs/challenges for their project as well as answers. I'm willing to __fill in gaps__, but I don't really want to be having to do the basic legwork for someone else's project.

I don't mean to sound like I want to stifle inconvenient creativity; it's certainly not the case, and when someone has really taken the time to make some new tooling/project with benefits and acknowledges the costs involved, I'm more than happy to champion such projects.

But when someone just has a desire (or disparagingly, a whim) to change stuff up because it simplifies their workflow and they expect someone else to handle all of the communication of their project without even giving me the courtesy of doing such research, I cannot deny I approach such proposals negatively as I feel a bit used and I think that the expectation is "I want this, make it happen", which is not my job.

Similarly, I find myself encountering persons who expect that I and the rest of the company will magically intuit the importance of very niche projects without being willing to take the time to simply explain the pain point they wish to address. I'm not even talking about deep technical details here, but simple things like:

"We spend N amount of time on task X"

"I have an automation workflow that will require Y hours to implement, but N is reduced by Z [time value]"

Instead, the presentation is "I want to implement this automation workflow; what do you mean explain the value? Can't you see it? Why are we so caught up in corporate bureaucracy?"

I'm all for reducing N as much as possible, but if I myself can't explain why spending Y is vastly cheaper than N, I have no confidence in my ability to convince others that the cost of Y is worth it.

I've truly been on both sides, and it is some work to justify a change, sure. Formal proposal documents are a bit much for my taste, but whether we like it or not, C-Levels aren't going to read your code and they definitely aren't going to read a 2000+ word stream-of-consciousness email describing the project in an unstructured way (much less any git readme.md files). The impetus is on the person proposing the change to at least make an effort to convey the reason for the change to the relevant stakeholders.

So then can you not say "but I also have REQUIREMENT_X for this project? Do you think that your solution will mesh with this other need I have?"

If you can't have a technical discussion defending why you feel your solution is the best then you must not be confident about your solution.

“We see a need to build X. Its fancy and shiny new technology. It is right thing to do. What problem does it solve? Dont worry about that. We are going to strong arm a few teams to adopt this, even though it costs money to build and support. Sure, we can make investment in Y instead but dont want to because solving Y doesn’t let us increase head count or write promotion documents. Plus, X is very complex. It guarantees job security for people who understand it. Let’s not worry about what happens if these people then quit and make this thing everyone elses problem”

Its not always outright nefarious reasons but there’s always an incentive structure incentivizing wrong behavior because it benefits individuals or is cool or fun thing to work on, without having meaningful impact or business value

From a user's perspective, perhaps. That doesn't make it incorrect, however.

> "Firstly: humans don't resist change when it's something that they asked for, they resist things being imposed upon them against their will."

“If I had asked people what they wanted, they would have said faster horses.”

~ not actually Henry Ford

> "There is an incredibly persistent cultural movement in product design that "we know best", this is a very parent-child style relationship: "Mother knows best", that both disempowers and disengages customers."

It's not that we know best, it's that we know better than to just listen to users. We have all the data and research. You have an opinion because you're upset.

> "Let me be clear: when I buy a product I am paying for what the product can do for me now. It fulfils a need that I currently have. I am not paying money out of my own pocket for a faint hope that the product may do something in the vague and nebulous future."

We are generally aware of this. However, when we develop a product, we have a process that, for various reasons, goes beyond your particular narrow view of our product.

> "When you as a product manager or designer or PO or whatever decide that your product should do A, B and C too, I don't care. I don't want those features, I didn't pay for them."

Indeed, not all user share the same requirements and therefore we don't develop the product for any one user in particular.

> "When you as a product person change the way that I have to use the product in order to do X, you are asking me to spend time, effort and attention to change my habits around X in order to do something differently, which may (or may not) benefit me in the future."

We apologize for the inconvenience.

> "In all likelyhood you made it easier for new users to learn X. I don't care about new users."

This is where your and our interests clearly diverge.

> "Every change that you make to the product after I have bought it makes it more likely that I will leave your product and find something else that does X instead, because the cost to me to learn how to something different in your product is now not much different than the cost to learn how to do something in a different product."

In all likelyhood, you won't. The cost of learning an entirely different product will likely still be greater than learning the changes we made. Furthermore, there is the cost of another purchase, as well as the sunk cost on your previous purchase.

> "The more times you force me to change my behaviour, the more badwill (being the opposite of goodwill) builds up. Eventually I'll become so pissed off that I'll move, no matter what the cost."

Really, no matter the cost? Who are you going to move to? The hypothetical competitor that never changes their product?

> "The vast majority of the effort that designers spend on look and feel, typeography, colour palettes, image choice and placement, tone of voice, button placement, size and style and a host of other things are of marginal value at best."

Design tends to either go over people's heads entirely, or it's highly important. I suppose you're in group A. Still, a product that hasn't had a facelift in a decade will have an appearance of being outdated, even if the underlying technology is modern.

> "Thirdly: the idea that you can just tell your customers to suck it up is a relic of last-century marketing that relied on captive customer bases and lack of customer knowledge, awareness and community. Modern customers are, in the majority, well informed and highly vocal with other customers in their community."

Vocal they are, indeed. A select few of them at least. Despite this, we will not have our product be held captive by these users.

> "The idea of EPP is thus: when you have a product that works, and an existing customer base - freeze it. Instead of a major redisgn because 'Material Design is so 2014' simply leave the product the way it is, bar minor BAU and bug-fix work. Instead devote effort into building a new, next-generation product that addresses (hopefully) a new customer segment, and allow existing customers to add this new product to their portfolio for a incremental fee. This allows existing customers to self-select into a new product, protects revenue and reduces the risk of existing product customers leaving due to badwill."

Unfortunately, there is no data to show that this is a terrible idea. Perhaps that's because not many would risk real money on implementing such a presumably terrible idea.

There are some known cases of drastic redesigns presumably killing a product. On the other hand, gradual redesigns as well as adding features incrementally are industry-wide standard practice. That process clearly works. Yes, users complain about changes. No, they generally won't switch because of them. They may delay upgrades, but that generally happens with or without changes.

This is not how real world works. People rarely intentionally communicate unclearly — or fail to add the “volume” they feel is necessary.

Only aspects that are in your control are: how you allow people to communicate with you - and what you do with what they share.

- Problem with how is that the more constraints you add, less likely they are to communicate; you’re basically increasing cost for them to reduce the cost for you.

- Easiest way to increase the efficiency of what you do with the information is to have another set of eyes helping process the information; in doing so, you’re delegating control and adding overhead — but gaining a predictable interface to filter less predictable information.

Communicating information takes energy, and there’s only so much efficiency that’s reasonable to expect, especially when dealing with random people via systems you do not fully control.

X department (usually marketing/sales) is asking for Y thing without understand that Z thing is actually the thing customers want to solve their root cause.

You have to stay on top of the 'signal strength' of feature requests. If one customers asks for a thing then okay maybe note it down. If 10 customers ask for the same thing ASAP, then clearly go make it a priority to go build the thing.

> have strong opinions

Being a subject matter expert / domain expert you can start to see an understand the 'shape' of the market, the customers, the problem being solved. You get a sense of the how/what/why that will really be impactful.

Some products are built with huge leaps forwards that 10x the previous experience. Others are build with 1000 tiny improvements that make for a delightful UX. Both are equally valid.

Having strong opinions means balancing those two operating modes. Figuring out when to bet big/when to refine/when; when to say no to little thing #342 because it's actually not helping anything.

> You have to pitch and explain the thing to them and even then they still might not get it. Only when you show them the thing and they like it will you get some confirmation that this might be something they want/need.

If you have to build first in order to pitch and show it, then necessarily you've had to assume that what you were building is something they want. Maybe your point was to get new features quickly into the hands of users to test the assumption early, but that has its own significant downsides.

I like the way you phrased it though, in terms of "don't assume foo" instead of "do bar", because it implies that there's really no replacing good old-fashioned _thinking_ with blindly following a 5-step plan to success.

I used to have visions. Now I have collaborative design discussions driven by some starting designs. I found that if people don't contribute to the overall design then they have little impetus to actually understand it. This tends to lead to a better design and a more engaged team so a win on all counts.

We don't really have established criteria, we're a smaller org and typically it's been the developers that have resisted implementing any dark patterns while offering alternatives and product has historically been supportive of this.

And yeah since we're a small org, we have a small design team with just a few floating designers. The example I mentioned was with just one in particular and the only one my team really works with.

Ha, seems like this someone doesn't know when and where to pick their battles. Yes, sometimes you can really push for change when you come up with a real, convincing argument. Or, A/B test the crap out of it.

When I was on the front-end of the stack, it really taught me "disagree and commit" often with product and design. Unless it's something existential, there's almost no reason to accept "good enough", move forward, measure, and iterate.

There is actually a type of orgnaisation that does not change their mind. They have a vague idea upfront what they want. They ask for a plan and an estimate. They never actually think about what they want in detail. When the thing is delivered, if nothing goes wrong, nobody looks at it or thinks about it. If anything goes wrong, then they say, "You didn't deliver what I asked for" (a vague idea that doesn't break things ;-) ).

The biggest problem I've had with some groups is convincing them that changing their minds is actually crucial to the success of the project. It's funny because you'll have a whole bunch of other people who are trying to cover their asses by getting management to sign off on the plan, etc, etc. But I'm coming in and saying, "I want you to change your mind" because then they have to have a mind in the first place. It's surprisingly challenging. I find that if I don't succeed in that, then it's pretty difficult to succeed with an XP team.

This gets uttered like a mantra, and there is a kernel of truth to it, but people often take the idea too far -- so far that it becomes false.

People generally know what they want to accomplish. People generally know what workflows work for them. Around the edges, they may not be aware that a particular change will improve their lives -- but in the main, they're pretty good at telling that.

> If you waste time listening to the masses and have no initial vision of your own

You need both.

> Build something great and they will come.

This is not generally true, and I've seen many, many ventures fail because they believed this. History is jam-packed with objectively great things that were build but were rejected by the masses.

I think this mostly happens because the great thing did not address what people really wanted, and the company did not properly determine what people wanted. You can build the greatest doohicky ever made, but if it doesn't actually meet a real need in people, nobody will come.

I'm in marketing/biz dev now at an engineer-led company, and in a meeting last week a dev team presented a new UI that is a MASSIVE departure from our current approach. At the end of the demo, they informed us that a) it's being released in 2 weeks, b) do you think the clients will like it, and c) can we charge more for it?

> It’s so easy to sell something that people just get at first glance because it’s actually good at solving their problem, because you had faced that same problem and decided to do something about it.

What am I missing? You did validate it. You were the (prototype) customer, were you not?

Take note, all ye entrepreneurs! This advice is just as applicable for software engineers as for designers, extremely so. So many issues could be avoided with people I do contracts for if they just approached issues in this way.

Usually, it's "change this, do that". So I have to reply with "OK, well, we could do that but it'll take 20 days and cost $3000 dollars". The entrepreneur, displeased yet unwilling to pay that much or give up that much time: "hrmph. well...".

Automatically, something that could have been a collaborative process has been turned into a confrontation. If he/she had instead approached the problem in the way you recommended, I perhaps could have found out what was driving the desire for change, and recommended a cheaper/faster solution to the problem. Usually, I'll end up in that place eventually, but by that time what could have been a collaborative process has turned confrontational, with my client thinking "ugh, programmers" and me thinking "ugh, idea guys".

That said, this has given me some ideas about how to respond in this types of situations. Perhaps with something like, "can I walk you through the reasons why I did/chose this?". Might be worth trying.