I recently cleaned up Operately's issues (now all public). Split them into bugs and papercuts.
I've seen many teams use "major", "minor", etc for bugs. But what does that really mean? We prefer more specific terms.
There's a big difference between:
❌ Something that should work but doesn't
🚧 Something that's just unfinished or crude
Calling every little issue a "bug" in a new product is demotivating.
Hence, papercuts.
Papercuts are small annoyances. Things like:
- Usability quirks
- UI inconsistencies
- Any little thing that frustrates users
Like, "posting a comment on a goal update should generate a news feed item". Sure, it should. But we never implemented it. We will get to it, though.
On their own, they seem trivial. But they add up fast.
So of course, in theory you want to fix all your papercuts. Your product will feel smoother. Users will be happier.
In reality, Operately is still in alpha stage and we have to balance feature completeness with a high enough quality to meet initial user expectations and validate it in the market.
So for now the strategy is, we'll trim them to the level that we estimate is acceptable.
If you read this this far 🫶 -- how do you handle bugs and papercuts in your projects?
Top comments (0)