Introduction

I came across a couple of articles and videos recently that talked about how well-known entrepreneurs ran their businesses to create products that have been extremely successful. 2 of these individuals that resonated with me were Steve Jobs and Elon Musk. I know, this might sound cliché, but there is a lot we can learn (and copy) from their approach to product development.

In the rush to ship features and meet deadlines, most organisations fall into a familiar trap: Product teams throw requirements over the wall to Engineering, who scramble to build whatever was asked for, often discovering critical flaws only during or after deployment. Resulting in costly rework, frustrated teams, and products that miss the mark.

But there's a better way, one that recognises software development as a collaborative craft requiring excellence from both Product and Engineering, working in tight partnership from the very beginning.

Two Key Philosophies For Successful Product Development

Steve Jobs: The Pursuit of Insane Quality

Steve Jobs famously said, "If you keep your eye on the profit, you're going to skimp on the product. But if you focus on making really great products, then the profits will follow".

Jobs was obsessed with details that most people would never notice. He demanded that the inside of the Macintosh be beautiful, even though users would never see it. He refused to ship products until every interaction felt magical. His question was always: "Is this the absolute best we can do?"

Elon Musk: Discipline of Ruthless Deletion and Simplification

Musk approaches product development from the opposite direction. His famous algorithm starts with making requirements "less dumb" and deleting everything possible. He believes that most features, processes, and complexity shouldn't exist in the first place. He is constantly asking: "Why are we doing this at all?"

At first glance, these positions seem contradictory: An obsessive detail and polish in Apple’s products, and ruthlessly cutting everything. But I’ll show you how both approaches are based on the same principle.

When Simplicity Meets Perfection

The genius is that Jobs and Musk are solving the same problem from different angles.

Jobs's obsession with quality centres around a ruthless focus on what matters. He once said: "I'm as proud of what we don't do as what we do". The original iPod's success wasn’t because it had more features than its competitors. But it was simple, intuitive and beautifully crafted.

On the other hand, Musk created a framework called “the algorithm”, which is all about eliminating everything that distracts from the main target.

The common denominator of these 2 approaches is keeping things as simple as possible and removing everything else that is not directly related to the “main thing”.

During my career, I’ve seen that most companies work in a hierarchical structure with “deities” like “The Stakeholders”, “The Business”, “The Product Team”, “Marketing”, you name it. Oftentimes, teams wouldn’t challenge those “deities” because they didn’t have the power to do so, they didn’t know they could, or they just didn’t care. So they would just do what they were told and try really hard to meet deadlines, and move to the next requirement.

Let’s go back to Elon Musk and Steve Jobs. Both of them demanded brutal honesty from their teams. They hated “people pleasers”. 

In companies like SpaceX, Tesla and X, engineers must be part of the decision-making process because they are the ones working to solve problems. Steve Jobs had the same policy for Designers when crafting the first Apple products.

The most important thing for them was to produce life-changing, high-quality products and solutions. They didn’t care if they were right or wrong at all.

This meant that every team member had the freedom to challenge ideas, even if they came from the CEOs. And if those ideas weren’t aligned with the immediate end goal of the product, then they should be trashed.

A Framework That Will Take Your Product Development To The Next Level

Say there is a list of draft requirements, let’s combine Musk’s and Jobs’ approach into a single “framework” with these steps:

1. Challenge every requirement: What’s the name of the person who asked for this requirement? (to then talk to that person and ask for more information), Why is this a requirement? What happens if we remove this requirement from our list?

2. Remove every requirement that is not directly related to the main goal of the company.

3. Simplify every requirement as much as possible and remove everything else. However, make sure that every requirement is crystal clear.

4. If you end up with just 20% or 30% of what was in the original list, that’s great!

5. Now focus on the new list and “obsess” over details like: intuitive and seamless user experience, speed, security, reliability, error handling, etc.

6. Deploy as soon as a requirement is built. But with some caveats: assuming it doesn’t break anything or depends on another one to work in Production.

7. Get feedback from everyone involved in the process: end users, designers, salespeople, marketing, engineers, etc. And keep an eye on how your competitors are doing, good and bad.

8. Golden rule: NEVER start working on a requirement that is not 100% clear, not even “to save time while waiting for more information”. If it’s not clear, then again, why is it a requirement in the first place?

Following these steps will help you with:

• Faster time to market, because you are building on a fraction of the original scope.

• Simpler and better products than your competitors.

• Greater ability to pivot after getting feedback.

The Engineering Practices That Will Take Your Product Development To The Next Level

By this point, you have already reduced and simplified your backlog as much as possible. And you and your team can start working in bringing those requirements to life.

These are some of the key practices that you and your team can apply:

