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
  • Affordable
  • Reliable
  • Better

Was this helpful?

Why build ourselves?

The OKR SAAS market is filled with competition. Yet, we chose to build our very own tool. Why?

We want to build a tool that is -

Simple

Most of the tools out there, offer a lot of overwhelming features. While valuable, those features often come in the way of using the software. Implementing OKRs properly is hard enough. We did not want to build a tool that makes it harder by asking the users to do more than what is absolutely necessary.

Affordable

The startup ecosystem in India cannot afford to pay for software that costs upwards of USD 5 per user per month. We want to build a tool that is affordable and accessible for all.

Reliable

OKRs once adopted become the backbone of an organisation's strategy. Building a tool that can be relied upon as a single source of truth requires a mindset that is currently not reflected in the tools out there.

Better

Partnering with an existing provider would not afford us the opportunity to learn and improve the tool according to the needs of our users. To serve the ecosystem well, we need a handle on what features to build, but more importantly what features to keep out. Building an opinionated tool that does not do everything, but only a few things extremely well requires a kind of control that only comes with building it yourself.

PreviousThe marketNextProduct philosophy

Last updated 6 years ago

Was this helpful?