Setting Product Goals
Setting product goals is hard, here’s a simple framework that will make it easier.
If you liked reading this, please click the ❤️ button on this post so more people can discover it on Substack. Thanks!
Most companies find it easy to set goals for revenue, customer retention, costs and other such metrics. That’s partly because there are benchmarks for them, but also because you can extrapolate from where you are to where you want to be. You’re at $50M in revenue and want to double? Then $100M revenue is the goal!
Much harder is setting goals for your product. For many companies, the product is the business and the method by which you’ll achieve all of those other goals. At the same time, the product isn’t a number and you can’t just extrapolate from where you are into the future.
“We have 10 features now, so let’s double to 20 features!” Doesn’t sound like a good approach.
The challenge of product planning is rarely a lack of ideas. Teams often have a wealth of ideas of how to improve their product, either from customer feedback, competitive research or ideas on how to push the envelope. The challenge is how to choose among those ideas.
Making the challenge even harder, different members of the team have different opinions on which ideas are the most important. This can lead to some heated arguments, as every opinion is going to have some merit.
To avoid the chaos and get your product planning under control, here is a simple process that works surprisingly well:
Step 1. Work backwards from your metrics goals. If we need to double revenue, then what would need to change in the product (if anything) to make that happen? The answers are going to be broad goals like “faster on-boarding”, but that’s okay for step 1. By identifying these high level goals, we can get agreement and clarity that will help us make more specific decisions.
Step 2. Establish your criteria. With the broad goals in hand from step 1, establish some clear criteria for what a specific solution would need to have. If it’s “faster on-boarding” then how much faster? What specific parts of on-boarding are slow and how much faster can they get? The criteria will help you avoid emotional decisions based on your personal preferences and make an objectively good decision.
Step 3. Lay out all the options. You have a lot of ideas, so lay them out! Group them by which broad goal they might help, but don’t filter for quality yet. Your aim is to have the largest possible number of options to choose from. If you make a bad decision, it’s most likely because the right decision wasn’t in the options you lay out.
Step 4. Gather data. If there is more data to be had, then get it! It might be as simple as some customer interviews or as complex as usage analytics. Data might not always be available, but if it is we want to use it.
Step 5. Choose your candidates. For each broad goal, choose a handful of specific ideas that are the best chances to address it. You don’t want to choose just one, as we don’t yet know the effort required and we need the flexibility to adjust. However, you should have narrowed down a lot of options into just a few.
Step 6. Estimate effort. Now, the final missing piece is effort. You won’t yet know how much effort it will take to achieve all of the specific product goals you have chosen, and you need that to create the roadmap. This is the point where your team takes over to deliver some rough estimates of effort so you can narrow down the list further.
At the end of the process, you have a handful of product goals and their effort estimates which you can use to build your roadmap! Even better, all of them are tied back to the metrics goals you set, so when you build your roadmap it’ll be clear what goals you’re aiming for and when.
I’ve seen this process done in a few days, or take as long as a few months. How long it takes depends more on whether you make it a top priority or try to fit it in around other things. The slowest part is typically gathering data, but you can speed that up with better data management and a consistent customer feedback process.
There is no product plan that will be perfect, and even this approach will lead to some mistakes. However, by working backwards with set criteria and narrowing down your options you increase the chances of success.
And, even if you make a mistake, you can trace back through this process how it happened to avoid making the same mistake again. That’s a feature, not a bug.
For more on Setting Goals, see:
This is a thoughtful, grounded take on a problem most teams quietly struggle with but rarely articulate well.
I especially appreciate how you separate metric goals from product goals and then work backwards without pretending the product itself can be reduced to a number. The framework is simple in the best way. It respects complexity without turning planning into a ritual or a spreadsheet sport.
What makes this feel realistic is the emphasis on criteria, options, and traceability. It acknowledges that good decisions come from narrowing thoughtfully, not from finding a single “right” idea upfront. And the point about being able to retrace your steps when things go wrong is underrated. That’s how teams actually learn instead of just reshuffling the roadmap.
This won’t magically remove uncertainty, but it does something more valuable. It gives teams a shared way to reason together when opinions, data, and constraints inevitably collide. That alone makes it a framework worth using.
True story: I once got a live frog in a bag of garden soil I purchased from Home Depot. At least I knew it was fresh!