Ishaan Agarwal, Senior Product Manager at Square.
Here’s something strange: the best product managers (PMs) I know don’t think about products that much.
Now, of course, they do think about products. But their mental model is way closer to how hedge fund managers think than how engineers think—which is weird! You’d expect the people building products to be obsessed with building stuff.
I’ve noticed something while watching some of the best PMs I know work. They’re not debating button colors. They’re doing mental math on opportunity costs. They’re not getting attached to features. They’re killing underperformers like a trader dumping bad positions.
In this way, product management is more about resource allocation than it is about building. With limited engineering hours, limited design bandwidth, limited marketing dollars and political capital that, once spent, doesn’t come back, how you spread these resources around can determine if your product succeeds or fails.
Why Your Roadmap Is Actually An Investment Portfolio
Investors don’t dump all their money into a single stock call. (Well, some do, but they usually end up posting about their losses on Reddit.) Smart investors build portfolios. They balance things out.
We as product managers love going all-in. We have our sights set on the big feature, the total redesign, the “thing that changes everything.” Sometimes this works, but often it doesn’t.
Instead, try thinking about your roadmap like a portfolio. You need your boring, safe investments, like bug fixes and those tiny features that customers keep asking for. These are like Treasury bonds. They’re not sexy and they won’t make you famous, but they help keep the lights on. I suggest that around 60% of resources should be placed here.
Then you’ve got your growth plays. These are new user flows that might boost conversion and features that could move the needle on retention. They have a real upside, but you wouldn’t bet the farm on them. I’d recommend another 30% of resources to go here.
The last 10%? That’s for the crazy stuff—the moonshots. This might include building AI features before everyone else or completely rethinking how users interact with your product. Most of these will likely fail spectacularly, but sometimes they don’t. And when they don’t, they change everything.
The problem I see too often is that most PMs flip these percentages. They spend over half their time on moonshots while core features stay broken, and while they’re busy building the future, they wonder why their users are angry.
Doing The Math
When VCs evaluate startups, they do their due diligence. They review numbers, talk to customers and build models. Product managers, by contrast, often skip this step and build features simply because an executive requested them or because the idea seems exciting. What’s really needed, though, is rigorous analysis—grounded in data and validated by math, not just intuition.
Take total addressable market (TAM), for instance. Investors obsess over this term. If you’re building a feature for power users who make up only 5% of your base, your TAM is small. Which is fine! Small can be good, but not if you’re spending three months on it.
Competitive advantage is another consideration. How long before competitors copy your feature? If it’s two weeks, then you’d better have a good reason for building it. Maybe it’s table stakes now, or maybe it’s part of something bigger. Ultimately, it’s critical that you know what you’re signing up for.
And always, always think about the downside. What if users hate it? What if it breaks other stuff? What if it works too well and crashes your servers? Many PMs only plan for success, which is how you end up shipping features that technically work but practically ruin everything.
Stop Thinking In Sprints
Day traders think in minutes while the Warren Buffetts of the world think in decades. Let’s say product managers think in … two-week sprints. If strategy is really front of mind, maybe this is measured in quarters. Either way, this is a dangerous way of thinking.
You need multiple time horizons working at once. Yes, ship something this sprint, but also know where you’re headed this year. At the same time, have some idea what the product looks like in three years. Rather than some dusty vision document, make sure this is an actual thesis that helps you make decisions today.
When you only think short term, you become a feature factory. You ship whatever’s easiest, whatever the loud customer wants and whatever makes your boss happy this week. When you think long term, you build systems, platforms and everything else that compounds value over time.
Killing Your Darlings (With Data)
The hardest things about investing are knowing when to sell, admitting you were wrong and moving on after taking the loss. The same thing is true in product management. That feature you spent months building? If it’s not working, kill it. But don’t kill it because you’re bored or because some executive doesn’t like it; kill it because the data says it’s dead.
Set success metrics before you build—real ones with real targets. If you miss them, pull the plug. The resources you get back can go toward something better. Investors don’t hold losing positions out of pride, and neither should you.
Closing Thoughts
It can help to think of product management as investment management with different assets. Rather than allocating capital, you’re allocating time, talent and attention. However, the mental model remains the same. This includes portfolio thinking, risk management, time horizons and knowing when to cut losses.
This doesn’t mean turning everything into a spreadsheet. Building products is still creative work. Instead, it means bringing investor discipline to that creative process. It means making hard calls with partial information, having the guts to be wrong and the sense to adjust when you are.
Next time you’re deciding what to build, don’t ask if it’s a good feature. Ask if it’s a good investment. This question will hit your priorities, trade-offs and long-term thinking differently, and your product will be better for it.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
