Simple Sells — How to Build a Simple Product

Engineers tend to over-engineer. In fact, everyone else does too, especially at the beginning of their careers. Founders can easily fall for the ideal of an elegant solution before getting close to product-market fit.

Complexity is an insidious, often self-imposed blocker — examples:

  • “I’ll write more once my blog is set up perfectly.”
  • “We’ll build one more must-have feature before we launch.”
  • “Once we redesign our deck, I’ll be ready to really start fundraising.”

Thoughts like these are completely rational and easily justified. Competition is fierce in startup land and the urge to improve before launch is very strong. It’s simple self-preservation. But it’s also holding us back.

A simple solution is the most difficult to create. It’s hard to translate a thought into simple writing your audience will understand. It’s difficult to write a catchy song. It’s damn hard to create a design for real-world processes.

What is simple?

How do I define a simple thing?

Simple means it easy to create, duplicate, change and understand. Easy to understand without any need to know the outside context.”

Basically, a simple thing does just what it should and nothing more. And to be easily understood, it should look very similar to other things that serve similar functions.

So how do we make simple products? Here’s a simple checklist to start:

  • Follow strong conventions and stay consistent
  • Add very few or no dependencies
  • Unify data-flow
  • Describe what you do in familiar, known terms
  • Offer the smallest option set possible

What is complex?

What disrupts the simple solution you set out to create?

Once you introduce an uncommon name or term, or change the data-flow in the middle — complexity creeps in.

Once you use an extra variable, function, abstraction — you force other people to spend their cognitive power to understand your idea. Once you add an unnecessary dependency you make it difficult to change in the future.”

Once you engineer an unnecessary optimisation — or worse, caching — you’ve created legacy that will need to be supported.

Now your simple product is no longer — now it’s a complex, opinionated process that limits your options going forward. To iterate from a point of complexity, you need to observe and monitor the whole system from the outside — instead of keeping yourself in a small piece of the puzzle.

Creating and defining a process that anchors towards simplicity is very hard. But tending towards complexity is remarkably easy.

Tech is complex by default

Legacy higher education systems define technology as an end goal of a process where technology is involved.

It kind of makes sense — the core technology problems are extremely complex. These problems include scalability, data consistency and isolation, network partitioning, fault tolerance, etc.”

Scientists and engineers address these core problems with abstractions, data structures, programming paradigms, patterns and more. A new engineer may look at any problem and think they need to solve it all the way down to these core levels. But that’s completely unnecessary!

Understand, but bury, that complexity.

For a new product, invention is not the goal. If something works, there’s no need to create a new solution from scratch.

Every problem that has multiple practical applications is already solved, you don't have to approach it as if it's a new complex problem. You need to understand how it already works and apply it. Better yet — simplify it by removing extra functions to better suit your needs.”

How simple happens

Experience is a filter from tech complexity to product simplicity. With every application of a given solution or tech stack to another problem, you gain a better understanding of the complexity underneath.

So simple becomes context-dependent. Examples:

  • Simple, rapid problem and idea validation process that relies on the story + a nocode website to gain early adopters.
  • Ready to deploy product management templates in Notion. A familiar, performant solution that founders already love.
  • Being involved in product idea sprints. Trying new roles within small product teams increases understanding of customers and breaks down communication barriers.

If you’re a founder who wants to build a product, our goal is to simply discover the right product. That’s the end goal — technology is just a powerful tool.

Inventors create simple solutions for difficult problems. Focus on the value you create first and don't make simple things difficult.”
You might also like
Communication breakdown: why teammates disagree and how to reach consensus faster

Communication breakdown: why teammates disagree and how to reach consensus faster