Episode 6 of Good Product Management brought to you by Scott Colfer.

Previously on good product management: we uncovered principles for ‘product-thinking’ that can be used by anyone to improve the values of their products and services; found out how I learned the most important principle is being passionate about problems and flexible on solutions; then defined what it means to be a product manager. Most recently we uncovered the skills and behaviours needed to be a good product manager.

5 Tips for your Product Strategy and Tactics

Good product strategy helps us meet our users’ needs and our organisation’s goals. It helps us to communicate with our users and colleagues. And when combined with tactics, helps our team to understand what they need to achieve and how to achieve it. I’ve pulled out five tips that help me build my product strategy and tactics. They might help you too.

Found this helpful? I’m planning on publishing a book in 2021 going into more detail on good product management.

Tip 1. Define Product Strategy and Tactics

The two most important product management skills are product strategy and product tactics. Problem is, ‘strategy’ is one of the most abused and misused words in our profession. It’s important to define what ‘strategy’ means in your context. Here’s how I define it for my context.

WTF is Strategy?

A strategy is a goal with a plan for how to achieve it. The goal has a measurable outcome. The plan is a series of steps that take us closer to our goal. Each step has a measurable outcome of its own.

WTF are Tactics?

Tactics are actions needed to complete a step of our strategic plan.

The Emperor’s New Strategy

A lot of things get called strategy but aren’t:

A goal without a plan is just a goal
A goal without a measurable outcome is an aspiration
A plan without a goal is just a plan
A set of specific actions is your tactics

These elements don’t work on their own, they need each other. You don’t have a genuine strategy unless you have them all. This stuff is hard. But it’s crucial.

WTF is Product Strategy?

OK, we’ve now got clear and specific definitions for strategy and tactics in general. But there are lots of different strategies at work in successful products. What is product strategy and how does it work with other strategies?

Organisational Strategy vs. Product Strategy

Organisational strategy is what your organisation wants to achieve. It’ll likely to express the overall impact the organisation wants to have in the world. It’s probably led by a CEO, CIO (someone with a C in their title), Director, Head of, etc.

Product strategy is how this impact will be achieved via the outcomes of your products. Hopefully this is led by a product person.

Product Strategy Aligns Specialist Perspectives

In a previous episode of this newsletter we defined the four perspectives that we need to understand and align as product managers:

Users of our product
Builders and maintainers of our product
Managers or people and workflow
Our organisation.

It’s the job of product management to align these perspectives and use them to form a product strategy.

Tip 2: Your product strategy needs a beginning, a middle, and an end

I think of product strategy as three units that speak to each other and shape each other:

Where we are now
Where we need to get to in the future
Everything in the middle.

1. Where we are now

We need situational awareness before all else. There’s no point figuring out where we need to go in the future if we don’t know where we are now. This is all about orienting yourself with your:

Users: What problems do your users have? What goals are they looking to achieve? What tasks do they need to complete? How can your products help them? This helps you to build your core value proposition.
Organisation and supporters: What are their goals? What impact do they want to have in the world? How can you help them meet their goals by meeting the needs of your users? This helps you win support for your product.
Team: What people, skills, and resources do you have? How can they build and improve your product? This helps you figure out what’s feasible.
Core product: What will you build and run in-house? What makes more sense to buy, rent, or consume from other products and organisations? This will help you figure out where in your value chain you can add the most value.
Partners and competitors: What are other people and organisations doing already? What other products exist already? Has someone else already solved your users problems? This will help you position your product in a gap where it has most value and/or most competitive advantage.
. . . and lots of other things too. The things you need to orient yourself with depend on your product and your context.

Let’s take one of those as an example: partners and competitors. I’ve worked in a charity on a software product. I was surprised how many charities there are and how difficult it is to avoid competing for the same users. I started by finding all the charities working in the same space. Then dug into their offerings. I found that I had at least three direct competitors. I met with these competitors and we figured out how we could become partners. This helped improve the core value proposition, and increase adoption. Orientation was crucial.

Figuring out where you are helps build the business model for your product. This isn’t a one-off activity, it requires regular testing and updating if we’re to continue to know where we are.

2. Where we need to get to in the future

Figuring out where we need to go can be simple if we have a good sense of where we are. What you’re looking to do is say ‘For the investment of [money/people] in our product, we’re going to help users and the organisation get from where they are now [benchmark figures] to at least this place in the future [target figures]’. This is commonly referred to as the vision for the product. Who you say it to and how you say it is up to you, but it should all add up to that information.

3. Everything in the middle

Now you just need to join where you are with where you need to get to. Easy, right? :)

This isn’t a single, straight line from where you are to where you need to be. It’s a series of decisions based on insights you develop over time, and the world changing around you. Every step of our journey we’re trying to choose the thing that’ll add the most value to our product. Each step is a hypothesis along these:

We think this action for these people
Will achieve this outcome
And is worth this investment
We will know we’re successful if we see this signal.

