large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

From Design System to ‘NFT Design System’: Creating TinyFaces

Neurodiversity and Inclusion: Choosing Kinder Design

medium_652ccf22c8853584bde5553986a4eed0.png

small_652ccf22c8853584bde5553986a4eed0.png

thumbnail_652ccf22c8853584bde5553986a4eed0.png

Web5 is here. Goodbye Web3? TBD.

Published on <a href="https://blog.prototypr.io/okrs-are-not-roadmaps-part-2-ef9efaf76a53?source=rss----eb297ea1161a---4">| Prototyping: From UX to Front End &mdash; Medium</a> Andy Ayim <img alt="" src="https://cdn-images-1.medium.com/max/1024/1*xgjL9mXg5OYF9SNqia-NUw.jpeg">
In my last article I introduced a way for Product Teams to wean Senior Management off Roadmaps (<a href="https://blog.prototypr.io/an-alternative-way-to-run-product-teams-part-1-f67a5d610c22">read here</a>). One of the hardest struggles to overcome (if at all possible) as a Product Manager (PM) is to deliver business value in an organisation in the absence of an overarching business strategy.
It is a tough pill to swallow when you join a company without a clear business strategy and therefore no guiding principles to inform a product strategy.
<blockquote>Obsess over customers, not competitors</blockquote>
Business strategy should cascade down to inform business unit strategies. OKRs are a brilliant tool for cascading strategy throughout an organisation whilst maintaining a golden thread to the overarching goals the company is trying to achieve.
<img alt="" src="https://cdn-images-1.medium.com/max/751/1*6jWjWMJ3SE8ULog-A4mSWA.png">Cascading Strategy
OKRs originated from Andy Grove at Intel but were popularised in recent years by tech giants like Google. It is based on two basic principles:
<ol>
<li>Tell people what you need them to achieve</li>
<li>Agree on measurable outcomes, not outputs</li>
</ol>
OKR’s are formed with qualitative objectives and quantitative results. A company could have an annual OKR that says:
Objective: Grow the eCommerce business in the UK
Key Result: Grow UK revenue by &gt; 15% in the next 12 months
A Product Teams quarterly OKR that ties to this could be:
Objective: Increase UK revenue on mobile
Key Result 1: Reduce checkout basket abandonment by 5%
Key Result 2: Increase basket size by 2%
Key Result 3: Increase repeat purchase in 30 days by 10%
At the end of each quarter, performance should be graded by the following scale:
On a scale of 0–1.0
<ul>
<li>0 = no progress</li>
<li>0.3 = accomplished the bare minimum but did not meet the key results</li>
<li>0.7 = achieved our key result</li>
<li>1.0 = accomplished more than anyone had hoped for e.g. revenue for UK grew by 10% in one quarter alone</li>
</ul>
A word of warning, when setting product OKRs it is important to ensure there is agreement with relevant stakeholders around the business e.g. Chief Revenue Officer so that the bar isn’t set too low or unrealistically high. That way you will get true value from scoring at the end of each quarter.
One of the main reasons I am a fan of OKRs over roadmaps is that they align with shareholder value. The Board of Directors care about company results and hold the C-suite accountable to agreed upon goals within their annual strategy. Therefore OKRs as a framework align with Board expectations. The Board do not communicate with the CEO with a roadmap. Secondly it drives accountability and the autonomy for the Product Team to achieve their objective in the best way they see fit. Roadmaps are often output focused with features to be delivered by a given timeframe.
Finally, OKRs encourage the right behaviours by focusing on outcomes rather than outputs. This is critical for business success. It is the difference between an eCommerce site focusing on sales over traffic. In the same way a PM should be focusing on goals over features.
In the next post, we will explore how to translate OKRs into Product Discovery and why this is needed before we write a line of code.
Credits: Marty Cagan from the Silicon Valley Product Group, he taught about this in practice!
<h4>Learned something? Click and hold the 👏 to say “thanks!” and help others find this article.</h4>
<iframe src="https://cdn.embedly.com/widgets/media.html?src=https%3A%2F%2Fupscri.be%2F6f261b%3Fas_embed%3Dtrue&amp;url=https%3A%2F%2Fupscri.be%2F6f261b%2F&#038;image=https%3A%2F%2Fupscri.be%2Fmedia%2Fform.jpg&amp;key=a19fcc184b9711e1b4764040d3dc5c07&amp;type=text%2Fhtml&amp;schema=upscri" width="800" height="400" frameborder="0"><a href="https://medium.com/media/6a088c9218e1ba9ed2e1962ac96450ec/href">https://medium.com/media/6a088c9218e1ba9ed2e1962ac96450ec/href</a></iframe><img src="https://medium.com/_/stat?event=post.clientViewed&amp;referrerSource=full_rss&amp;postId=ef9efaf76a53" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="https://blog.prototypr.io/okrs-are-not-roadmaps-part-2-ef9efaf76a53">OKRs Are Not Roadmaps (part 2)</a> was originally published in <a href="https://blog.prototypr.io">Prototypr</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

OKRs Are Not Roadmaps (part 2)

OKRs Are Not Roadmaps (part 2)

Top Stories