visit
How to Identify and Navigate Chaos in your Product Strategy
Imagine if the above didn’t have to happen…We’ve all been there: the feeling of dread when nothing you’re doing seems to work, clients are angry, sales is furious, and you are swimming in a sea of feedback while being pulled in a million different directions. Although we don’t talk about it, most product managers will be handed a bad strategy at some point in their career and be expected to succeed.Having worked across companies of different industries/sizes/goals, I wanted to distill a general framework for evaluating product strategy across industries and company sizes. So by way of an illustrative analogy, here are the ways to both diagnose the symptoms of a bad strategy, and the tools I’ve used to help fix them.While product vision describes the ultimate end-state, product strategy describes how to get there (how to navigate the maze). More importantly, product strategy requires taking into account the limited resources and time a business has to prove a concept. Much like being trapped in a maze, there’s only so much time you have to escape before you run out of resources… you’re not likely going to have the time or energy to wander down every path.
Product strategy therefore is how to describe to your organization the path you want to explore to get out of the maze (AKA achieve your product vision). It’s also important to note that much like an initial path, a product strategy can be informed and change frequently, whereas vision is usually more static. So you find yourself in the maze, with an idea of how to chart a course out, but how do you choose which path to go down first?Symptom 1: Trying to go down every single path (hunting for revenue/lacking focus)
It can start of as completely harmless — “We’ll just go try out some things until we find something”, but this is not always an unreasonable thing! However, when you analyze the situation you come across two big problems:Solution: Create a way to leave a trail! (wander with a purpose)
Without tangible goals or tracked assumptions you’ll go down a path and eventually forget how to ever get back. Instead make like Hansel & Gretel and create a trail of breadcrumbs to help you get back! So what are breadcrumbs in the business sense?They are typically called a roadmap, which traditionally shows a multi-year stack-ranked timeline of features to be completed. In reality, it’s a list of stuff you’ll mostly never get to that’s only accurate for about 1–2 months out, ouch. If it sounds like I’m being harsh, it’s because roadmaps are a terrible tool to relay strategy and business value! Let’s go back to the maze example — if you were stuck with a group of people in the center, how confident would you be telling someone where they’ll be half a mile? It sounds absurd in an analogy, and yet this is how thousands of PMs are trained to communicate where they’re heading!In reality, the way you convey what your team is building should relay the value of the path you as a PM are sending people down. So instead of relying on strategy proxies like a multi-year feature map that changes every quarter, consider moving to paradigms such as ‘’ that focus around the value of the work delivered rather than describing the work itself.
Another similar approach the Monzo team wrote about is called ‘’, which is the process of identifying where the business makes and loses money. Both approaches change the focus from mindlessly shipping work to describing what you hope to achieve with that work. Further combining things like Themes + Personas can even tell you what paths may be a complete waste of time without ever walking down it!Symptom 2: Going down the wrong path for too long (not validating product/features)
This can be a harder symptom to detect because it often involves more than one stakeholder. For example, 1) the CEO of the company may have experience in the industry and state what you need to build, or 2) your favorite customer could request a one-off feature that they say is valuable to them.While it is tempting to just follow the lead and take the request at face value, there are problems to this approach:Solution: Decide how far is too far before setting out down a path (market validation)
One amazing tool to do this is the which was made popular by the Silicon Valley Product Group. Much like Amazon’s of working backwards, it’s a devilishly simple looking list of questions that forces the PM to really understand what they’re getting into, and the value they’re seeking, long before code is written. In essence, it creates valuable friction around the product development process and forces you to think about mapping out the journey before actually going down the road.If you see multiple paths as equally valuable, consider using the above in addition to the to map out your total addressable market. This not only helps define isolated opportunities, but also maps them to the total addressable market and helps visualize realistic stop points for validation. To go along with the maze example — the core of a circle would be your initial market validation, with the outer circles representing potential expansion markets. Once a PM has launched a product with users completely served by your solution you now have a safe zone to expand from. This way forces people to understand that various segments of addressable markets can exist, and whether or not you’re even near the right area to expand to closely related segments. Ultimately, if you keep going out further of the safe zone without achieving a solid user base for what you’ve built, you’ve probably gone too far.Symptom 3: Misinterpreting signals for validation
Out of all 3 symptoms, this is the most non-obvious of the bunch, because everything is usually right… until it isn’t. Much like a maze — wind (signals) can be an indicator you’re almost at the surface, or it can lead you down deeper into the labyrinth.This happened to one of my former companies, we were experiencing great success, had momentum and clients, but started becoming too reliant on client requests as a measure for where we needed to go. Eventually it went sideways when we built a multi-month integration one client demanded, only to have them end up not using it because the person asking for it wasn’t the person writing the checks…I still have nightmares from this. So how can you minimize the chance this happens to you?Solution: Never get Comfortable with the path you’re on!
Iterative feedback is absolutely critical if you want to continue to drive success for a product. This can happen in a plethora of ways — low fidelity mockups, user betas, product council groups, the list goes on. The key though is regardless of the methodology you take up, never lose touch with the heartbeat of your industry!Personas can be a valuable tool for this, but can’t be created in a vacuum! It’s fine to own the creation and updating if that’s what you as the PM decides works best, but owning does not mean being the only one that decides what’s included in the persona. As a PM you need to understand that this is a collaborative effort, usually with the people selling your product. Think about the maze again — a person stuck alongside you may not know specific characteristics of a good path, but if you give them a torch (persona) they can definitely assist in helping find what you’re looking for in a good exit path.I find that personas work best for this purpose when you focus it around 3 sections: