There are three parts to an OKR

• Objective(s). These are concise statements of the goals and intents you want to achieve with your efforts. It’s important to note that each Product Team will likely have multiple Objectives. Objectives are qualitative, specific, time-bound, and measurable goals. They should feel challenging yet achievable. Aim for ambitious goals and occasional stretch goals. And most importantly they should be tied to one of the company level OKRs to ensure your OKR is meaningful to your entire organization. 

• Key Results. 3-5 measurable outcomes that track progress in achieving the Objective(s). Key results are measurable metrics that track progress toward the objective. They provide a clear indication of progress and performance. Key Results are tracked on a per quarter basis and should contribute directly to your Objective.If all Key Results are achieved, the objective is achieved.

• And finally, Initiatives. Initiatives are the individual tasks captured on the Product Team’s roadmap, these include the various deliverables and work products that are necessary to achieve the Key Results.

The definition of the OKRs is the responsibility of the Product Team. The Product Team will discuss possible outcomes they would like to create for our customers and our business. Using Market and User Research Data, alongside technical assessments, the Product Team should be able to provide solid business cases for their Objectives. The Product Teams are also encouraged to validate their OKRs with key customers, especially customers who have made specific enhancement requests.  

While it will be tempting to fit their OKR to cover their current deliverables, each Product Team needs to start the quarter with a fresh point of view on their Objectives. Rather than working backwards from their current backlog, the quarterly OKR process is intended to give each team permission to reassess how they can deliver the greatest value for SnapLogic and our customers. 

3. Initiatives Roadmap - “How, When, and Who”

OKRs focus on the desired outcomes but intentionally they do not delve into specific features, tasks, or requirements which need to be planned and delivered to achieve the desired results; that is where the Initiatives Roadmap comes into the process. 

Note: not all initiatives or roadmap items map to OKRs. Business As Usual (i.e. the normal activities necessary to maintain operations) work does not get codified into OKRs. 

With their OKRs in place, the next step for the Product Team is to agree on the specific initiatives required for them to successfully achieve their Objectives. The Initiatives Roadmap should be used for the sprint planning process by the team. Each Product Team is expected to have 80% confidence in their quarterly roadmap, and 100% in their Monthly release roadmap. Initiatives more than one quarter out will necessarily have lower degrees of confidence but the team should still believe they will be delivered. 

Feature definition is shared between all three members of the Product Team (product management, design, and engineering). Backlogs should be aligned to the Product Team’s priorities and sprint planning should largely focus on how many of the next items can be completed within the next sprint cycle. 

However, playing to the various strengths of the Product Teams members, they should divide and conquer. This will enable the Product Team to work more efficiently with the extended development team and ensure these other areas are included in the development discussion and planning in a timely manner, ensuring everyone who needs to participate in fact does so. Accountability across the Product Team can be summed up as ensuring viability, desirability, and feasibility for Roadmap Initiatives.

• Viability: The Product Manager will confirm both the customer level of interest in committing to buying the new features, including pricing and packages. They will also assess any competitors that are offering or developing a competing solution and assess its threat. The PM will also meet with Product Marketing and Sales to give them an update and to solicit input on items for inclusion in the roadmap. For all customer calls, the full Product Team needs to be invited to attend. 

• Desirability: The Designer will assess the potential impact the features will have on the product’s usability and usefulness in helping to increase user efficiency and decrease errors and rework. The Designer will also check with the design team to review the design patterns and whether any of the proposed features/solutions would be valuable for their products as well. The Designer will also work with User Research to coordinate validating and testing the designs. And to identify any user metrics that need to be tracked for the feature.

• Feasibility: The Engineer will confirm the feature’s feasibility ensuring we have both the means and resources to actually build the feature. The engineers will also work with the other engineering teams to identify any dependencies. Likewise they will coordinate with QA about any impact to their testing frameworks, as well as with Docs to make sure they are prepared. 

Once the Product Team has an initial draft of their Initiative Roadmap, it is strongly recommended they meet with their full development team (all the engineers, QA, Docs, Product Marketing, Customer Support, Sales, Enterprise Architecture, etc.) to review and solicit their input on the prioritization and timelines for delivering the quarter’s initiatives. Additionally any items which span more than one quarter should also be reviewed to ensure there are no surprises later when the Product Team is ready to ship those components. 

There are a number of meetings the teams could choose to have to make sure everyone involved in the product development process is up to date on the strategy and the progress they’re all making toward it. These are the recommended meetings: 

• Discovery Planning - This is where the Product Team will identify which areas they need to Discovery work on to ensure they understand customer needs, market trends/changes, competitive threats, and emerging technologies.  

• Discovery Sessions - These are the actual interview sessions with customers where the Product Team working with User Research learn about their needs, issues, workarounds, etc. 

• Design Session - This is a meeting to work through feature definition and the design details of each feature. This should include the members of Product, Design, and Engineering as all three disciplines need to understand the high level design of the feature from the UI through the Service layer.

• Backlog Grooming - These sessions should focus on making adjustments to the backlog as progress is made and making sure everyone understands what work is coming up next

• Demos - The bookend to the design session, the demos give members of each functional team time to ask questions, identify bugs, and close the loop on the discussions that happened in the Design Session

Note: This is not an exhaustive list and each Product Team can add any additional meetings they feel will help them best achieve their OKRs 

NOTE: If the Product Team has dependencies on other teams to deliver the Initiatives Roadmap, those cross-team dependencies need to be called out both on the roadmap and in the subsequent “big room” Quarterly and Monthly Planning meetings. 

