Users can't envision configurable software in their specific contexts by themselves

First gig at [[Trayio]]. We're selling a workflow builder. Fancy drag-and-drop stuff. My initial approach? Textbook clown behaviour.

🤡: “Just show them all the features!”

🤡: “They'll see how great it is and buy!”

I knew our product cold. Every feature, every quirk. Thought that'd make me a demo god. Wrong.

My demos were a blur of clicks and connections. I'm thinking I'm hot shit, but the audience looks like I'm speaking Klingon¹. Eyes glazed over. Brains offline.

Then the kicker:

“[[But can your software do this?]]”

Jesus Christ. I'm showing them what's essentially a for loop², and they can't see the possibilities.

We even tried throwing pre-canned templates at them. Still no dice.

Meanwhile, I'm doing these “Office Hours” on the side. Free trial users, 60 minutes to help them build something. Pure gold.

Here's where the megachad approach kicked in:

🗿: “[[Recontextualise their problems within your unique perspective and solution]].”

We'd tackle their actual problems. Map it out, field mappings, the works. Working prototype in an hour. Nothing screams ease-of-use like watching your really difficult automation challenge get solved in real time.

And suddenly, it's raining credit cards.

Why the night and day difference? Two reasons:

1. Software is hostile to a user's mental model of their processes. In the Office Hours, I bridged this gap. Instead of showcasing abstract features, I directly mapped our software to their specific processes. This reframing made our solution immediately relevant and understandable.
2. Emotional urgency clashes with enterprise software complexity. Our product's flexibility was both its strength and its weakness. In demos, this paradox left prospects confused. But in Office Hours, we resolved it by configuring the software to their exact needs in real-time. Seeing is believing, and they saw their specific problems vanish before their eyes. (This can sometimes be harder with enterprise software: [[Software is either easy or powerful]])

We weren't just selling software; we were [[Recontextualise their problems within your unique perspective and solution|contextualising]] our solution within their world (see: [[Sales is a middleware for frames]]).

This approach didn't just demonstrate the product – it reframed the entire conversation, shifting from “[[But can your software do this?]]” to “How quickly can we implement this?”

See also

• §Abstractions
• Recontextualisation — as we need to re-contextualise software into the prospect's context.
• Always focus on the analysis and don't worry about the code