Elon Was Right: Most Requirements Are Dumb—Here's How You Make Them Better

I’ve been coding software for 23 years, and let me tell you, I’ve seen my fair share of dumb specifications. But don’t worry, I’m here to help you spot them and make them better. This post is for non-technical product managers, co-founders of software companies, and anyone building their own software product. Let’s dive in!

Understanding the Purpose: Elon Musk’s Problem-Solving Approach

Before we get into the nitty-gritty, I want you to watch this video of Elon Musk. His process is pretty illuminating, at Space X

1. Make requirements less dumb 👈
2. Delete unnecessary requirements
3. Simplify
4. Make it faster
5. Automate

It’s crucial to remember that requirements are always dumb to some degree. No matter who you work with, you’ll always get incomplete or dumb requirements. It’s just part of the process.

Requirements are always dumb to some degree.

How to make them less dumb? Delete some of them. If you’re not forced to bring back 10%, then you haven’t deleted enough.

The Fallacy of Reverse Order

Applying this mantra in reverse order is a recipe for disaster. You might end up creating something that shouldn’t exist!

Common Types of Dumb Specifications

1. The “Just Copy X” Syndrome

The first dumb requirement is basically no requirement at all. It’s just someone pointing at existing software and saying, “Copy this! It can’t be that hard!”

There’s a hilarious clip from the “Dumb Starbucks” episode of Nathan For You that perfectly illustrates what happens when you just clone something. Spoiler alert: it usually doesn’t work out well.

Solution:

• Recognize that cloning rarely works well
• Understand the unique needs of your project
• Develop original solutions tailored to your specific requirements

2. Laziness in Specifications

I’ve seen this many times. It’s just pure laziness, like forgetting to specify what a “Show All” button does.

Solution:

• Follow the 10% rule: Spend at least 10% of the expected development time on specifications
• As a product manager, create breadboards (I have a video about this process)
• As a developer, make a click prototype

3. Designs That Look Bad with Little Data

UX designers and product managers often forget to consider how an app looks when there’s no data. They design for the “good case” but forget about the “bad case.”

Solution:

• Ask about the minimum and maximum number of entries for lists
• Test with real user data when possible
• If real data isn’t available, release a simpler feature first and iterate

4. Unrealistic Timelines and Budgets

I once had a client who wanted an Instagram clone for internal use, done in 20 days for $100. I laughed so hard!

Solution:

• Run! (Just kidding… sort of)
• Educate clients on realistic timelines and budgets
• Start with smaller, achievable projects to build understanding

For those with unrealistic expectations, the best fix is to go through the pain of development once. Seeing a project go over deadline can be a valuable learning experience.

5. Missing Edge Cases

This happens when people have an idea of how something should look but don’t think about backend processes or edge cases.

Solution:

• Play out the entire feature in your head or in a flow chart
• Ask lots of questions before building anything
• Don’t build abstractions in the beginning
• If you’re a product manager, ask developers to list potential edge cases

6. Contradicting Specifications

I’ve seen “requirements docs” that went over 200 pages and contradicted themselves. It’s a mess!

Solution:

• Be cautious of docs larger than 10-20 pages
• Agree on a simple first milestone or MVP
• Use large documents as inspiration, not gospel
• Aim for a maximum dev time of 3 months for the initial version

Remember: Good Developers > Good Specifications

Even with the best specs, a mediocre developer might deliver something that meets the requirements but doesn’t meet your needs. A good developer, on the other hand, can work wonders with even half-baked specs.

In the end, it’s all about iterating and maintaining control over what’s being built. If you want to see how to make those breadboards I mentioned, check out my video on the topic. It’s been a game-changer for our software development process.

What kind of dumb specs have you encountered in your career? Let me know in the comments!