How to Make Your Requirements Less Dumb: A Guide to Smarter Product Development
Want to give your tech venture the best chance of success?
Whether hardware or software, most tech ventures fail and products never see the light of day. Why? Elon Musk identified a product development weakness we’ve seen in 90% of ventures launching in South Africa and beyond.
He identified it during a 2021 interview that led to the now-famous concept of Elon’s 5-step design process – see it unpacked fully in our step-by-step guide to creating better products.
The most fundamental step, though, and the one cardinal error most new companies get wrong, is step one, i.e. ”Make your requirements less dumb”.
Musk never fully explored it, but we’ve developed our own interpretation and have successfully used it to help numerous new tech companies that would have folded or never started, get going changing the world for the better.
Here’s how to do it – aka, how to make your product requirements less dumb…
First: What are Product Requirements?
Product requirements are the essential conditions, features, and constraints that your product must meet to function as intended.
Both hardware and software teams develop formal documents, often called a PRD (Product Requirements Document) listing things like project goals, scope, functional and non-functional requirements, hardware and software needs and limitations, and even outline testing parameters.
This becomes the roadmap for how you go about developing your product.
And the point Musk was making, which we’ve seen time and again in many real-world tech projects, is that the methodology you use in creating your PRD can make or break your future company…
The Danger of Unquestioned Assumptions
To simplify what Musk means by requirements being “dumb”, it helps to rephrase it into a single powerful directive – assume every requirement is wrong until it earns its place on your product's blueprint.
In many projects, requirements from "smart people" or higher-ups can sneak in without due scrutiny. These unchallenged assumptions add unnecessary complexity, inflate costs, and often lead teams down the wrong path – when they start investing time and energy into optimising features that shouldn’t have been there in the first place.
Musk’s example from Tesla’s factory perfectly illustrates this: The team faced massive production delays due to a fire insulation requirement between the battery and engine. They spent significant time and resources trying to solve this problem, only to discover later that the insulation wasn’t needed at all.
The requirement had been added early on as a "just-in-case" safety measure but had no legal or practical merit. Once removed, the project could move forward smoothly.
The Core Insight
On inspection, the requirement was found to have been blindly followed without question. And the PRD provided no information as to who or why it was added, meaning the team battled to intelligently engage with it – i.e. the way it was handled was “dumb,” they needed a way to handle requirements that embedded it with more information, in other words make it smarter or at least “less dumb”.
At Octoco, we encounter similar situations with many of our clients – where unnecessary features or steps have been added based on assumptions that no longer hold. The goal is to eliminate these assumptions early on, so you don’t waste time optimising features that shouldn’t exist.
Step 1: Make the Requirements Less Dumb
Musk’s first step is simple in theory but often overlooked: assume every requirement is wrong. This doesn’t mean scrapping everything, but rather questioning each requirement until it proves its value. Here’s how we approach this at Octoco:
Assign Ownership to Every Requirement
Every requirement should have a specific person’s name attached to it. This creates accountability and forces teams to ask critical questions. At Octoco, we believe that by linking each requirement to an individual, you bring clarity and accountability into the process. This allows for a deeper examination of why a particular requirement exists.
Apply the ABC Model:
To interrogate every requirement, we use the ABC Model:
A: Assume nothing. Challenge the assumption behind every requirement – no matter who proposed it. Could the product work without it?
B: Be curious. Ask why this requirement is included. What problem does it solve, and does it serve the product’s ultimate goal?
C: Confirm the important. Validate whether this requirement contributes to the core functionality of the product. If it doesn’t, it’s time to cut it.
Case Study: Henlo Coffee’s Wooden Chassis
A great example of this in action is Henlo Coffee, an AI-powered coffee machine project that aimed to empower owners with data and revolutionise the barista and barista training experience.
The founder envisioned the machine with a stunning, complex wooden chassis to give it a premium feel. However, this design element was so expensive and time-consuming to execute that it slowed down the entire development process.
By applying Musk’s "make it less dumb" philosophy, we questioned the necessity of this design. The chassis added no value to the machine’s core AI features, which were the real differentiator in the market.
Once we eliminated the wooden chassis requirement, production could move forward at a fraction of the cost and complexity, allowing the machine’s AI features to shine.
Avoiding the Smart People Trap
One of Musk’s critical insights is that requirements from "smart people" can be the most dangerous because teams are less likely to question them. At Octoco, we stress the importance of questioning every assumption – even if it comes from the CEO, lead engineer, or an industry expert.
Smart people can be wrong too. Their ideas, while well-intentioned, need to face the same scrutiny as everyone else’s. By fostering a culture where all ideas are challenged, teams can avoid falling into the trap of accepting flawed requirements.
The Hidden Costs of Unnecessary Complexity
Failing to challenge requirements adds hidden costs to your project. Each unnecessary feature increases development time, complicates design, and inflates costs. More complexity also means more opportunities for something to go wrong.
By questioning and refining requirements early on, you save time, reduce costs, and create a leaner, more focused product. Tesla’s fire insulation and Henlo Coffee’s wooden chassis are prime examples of how cutting out unnecessary elements can streamline production and prevent major setbacks.
Iterate on Your Requirements Over Time
Remember that requirements aren’t set in stone. As the product evolves and you receive feedback from users, you should continuously revisit and challenge your assumptions. What made sense in the early stages might no longer be relevant.
At Octoco, we encourage teams to adopt an iterative approach, where requirements are continuously scrutinised throughout the development process.
This helps ensure that the product stays aligned with its goals and customer needs.
The Octoco Approach: Making Your Requirements Smarter
At Octoco, we offer vital outsourced CTO support and services to founders, teams or ventures that do not have an internal CTO or require specialised engineering expertise, as well as hardware engineering and software engineering to help more SA companies succeed.
We’ve used this process to help ventures across South Africa streamline their product development. From hardware projects like Henlo Coffee to software solutions, we focus on eliminating wasteful complexity by questioning every requirement.
Why this matters: If you skip this critical first step, you risk building a product on flawed assumptions. By applying this principle early, you can prevent your project from getting bogged down by unnecessary complexity and set yourself up for success.
Need help developing a better product with more chance of success?
Book a free strategy session with the Octoco team right now.
