11 Things Steve Jobs Can Teach You About Making Extraordinary Products
Some time ago I’ve finally put my hands on Steve Jobs biography by Isaacson. It sat on my finally-read-it list forever, and I’m glad that I brought myself to go through it, because for me it reads like a manual to making extraordinary products with a plot about a genius behind Apple. And if I can learn about this craft from the man himself, be sure I’m reading carefully.
So here are 11 things about building industry-defining products that you can learn from how Steve got things done.
Lesson 1: Taste, taste, and once again, vision. Ignore customer research.
Okay, “ignore customer research” is a provocative way to say it, because obviously Jobs did not build products in a vacuum. He noticed people. He watched how they struggled. He had a very good sense for the weird little frictions that everyone accepted as normal.
But he did not treat users as product designers.
And I think this distinction matters a lot. There is a difference between listening carefully to what frustrates people and asking them what features they want. Most people are quite good at telling you that something is annoying. They are much worse at imagining a completely different way of doing it.
Before the Macintosh, computers felt cold and intimidating to normal people. Before the iPod, digital music was scattered between CDs, files, bad software, piracy, cables, folders, and a general sense that you needed to be slightly technical to manage your own music. Before the iPhone, phones were a mess of plastic buttons, carrier menus, tiny screens, styluses, and compromises everyone had learned to tolerate.
Apple did not win because users filled out a survey saying, “Please give me a software-first touch computer with a capacitive screen and a full browser.”
Users don’t speak like that. They speak from inside the world they already know.
That’s why taste and vision matters so much.
Vision is the ability to look at a messy reality, notice what feels wrong, and imagine a version that feels almost obvious after someone makes it. Good taste means trained judgment. It means knowing when something is clunky, when it is dishonest, when it is trying too hard, when it is solving the wrong layer of the problem.
So yes, listen to customers. Listen very closely. But don’t hand them the steering wheel.
Use research to understand pain, desire, context, behavior, language, and hesitation. Then do the harder part yourself. Synthesize findings, choose, have a point of view.
That is uncomfortable, because once you stop outsourcing vision to customers, you can no longer hide behind “the research said so.” You become responsible for the idea that is being brought to life.
And that, I think, is where extraordinary products start.
Lesson 2: Simplicity is not minimalism. Simplicity is the result of solving complexity.
One thing that comes back again and again in the biography is Jobs’s allergy to unnecessary complexity. He hated things that felt messy. Too many buttons, too many options, too many product lines, too many explanations.
But the interesting part is that Apple’s simplicity was not achieved by doing less work.
Usually, it was the opposite.
The iPod looked simple from the outside. You had a small device, a wheel, a screen, and a sentence anyone could understand: 1,000 songs in your pocket. But behind that simple promise there was a ridiculous amount of hidden coordination. Hardware, software, storage, industrial design, battery life, licensing, the iTunes store, syncing, packaging, retail, supply chain.
The user got one clean experience because Apple swallowed the complexity internally.
This is such a useful lens for looking at products. A lot of bad products are not bad because the team is stupid. They are bad because the company lets its own complexity leak out onto the user.
You can feel it when it happens.
You open an app and it asks you to understand the company’s internal categories. You try to cancel something and suddenly you are navigating a maze that clearly reflects someone’s retention KPI. You buy software and then need to connect three integrations, read four help articles, and learn vocabulary that only makes sense to the team that built it.
That’s clean example of organizational complexity exported to the customer.
A simple product is often the result of a team taking on the annoying, expensive, cross-functional work that everyone else avoids.
So instead of asking: “Can we make this screen cleaner?”
Start questioning if we are simplifying user’s life, or merely our own implementation?
Most mediocre products choose the second and call it pragmatism.
Lesson 3: To create a magic moment you might need to control everything end-to-end
Jobs had this almost obsessive preference for integrated systems. He even sabotaged possible partnerships out of fear that no one can make apple-compatible products good enough, except of Apple itself.
From the outside, this can look like control freak behavior. And sometimes, honestly, it probably was. For sure it helped Microsoft to become the most valuable company in the USA for some time.
But the product logic behind it is hard to ignore.
If you want the whole experience to feel effortless, you need influence over the whole experience.
The “magic” people talk about with Apple products usually did not come from one isolated feature. It came from the fact that many separate pieces behaved as if they had been designed by one mind. The device, the software, the account, the store, the box, the first-use experience. They all pointed in the same direction.
This is very hard to do when every part of the journey is owned by a different partner, vendor, department, or platform.
You can see the opposite everywhere. A product has a beautiful website, then a confusing onboarding. Or a great core feature, but terrible support. Or a premium brand, but invoices that look like they were generated by a forgotten internal system from 2009. The interface says one thing. The rest of the experience says another.
Jobs seemed to understand that the user does not care which team owns which part.
For a digital product, end-to-end responsibility means caring about onboarding, speed, empty states, pricing, cancellation, error messages, emails, notifications, documentation, support, trust, and the emotional state the user is in before and after using the product.
The product is not just the interface, but rather – the whole experience the person has while trying to get something done.
And if you only control the pretty middle part, don’t be surprised when the whole thing does not feel magical.
Lesson 4: Focus is mostly about saying no
Jobs’s return to Apple is probably one of the cleanest product strategy lessons in the book.
Apple had 67 product lines. And it was not doing great. When Jobs came back, he immediately started to kill projects. The famous 2×2 grid, consumer and professional on one axis, desktop and portable on the other, forced the company to choose.
And this sounds simple until you try to do it. Focus is a resource allocation mechanism. It tells you what will not get people, attention, money, meetings, roadmap space, and emotional oxygen.
Most companies want the identity of being focused without the pain of removing things.
They keep too many personas alive. Too many features. Too many segments. Too many strategic priorities. Too many integrations. Too many “small” exceptions that quietly destroy the shape of the product.
The result is usually a product that is polite to everyone and loved by no one.
Jobs’s version of focus was more brutal. If something did not strengthen the core idea, it was deleted. This is painful, because saying no often means disappointing reasonable people with reasonable requests.
But that’s the trap. Almost every distraction sounds reasonable in isolation.
A product becomes extraordinary when the team has enough courage to disappoint secondary audiences so the primary experience can become exceptional.
Lesson 5: Best products are never neutral
Apple products under Jobs had opinions.
The Macintosh had an opinion that computing should be visual, approachable, and humane. The iPod had an opinion that digital music should feel effortless, personal, and legal. The iPhone had an opinion that the phone should become a touch-based software platform, not a plastic object defined by fixed buttons. The iPad had an opinion that casual computing could be more intimate, relaxed, and direct than sitting behind a laptop.
These products were not just lists of features bundled in the form of a device because „customers said they wanted them”, or „competition already got it”, or „we thought it might be cool”. Each of them was a thesis about some issue that you could agree or disagree with, but that you couldn’t ignore.
Some people thought that removing keyboard from the phone was killing the very idea of the phone. Others absolutely hated that newer generations of mac were becoming worse and worse for hobbyists that wanted to play with their hardware.
But opinions of people outside of core target user group never bothered Steve at all.
When he coined the opinion on how the things should be for a given product, he just rejected other points of view.
I like this way of thinking about product strategy, because it makes weak product thinking very visible.
A weak thesis for the iPod would be something like:
“We help users manage and listen to digital music files.”
Accurate, maybe. But it’s pure fluff.
A stronger thesis would be:
“Your entire music library should feel as natural to carry as your wallet, and as easy to use as pressing play.”
That already gives you direction. It tells you that file management should disappear. Syncing should be painless. The device should be pocketable. The interface should be simple enough to use while walking. The story should not be about storage capacity in technical terms, but about what that storage means in someone’s life.
Same with the iPhone.
A weak thesis would be:
“We make a phone with internet, music, and apps.”
A stronger thesis would be:
“The phone should stop being a fixed device and become a pocket computer that can reshape itself around whatever you want to do.”
That thesis makes the no-keyboard decision more understandable. It explains why software mattered so much. It explains why the screen had to dominate the object.
A product with a thesis can make coherent tradeoffs. A product without one becomes a pile of requests, competitor reactions, and internal compromises.
And users can feel the difference, even if they never can describe it.
Lesson 6: Product excellence comes from unreasonable standards
This is one of the more uncomfortable lessons from this book. And this biography’s definitive highlight is that Isaacson din’t tried to flatten the Steve’s character by trying to make him look like he was some clean, charitable poster character. He could be, and very often was cruel. He could be manipulative. He could dismiss people in ways that were plainly unfair.
So I don’t think the lesson is “act like Steve Jobs.”
Please don’t.
But I do think there is something important hiding inside the discomfort. Extraordinary products rarely come from reasonable standards.
Reasonable standards usually produce reasonable products. Competent products. Products that pass internal review. Products that nobody is embarrassed by. Products that work fine and disappear into the grey ocean of things that exist.
Jobs rejected work that many other organizations would have accepted. Sometimes he was irrational. Sometimes he was right before others could see it. Sometimes the unreasonable demand forced a team to find a path they would never have found if the target had been more comfortable.
There is a very real difference between pushing people and humiliating people.
But avoiding bad behavior does not mean lowering the bar.
If you care about the work, you need standards that create tension. You need someone in the room who is willing to say, “This is not good enough yet,” even when everyone is tired and the deadline is too close.
That sentence can be said calmly. It can be said with respect. Maybe even with kindness.
But it still has to be said.
The mature version of the Jobs lesson is to separate unreasonable standards from unreasonable behavior. Don’t yell. Don’t humiliate. Don’t create fear as a management system.
But also don’t confuse politeness with excellence.
You probably cannot build a truly exceptional product with vague taste, low-friction consensus, and a culture where mediocre work is allowed to pass because challenging it would make the meeting uncomfortable.
Lesson 7: If you don’t have feelings towards it, it’s not a great product
Jobs understood that people do not experience products only through pure reason and utility.
They feel them.
The Macintosh was not just a computer. It wanted to feel friendly, creative, almost rebellious. The iPod was not just storage plus playback. It felt like freedom. The iPhone was not just a better phone. It felt like holding a piece of the future. Apple Stores were not just retail locations. They made the products feel important. Even the packaging turned ownership into a small ceremony.
This is easy to mock if you are very rational. And to be fair, product people can overdo this stuff. Not every button click needs to be a spiritual event.
But the underlying point is powerful.
A great product creates an emotional aftertaste.
It might make you feel capable. Or calm. Or tasteful. The feeling depends on the product, but there has to be something.
I think about this a lot with software, because many teams stop at “what can the user do?” That’s an important question, but it’s not enough.
What should the user feel after using this?
Relief?
Confidence?
Momentum?
A sense that somebody finally understood the problem properly?
That feeling is part of the product. It is not decoration added by marketing later. It is shaped by speed, wording, defaults, visuals, pricing, support, and a hundred other small signals.
If nobody has feelings toward your product, the product may still be useful.
But it probably isn’t great.
Lesson 8: Storytelling is part of product development
Jobs’s keynotes were obviously marketing events, but they were much more than JUST marketing events.
Of course, Steve liked to put on a show for the sake of it.
Of course, these conferences helped to create media buzz and direct attention towards new Apple products.
But there was something profound about how they weren’t much about how their product was better, or why you should buy it.
They were more about explaining – what it is, what the idea behind it is, who it is for.
They were setting an example of how you would use this product, how it would integrate with your life.
Steve had been doing it so well that when people left, they felt like they already missed the product in their life.
But he could do it this way because the stories that were told and the feelings that were provoked by the product and its context during these shows were an essential part of product planning and development from day 1.
These things were just parts of the vision, the POV that Steve was preaching to product teams first, and later – to customers.
The lesson here is that messaging is not something you can skip until the product is ready for distribution.
If you leave this until the very end of the process, you simply risk that the product you’ve made is actually not the product you should’ve created in the first place.
Lesson 9: Constraints are not the enemy
A lot of Apple’s products were shaped by constraints. Memory, battery life, physical size, manufacturing, costs, licensing. The usual annoying reality of making things.
Jobs’s interesting move was that he often treated constraints as clarifying forces rather than just obstacles. On top of ones that were „gifted” to him by external world, he tended to add his own ones.
And sometimes it helped to achieve giant breakthroughs.
The iPhone’s lack of a physical keyboard is a good example. At the time, it was risky. Physical keyboards were familiar. And „serious” business phones had them. Removing the keyboard created a huge design and usability challenge.
But that constraint also made the product more powerful. Once the keyboard became software, the whole front of the device could become screen. And the device could keep changing depending on the context. Keyboard when you need typing. Controls when you need music. A map when you need directions. A game when you want to play.
The constraint helped reveal the product’s deeper idea.
Too much freedom often results in products that are bloated with features, but lacking desirability. When anything is possible, teams tend to add. Add another mode. Add another option. Add another configuration. Add another persona. Add another “just in case.”
Useful constraints force shape.
Sometimes constraints are external, but sometimes it’s necessary to introduce constraints artificially to enable sharper design decisions.
One primary user.
One core job.
One key metric.
One sentence value proposition.
One emotional promise.
These are ways to create clear guidelines for the product team. Such constraints reveal priorities, create pressure and enable product getting it’s own POV, as we explored in earlier paragraph.
Lesson 10: Details are never „just details”
Jobs cared about typography, icons, bezels, corners, materials, animations, store layouts, packaging, and even parts of the product most users would never see.
There is a story in the book about caring how the inside of the machine looked, even though normal users would not open it. You can read that as obsessive, but you can also read it as a deeper philosophy of craft. The parts people don’t notice still shape the standard of the people making the thing.
The product lesson is not that you should micromanage every pixel. That usually becomes a bottleneck and annoys everyone. And realistically, you’re not SJ.
So the learning you can take out of this is that details accumulate into trust.
Users may not consciously notice every detail, but they feel the aggregate. A font not playing along with the vibe of the product. A laggy transition. A confusing empty state.
Any one of these things can seem minor.
Together, they communicate that this team does not fully care.
Great products create the opposite sensation. You keep touching the product and it keeps quietly confirming that someone thought about this. Someone cared enough to make the awkward thing smoother. Someone removed the little anxiety before you had to notice it.
That is why details are not just details.
They are how the product reveals the team’s standards.
Lesson 11: Sometimes, you don’t need to be „realistic”. But know the price.
Jobs’s “reality distortion field” is one of the most famous ideas from the book. People around him used it to describe his ability to make impossible things feel possible, at least for long enough that people started trying.
And sometimes that worked.
It compressed timelines. It raised ambition. It made smart people question whether their constraints were real constraints or just assumptions wearing a serious face.
That is valuable. A lot of teams are too realistic too early. They kill ideas before they have properly explored them. They confuse “we have not done this before” with “this cannot be done.” They protect themselves from disappointment by lowering the ambition until the work becomes safe and forgettable.
Jobs pushed against that. Hard.
But the biography also shows the price. The same force that helped people break through limits could also become denial. It could create unnecessary pain. It could make reality seem negotiable in places where it really was not. In personal contexts, especially around his health and relationships, that side of him becomes much darker.
So the product lesson needs both halves.
Visionary pressure can unlock hidden capacity, but only when it stays in contact with reality.
The healthy question is:
“What would have to be true for this to be possible?”
That question opens a door. It invites engineering, creativity, tradeoffs, sequencing, and courage.
The unhealthy version is:
“It must be possible because I want it.”
That closes the door. It turns ambition into ego.
Extraordinary product development needs people who are willing to challenge constraints. It also needs people who can tell the difference between a constraint that can be bent, a constraint that can be engineered around, and a constraint that will break you if you pretend it is not there.
Maybe that’s the most useful final lesson from Jobs.
You don’t create industry-defining products by doing things that always seems comfortably possible, within reach.
But you also don’t get a free pass from reality just because your taste is good and your vision is strong.
The real craft is learning when to push, when to cut, when to simplify, when to insist, when to ignore what people say they want, and when to listen more carefully than anyone else.
That’s why the biography stayed with me. Not because Jobs was a perfect model to copy. He wasn’t.
But because his life shows, in a very vivid way, that extraordinary products are not accidents. They come from taste, pressure, integration, story, standards, and a kind of caring that borders on obsession.
And whether we like him or not, there is a lot to learn from that.