How I turn strategic initiatives into actionable product work
For the past few weeks, I've been laying the groundwork for my product's Q2 strategic initiative, attempting to turn it from this:
to this:
Here's how I went about doing that.
Step 1: Understand the initiative
In this case, the initiative came from a 3-year strategic investment from the business.
This is exciting.
The work is likely to impact the business at a deep level and be a real game-changer.
This is also a bit daunting.
'Strategic investments' handed down by the C-suite can be quite vague. And we certainly don't want to go down the wrong path early on.
So, first, I work on the following three tasks:
Speak to my manager about the initiative. She's the link between the C-suite and me. She can clarify expectations.
Define terms. Because I'm the 'man on the ground' for this product, I have a deeper understanding of the industry, capabilities, and technology than most, including my boss(es). I emailed my manager definitions of key terms, particularly some I noticed stakeholders using interchangeably or in the wrong context.
Write a summary of the initiative. I wrote a few paragraphs on my understanding of what the business wants to achieve and what I'll be working on.
Step 2: Zoom in on target customers
Next, I dug out our target industries and customers.
I want to make sure our initiative helps them. We want to satisfy their expectations and solve their pain points.
I picked our top 3 industries to start with.
For each of them, I did the following:
Summarising pain points. This was simple enough as we've been servicing these businesses for years; we know what their pain points are.
Data insights. I backed up those pain points with cold hard facts, reports, and research.
Brainstorm use cases. I brainstormed how our (currently vague) strategic investment could positively impact those industries.
Step 3: Targeted use cases
If your strategic initiative is high-level, there could be hundreds of use cases to work with. This is particularly true in enterprise B2B software.
Since the whole point of this work is to go from hazy to actionable, 'hundreds of use cases' just won't do.
Out of the use cases brainstormed earlier, I handpicked two per industry. I filtered them out based on:
Highest potential positive impact on our target customers.
Most applicable to our existing business/product.
For each use case, I go as deep as possible into the challenge, solution, users, flow, and so on.
Step 4: Interviews
So far, we haven't talked to anyone. Yikes.
Depending on the business, getting this far without speaking to a customer might be ok. In my case, we've been serving the same customers for three decades so we have a pretty good grasp on their needs.
Still, feels yucky not to talk to anyone. Let's change that.
Ideally, I break my interviews down into three groups:
Customers in our target industries
Internal sales teams
Internal customer service teams
By speaking to the customers and the people who deal with these customers, I get a more holistic view of their wants and needs.
Some customers might say they want something. But are they willing to spend money to solve that problem?
Some customers might say a feature is unusable. But are they constantly raising support tickets about it?
I work through this trifecta for each of my target industries and speak to as many people as I can. My goal is to:
Validate research. I want to confirm my pain points resonate with them.
Validate use cases. I want to know if my use cases are real and if solving them would indeed help our customers. I also want to gauge the intensity of their response. Is it a 'yeah, would be nice' or a 'hell yeah we need that!'?
Understand must-haves and rebuttals. Speaking to sales can teach me more than 'yes, customers will pay for this'. They deal with prospects all day and know what they're sensitive to, where we lose deals to competitors, what shiny feature isn't actually a must-have, etc.
Clarify flows and applicability. Customer service uses our product all day every day. They know how customers truly use our product, rather than how we think they do. They'll teach me about user flows, expectations, inefficiencies, and more.
Step 5: Projects
I'd estimate the work above would take 4 to 6 weeks.
That's a long time to be immersed in an initiative, thinking about it, trying to put the pieces together.
By this stage, my brain looks like this:
This is a good thing. The puzzle is starting to make sense.
I'm now focusing on two things.
First, I want to summarise all of the above and send it to my boss. For this last initiative, I ended up producing a ~30-page document. This is as much for the business as it is for me; writing it forces me to clarify my thoughts (much like writing this Substack does!).
Second, I want to break the work down into actionable projects to hand over to the engineering team.
To do so, I look for commonalities across my use cases and interviews and work my way down the list. There are no secret sauces here. It's about connecting the dots based on my experience, interviews, product sense, and understanding of the strategic direction of the business.
Out of a single strategic initiative may come 4 or 5 projects. I want them logically sequenced so each project builds upon the previous one.
At this point, I involve the engineering lead to help me chunk out the work. I'll use this opportunity to 'pitch back' the initiative and summarise the above, then present my project sequence and get their feedback.
All in all, it may take about a quarter to prepare for the next.