Product Strategy: The Zeroth Engineering Unlock

The Product Strategy Unlock

In my experience, lower level artifacts like the product roadmap or the Engineering strategy (if one is documented) just aren’t sufficiently consumable to the business. They’re simply too detailed to connect to company level outcomes. And higher level artifacts like company level OKRs or KPIs are simply too disconnected from building software to drive discernment. Like, if the goal is $X of bookings, I guess any project that helps bookings in any way is good, right?

But a meaningful and consumable product strategy creates a Goldilocks artifact to meaningfully relate company strategy and priorities to product strategy and priorities, and also drive meaningful alignment discussions about adjusting either or both.

The Ingredients

What goes into the Product Strategy? It doesn’t have to follow a very specific structure or template, but it should definitely address the following big elements:

• Customer: Who are the target customers? I.e., who is the product for
• Problem: What problem do they have that we will solve for them? I.e., why will they want the product
• Competitive context: What is the competition / state of the art? This can include actual competitors, or it can include competitive ideas like “do nothing” or “build a solution myself”
• Differentiation: How is our approach different? I.e., why will we win versus the competition? Ideally for existing products this should be based on evidence – like, talking to customers to find out what they like about our product compared to the alternatives. But beyond what customers may love today, it can also include ways we expect to be even more differentiated in the future. It’s often useful for this to include some insight into why the timing of the proposed approach is right (e.g., new hardware innovations changing cost model for a given approach, new advances in AI that obviate historical manual approaches, etc. – so, not just “why this” but also “why now”).
• Vision: A brief vision statement that expresses what is the long term / north star vision for what this product will become (ideally a one sentence summary – not long form!)
• Near term opportunities: What are our biggest opportunities over the next year – in particular, what are our best known opportunities for improvement in the following areas (focusing on problems we actually propose to solve):
  • Quality / reliability / customer satisfaction
  • Customer retention – i.e., what are existing customers consistently asking for us to add?
  • Obtainable market expansion – i.e., what are the best known things we can do to drive near term revenue
  • Addressable market expansion – i.e., what can we do to expand into new markets (e.g., address a new type of customer, solve a new problem for existing customers, etc.)
• Proposed investment themes (and allocations): Based on our known opportunities, what are the areas of investment proposed (these can be roadmap themes, technical investment themes, etc.) and approximate investment amounts (e.g., approx number of FTEs, percentage of R&D spend, etc.)

To be clear, there are tons of resources out there on product strategies – deeper discussions of what makes a good strategy, templates to help document strategy, etc. The above is by no means meant to be comprehensive or overly prescriptive, but rather to give a sense of what needs to be captured.

The Magic Is The Process

The magic here is in the process, especially as it becomes enshrined as a regular ceremony to update the product strategy, at least annually (e.g., as part of annual company planning), perhaps more frequently in very dynamic environments. I’ve found using a document oriented process, such as using the classic Amazon “6 pager” meeting approach, is great. But the truth is that, whatever works best for your team, just making the space to get the strategy on paper is the key.

In particular, I find that the best part of the process is in building alignment across the organization. This starts between Product and Engineering (and other R&D disciplines such as design, ops, quality, DevEx, etc. as appropriate within the organization). Hammering out the initial draft of the strategy builds shared fluency across the disciplines about the problems to be solved and the constraints around solving them. For example, how much resource is required to “keep the lights on,” what level of engineering platform / DevEx investments seems reasonable based on survey feedback from the team, etc.

Once the R&D team has run a process to align on a draft product strategy, it then becomes the perfect basis for aligning plans with the other functions. I find starting out with key influencers in various parts of the org is a great first step to make sure nothing big has been missed. This in turn makes it easier to bring up the chain to executive leadership, so that by the time the CEO is asking questions like, “Is the sales team excited about this?” or “Is the top feedback from our key customers well reflected here?” have already been well litigated and can be easily addressed.

And beyond internal alignment, having product strategy well documented then becomes the perfect basis for constructing a roadmap narrative for external consumption. For example, how do you frame your thematic roadmap investments for customers (e.g., to bring to a “Customer Advisory Board” or similar), a roadmap presentation at the annual user conference, or in an analyst discussion, etc. Having deeply considered, documented, and aligned upon strategy means your discussions of how you think about the product and technology are more credible and authentic, which in turn tends to lead to more enthusiastic engagement and better targeted feedback.

But Why Is This So Important For Engineering?

Coming back to the original point, beyond all of the obvious benefits, capturing a consumable documented product strategy is among the most important things you can do to create a foundation for Engineering organization success. Now more than ever, Software Engineering is integral to the success of more and more organizations, and it’s widely appreciated that Engineering Leaders need to move beyond execution in their area and become deeply engaged as a steward and direction setter for the business.

This in turn unlocks great execution for Engineering, or at least the opportunity to execute well. For one thing, despite so much discussion covering Engineering productivity and efficiency, especially as tech salaries have soared in recent years, I believe it remains true that the best first step you can take to optimize productivity and output is to ensure that effort is pointed in the right direction and allocated to the highest priorities. Time and time again when working with various Engineering organizations, I find that independent of how well or how poorly they are executing Engineering work, the biggest swing in terms of perception of output and performance is both making sure that the team is working on the right priorities, and, equally importantly, making sure that these priorities are well understood and appreciated by everyone across the organization.

That last part is worth emphasizing. So often I’ve run into Engineering orgs doing most stuff reasonably well, but still hearing feedback like “Why aren’t we doing more of what the customer is requesting?” or “Why isn’t the sales team excited about the roadmap,” or “Is quality really good enough?” All of these are symptoms of lack of clarity and lack of alignment about product strategy.

On the other hand, with the product strategy well understood, the opportunity then exists to much more meaningfully explain and justify Engineering investments. A clear eyed assessment about what needs to be delivered now to drive the business, versus what are the opportunities or threats longer term, may explain why platform or technical investments make sense, as well as helping to inform what types of ROI assessments on these investments make most sense.

Without the larger strategy context, Engineering or platform investments can so often seem like “nice to haves” versus roadmap priorities that come with clear commercial drivers. Of course the one off explanation of the intended benefits by the Engineering leader can be helpful, but how much more powerful can these explanations be when related back to a larger product strategy?

One last point about product strategy in the Engineering setting: in my experience, it’s also a very powerful engagement driver for Engineers. Not to over-generalize, but Engineers tend to be smart and analytical, and also have a strong capacity for skepticism. If they’re being asked to build stuff without a solid foundation of justification, they can see right through it and it isn’t very motivating. On the other hand, the Engineering teams I’ve worked with have always had a strong desire to help the business win. Getting to concretely see that their work is strongly justified by a thoughtful product strategy is both a strong motivator to drive to outcomes, as well as fantastic context for the people closest to the code and therefore among the best able to generate practical ideas to improve the product. In my experience, documented product strategy is a turbo charge for the Engineering team.

For more engineering insights from Adam, check out his newsletter, Engineering Together.