Battlefield Product Management
Your lead PM just quit. You have 2 PMs for a group of 30 engineers who are looking for direction on what will help the business. If you can’t figure out what to build, and define it well enough for your team to execute, you’ll risk losing your engineering team’s confidence – which ultimately risks losing the team entirely. What do you do?
You need battlefield product management. Your engineering manager, your CEO, or a lead designer just got field-promoted to product manager. We’re sorry that it had to be this way, but that’s life and the product isn’t going to manage itself.
Battlefield product management distills the craft of being a PM to its most essential components. These are the steps that absolutely cannot be skipped, and an approach to tackling them that can hopefully be executed by someone who is busy, distracted, or otherwise not a trained PM.
Following these steps won’t make you a great PM, and it might not even make you a good PM. But it’ll help you conduct the minimum steps necessary to stop any bleeding and keep a product moving forward and solve business problems until you can get the right leadership in place.
Write it Down
The primary outputs of product management are decisions, and decisions are best communicated in writing.
You should use some form of Product Requirements Document, Technical Design, or other form of collaborative documentation to lay out your research and plans. This living document should state your goals, success criteria, and document all major research and decisions made thus far. For maximum effectiveness, invite the entire team to collaborate on this doc and regularly tear the plan to pieces so that you can be sure you’re getting to great decisions.
This might feel like a cheap throwaway step, akin to “the first step is to have empathy for the user!” but it really isn’t. If you write down what you’re deciding, and why, you are going to get better results. And if you don’t, in my experience any projects you take on have a significantly higher chance of completely failing.
Believing that you don’t need a formal document is a common trap:
We’ll have a PM in the future who will take the project over (are you sure?)
The team will remember the details (they won’t)
The project will be quick (it won’t be)
The What or Why is obvious (never in history)
Set and Broadcast a Clear Goal
The next step of battlefield product management is clearly defining a goal. The fundamental role of product management is being the navigator who steers a product development team towards high value goals and then helps facilitate execution. Without setting a clear goal it’s extremely easy and tempting to slide into a world where you start focusing on solutions when you should really be focused on problems.
Goals can be simple but should always tie back to some sort of business outcome. This outcome should summarize (briefly) why your goal is important.
For the sake of an example, we’ll say that our goal is to decrease your data storage product’s onboarding time. The “why” behind this goal is that we want to reduce the risk that customers churn midway through onboarding, and to delight customers with a magical experience.
Once a goal is set, you need to evangelize it. There’s only one way to do this, but it’s a simple one: repeat your goal to people all the time. Every time you have a meeting on a project, start it by stating your one-line description of what you’re trying to achieve. You will feel weird and awkward. People will look at you strangely, like you have memory issues. Ignore these feelings and enjoy your smoother running project. If you hear someone complaining that “there they go again, talking about why we need to improve onboarding,” you’ve done the job well.
Define Success Metrics
Once you have a goal, you need to figure out how to concretely measure whether you’re hitting it. Without this step you run the risk of setting completely arbitrary or fluffy goals – “improve satisfaction” or “increase sales.” Setting success metrics makes your goal concrete. Concrete goals also reduce the odds that your project will fail due to poor execution. If your team knows what they’re trying to accomplish, it’s much easier to reach a successful resolution even if you have to get there via trial and error.
If we want to reduce onboarding time, we could set the success criteria that we want to reduce the average time between when a new account is created and when the first gigabyte of data is stored from 24 hours to 30 minutes. If you set up analytics to measure this, you can concretely determine whether you’ve hit your goal.
A common trap is to obsess over getting success criteria absolutely right. Should we get our go-live time from 24 hours 30 minutes, or 24 hours to 90 minutes? Are we defining onboarding correctly? In practice it’s usually better to pick success metrics and make them measurable, rather than risk having no success criteria or waste cycles arguing. These aren’t the 10 Commandments and in most cases success criteria can be adjusted as you learn more, if the reasoning behind the change is sound.
Execute in the Order of Scariest Open Question
At the start of a project there are usually a ton of open questions. There’s a very natural human tendency to want to tackle the most tractable questions first – what frontend framework do we use? What should we name our new feature?
Resist this temptation. As a PM your main contribution to project execution is guiding the team to answer questions in order of how scary they are – how likely they are to reveal an insurmountable roadblock.
In my experience for ~90% of projects the scariest open question is whether users want what you intend to build. Many products simply don’t deserve to be built and you need to find them and terminate them with prejudice.
This is especially true for many of the products that are most fun to build. Beautiful product experiences, elegant technical solutions – nobody cares. Users will often ignore beautiful new products that you’ve poured your heart and soul into, while raving about a simple, ugly feature that solves a very tough problem you barely realized they had.
Happily, this is also one of the easiest risks to resolve: just ask customers. Try these simple techniques:
Putting a prototype in front of customers (even a very rough one) and asking them if it would be useful. Dig deep – figure out if they really mean it
Launching a very simple MVP and tracking its usage
Putting a rough product into beta
Trying to pre-sell a product (get customers to confirm that they intend to purchase if you build a new product)
For our onboarding improvement example, I would try a combination of the first 3 bullets above.
The hardest part of product validation is being honest with yourself. It’s easy to be optimistic and believe that half-assed feedback (“oh sure, this could be useful”) is stronger than it really is. Real feedback sounds like “this is incredible and we will use it every day,” “I can’t believe that this doesn’t exist already,” or “I will buy what you just showed me this afternoon.” If you’re in doubt about whether customers will care, there is no doubt.
Takeaways
To be an effective battlefield product manager:
Write things down in a clear living design document
Set a clear goal
Define success criteria that tell you whether you’re hitting your goal
Lead execution in order of the scariest open questions