Product Strategy: The Zeroth Engineering Unlock

So, here we are in my very first post after a rambling welcome, and we’re already off the rails! The whole point of this substack is to share valuable (I hope) experiences with fellow Software Engineering leaders, and here we are talking about product strategy, which is clearly a topic for Product leadership, right? Well, in my experience it’s not that simple. The company (or group) product strategy really should be a first class concern for the Software Engineering leader in any organization where software is core to the company strategy.

Why is it so important? I believe the core reason is that it creates a truly meaningful bi-directional channel for the operation of the software engineering organization to both reflect and affect the business strategy of the company.

We often like to think of software teams as “delivering what is requested,” as if the business decides upon a target customer it would like to address, the Product function translates that into a set of requirements, and then the software team creates a project plan and delivery date, and works on building software. But the real world is simply way messier and more complicated than that.

A software team isn’t simply a project delivery machine (as much as people outside of R&D sometimes seem to look at it that way!). The team has critical additional responsibilities, like serving as the ultimate layer of support for existing products. And even more basic, the Engineering org is responsible for the future sustainability of company operations, such as ensuring sufficient staff are on board who know the technology. This requires hiring and onboarding new engineers over time, and appropriately driving goals around quality, reliability, evolvability, etc. to support the business over the long haul. In other words, the software team is thinking in all timescales: the past, the present, and the future — and in the specific domain of software (and often operations) which are frankly a bit of a mystery to most other functions.

The idea that such a complex operation could simply be given a set of requirements and produce anywhere near an optimal plan for the organization is comical. In reality, what the Engineering org can produce in response to a heap of initial asks is a set of options that the business can consider, and through iterative refinement arrive at an optimal plan. Optionality is pervasive in your Engineering plan, for example:

• We can run lean or rich in terms of staffing spend, and there are very valid reasons for either decision that should be explicitly considered

• We can tip the balance of short term versus long term investments, and again, either answer may be correct depending on circumstance

• We can invest to improve productivity (unlock future business value), or we can emphasize direct value delivery

• We can tip the balance between delivery activities and team growth

These are just a few of the dimensions that can be considered, and which can have a very real impact on company trajectory. But they’re often hard to talk about in the boardroom due to the complexities of the Engineering discipline.

The Product Strategy Unlock

Developing a well documented Product Strategy, one that is consumable by the business (i.e., reasonably concise, not too technical nor in the product details, etc.), and one where Engineering leadership (management and senior IC / technology leaders) actively participates in the development of the strategy, creates the perfect “meeting place” for the business and R&D leadership (including engineering) to align on a plan.

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 overgeneralize, 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.

There’s much more to write on this subject, and I hope to return to it. I hope you have a positive experience driving product strategy discussions in your environment. As a parting thought, I will say that for me personally, the work and meetings to drive to the product strategy are among the most delightful to participate in. It just feels good to put the big central question of your organization on the table and develop a great version of the answer for your org.Doing this together as R&D leadership, sharing in that delightful experience is an awesome bonding process. The team comes out not just smarter, but more closely knit, healthier, and more productive.