A quick checklist to help engineers get to simple when designing a product feature. AI code generation tools are lifting the burden of execution, which means engineers must be even more careful in deciding what to execute on.
Core Checklist
| Category | Questions |
|---|---|
| Sufficiency Test | • Does the basic version actually solve the problem? • Would users pay/use it without the extra polish? • Can you ship it today and add polish later based on feedback? |
| Polish vs. Core | • Is this feature core functionality or nice-to-have UX? • Will 90% of users even notice this refinement? • Does removing this change the value proposition? |
| Timing | • Are you polishing before validating product-market fit? • Could you be learning from users instead of perfecting in isolation? |
| Scope Creep Signals | • Did this requirement emerge during build, not before? • Are you solving hypothetical future problems? • Is “while we’re at it…” driving decisions? |
| Ego Check | • Are you building for your portfolio or for users? • Would you be embarrassed to ship the simpler version? • Are you over-engineering because it’s more fun? |
| Hard Rules | • Ship the ugliest version that works • No edge cases until the main case is validated • No “delight” features until core problem is solved • Stop when it works, not when it’s perfect |
Additional Checks (Based on Experience)
Not mentioned above, but stuff I have noticed on the job.
- Do we already do this elsewhere?
- Is it sensible to build on the foundations we’re proposing?
- Does it require a lot of time commitment but have comparatively low conviction?
- Is there a hackier way to achieve this in the short term?