Build simple first
An engineer built me something with “tons of features” so I could tell him what was good or bad. It was so confusing and dirty. Think multiple login types, four different ways to view the same feed, multiple ways to take the same action, dropdowns, account management, light and dark mode, etc.
When there are too many features, you can’t tell what is good. You can’t tell what is distracting people and pushing them away, or more importantly, what makes them stay. We should build simple first and earn complexity.
Too many features hide what’s good
Most features don’t get touched. In 2019, Pendo looked at feature usage across 615 of its customers’ subscriptions and found that users rarely or never use 80% of the features in the average software product. Just 12% of features generated 80% of daily usage.
More features also mean more choices for the person using them. Hick’s law says the time it takes to make a decision increases with the number and complexity of choices.
AI makes bloat easy
AI makes it easy to bloat. As good product engineers, our job is to keep things simple and straightforward, not all razzle-dazzle.
Ask an AI for a “cool new feature” with no guidance and you get extra buttons, near-copies of pages you already have, and a summary page with no use to the user.
The new shiny toys look like dashboards nobody reads, a chat assistant bolted onto every screen, and settings for everything. Really, if it’s not needed for minimum viability, try and keep it out of v1, unless it’s a major quality-of-life improvement.
Build an MVP first
The thing to build first is an MVP, delivering a solid, valuable outcome with the simplest of inputs and outputs.
Eric Ries defines the minimum viable product as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
Least effort, most learning.
Finding what makes people stay
Finding what makes people stay comes down to three habits.
Watch real users. Sit with them or watch their sessions, and see where they stop.
Pick one number that means value, and watch it move.
Use it yourself. Spend time in your own product, and find the friction spots and the distractions.
When you have earned complexity
You have earned complexity when users keep asking for something, when the number you picked moves, or when people are already hacking around the gap. Any of the above, really.
Typically you’ll know when something needs to be added, especially if you’re eating your own dog food and using the product yourself.
Why starting complex is the worst thing you can do
The worst thing you can do is start complex and then not understand your own application intimately.
When you don’t understand your own application well, you’re more of a user than the creator. The spark that led to solving the problem gets lost in the noise, and making the right adjustments becomes difficult.
A chemist who’s only ever walked into fully functioning labs with a nice set of instructions would have trouble creating his own lab and creating his own experiments.
This knowledge is hard won. It’s what really makes things valuable, not being able to just meat-puppet an application to life.
Earn complexity.