Hacker News Reader

Absolutely.

95% of the suggestions product creators receive are solutions. A product creator's job is to work out what problem their customer is trying to solve. It goes to the same motivation as root cause analysis when analysing an outage: the actual problem is nestled deep under layers of semantic shielding.

Whether your product is trying to solve that problem is another question, but at least you can understand how others perceive and try to use your product, which goes a long way to getting a product to be more broadly adopted.

semantic shielding is a word I have not heard before. But it perfectly summarizes most of the interactions with customers and stakeholders

Causal shielding feels like a better term in this case

I honestly made it up on the spot, so don't take it as proper nomenclature. However, to describe it another way: the unconscious mind synthesises its emotional choice, which the conscious mind presents as rational fact. If you want to know how the mind arrived at that conclusion, you've got to go on a fact-finding mission, i.e., asking why.

However, asking that question without triggering a negative response is an art form within itself. Rarely can you be so direct, which is why it's often much easier to watch how a person interacts with a product rather than asking them why they did what they did.

> the unconscious mind synthesises its emotional choice, which the conscious mind presents as rational fact. If you want to know how the mind arrived at that conclusion, you've got to go on a fact-finding mission, i.e., asking why.

the more common name for it is post-hoc rationalization.

Thanks for that, I'll add that to my vocabulary.

> layers of semantic shielding.

I love this term. It describes perfectly something I encountered during my days as the sole technical support for a small ISP. I got really good at routing around it in my customers brains.

I would ask "have you installed anything?", they would say no.

I would ask "do you have any new programs or stuff?", they would say yes.

Because to them, installing something was like adding something under the hood of a car. Since putting in a new program didn't involve taking the cover off the computer, there wasn't anything "installed".

There was mismatch in our definitions of terms. I had to figure out how to route around it. I got really sensitive to things like that, and routing around it.

Semantic mismatch might be another term for it in my case.

Fully agreed.

Once worked in a place that hired a design researcher and they were amazing, they took the time to dig in to what you’re talking about here: the actual issues, not the words that came out of people’s mouthes. Had a lot of good insights, which were ultimately wasted on that particular business, but that’s for different reasons.

The most successful company I ever worked out figured out a way to perform and get high quality feedback on low cost user experiments with a quick turnaround.

About 4/10 failed, 5/10 did ok and then with 1/10 they would absolutely hit it out of the park - usually on something that looked about as promising as the other 10. They did this frequently enough that they clobbered the competition, who were mostly just trying to do normal product management stuff like user surveys, etc.

The most interesting thing was that most people if you'd have asked them before would have gone "I don't think you can turn this into an experiment" and then immediately adopted a different strategy. Somehow they always figured out a creative way of injecting a low cost experiment where most people would have imagined that it wasnt feasible to run any experiment at all. It required quite a lot of pressure/leadership from above.

Concrete examples sound interesting here in so far as you’re able to share

One example was when they decided to test out the idea of sending particular kinds of price change notification emails to users. They created one checkbox on a form our users could click and set up a trigger to fire notify somebody in the Philippines who would construct the emails manually from the database. They then iterated on those emails, creating them manually the whole time.

Once the email was iterated upon and the idea was proven (i.e. that users actually wanted it in the form that existed), it was handed back to me to automate properly, which in that case took about 7-10 days of dev work.

Or not, if it turned out the customers simply weren't interested. There were plenty of experiments like that where I created a checkbox or something and then we quietly removed it 2 weeks later.

It was a refreshing change from past jobs where I'd spent weeks working on a feature asked for by users that we were so sure would be a game changer only to see 1 or 2 people actually use it.

It's the same advice as building an MVP, do everything manually first, then automate once you've proven the market, basically Paul Graham's advice of doing things that don't scale. The Doordash founders hand-delivered food first before building an app.

Obviously, that does not apply if the market already exists, which it usually does. In that case you have to be different and better enough than the alternatives.

Why doesn't it apply? Even if there were a lot of food delivery companies, it would still be good to gain traction through doing it manually instead of (or before) spending months building out a software solution. Even better, because one would personally deliver the food, they can talk to customers and ask what problems they have currently with other food delivery competitors, thereby learning what differentiating advantage would work well when creating the software solution.

In other words, doing things that don't scale is not just useful for validating the market, it's arguably even more useful for validating one's specific implementation of a product, and also derisking the business model as a whole rather than having high capex initially.

