---
# System prepended metadata

title: Notes for planning docs / workflows / OKRs

---

# Notes for planning docs / workflows / OKRs

Purpose of planning documents:

1. Firstly, creating the document acts as a brainstorm session for team members and helps to define the work that needs to be done for the coming Qs. Feature/Product direction should ideally come from executive management and product council (based on user research/interviews and requirements gathering/business development)
2. Alignment of goals across teams/orgs (sharing road maps)
3. Act as a north star during the Q. Semi regular check-ins enable the team to reflect on the work they are doing and to ensure that they are on track / focusing on the right things. 
4. Provide visibily to executive managemnet on each teams progress and goals for a particular timeline. 
5. Provide visiblity to external teams (in the open source community)


Tendermint / Hub Approach (More focused on workflows than OKR style)

Positives:

- I like the way that the epics first acknowledge the user concern for each feature.
- Each epic has a performer / champion which helps with accountability
- I like the seperation of the (user) result and the expected (perfomer) activities. I think this helps to frame the conversation in the context of requirements gathering
- I think having a longer timeline (not just one Q) helps to provide long term vision and direction. Not all projects can be completed within a single Q. 
- The template allows for a larger vision and I can see how using this model can help integrate several teams into the planning process (internal/external/open source community etc)


Negatives:

- I found some sections a bit wordy and overall the documents are a little bit tough to parse initially. You need to spend some time going through it as there is a lot there. 
- The activies/results are mostly binary in terms of measuring completion. Something is either done or not done. This makes it more difficult to do check-ins and does not provide much visibilty in terms of progress. 


IBC approach (OKRs)

Positives:

- Minimalist and easy to parse. The Objects are direct and the key results are concrete tasks achievable within a Q. 
- Because of the minimalst approach the OKRs can be written in a single day (1 or 2 sessions)
- Key results are measureable with percentages. The OKR philosophy is 70% is considered a success. This makes it easy to track progress and do semi regular check-ins

Negatives:

- OKRs lose perspective on the bigger picture and longer term goals (6 months+)
- Not much visibilty on the user problems being solved or the end result (the result for the user not the expected activities) 

