Product Decision Record

A record of major product decisions along with context within which they were taken.

Ownership is held by a single individual.

Context:

Although OKRs are often taken up by teams or departments, it is recommended that there should be a directly responsible person for each OKR. The owner should have complete control over the journey of her OKR, while ensuring that the owners of OKRs who might be affected are kept well informed and upto date.

Decision:

Ownership is held by one person, and one person alone. Changes cascade upwards and sideways to other owners whose OKRs might be affected in turn.

Status: Accepted

Every OKR is traceable to the highest level possible.

Context:

Best Practices followed by companies worldwide mandate that the majority of OKRs (if not all) should be derived from and aligned to the company's top 3-5 priorities. In an ideal world, every person's OKRs should contribute to the company's direction. That said, there are often maintenance and hygiene OKRs that do not align to company objectives, which also need to be accommodated. Hence the tool allows for creating an independent objective.

Decision:

The tool helps the users see the contribution of their OKRs to their parents, siblings and overarching company objectives.

Status: Accepted

Dependencies are linked between OKRs.

Context

OKRs are often dependent on other OKRs. Without linking, it is hard to plan capacity and break functional dependencies.

Decision

The tool allows linking of OKRs as dependencies.

Status: Dropped for MVP

OKRs are actively accepted or rejected by owners.

Context

No OKR should be dumped on an individual. The assigned owner should have a strong say in accepting or declining an OKR. A “good no” is better than a “bad yes”.

Decision

The tool facilitates the ability to accept or reject an OKR request.

Status: Accepted

OKRs can be edited by owners and parents.

Context

In an ideal world once OKRs are accepted, the targets should not be moved. However, in the real world, targets do move, and OKRs do change.

Decision

The tool facilitates editing OKR's at all times, but it also surfaces the change quite strongly. Additional friction in the form of conformation dialogues is also added.

Status: Accepted

Orgs reflect on OKRs from the past to improve themselves.

Context

OKRs feed into learning and performance management: Learning from OKRs becomes a way of life in the company; the track-record for each team or individual becomes an input to the performance and feedback process.

Decision

The tool captures learnings and reflections for view by the organisation when an OKR is closed.

Status: Accepted for MVP, but needs further validation.

OKRs are estimated by effort and stack ranked by teams.

Context

In order to facilitate prioritisation, teams should stack rank OKRs in the order of importance. Furthermore, teams should allocate effort to each OKR.

Decision

The tool allows effort estimation for each OKR, and moving OKRs up and down so that they can be stack ranked. This leads to a non-hierarchical flat view.

Status: Dropped for MVP

A parent's Key Results show up as Objectives for the child.

Context

Each OKR has a defined owner. When a KR is owned by an individual, it becomes their Objective in principle. This way OKRs branch out from company Objectives. The KRs for the company Objective become the Objectives for the KR owners. These Objectives are further broken down into KRs, which become Objectives for someone else. The logic continues till the point a KR cannot be broken up further.

Decision

The nomenclature assigned to each OKR is relative, not absolute. The owner (parent) of an Objective can assign KRs to her subordinates (children). In her view, she sees them as KRs, but in the subordinates' view they show up as Objectives.

Status: Accepted

Users can subscribe to an OKR and follow it

Context

A user's OKRs might be affected because of an OKR she does not own or is a contributor to. The ability to keep track of such OKRs might be important.

Decision

The tool facilitates the ability to follow an OKR as a subscriber. This way any updates about that OKR can be relayed to the user through notifications.

Status: Dropped for MVP

User roles and permissions

Decision

The tool will support three types of user roles — Owners (super admins), Admins and members.

Administrative roles

Owners (Super admins) — Description here

Admins — Description here

Non-administrative roles

Members — Description here

Pending members — Description here

The following table shows the types of users and their respective team management privileges

	Owner (Super admin)	Admins	Members
Make admin	Yes	Yes	No
Revoke admin rights	Yes		No
Remove members	Yes	Yes	No
Remove admins	Yes		No
Transfer Owner role	Yes	No	No
Invite new members	Yes	Yes	No
Change workspace/company URL	Yes	No	No
Manage billing	Yes	Yes	No

Teams and team management (Deprecated)

Context

Teams reflect the organisational structure of the company. Any member of the company can create a team and add people in it. In the Teams OKR view, OKRs are classified based on the teams that a person is member of.

Decision

A team will have an owner (original creator by default) that has full control over that team. A non-member can request to join a team. Once added as a member, they can add other members, as well as remove them.

The following table shows the types of users and their respective team management privileges

	Team owner	Team members	Team non-members
Join team	—	—	Must be added
Leave team	Must assign another owner first	Yes	—
Add members	Yes	Yes	—
Make team owner	Yes	No	—
Revoke team owner rights	Yes	No	—
Remove members	Yes	Yes	—
Edit/Delete team	Yes	No	—