OKRs
  • About OKRs
  • The market
  • Why build ourselves?
  • Product philosophy
  • Product Decision Record
  • Key milestones
  • Features
    • OKR Unit
    • OKR Views
    • Default Sorting in views and Filters
    • OKR details page
    • Filters
    • Notifications
    • Move and Paste feature
    • Personal Starring ⭐️
    • Due date as an attribute
    • Cloning OKRs to a new quarter
    • Help Section
    • OKR dependency resolution
    • Drag and Drop (Upcoming)
    • Visibility control 🔒
    • Admin Page (Upcoming)
    • Search
    • Sort feature
    • Slack Integration
  • Key Documents
  • Data Strategy
    • Success Metrics
    • Reporting/Metrics Dashboard
  • Program Management
    • Team
    • Working Principles
    • Toolkit
    • Meetings Schedule
    • Product Roadmap
    • Release notes
  • Major links
    • Project Board
    • Design Mockups
    • Feature Discussions Document
    • xto10x Google Drive
    • xto10x Wiki
    • xto10x Slack
    • Staging (OKR tool)
  • Templates
    • Document Template
    • Voice and Tone
Powered by GitBook
On this page
  • Simple is better than complex
  • Lean is better than heavy
  • Mainstream is better than special
  • Familiar is better than new
  • Comparable is better than stand-alone

Was this helpful?

Product philosophy

Ethos of the OKR product and the core philosophy that informs its design.

PreviousWhy build ourselves?NextProduct Decision Record

Last updated 5 years ago

Was this helpful?

Simple is better than complex

The temptation to add more information to help the user make decisions is hard to resist, but it often ends up working against the user. Provide all information that is needed to make decisions, but no more. In the battle between richness and simplicity, bias towards simplicity.

Lean is better than heavy

Nothing renders products more unusable the way feature creep does. The answer to every new problem need not, and should not, be a new feature. Converge all solutions to the minimum number of solutions possible. Design a new feature only if a problem cannot be solved by a feature that already exists.

Mainstream is better than special

Avoid power features as much as possible. If a majority of your users are not going to use it, it’s probably not worth it. Think twice before working on a power feature. If the holds true i.e a feature that might be used by just a handful of users, but it might take a majority of development time, it’s probably best to leave it out.

Familiar is better than new

The interface should not feel alien to the user. It should create a sense of familiarity and connection the first time the user sees it. A good approach might be to leverage the familiarity of an excel sheet, something most companies already use to manage OKRs.

Comparable is better than stand-alone

OKRs by their nature are dependent on multiple other OKRs. Being able to compare the impact of one OKR on the other is quite important for clarity and prioritisation.

Pareto Principle