Pair Programming: Knowledge Transfer at Speed, Avoid Silos and Single Specialists.

Pairing should be the default way of working of your team. I know that, at first glance it may seem like a waste of time and effort. Why having 2 or more people work in a single task when you can have them spread and cover more ground?

But if you think about it, it makes a lot of sense:

• Multiple minds and eyes can approach a problem better than one.

• Team members will share findings, challenges and context.

• You avoid “specialists” and “silos”, and this is key, because your team won’t rely on a single person for anything. If that person is unavailable, anyone can carry on with the task.

• Newcomers and junior members will get up to speed fast.

• Your teams code reviews will happen in real-time, which saves time.

But pairing isn't just for engineers. Product Managers, Designers, even sales people should also pair with Engineers during development, because this creates rapid feedback loops and prevents misunderstandings from the beginning. In fact, both Elon Musk and Steve Jobs believed that everyone involved should have a deep understanding of the product development process.

Trunk-Based Development: Eliminate Integration Hell

A few years ago, the norm in Software Engineering was to have multiple repository branches, one per task basically, and then have those branches merged into a single repository.

But this has produced certain challenges like merge conflicts and integration problems, especially when a single task requires multiple changes across the code.

The solution to this problem is called “Trunk-based development”, and it means that everyone commits to the main branch at least daily, with feature flags controlling what's released to users. 

If you apply this approach, you will see key benefits from day 1, like:

• Continuous integration becomes actual continuous integration, not "integrate once a week and pray everything goes smoothly".

• Problems are discovered within hours, not weeks.

• Forces small, incremental changes.

• Enables true continuous deployment.

Test-Driven Development (TDD): Design Your Implementation Through Tests

TDD isn't about testing, it's about design. By writing tests first, your team is forced to think about interfaces, dependencies, and what "done" actually means before writing implementation code. Therefore your code will cover only what the requirements are, and nothing else.

You and your team can implement TDD with something called “Red-Green-Refactor”:

1. Write a failing test that describes the desired behaviour

2. Write the minimum code to make it pass

3. Refactor for clarity and simplicity

Behaviour-Driven Development (BDD): Common Language And Shared Understanding

You can think of BDD as a bridge between Product and Engineering. The idea is to write  requirements as executable specifications. When Product writes acceptance criteria in a format like:

Given [context]

When [action]

Then [expected outcome]

Engineers can turn these directly into automated tests easily. This creates a single source of truth that everyone understands: business stakeholders, developers, and testers alike.

Agile Development: Real Agility, Not Cargo Cult Ceremonies

Many people think that “Agile” is about standups and sprints, and a ton of meetings in between. But in reality Agile was borne as a framework for rapid iteration based on real feedback. Which can be simplified to:

• Ship small changes frequently.

• Measure real user behavior, not opinions and thoughts.

• Adapt based on data.

• Keep everything small enough to throw away if it doesn't work and pivot quickly.

Like any other tool, Agile should serve you and your team to achieve your goals easily and efficiently, so if it becomes a “ritual of meetings” then think about reducing it to the absolute minimum required to help the team reach their main goal without wasting time and energy in useless meetings.

Summary

Imagine applying this workflow to your business and teams. This is how you and your team can build high-quality products efficiently and fast:

1. Product owners identify a problem through research, getting information from end users, sales and marketing, designers, engineers and anyone else involved with this problem.

2. Product, Engineering and Design pair to question the requirement: Is this the real problem? Who asked for this and why? What happens if we remove this requirement? How can we simplify it? Cut out everything that is not related with the main goal of your product. Simplify the rest to its absolute minimum and focus on intuitive user experience, security, reliability, and efficiency.

3. The team also pairs to write BDD scenarios that describe the simplest solution as well as edge cases and exceptions.

4. Engineers start working on the requirements that are 100% clear.

5. Engineers pair to write TDD tests derived from those scenarios and implement in small increments, committing to the trunk and deploying frequently.

6. The team gathers feedback after deployment.

7. Product validates continuously as features emerge based on real data.

8. Repeat.

Conclusion: This Is Not a Theory

No matter what you think about Elon Musk and Steve Jobs, it’s undeniable that the companies they founded and ran have produced very successful products.  

My goal with this article was to explore how they approached product development and layout practices that you can try in your company or team to improve and simplify your outcomes.

Sources and Further Reading

Musk's Algorithm:

• Walter Isaacson. Elon Musk Autobiography - Original documentation of the algorithm

Steve Jobs on Product Quality:

• Walter Isaacson. Steve Jobs Autobiography: The Exclusive Biography.

Technical Practices:

• Kent Beck. “Test Driven Development: By Example”

• Dan North. Introducing BDD

• Paul Hammant Trunk Based Development

• Martin Fowler - On Pair Programming