Someone once proposed giving every new iPhone customer £10 worth of free music. Steve Jobs hated the idea.
And I think there is an important lesson in that story for almost everyone working in Solutions Consulting.
I recently came across a video of Neil West, Apple’s former head of music in Europe, sharing an experience from his time at the company. His team had come up with what sounded like a genuinely good marketing idea. Include a £10 iTunes gift card in the box with every new iPhone. Customers would receive a nice little surprise when opening their new phone, and Apple would have an excellent opportunity to introduce millions of people to the iTunes Store.
From a commercial perspective, it made perfect sense. The customer got something for free, Apple encouraged adoption of another service, and everybody seemed to benefit. The proposal went up the management chain, where Steve Jobs rejected it.
Not because the idea was necessarily bad. Jobs simply didn’t want to interfere with something Apple had worked incredibly hard to perfect: the experience of opening a new iPhone for the first time. That little gift card, with its own instructions and invitation to do something else, would have interrupted the experience. According to West’s account in The Irish Times, the customer would suddenly have to think about a separate transaction instead of enjoying the new product.
Was Jobs objectively right? Perhaps. Perhaps the gift card would have been a huge commercial success. We will never know, and that’s not really the interesting part of the story.
What interests me is that Jobs was willing to reject an idea with obvious benefits because it competed with something he considered more important. The simplicity of the experience was not an accidental side effect. It was part of the product.
Jobs expressed the underlying philosophy in a 2008 interview with Fortune: “It means saying no to the hundred other good ideas that there are.”
That sentence deserves a lot more attention in Solutions Consulting than it usually gets.
Good Ideas Are Often the Biggest Source of Complexity
Having spent more than two decades in technical pre-sales, I’ve seen a lot of complexity accumulate around products, demonstrations, customer projects and internal processes. What fascinates me is that most of it was introduced with perfectly reasonable intentions.
Someone wanted to make a demonstration more comprehensive. Someone else wanted to add another useful capability to a proof of concept. A customer requested an additional integration. A product team built a feature that solved a genuine problem. A manager introduced another report to gain better visibility into the business.
Individually, these decisions often make sense. Each addition has a justification. Each feature addresses a requirement. Each new process solves a problem that existed at some point.
But when was the last time someone went through all of it and asked whether those things still belonged together?
That’s where complexity becomes difficult to manage. It rarely arrives as one obviously terrible decision. More often, it grows through a series of small improvements that were never evaluated against the bigger picture. And because every addition has a reasonable explanation, removing anything becomes surprisingly difficult.
We tend to evaluate new ideas by asking whether they add value. I think that’s the wrong question, or at least an incomplete one. We should also ask whether the additional value justifies the complexity we introduce.
A feature can be useful and still make a solution worse for a particular customer. A demonstration can be technically impressive and still fail to communicate why someone should buy the product. And a process can produce valuable information while consuming considerably more time than that information is worth.
Sometimes the better decision is to leave a good idea alone.
The Solutions Consulting Trap: Showing Everything Because We Can
Let’s bring this back to our daily work.
As Solutions Consultants, we spend years learning products, architectures, integrations, APIs and technical details. We become experts in understanding complicated environments and explaining how technology fits into them. Naturally, we want to put that knowledge to good use.
And that’s exactly where things sometimes go wrong.
Imagine a customer who is evaluating a SaaS security solution because their IT department has lost visibility into which cloud applications employees are using. They are concerned about unmanaged accounts, unknown services and the security risks associated with them.
A well-prepared Solutions Consultant could demonstrate how the solution discovers previously unknown applications, presents relevant findings and helps the security team investigate what needs attention. The customer sees their problem reflected in the product. They understand how the solution might help them and can start evaluating whether it meets their requirements.
That’s already a meaningful demonstration.
But we’re technically curious people, and the temptation to continue is enormous.
While we’re here, let’s show the reporting dashboard. There’s also a nice integration we could demonstrate. We should probably mention the API capabilities. Oh, and the new administrative feature that Product Management released last week is genuinely impressive. We might as well include that, too.
Suddenly, the customer has spent another twenty minutes looking at functionality that may be excellent but has little connection to the problem that brought them into the meeting.
Every additional feature introduces another concept to understand. Another screen to remember. Another potential question. Another opportunity to lose the thread of the original conversation.
And the really frustrating part? The Solutions Consultant may have done a technically excellent job. Every capability was explained correctly. The demonstration was comprehensive. Questions were answered. Yet the customer leaves without a particularly clear picture of which part of the solution actually matters to them.
We’ve demonstrated the product, but we haven’t necessarily helped the customer make a decision.
This is something I regularly think about when reviewing how we approach technical sales engagements. Our job is not to give customers a guided tour through an application’s navigation menu. Our job is to connect technology to a business problem and make that connection sufficiently clear that a customer can evaluate it.
There is a difference between proving that something exists and proving that it matters.
Interestingly, this isn’t just a personal observation. Gong’s analysis of 67,149 recorded sales demonstrations found that successful demos tended to follow the priorities identified during discovery and involved more interaction with customers. That’s an observed association rather than proof of causation, but it aligns with what I’ve experienced throughout my career: the best demonstrations are usually conversations built around a customer’s problems, with the software providing the evidence.
Simplicity Is Not the Same as Showing Less
There is an important distinction here, especially when working with enterprise customers.
I am not suggesting that we should hide complexity, ignore requirements or deliberately leave out information that a customer needs to make an informed decision. Quite the opposite.
If I’m discussing an identity security solution with a customer who has complex regulatory requirements, multiple identity providers and thousands of users across different environments, those details matter. Authentication flows, data handling, permissions, administrative responsibilities and security boundaries may all require thorough examination. Pretending those questions don’t exist would be irresponsible.
But that doesn’t mean every stakeholder needs to understand every technical detail at the same time.
A CIO evaluating the business case has different questions from a security architect validating the design. An administrator who will operate the solution needs another level of information again. The complexity of the underlying technology may be unavoidable, but the complexity of how we communicate it is largely within our control.
For me, simplicity means making the relevant part of a complicated subject understandable without misrepresenting it. Sometimes that requires a five-minute demonstration. Sometimes it requires a two-hour architecture workshop. Both can be simple in the sense that they are focused, purposeful and free of unnecessary distractions.
And there is another uncomfortable truth: creating that simplicity takes work.
It’s comparatively easy to prepare a demonstration by walking through everything you know. It’s much harder to understand the customer well enough to decide what can safely be left out. You need sufficient technical depth to distinguish an important requirement from an interesting distraction, and enough commercial understanding to recognize what will actually influence the customer’s decision.
In other words, simplicity is often the result of expertise, rather than a lack of it.
What I Want Solutions Consultants to Think About Before a Demo
If I were to translate the lesson from Neil West’s story into a practical exercise for a Solutions Consulting team, I would start by challenging the demo agenda before challenging the demo itself.
Take a typical 40-minute product demonstration and ask one question: What does the customer need to understand at the end of these 40 minutes that they don’t understand today?
Not which features we want to demonstrate. Not how much of the product we can cover. What does the customer actually need to understand to move forward with a decision?
If we cannot answer that question, I would argue that we’re probably not ready to demonstrate anything yet. We need more discovery, or at least a clearer agreement about the purpose of the meeting.
Once that is clear, I would challenge the presentation from the opposite direction. Instead of asking what else we could add, remove something. Take out a feature, skip a configuration screen, shorten an explanation. Does the customer lose anything essential? Would that omission prevent them from evaluating the solution properly?
If not, why was it there in the first place?
Of course, customers will sometimes ask about additional functionality. And when they do, we should take those questions seriously. But even then, I think experienced Solutions Consultants should be comfortable asking why the requested capability matters.
Imagine someone asking whether the product supports a particular integration. The natural response is to say yes and immediately demonstrate it. A better response might be to understand what the customer intends to accomplish with that integration. Perhaps it’s a critical architectural dependency. In that case, it deserves proper attention. Or perhaps it’s something somebody put into a requirements spreadsheet years ago and nobody has challenged since.
Both deserve different treatment.
The same thinking applies to proofs of concept. I’ve seen how easily a focused technical validation can turn into an extended exploration of everything a product is capable of doing. Every new stakeholder brings another requirement, every successful test creates the opportunity for another, and before long the proof of concept has become a miniature implementation project.
This is where clear success criteria matter. If the customer wants to establish whether a particular authentication workflow works with their existing infrastructure, that should remain the central objective. Other features might be worth investigating, but they should not quietly expand the project unless there is a good reason to change the scope.
Being helpful doesn’t mean agreeing to every additional request. Sometimes being genuinely helpful means protecting the customer from spending time on something that won’t improve their decision.
The Leadership Challenge: Knowing When to Say No
Moving from an individual contributor role into Solutions Consulting leadership gave this subject another dimension for me.
As a Solutions Consultant, the complexity I introduced was mainly visible in my own work. My demonstrations, my customer engagements, my technical recommendations. As a manager, the consequences of adding complexity can affect an entire team.
A new reporting requirement might take only five minutes per person. An additional meeting might seem harmless. Another internal approval step might improve consistency. A new template might make it easier for leadership to compare customer engagements.
But multiply those additions across an international organisation, and they start consuming something we have a limited amount of: time that our Solutions Consultants could otherwise spend preparing customer engagements, developing their technical skills, supporting colleagues or working directly with customers.
As a leader, I need to apply the same discipline to my own decisions that I expect from my team when designing a customer demonstration.
Does this process solve a problem important enough to justify the additional work? Is this meeting genuinely necessary? Do we need another dashboard, or could we make better use of the information we already have? And perhaps most importantly, what are we willing to stop doing when we introduce something new?
That last question is particularly uncomfortable because organisations are much better at adding things than removing them. An initiative often has a sponsor, a goal and a reason for existing. Once it becomes part of the routine, however, few people feel responsible for questioning whether it is still needed.
I also believe that this is a coaching responsibility. If someone on my team has invested considerable effort into building a sophisticated demonstration, simply telling them to remove half of it is not particularly useful feedback. The better conversation is about understanding which parts help the customer and which parts mainly demonstrate our own expertise.
We should be able to appreciate the technical work behind something without insisting that every minute of it belongs in front of a customer.
And we shouldn’t confuse a good idea being rejected with the person behind it having done something wrong. A healthy team needs people who are curious, who experiment and who come up with ideas that challenge how things are done today. But it also needs an environment where those same ideas can be questioned, modified or dropped without becoming a personal conflict.
We don’t have to copy Steve Jobs’s sometimes abrasive management style to learn from his discipline around focus. In fact, I think we can do better by combining that discipline with a leadership approach that gives people room to contribute and understands the effort behind their ideas.
That’s the part of the story that interests me most as a manager. The ability to say no is valuable, but creating an environment where the team understands why something doesn’t belong is far more useful in the long run.
Find Your £10 Gift Card
What makes Neil West’s story so memorable is that the idea really wasn’t ridiculous. I can easily imagine myself supporting it. Free music for customers, more traffic to the iTunes Store and a pleasant surprise in the box. What’s not to like?
And that is exactly why the story works.
It’s easy to reject something that is obviously unnecessary. The difficult decisions are the ones where the additional feature, meeting, requirement or demonstration step has genuine value, but that value is smaller than the cost of introducing it.
The next time you’re preparing a customer demonstration, reviewing a proof of concept or introducing a new internal process, try looking for your own version of that £10 gift card.
It’s probably something you like. Something you worked hard on. Something you could defend with perfectly reasonable arguments.
Now ask yourself whether it makes the overall experience better, or whether it’s simply another good idea competing for attention.
Because one of the most valuable skills we can develop in Solutions Consulting is knowing what matters enough to include, and having the confidence to leave everything else out.
Even when it’s a really good idea.
