Thoughts on Human Oriented Programming and Design

How to Create a Successful Software Product

Floppy Disks

Many tech startups take the "If you build it, they will come" approach to product creation.

They spend a lot of time building something that's supposed to solve something they believe to be a big problem, without knowing if customers actually care enough about that problem to sustain a business built around solving it.

Here is a alternative approach, which is more likely to result in success (though maybe not in the way you expect).

It can be applied to commercial product creation, as well as to software development efforts internal to a large company or organization.

Step 1 - Create Something Useful as Quickly As Possible

Demonstrating value and getting in the door with a customer(s) as quickly as possible should be priorities 1 through 10.

Because of this, you should choose technologies and systems that maximize for:

  • productivity
  • development speed
  • enabling iteration/adjusting quickly/pivoting

Creating something useful is table stakes - it can get you in the door and engaging with customers, which is when the real development begins.

Your initial product does not have to be (and should not be) perfect. It just needs to be good enough to get you in the door. Don't fall in love with your initial product, and don't become too attached.

The way your product looks when you begin is almost never how your product will look when it really takes off.

This is because at its core, software development is about solving problems for people, and the hardest part of software development is understanding the real problems that customers have.

Once you understand the problems, writing code is actually the easy, predictable part.

Shipping something, getting feedback, asking questions, and iterating is the best way to find and solve real customer problems.

Step 2 - Identify the Real Problems and Solve Them

Once you've shipped something, the real work can begin.

You can start engaging with customers and prospective customers about what you've built, and use that as an excuse to have conversations and discover what problems they really care about.

Throughout this process, you should:

  • Be relentlessly focused on figuring out what problems your customers have.
  • Be humble and open minded, sincethe real problems will often be completely different from what you thought they were.
  • Hold solutions loosely - Be ready to pivot to a different solution when you discover real, valuable problems.

Have you ever had this experience?

You spend months building something for a customer or prospective customer, and when you demo it to them, the reaction is lukewarm.

But then you casually mention some unimportant feature, and see their eyes light up. "Oh! Now that's cool. That would be useful."

You get discouraged, because they've missed the point of what you were trying to build for them.

Don't overlook the opportunity

Instead of being discouraged, you should be excited.

You've just identified a problem that they care about, AND you've shown them that you could solve it.

Maybe the customer doesn't care about the learning management system you're trying to demo to them, but they're really excited about the file sharing feature you added as an afterthought. As it turns out, they desperately need a better way for their teachers to share files.


Dig in - ask them questions about their file sharing problem.

  • What are they struggling with?
  • Why haven't they been able to find a solution?
  • What solution would be compelling enough for them to buy?

Now, you know what they need, and they know that you can build it for them. You're in a fantastic position.

Step 3 - Repeat Steps 1 and 2

Now that you have a deep understanding of a real problem that a real customer has:

  • Build something useful as quickly as possible
  • Demo it to the customer
  • See if it solves their problem
  • Find out as much as you can about additional problems they're having
  • Repeat, repeat, repeat

Keep following this process, and you'll end up with an incredibly valuable product, and a customer that loves you and will advocate and advertise for you.

Scaling Only Matters if You Have Something Worth Scaling

It's a metaphor, get it?

Scaling too early

Engineering teams often focus on scaling a product before they have a product worth scaling, or even know if they'll need to scale it.

This is called "premature optimization", and it kills projects.

Focus on building something that delivers value first, and figuring out how to scale it second. If you don't nail step one, you will never get to step two.

This sounds simple, but it's actually very hard due to "performance shaming":

"Your app is nice, but you built it with Python? That's cute. I could implement that in rust and it would be 100 times faster."

("Yes, but your Rust implementation is going to take 5x as long, and no one on our team knows Rust, so we'll have to spend months training instead of adding features")

Our reputations as engineers are our meal tickets. If we feel like our colleagues are thinking less of us because we don't use a "real language", it can drive us to choose languages which are less productive and harder to use, because we believe that:

"ability to work in a hard language" + "creating code that runs fast" = "good at software development"

In reality, the things that make a really good software engineer are much more complicated and harder to measure.

How to approach scaling your project

  1. Accept that most projects/startups fail because the team couldn't build a valuable enough product

    NOT because the product failed to scale. If a product takes off and is successful, money and resources will usually become available to improve it.

  2. Choose tools that are fast enough for the problems that you know you have right now

    Choose tools that are productive instead of fast, provided they are fast enough. Language speed/performance is easy to benchmark. Language productivity is more important.

  3. Focus on creating an excellent product

    Don't focus on scaling, focus on adding features and making the product valuable enough

  4. Avoid coding yourself into a unscalable corner

    When the productivity cost is low, make decisions that will allow for future scaling if needed.

    For example - When building a web app, have user uploaded files stored in an object store, instead of on disk, so your servers can be stateless.

    This will enable server load balancing in the future, while costing very little in development effort (assuming you're using a language/framework with a good ecosystem and library support).

  5. Scale the things that need to be scaled, when they need to be scaled

    When you hit a real performance limitation, or you've accumulated enough concurrent users that your application/service is about to have problems, then you should put effort into scaling.

Hello, world!


My first post on listed. Is this thing on?

class SyntaxHighlightingTest
  def some_code
    puts "How does this look?"