A checklist I put together for students and as well as people coming into the place I've been the past year and a half to help articulate what a product strategist should be thinking about from day to day.
It’s something I return to often.
1. What’s important vs. what’s urgent.
Making sure to build features that provide the most value for the platform overall. There will sometimes be things that are urgent (bug fixes) or something a client asks for that just needs to get done. But make sure you are focused on building things that will be important for your product and all your customers.
2. What is the job to be done and how does this support that?
I've talked a lot about the job to be done, but a product is essentially something that a customer hires in order to accomplish an end goal (peel a carrot, get a ride, find directions). Print out in big letters what your products “job to be done” is and hang it on the wall for all to see.
Everything you do should be in service of your job to be done. If something is being proposed that doesn't support that, ask why you are doing it.
3. Does this deliver on the core value proposition?
Related to the job to be done. Also hang this on the wall (your actual value prop statement). A value proposition outlines the benefit you are providing to whom and what makes you different / novel / unique. How is what you are doing adding value to your value proposition?
4. Does this open up a new opportunity for us?
Sometimes you do something that ISN'T immediately realized right away. There will be strategic investments you make in order to expand to a new market or realize a new revenue stream. Just make sure you understand what the opportunity is and HOW long you think it will take to realize the value of that new opportunity. Build as much for tomorrow as you do for today.
5. What will signal its success if it is implemented?
Outside of metrics there may be other things that signal the success of something you do. If you don't know what success should look like maybe you need to hit the pause button and make sure you do. I personally like to use things like Googles HEART framework to help not just set goals but understand how we will begin to recognize the success we want to achieve.
6. Does it align with an important metric?
Do you know what your metric is that will help you measure success? Depending on your product your metrics will be different (I'm loving the Google HEART framework). Does it promote your main metric or an important metric that will move the needle. And how will that metric help you understand whether your product is getting traction with customers?
7. How many customers will be be impacted and how frequently will they use it?
What % of customers will be able to use this feature and how much will they use it? You can graph this on a horizontal and vertical axis of a chart and test it out. Use an 80/20 rule. If 20% of customers use a feature 20% of the time then is it worth supporting?
I have come across cases in B2B software companies where the decision has been yes, especially if a client drives a large percentage of revenue. But be careful, making purely short term revenue decisions can mean you build a product and features that are so custom that they cannot be leveraged across the platform for other customers.
8. What is the cost of supporting this feature vs. how many can use it?
This is related to #7. Know your carrying costs of both your customers and of features. If you have particularly high carrying costs of a particular feature or set of customers which uses up a high % of resources, it could mean that you get so bogged down in supporting it, that you don't actually have time to innovate for the future.
9. What has the highest impact for lowest cost?
This is more of a prioritization question but I do think this is something you should constantly asking. Sometimes the smallest things can add the most value to customers (small delighters are better than “meeting expectations” features).
Which leads us to…
10. What would be stupid for us NOT to do in the next 90 days?
Are you familiar with the “buy-a-feature” Agile game? If not let me know and I'll teach you. It's great fun, But you don‘t always have to play the game to identify that one that would be a “no duh” decision. But sometimes it’s good to take a no duh approach.
You can even try running a pre-mortem which is an Agile "think forward / look back" game. Imagine it‘s a few months from now, talk about the one thing you didn’t do that was stupid not to have done. Talk about the things that ended up being a distraction. Great, now come back to the present and re-prioritize.