2020-01-01 // Product Management //
Over the last six months, I’ve chatted with a bunch of Product Managers about approaches for building a long term strategy for their products. The theme that came up time and time again was that the whole idea seemed daunting. How could they find the time to do the research and analysis needed to build a robust strategy?
Sound familiar? If so, here’s the thing. Part of what’s stopping you from getting started is that you’re probably framing it all wrong, and that’s why it’s daunting. What if I told you that..
- It’s not about “building a strategy”, it’s about “strategic understanding”.
- Strategic understanding does not land with a bang. It emerges slowly, iteratively, and collaboratively.
- You can gain robust strategic understanding and find a long term direction with an hour a day (for as long as it takes).
Back in 2016, the awesome Brian Donohue (Director of Product at Intercom and my boss) said:
[..] if you put a block of two hours in your calendar every week for “strategic thinking”, it’s just not going to work. [..] I think it’s important to make time for tasks that have no immediate payoff. You have to fight for the time to plant seeds in your head, which will germinate and grow over time. So things like research, talking to customers etc. Solving the most immediate problems usually feels rewarding, but it won’t lay the best foundations for your future thinking. [Intercom blog]
Here’s what has worked for me in the past, and have seen pay off for others when they’ve done something similar. If your new year’s resolution is to think more about strategy, read on. Hopefully, this will be helpful.
First up, figure out what a reasonable time commitment is for you, and make it part of your routine. For me, that means an hour a day for ‘product thinking’, which could be any number of activities. It could be working towards better strategic understanding, but it could just as easily be other things like short term planning, roadmapping, professional development etc.
Next up, put together a strategy working document. Sounds fancy, but it’s definitely not. It’s the messiest document I work on because it’s always evolving, is full of things copied and pasted, and has comments stacked as high as the moon.
What goes in the doc? Good question.
- The key points from the company strategy, if you have one (eg. target customer segments, use cases/jobs etc).
- What we know about our product (eg. adoption, feature usage, revenue, retention, expansion etc).
- Learnings from customer interviews, feedback, feature requests, product/tech debt etc.
- Learnings from competitive analysis.
- Known gaps in knowledge (eg. we don’t know what revenue is attributable to our product).
- Hypotheses and assumptions.
Keep it short and sweet. Bullet points. This isn’t a place for elegant prose. It’s a place for focused thought.
In the beginning, just getting to that base level of info will take a little time, but it’s worth it. From then, you’re using your thinking time to fill in the gaps, add detail, and validate your hypotheses/assumptions where you can. You’re expanding on your product understanding and asking yourself why repeatedly, layering in more context and data as you go. Slow and steady wins the race.
Make the doc collaborative as early as you can. It’s stressful because it’s messy, but you will benefit from having other perspectives from very early on. Trust.
When the time is right, you’ll be able to extract the key points and themes that you will want to act on. Take your time and really refine your understanding here. Boil it down to one impactful metric if you can. Through this process you’ll have your robust strategy, backed up with detailed research and data. Write it up nicely so that you can share it 😉
For me, it took about 3 months elapsed time to go from nothing to a detailed strategy and North Star with buy in from our leadership team, comprehensive product dashboards, a short term roadmap, and a directional medium-term roadmap. That amounts to around 80 hours of work from me, plus the time my team and others put into the more collaborative elements of this. What we learned has completely transformed the way we think about Mobile SDKs at Intercom, and has resulted in rallying around a mission, organisational change, expanding the size of the team, and more. All of that from an hour a day.
Maybe you don’t have an hour a day. Maybe you have less. Maybe you have more. The point is that with a little structure, acceptance that the process will take as long as it takes, and a bias for progress, you’ll get there. I’d rather you got there eventually than never at all.
If you liked this, check out a couple of other interesting reads on the topic:
- The Amplitude North Star playbook.
- How should Product Managers Prioritize their time? A conversation between Brian Donohue and Colin Bentley at Intercom.