It’s helpful to break this middle into smaller, less daunting bits. There’s value in constraints. To give one example, the product lifecycle can help to give shape to our strategy:

Problem definition/discovery: Test the riskiest assumptions about the problem through research. Check that it’s worth solving and identify the main user needs
Problem-solution fit/alpha: Test the riskiest assumptions we’re making when thinking we are best placed to solve the problem we’ve identified.
Build/private beta: Build the core product and service wrapper needed to meet the main needs of our users. Develop incrementally using build-test-learn feedback loops with a small group of users. Ensure resilience ahead of growth
Growth/public beta: Get the product into the hands of enough users to justify the time and money invested up to this point. This one definition of ‘product/market fit’ for non-profit contexts.
Maturity: Make use of insights to improve the value of the product for your users and your organisation whilst reducing costs. This might include expanding to new user segments, user types, or territories. It might include taking aspects of the product and spinning them out as products in their own right.
Retirement: Stop the product as soon as possible once value decreases or costs increase to the extent that the business model breaks.

This isn’t a perfect description of the product lifecycle but it allows me to make the point that placing yourself in a ‘phase’ can help to set expectations and mould our hypotheses. For example, I know that once I’m out of the early ‘build’ phase it’s no longer as simple as prioritising new product features. It becomes necessary to balance new features for the product with paying down technical debt. This needs to be further balanced against improvements to the service wrapper, so that users can find and use the product. And investment in research and innovation that will allow us to generate new opportunities. We’ve taken a massive space (‘the middle bit’), narrowed our focus to a specific phase (‘build’) and introduced classes of activity (new product features, new service wrapper features, reducing technical debt, and research/innovation). Introducing constraints can unblock our thinking by creating smaller, safer spaces.

I’ve avoided talking about product roadmaps so far. ‘Product roadmap’ is often shorthand for ‘everything in the middle’. It’s often used as a way of simplifying and communicating product strategy. I see them used less often as the tool used to figure out product strategy in the first place. There’s a lot already written about product roadmaps including my own post on Mind the Product’s blog.

Tip 3: Product strategy is a collection of decisions

Our strategy assumes we know where we are today but that we’ll hit decision points that will change our path. Because, you know, life is complicated. Each step of our plan helps us gather insights that help make these decisions. ‘Strategy’ is the collective name for all these decisions. This image (external link to Twitter) from someone I follow on Twitter called Pavel A. Samsonov helps me visualise and explain what a this means.

Each step of our strategy is about getting data to generate insights to help us make these decisions. It’s a constant balancing act. We want to learn enough to make good decisions. But we don’t want to take so long that we miss opportunities. There is always tension between urgency and value. If we always focus on urgency then we’re driven by fear of the cost of delay. We’re at risk of churning out new stuff with little value. If we only focus on value then we’re driven by opportunity cost (the value we miss out on when we commit to an opportunity). We’re at risk of making smart decisions but taking too long to arrive at them. We need to consider urgency and value. Our product strategy helps us find the right balance.

Limiting our investment is one way of finding the right balance. Look again at the suggested format for our hypotheses. We believe that this action for these people - will achieve this outcome - and is worth this investment - we will know we’re successful if we see this signal. You’ll see that this has investment baked into it. We’re making the commitment of investment in finding out more. And we’re limiting our investment so we don’t expand to fill time/money/people.

Our team’s rhythm and meetings can also help to find balance. I have used refinement meetings between reviewing one goal and planning the next. This meeting of about three people was a chance to reflect on our next goal in light of what we’d learned. I’d use insights from colleagues to refine where we are, where we need to get to, and how we’re going to get there. The other specialists would likewise refine their individual strategies. We’d make our best guess for the next goal. It’d be sketched in as much detail as was useful for the whole team to refine and break into actions at sprint planning. I guess you could say this is another type of investment. We invested 1-2 hours every 2-4 weeks to make decisions about what to change based on what we’d learned.

Tip 4: Don’t let tactics drown your strategy

You might’ve noticed that I’ve not spoken much about tactics.

Tactics are well-covered well by frameworks we’re already aware of. For example, The Scrum Guide contains excellent guidance.

Product managers are generally good at tactics. Maybe a little . . . too good. We’re sometimes focused on tactics to the exclusion of strategy. When faced with a team who need our help versus an out of date product strategy, it’s the team who’ll get our attention 99 times out of a 100. It’s more emotionally rewarding to help the team, but we’re not always serving them or the product by doing this. How do we make more time for strategy?

We can start by reminding ourselves that we don’t have to have one massive backlog for everything. Our bank of hypotheses for improving the value of our product can sit separately from the actions needed to make this happen. In an empowered, multidisciplinary team the product manager is responsible for shaping the hypotheses for improving the value of the product. The rest of the team is responsible for shaping the actions needed to make this happen. Setting the expectation that the team should be defining, carrying out, and reviewing their own actions can help to increase team performance and release more time for the product manager to focus on strategy.