While OKRs are focused within the current quarter, the Product Team’s Initiatives Roadmap should frame out the long-term plan (3 months, 6 months, 1 year, or more), in anticipation of what will need to be built based on the team’s assumptions of where the product needs to be in the next 12-18 months. This longer-term focus will also allow the Product Team to invest in development efforts that span multiple quarters (i.e. updating the project spaces, or rolling out RBAC, etc.) The Product Team’s OKR should reflect the progress they want to make in the current quarter towards the delivery of these longer timeline initiatives, creating a multi-generational approach to planning and execution.

For these multi-quarter initiatives the Product Team will need to track their progress against these efforts as part of their current quarter’s OKR to provide transparency and to ensure cross-team alignment.  

However it is important to note: that nothing on a Product Team’s roadmap beyond the current quarter should be considered as “committed” to either customers or the company. 

Timeline for writing OKRs

4-6 Weeks before the New Fiscal Year 

Putting OKR’s into practice

1. Quarterly & Monthly Planning Meeting

With their Quarterly Theme and a well articulated set of OKRs, the Product Teams no longer need to walk through their detailed roadmap during the Quarterly or Monthly planning meetings. They can focus on the high level Objectives they have given themselves, and discuss any cross dependencies they may share with other Product Teams. For the first meeting of the year, the Product Teams can also introduce or reintroduce the full development community about their Vision and their Annual OKRs as well. 

During the course of the year, if a Product Teams is compelled to make any corrections or adjustments to their plans, they can review their updated plans with the full development community, to help ensure alignment and transparency. Likewise, any impact these changes have on the shared engineering resources will need to be discussed. 

2. Escalations

If at any point either in planning their quarter or during the quarter, a Product Team has an unresolvable conflict, the team should immediately escalate to leadership (i.e Mark, Anju/Greg/Jump/Nitin, Anjana, Matthew) to seek assistance in resolving the matter. If those people are not able to resolve the issue, then it will be escalated to Jeremiah & Krishnan. It is good practice for a Product Team to discuss in detail situations which would lead to escalation, and even set up an escalation prep “practice run” with relevant leadership to ensure mutual understanding and comfort with the process - escalation is not a negative event or word, it is a normal part of trying to do hard things in a dynamic organizational environment! While it is noble to handle our own issues, sometimes we all need help to successfully overcome obstacles or benefit from mediation in high-value and contentious debates.

3. Reevaluation

Product development is not an exact science: issues arise, customer escalations come in, security risks emerge, the sales team will make feature requests, a competitor releases a new product, etc. Any number of scenarios could either distract the team or shake their confidence in their plans. 

Teams are encouraged whenever possible to simply say “thank you, but not right now”. If that is not an option, whether it’s a change to their quarterly Initiatives Roadmap or their OKRs, if the Product Team feels a change is required in order to allow them to better support the Company’s OKRs, they can at any time reprioritize.  

For changes to their Initiatives Roadmap each Product Team is empowered to determine what to build during the quarter to best meet their OKRs. This also applies to initiatives that span multiple quarters, if those larger efforts need to be elevated the Product Team is free to do so. 

For changes to their OKRs, given OKRs are cascaded, any changes may impact the ability of Design, Product, and Engineering to deliver their OKRs’ on behalf of the company, the Product Team will need to set-up time with leadership to review their situation and get approval for their proposed OKR changes.

In both cases, the Product Team will need to communicate a very clear and specific description of the changes, including any impact the change(s) will have on other Product Teams, and all their stakeholders including QA, Docs, sales, customer support, Product Marketing, etc. 

4. Reporting

Every week each Product Team will provide an update to their OKRs via 7Geese noting whether the OKR is on track to attainment of 90% progress by the end of the quarter and documenting the current state of progress. If there are any issues that require escalation to leadership, the Product Team should send an email to the leadership with their summary, and plan of action for resolution. If a meeting is required to discuss any issues, realign resources, etc. the Product Team is responsible for setting the meeting and facilitating the desired outcomes. 7Geese OKRs will be rolled up to e-team in weekly Plan, Progress, Problems (PPP) documents.

At the ground level, feature definition should be shared between product management, design, and relevant engineers. Backlogs should align to the order of priorities on the roadmap and sprint planning should largely be about how many of the next items can be taken off the top of the stack. There are a number of meetings the teams could choose to have to make sure everyone involved in the product development process is up to date on the strategy and the progress they’re all making toward it. These are recommended, this is not an exhaustive list:

• Design Session - This is a meeting to work through feature definition and the design details of each feature. This should include the members of Product, Design, and Engineering as all three disciplines need to understand the high level design of the feature from the UI through the Service layer.

• Backlog Grooming - These sessions should focus on making adjustments to the backlog as progress is made and making sure everyone understands what work is coming up next

• Demos - The bookend to the design session, the demos give members of each functional team time to ask questions, identify bugs, and close the loop on the discussions that happened in the Design Session

5. Retrospective

At the end of the quarter, the Product Team needs to schedule time to review their overall product vision, as well as the Theme, OKRs, and Initiatives Roadmap for the quarter. They should take a clear and objective look back to see if there are any improvements they could make to their process, changes they should consider who’s included, their evaluation criteria, their overall approach to planning their roadmap, etc. And they should share any of their learnings with their larger team and with the other Product Teams as well. 

This is also a natural segue for the Product Team to begin planning their next quarters OKRs. Which they need to have ready two weeks prior to the start of the next quarter.