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?
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 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.
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.
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.