ISSUE #13 - JANUARY 24, 2023
Thoughts on goal setting, planning, and opportunism
In this post, I am sharing some thoughts on my OKRs and how they look like, planning and the time horizon of early-stage roadmaps, and opportunism when it comes to product and team resources allocation.
A few weeks ago, most product teams set their objectives and formed roadmaps for the ongoing quarter. This process took significant work for product managers, engineers, and anyone involved. Regardless, a part of those plans will never be implemented, and some of those objectives might not be hit. As most of us have experienced in the past, this could happen for various reasons, such as unforeseen obstacles, a change of priorities, or simply bad planning.
For the past few weeks, I have been reflecting on this and decided to put together some thoughts in this post.
How should my OKRs look like?
OKRs have always been my framework of choice when it comes to setting objectives. I like the way in which they give structure and clarity to the team. When done correctly, they can seamlessly answer to anyone in a product team why we are doing what we're doing.
Something that I always tried to do with my OKRs is that I wanted them to be results-oriented and not project oriented. Meaning that I always pushed for a key result to be like "increase metric X by Y%" and rejected one that would like "deliver feature Z by then." I recently changed my mind and decided to embrace delivery-related OKRs occasionally.
The reason behind this is that whether we like it or not, there are cases where delivery is what matters the most. For example, a feature might be a prerequisite for closing an enterprise sale. Or you might have to meet a compliance deadline. In such cases, setting a delivery-related OKR will give the team the necessary focus and point out the importance of the task.
However, OKRs of this type should have two things: Firstly, the deliverable should be well-defined. Secondly, the deliverable should always be accompanied by a delivery deadline, and this date should be realistic.
How long should we be planning for?
For most of my career, I have worked in early-stage companies, so I am no stranger to frequent alterations and plan changes. Especially at the early traction or pre-PMF stages, planning could be a real struggle. It involves estimations and predictions for the future, things people are not great at by definition.
I have found that most early-stage companies prefer to plan in quarters, but I have wondered: Why do we prefer to plan for this time horizon? In my experience, the plan will hold for approximately the first half of the quarter. Then, for the second half, lots of the items that will take place will be different than those initially planned. This should not come as a surprise. The earlier you are, the less you know about your customers, their needs, and your market, hence the biggest the uncertainty. Consequently, you cannot plan for really far into the future, at least not without transforming your planning into guesswork.
Breaking the mental barrier of the quarter, meaning that you no longer plan for the next three months but for as long as the items you are confident enough will last, is liberating both for the product manager and for the team as well. If what you have validated as valuable projects that will help the company meet its objectives last for thirty days or a bit more but not for a whole quarter, that's fine. Instead of twisting your head to fill in the rest of the roadmap with items you're highly uncertain about, get out there and work on discovery so that you come back later and fill in the rest. There is no point in struggling to create a complete roadmap with items that most likely will be dropped in the future just to conform with the "quarterly plan doctrine."
How opportunistic should you be when it comes to your team resources?
Here's the case: There's this fantastic project or this promising partnership that just came up and only requires a small integration and could have great potential for the company. What do you do? Will you make some space in your roadmap (by eliminating something of potentially lesser value), or will you pass?
As a product manager, you will be frequently asked to make this decision. And the upside will always seem great. In the era where being agile rules, it's always tempting to change your plan and gamble a little. However, resources will always be scarce, and if you constantly take bets, you will end up not doing what actually matters. You will have to accept that you can't do it all, and there will be opportunities that you'll have to let go. So, how do you decide which to take and when to pass?
After being falsely opportunistic a few times in the past, the heuristic that I created is this: Firstly, I will not take a bet unless I will earn even something small, in the case where the bad scenario plays out. For instance, in a scenario where a feature will not succeed, it will lay the groundwork for something else that we were, either way, going to implement in the future. Secondly, taking this bet should not jeopardize something of strategic importance.
Closing
Well-thought-out objectives and good planning lay the ground for efficient teamwork and, most importantly, adding value to the broader company goals. However, we occasionally get ourselves into boxes, either out of habit or to comply with the theory or an industry standard. Sometimes breaking out of these boxes is the key to being more impactful and delivering better results.
Past Newsletters
ISSUE #12 - DECEMBER 15, 2022
Product Lessons Learned in 2022
Ten product leaders from US, UK and Greek startups, scale-ups and Big Tech share their greatest learnings for the past year.
ISSUE #11 - NOVEMBER 14, 2022
Creating an experimentation-driven product culture
How to create an experimentation-driven culture within your product team? What are the steps to set this up? How to manage & prioritize your experiments?
ISSUE #1 - JANUARY 4, 2022
My year in books
Read through my reviews of the books that I read during the past year. Some of them are "must-reads", some of them I trash. The topics vary across..
The Product Notebook by Manos Kyr.
Once every month, I’m sharing my thoughts on product, growth & entrepreneurship.
Copyright © Manos Kyriakakis