Category: Rich Pictures

I was talking to a friend yesterday about how our experience of the sales process has changed over time.

Selling is a critical part of a business – it’s what makes everything else possible.

But too much selling is based on Freudian principles, assuming that the main drivers for buyers is to seek pleasure and/or avoid pain.

Victor Frankl, on the other hand, thought that people’s primary drive is towards finding meaning in their lives.

This is a more nuanced lens that is tricker to pin down.

The idea is that we tell stories to make sense of the world around us.

The stories we tell, especially about how we see problematic situations unfolding in front of us, give others insights into the way in which we structure our understanding and find purpose and meaning.

For example, the way in which you approach sustainability will be different if you are a purpose-driven firm that wants to minimize your environmental impact versus a profit-driven firm that wants to comply in a meaningful but compliance-led way.

Purpose matters.

If we understand purpose then we can build solutions that are fit for purpose.

Interestingly, that’s now the accepted definition of quality.

Juran’s quality handbook defines quality as \”fitness for purpose\”.

But how do you understand purpose from a buyer’s point of view?

That’s where having a good discovery process at the front end of your sales cycle is essential – and that’s the thing that’s changed.

Fewer decks, less pitching.

More listening and more problem structuring.

Will something like vibe coding take off? As an operations manager, should you or I spend more time on this, or will it pass away in a year or so?

I was just thinking about a post by Judah Diament – seen via mastodon, starting on BlueSky – about a computer scientist’s perspective.

As engineers and managers we need things that work.

Success or failure matters.

With a new tool, the promise always is that “this time it’s different”.

The opposition to that starts with a minimal knowledge of history. There have been many tools that aimed to construct complete applications.

But the market wasn’t ovverrun by automatically generated applications.

These tools produced code and documentation and you could understand what was going on.

Their successors live on in frameworks that you can start from and build on – but no one pretends they are ready out of the box.

That’s because any real world application has variety – it needs changes, has complexity, introduces unusual requirements.

At some point, you may need to understand what’s going on to match a client’s needs – and how can you do that if the output is unpredictable and depends on the particular prompt you used?

Then there’s the question of value.

If an entire system can be created from a single prompt, then what’s the value of the output?

It’s probably the cost of the prompt in whichever platform you’re using.

Say you can build an application for ten dollars.

If an operations manager can do the same thing then she might as well use the prompt to create the application too.

The real cost comes over time, in customising and maintaining that application.

The value then comes from the team that delivers the ongoing service to the manager, not the product.

In short, if this approach starts to succeed , the cost of products will fall close to zero.

Managers will instead pay for operations and maintenance teams to understand and keep this pile of code operational.

The SaaS model becomes one where the S for service starts to matter much more than the S for software.