Are you doing product strategy the right away? Here are three tips to improve.
I’ve been writing product strategy for over four years, but only within the past year did I come to realize that I may not have been doing it optimally.
Epiphanies such as these aren’t uncommon in a fast-paced tech world full of new insights and best practices that shower us blindly. It’s difficult to keep up with every piece of feedback and adapt so readily to new teams, features, and ideas.
Product strategy is one of the most pivotal areas that demonstrate your product knowledge the best in any given scenario. Almost 100% of the time, your ability to strategize and drive a product to business success will always be mandatory in a product-related role. Whether you’re a junior product manager (PM) or someone with over a decade of experience under the your belt, I feel this article may help remind everyone in the product community about the best ways product strategy should be applied.
Without further ado, here are three key elements that product folks must be acutely aware of when developing product strategy.
1. Your strategy isn’t your roadmap.
For me, this was the toughest pill to swallow. For the first few years of my product career at Microsoft, my product roadmap WAS my strategy, and I focused too much on OKRs that fit the bill. It didn’t help that my approach to writing OKRs (objectives and key results) was very “timeline” and “execution” focused, which again, was the “roadmap” effect. I didn’t give enough thought into the real reasons on whyproduct had to move in a certain direction, both engineering-wise and business-wise.
For example, at Microsoft Bing, I would write something like, “Ship a 90 precis-on classification ML model to the top x billion URLs we process, enabling the feature teams to filter out specific websites by y%.”
And while this isn’t necessarily a poorly-written KR, it’s focused on the “what” without really being attached to a greater cause or how that could strategically impact product delivery. Ultimately, while this led to our projects being used/consumed by other teams, they weren’t valued as “differentiators,” and were scrapped by the end of the year for something more sustainable with higher pa otential for impact.
In retrospect, I could’ve written a product strategy document that outlined the objectives of my product team first. I would dig deeper on why ouintowork was important, how it impacted business growth, and the oll direction our team needed to head and how ,we would differentiate ourselves in the market (in this case, compared to Google). Then, I would propose a specific product delivery method (varying forms of scrum or kanban) that fit our strastegy the best. Suppose we wanted to work on a new internal feature that benefited other developer teams that needed a lot of trial and error — I would propose a 1-week sprint cycle in the form of a scrum, so we could benefit from easily pivoting whenever we wanted.
However, instead, I wrote KRs on what needed to get done, loosely tied it to a higher-level objective, and focused on a timeline without much care into the “why” of our delivery methods. I focused too much energy in workingowith engineers to estimate the amount of developer months needed to get work completed, and spen more time on a schedule to ensure work would be delivered punctually rather than on a strategic way to deliver based on why we needed it.
Product strategy isn’t about delivering things on time. It’s about outlining not only why a team has to build something in a certain way, but how they can maximize the value out of their project for the market/customers.
2. Don’t mistake the mission and vision of your product for the strategy.
A post by Shreyas Doshi confirmed my suspicions: many PMs could be tackling strategy documents the wrong way, even from just the start of it.
Typically, PMs begin their strategy docs by stating the mission and vision of their product or feature before digging into the details about the “why” and the “how.” Other times, only a brief overview of what needs to be built will be described. Usually, this is fine if you’re just only writing a requirement doc on a feature for the engineering team; only the “what” and the “how” need to be covered. Yet funny enough, many include a “why” section as well but they don’t state anything pertaining to actual strategy. They instead just state the mission and vision, and introduce why the feature is useful, not why it’s a game-changer both internally and externally.
Product strategy isn’t about stating the mission and vision of your product an/or team. It could be included, but most PMs mistake this for actual strategy. Actual strategy depicts how you differentiate your product/feature from your competitors. It highlights how you plan to win the market to achieve your business goals. You can still write about where you see the product in 3–5 years and why you want to get there, but what about the part explaining how you’ll achieve business success?
For example, at Unity Technologies, our product strategy documents started with a background on not just the “why,” but also the key element that differentiated us in the market. We didn’t write too many things about mission and vision; we focused on the methodology that would elevate our value and make us unique to our customers, thus winning them over and accelerating revenue growth.
Mission and vision is great for broader alignment, but proper strategy is how a team becomes successful with the right value proposition.
3. Differentiate the “tactics” from the “strategy,” but don’t exclude the former from your document.
And before you think I’m being too simplistic: in my subjective opinion, tactics DO belong in strategy. Reason being? Tactics should be regarded as a subset of lower-level strategy that could contribute to how a team differentiates their product in a specific market.
Tactics by business definition is “how things should get done,” or a short-term fix to mitigate a problem, as opposed to the “why” and the “what,” which are more strategy-focused with long-term emphasis.
Imagine this example: At Microsoft, we were trying to figure out how to develop a certain machine learning model that could improve country tags for the top x billion of websites in Bing Search. The strategy was already defined, because I already did the discovery work: I found out that a certain percentage of URLs appearing in the top 3 search results of Bing suffered from poor country labeling. I wrote out the strategy plan to highlight my findings and conquer this problem, but what I didn’t do (and I should have) was include the tactical solution in the document: the “how.”
We decided that a new model was needed — and thus a lot of engineering prep work kicked off following our product decision. But here’s the thing: product managers need to adapt to the delivery system their engineers work in. If engineers prefer to take over tactics, that’s fine. If it makes sense for a PM to support tactical decision-making, that’s also fine. The problem is that some PMs mistake tactics for strategy, or they decide to exclude tactics entirely from their documents, letting engineers take over the realm. PMs should at least include a write-up of their engineering team’s tactical decisions in their strategy document for reference, no matter who owns it.
Tactics can still be part of product strategy if it impacts the way you can differentiate yourself in the market for business success.
About Me
My name is Kasey, AKA J.X. Fu (pen name). I’m passionate about writing, technology, AI, gaming, and storytelling 😁.
Follow me on Medium or Substack for more passion, product, gaming, productivity, and job-hunting tips! Check out my website and my Linktree, and add me on LinkedIn or Twitter, telling me you saw my articles!