Next thing we can do is make our ‘strategic’ work visible and accountable. Work is work. All the team should visibly define and prioritise their work. Product managers are just another member of the team. Those meetings that we do? Those roadmaps we’re updating? Make them visible. Define the outcome we want. Explain why it’s important. Estimate how much time it requires. Make time for our work the same way the rest of the team does.

As a bonus, this can help us to chill out with user stories. Hypotheses for improving the value of the product should be written in a way that makes it clear how we’re helping our users, including pass/fail criteria. User story is one format we can use to do this. But we do not need to use the same format with every action required to make this improvement. It is not necessary. You can write actions as actions. I release you from the curse of everything being a user story. You’re welcome.

Tip 5: Start where you are

What does this look like in practice? Take a look here. It’s a Trello board I’m using for the strategy and tactics for a personal project. It’s sketchy, imperfect, has room for improvement, and is real. We don’t get to a shiny-looking product strategy all in one go, it might take months to emerge. The goal is not to have perfect strategy and tactics. It’s to have enough of both to keep improving the value of your product. It doesn’t get ‘done’ all in one go, in isolation. It needs to be regularly shared, questioned, and improved. For as long as the product exists.

Let’s take a look at the strategy and tactics for my personal project.

Context: I’m currently on shared parental leave and don’t have access to my professional boards. The board I’ve shared is for me. It’s not designed to help others understand what the goals are and how to achieve them. I’ve tidied it up ahead of sharing it for this newsletter so it should make sense but it’s not clear enough for others to get involved and feel confident in what they’re doing. I’ve come to the end of my current mission so most of my tickets are in ‘actioned’ or ‘history’. I spent a bit of time turning the large number of small tickets into a smaller number of epics, so there’s less to read. Over the next few weeks you’ll see me take the notes from the next mission and unpackage them into individual tickets in sandbox/icebox/backlog. Additionally, my project is young. I’m unclear what the value proposition is and still building confidence in the users, their needs, and the product itself. Right now it has more questions than answers. And that’s fine. This is how it always starts. I have decisions to make and am building insights to help me make those decisions.
Tool: I’m using Trello. I’ve used Trello since it became available, pretty much. Other software has come and gone but Trello has remained my go-to for this kind of activity. What’s important here is to use whatever you’re comfortable with, rather than convincing you to use Trello. You could do this with pen, paper, and stickers.
Format: Going from left to right, the first three columns are my emergent strategy. My vision is where I want to get to. The missions are my best guess at the first steps needed to get there. I’ve prioritised one mission to start with and split that into specific objectives in column three. I had an instinctive vision to begin with but it wasn’t until I started on my first mission and began figuring out where I am that it began to take shape in a meaningful way. Column four is ‘opportunities’. Right now it’s ideas I’ve spotted but put on hold. At work, this is more of a space to show what’s going on in the real world: contracts ending, accessibility requirements changing, cross-government groups, etc. Stuff that’s happening outside of our team that we should know about and consider working with. The next few columns are tactics and are fairly standard. Sandbox is a place to dump anything relevant to the current mission without second-guessing yourself. Icebox is stuff that’s been considered, refined, and is likely to be useful. Backlog is stuff that’s been prioritised to be worked on, with ‘doing’ and ‘actioned’ pretty self explanatory. ‘History’ is something I’ve only just started trialling. It’s a space to leave a record of what we’ve done and to check-in that it led to the outcomes we expected. It’s easy to get caught up in NEW NEW NEW. It’s harder to make space to figure out if what we’ve done is worthwhile. I think this might also act as a useful decision log for new people joining the team.
Improvements: My vision needs a lot of work. The next couple of missions should lead to a meaningful vision that I can start to use with other people. The next couple of missions should also help me get a clearer sense of where I am now. There are lots of things out there already to help organisations connect, it’s highly possible that I could join, support, or amplify an existing one rather than create another of my own. Or that I can do more by personally connecting 2-3 organisations together in the real world than by creating a whole platform at scale. On the book, I’ve done a fair amount of testing the riskiest assumptions and already refined the value proposition, identified a better user segment, and narrowed the scope. There’s no need for the missions to have much more detail whilst it’s just me working on them but they would be ineffective in a team context. Here is a tweet showing the format I’ve been trialling with the Lead Product Managers in my profession.

Please don’t think I’m sharing this board as an example of good strategy and tactics. It’s not. But I am sharing it as an example of something that’s good enough to start with. It’s helped me to think about what I want to do and why I want to do it. It’s made the gaps in my thinking clearer to me and helped me to prioritise where to start. I reckon the next 6-12 months will be filling those gaps. I’ll use the emerging insights to either kill the project or to make decisions that improve how valuable it will be. Which, at the end of the day, is all our strategy and tactics need to help us do.

You could knock-out something like this in an hour or two and I bet it’d be some of the most valuable time you spend on your product this week. Good luck!

Thank you

Thank you for subscribing to this series of emails on good product management and for reading this episode. If you’ve found it useful or interesting please consider sharing it with someone else and sticking around for the next episode.

Sharing

Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0)