If you're building in an established category, you should bring product intuition, honed by deep knowledge of the existing products, and confirmation of their weaknesses from their users. You are not going to win by rapidly cornering the market ("blitzscaling") because it's already cornered. You want to disrupt it with something better and different. I think the focus on "things that don't scale" takes away from this more important requirement.

Of course, you should try to validate assumptions as quickly and cheaply as possible. If "doing things that don't scale" means temporarily not automating things involved in validating assumptions, then fine. But don't manually do things that are not part of that calculus.

thanks! Seems very pragmatic. It seems the secret ingredient is having a responsive userbase big enough to have statistical significance though. Something we've struggled with in a recent startup.

Would love to hear the examples and how they were turned into experiments.

It's a good old XY problem. Funnily I've heard customers that doesn't wanna bother getting asked why, they just want someone who do what they're told. Some junior engineers too, just wants the answer of what is asked instead of "the real problem".

The XY problem is poorly-framed.

First of all, it's often a false dichotomy: you can answer the X directly and dig deeper to find Y.

Second, it places the questioner in a "normal" bucket: surely they must have the same boring mundane needs as everyone else, and we just need to figure out which one it is (Y). But some people really are working on something interesting, and need to understand X to do so.

Thirdly, even if Y really is better for them, they still might benefit from an answer to X to avoid asking future variations of X.

> They ask me WHY I want the alternator replaced. I tell them my vehicle isn't running and I need it to transport me from A to B. They then start asking me questions. Turns out it was the solenoid, they replace it, my vehicle successfully transports me from A to B

An XY problem[0] about A-B!

[0] https://en.m.wikipedia.org/wiki/XY_problem

Thank you for this link! I finally understand why one of my former coworkers' answers always frustrated me as much as they did.

I would always ask my Slack questions in XY format, but lead with the actual question, followed by a full paragraph explaining exactly why I believed X to be the solution for Y, and what other letters I had tried before concluding that X was the next likeliest solution for Y.

Something in her brain was programmed to see an XY question and immediately assume the asker was wrong about X. Not once did she read the following paragraph. I would have to reiterate it sentence by sentence as she asked as many "what abouts" to try to challenge my X as I had sentences in the paragraph. It drove me BONKERS.

But I never understood how there was such a disconnect between my frustration and how much customers actually apparently liked dealing with her. Her default approach to XY questions was probably very effective with people who actually did not know the product in-depth, but was profoundly aggravating to those of us whose job it was to be familiar with all the other letters, who really, truly only wanted the answer about X and did not need someone to rethink our entire process.

I have such little patience for that kind of person. In slack (well mattermost, but it's essentially the same thing) you can copy the direct link to a message and it'll re-embed it if you link to it in a subsequent message. I'll do that if someone is asking questions I just answered, because really what's the point of a conversation if you're ignoring my half of it.

I started so many replies with, "As I mentioned," that I needed a keyboard shortcut for it.

I can relate to the senior developers in PM roles. I only worked with one such PM, but he was amazing.

Most of the PMs come from non-tech background, more project-management types, and it shows.

The challenge here can be often that even though the client doesn't really need it, they are convinced they do. Even after digging deeper you understand there are other issues, for instance marketing or sales, that might not even be related to your software.

But if they are a key client you might end up building it, understanding it won't solve their core issues but doing so in order to keep them happy

That happens, then you need to figure out how to handle them. Sometimes when you show them what they really need 'the light goes on' and they don't care about what they asked for anymore (or worse someone else shows it to them and they don't buy from you at all despite your customer focus). Other times they remain convinced they need that thing and so you need to gike it to them lest they buy from someone else).

this it a hard problem to figure out, good luck.

This is one reason why it's better to have lots of small clients than a few big clients, because over time, the few big ones will increasingly dictate your product strategy in ways you will not want to go. Jason Fried from Basecamp has a good article about this [0].

[0] https://www.inc.com/magazine/201206/jason-fried/huge-account... (Archive link: https://archive.is/IHmwL)

It's hard for me to say this without wondering if I am being rude, but did you mean to say "dig down"? At least to me, "to dig in" means to prepare for a long-drawn confrontation (like an argument or a battle). Maybe I am wrong, but my brain just wouldn't let me go on to the next comment without pointing it out.