Source: Why and how: Long term product goals
Author: Allan Kelly
Section: 5 — Benefits, time horizons, and keeping goals alive
Reading time: 6 minutes
Tags: goal-benefits right-to-left-planning short-vs-long-term goal-cadence goal-change-signals shared-understanding stakeholder-alignment product-goal-review quarterly-vs-annual ideas-in-heads-not-paper
Summary: Kelly outlines the benefits of product goals for teams, management, and stakeholders: shared understanding enables coherent decisions, backward planning from the end state, and measurable progress. He recommends keeping long-term goals deliberately vague beyond 6 months, and warns that frequently changing goals signals poor strategy, not a changing environment. The true output of goal-setting is the idea in people’s heads, not the document on paper.
Benefits
There are multiple audiences for these goals: the build team, management, possibly actual customers, and many stakeholders.
Within the team building the product these inform the decision making. When any product is created, even updated, there are a multitude of decisions that need making. The big decisions will be discussed and maybe agonised about for weeks. But every day thousands of small decisions are being made by individuals.
Decisions are informed not just by the immediate ask in hand but by common ways of doing things, explicit standards and rules. Many of the small decisions will be made quickly by the person doing the work. Especially when a team or product is new, it is important to establish a common understanding. The more a team have a shared understanding the more coherent the decisions will be. Creating a common, shared, understanding of the desired outcomes will go a long way towards helping consistency in those decisions; and hopefully, accelerating decision making.
Then there are those outside the immediate team - stakeholders. Some of these may exercise power over the team, e.g. budget holders, while others are on the receiving end, e.g. users and customers. These people will have their own questions because what you are doing impacts their own decision making.
Having a shared understanding of where the product is going, and what it can do, benefits everyone. It is also the start of the planning processes. As Steve Covey (Covey, 1992) would say “Start with the end in mind”.
Knowing the end allows backwards planning - also called right to left planning (Burrows, 2019). When the end position is unclear planning can become a “kitchen sink” as everybody adds to the plan the things they think need to be done. Without a clear end state, it is difficult to turn requests down.
When the end is known, the question becomes “what do we need to do to create that end result?” This makes it easier to determine what is truly needed and what is superfluous.
Then, when work does commence, knowing the end state makes it easier to measure progress. Rather than progress being measured by “what was done” progress can be measure by “how close are we to the objective?”
That said, once those differences have been explored and exploited, the final documents should be consistent. It is here that the Product Leader must come
into their own and, if necessary, make a decision one way or the other. Discrepancies and contradictions in the final output will undermine the shared understanding and benefits.
How short is short? How long is long?
Thus the question: when is the short-term/long-term cut-off point?
Let me suggest that cut-off point is going to depend a lot on the circumstances you find yourself in. One year might be a one time, or it might be short term if you are thinking about needs in 5, or even 10, year’s time.
Personally, I would shy away from having anything beyond the next six months described in too much detail. A six-month time frame more than covers the current quarter and allows for adequate discussion over the quarter after. Beyond that everything is yet to be decided.
If you spend time specify an objective in great detail now, but work will not begin for another six months, and completion will not be for nine months then there is more risk that things will change. Maybe the customer will change their mind, maybe the technology will change, maybe world events conspire to change what is needed. Or maybe, the work that is done in the next six months will render the 6–9-month objective meaningless.
Whatever the time frame used, the intention is to have:
One solid, quantified, objective with key results to target by the end of this period. Typically, this is 12 weeks, three months, one calendar quarter.
Another longer-term goal, which might be called a Product Goal, True North, North Start, or any other name you desire. This goal need will not be quantified. This might be one year hence or five years.
At some time during the current period, you will want to begin discussions on the next objective (and key results) for the coming period. The later this is decided the more time there is to learn (about the technology, customer need and what will be achieved this period) but, since many organizations will have some review and approval process this probably can’t be left till the last minute.
You may also choose to have a rough idea of what goals you will aim for in the period after the next one. Any such schedule should be deliberately vague and rolled forward each quarter. This is intended to promote conversation about what might be, it should not be considered promised, agreed, certain or written into contracts.
KE Exercise
Decide how long the short-term and long-term horizons are for your product. If you haven’t already sketch a cadence calendar showing what update rhythm you would like your product to follow.
And if it changes?
Of course, something might happen to invalidate the long-term goal or the short-term objective. One should never close one’s mind to the idea that the goal was wrong or out of date. However, if these thoughts dominate, if the team process and routines are oriented around the possibility that things might change, then it will be harder to make progress.
Building in periodical reviews - at the end of each cycle - and delaying short term objective setting then the problem of changing targets should be reduced. However, if cycles are being regularly disrupted, or goals is changing often (say twice in one year) - then something is wrong.
Perhaps strategic thinking is missing or is being done poorly. Or perhaps the environment is genuinely changing rapidly. In my experience the latter reason (change) is often given but in truth it is the former (poor strategy) that is usually the case.
Either way, it would be wise to consider how goals and objectives could be said to reflect the changes. Look for the goal behind the goal, what is the aim of changing? what is the bigger goal that is remaining constant as people run in new directions?
Conclusion
The aim of creating short term objectives and long-term goals is to fix the idea in peoples’ heads. Thus, the true output of the goal setting process is what is in peoples’ heads not what is on paper. The words on paper are less important than the ideas inside heads.
None of these techniques is intended to produce a shopping list of features, a backlog of stories, a requirements document, a PRD, or even a business case. They are both intended to be short - 2 pages absolute max! - and more emotional. These techniques aim to envisage the future, not cataloging it.
As you work towards your desired end remember to revisit the goal regularly and ask yourself “are we advancing?” Obviously if you are setting (and
delivering) against quarterly specific objectives you will want to review the goal every time you come to set new objectives.
And remember what Jeff Bezos said: be flexible on details. No feature or function is sacrosanct. Regularly revisit what is needed.
KE Share
Share your answers to the exercises here on the KE.
Once posted you will receive comments and feedback – plus you will be able to learn from other’s exercise results.
References
Burrows, M., 2019. Right to left. New Generation Publishing.
Christensen, C.M., Anthony, S.C., Berstell, G., Nitterhouse, D., 2007. Finding the Right Job For Your Product. Sloan Management Review 48, 38–47.
Covey, S.R., 1992. The seven habits of highly effective people : restoring the character ethic. Simon & Schuster, London.
Kelly, A., 2023. Succeeding with OKRs in Agile, 2nd ed. LeadPub / Software Strategy.
Monarch, R., 2019. PR FAQs for Product Documents. Agile Insider. URL https://medium.com/agileinsider/press-releases-for-product-managerseverything-you-need-to-know-942485961e31 (accessed 9.9.26).
Moore, G.A., 1999. Crossing the Chasm. Capstone publishing.
Peters, T.J., Waterman, R.H., 1991. In search of excellence. Harper Collins Publishers.
Rumelt, R., 2011. Good Strategy/Bad Strategy: The difference and why it matters. Profile Books.
Sutherland, J., Schwaber, K., 2011. The Scrum Guide: The Definitive Guide to Scrum: The Rules of the Game.