From Investor Mindset To Product Mindset: Making Decisions Under Uncertainty

The mental model I keep coming back to is the 70-20-10 allocation - not a hard rule, but a forcing function that makes the conversation unavoidable. 70% of effort to optimise what’s already working, 20% to adjacent bets with reasonable evidence, and 10% to really exploratory, asymmetric work. The trap most product teams fall into is not that they ignore the asymmetric bets consciously – it’s that incremental work fills all available time, because it comes with a built-in justification. It has metrics, it has stakeholder buy-in, a clear narrative - it basically arrives pre-justified. There’s none of that in the asymmetric bet yet, and in a resource-constrained environment that ambiguity reads as risk, not opportunity.

What I have learnt is that you have to protect the asymmetric bets structurally. Culture alone won’t save them. You need to create a small team, give them a different cadence than the core product cycle and, critically. measure them against different metrics. To judge an exploratory bet on conversion or retention numbers after week six is like marking a venture fund to market after a single quarter. Portfolios only work if you’re honest about which bucket an initiative belongs in and don’t succumb to the temptation to shove them all into the same evaluation framework.

This is one of the harder calibration problems in early product work and I don’t think there is a clean answer, but there is a useful heuristic. Qualitative signals tell you what and why. Quantitative signals indicate how much and how consistently. In 0-to-1 work you’re almost always working on qualitative signals first. The error cuts both ways: go to quantitative validation too early and you kill an idea before it has any shape; stay qualitative too long and you are essentially writing fan fiction about your own product.

I draw the line between opinion and behaviour. When users tell me something is a problem, that's opinion. If I see them doing something painful, inefficient, or expensive to work around a problem, that's behaviour, and behavioural signals carry dramatically more weight in my decision-making. In every interview, users verbally validated a feature concept in one of our regulated market builds. But when we saw them actually use the workaround they'd built, we realised the problem we were solving was real, but our proposed solution was actually solving the wrong layer of it altogether. The qualitative signal was there. We had the right antenna pointed at the wrong frequency.

On time-to-market pressure: I’ve made peace with the fact that you’ll never have enough data to feel comfortable with a 0-to-1 bet. The goal isn't certainty; it's a high-enough-resolution image of the problem that your solution hypothesis isn't random. If you can’t clearly articulate what would have to be true for your bet to pay off, that’s not conviction - that’s just optimism with a roadmap.

Honestly? Optionality is psychologically addictive - especially for people who pride themselves on systems thinking. You can always make a reasonable case for why it’s too soon to commit. And early-stage environments tend to respect that argument because it seems like intellectual rigour.

For me, the tell is when the question “should we keep our options open?” stops being about the product and starts being about the team’s discomfort with commitment. Real optionality has a defined shape: you know what information you're waiting for, when you expect to have it, and what decision it unlocks. Manufactured optionality is procrastination wearing a framework. 

In practice, I explicitly set decision gates. Before moving into a phase of deliberate ambiguity, I name what we’re learning, by when, and what we’ll do with the answer. If we can't name those three things, we're not preserving optionality; we're deferring a decision we're afraid to make. That doesn’t come without a cost. Nothing erodes team alignment faster than sustained ambiguity. People begin to locally optimise over their own interpretation of the direction, and by the time you commit, you’ve paid the coordination tax a few times over.

In the absence of any historical record or a true comparable, I rely on three proxies to put together a strong enough signal for a bet.

First proxy: pain intensity and the cost of the workaround. When you have users laying out hard cash or time, or putting up with social friction because their tools are lacking, it is a revealed preference. The market is there, only underserved. By looking at what they are already putting out for the workaround, you can triangulate a fair estimate of its size.

Then there is the matter of regulatory or structural tailwinds. In the fintech and healthtech spaces I am in, where data is heavily regulated, an unproven market will often be made so by some external force - be it a new law, an institutional mandate or a change in infrastructure. Spotting a structural shift that will compel people to alter their behaviour in volume goes a long way to de-risking the uncertainty, product certainty or no.

My third is to look at the adjacent market. You may not have a direct parallel, but there is usually something next door that provides a floor. If I am building at the crossroads of two established categories, I can bracket the opportunity by running the numbers on each and figuring out how much of that value I might reasonably take.

I have zero patience for the top-down TAM exercise that quietly becomes its own mythology. “We have 50 million potential users, so one per cent is a huge business” - more often than not that is just post-hoc reasoning to cover an intuitive call. Give me an honest, if modest, proxy over a contrived model of the market any day.

Take the product we put together for a regulated financial services firm as a case in point. We were dealing with an onboarding process that had a lot of friction. If you listened to the rest of the market, the conventional wisdom would have it that you can’t convert anyone in a regulated environment; compliance is a conversion killer, and you just have to accept 40% or 60% drop-off as the price of admission when users hit those hurdles.

I didn’t buy that. My read was that the problem wasn’t the compliance requirements but the way they were put in front of the user. When you ask for something sensitive and don’t provide the right context or trust signals, people leave. It was a qualitative thing I picked up from watching how our users behaved and talking to them, there was no hard data to back me up on it.

So we went with it and re-architected the whole onboarding experience to build trust progressively instead of hitting them with compliance up front. We ended up with a 90% conversion rate in a flow everyone said would top out at 50%.

Was I well-calibrated in my uncertainty? In some ways. I was spot on with the diagnosis: it was about trust, not the regulations. But I’ll admit I was overconfident on the execution side. I figured having the insight was the difficult part. It turned out the craft of making it work was just as hard. We came close to throwing away our gains on three or four occasions because of some minor callousness in the copy, a loading state or the order of things. The hypothesis was fine, but my confidence in the details was misplaced.

There is no denying the loudest stakeholder problem is a real one, but I would put it down to process design rather than people. When your way of prioritising leaves room for advocacy and doesn’t ask for proof, you are going to have advocacy. You need to set an evidentiary bar that is uniform and explicit; not in a punitive sense, but to be consistent.

My own framework has a simple rule: before any initiative is put on the table for resource allocation, it must make its case by answering four things. What user behaviour are we trying to change? Show me the evidence this is an actual problem. Why do you hypothesise this solution will be the answer? And what will we have to see in six or eight weeks to prove we were right? That final point is key. It makes people define their exit criteria while they still have skin in the game, which goes a long way toward curbing the kind of motivated reasoning that undermines objectivity down the line.

For the most part, the vocal stakeholder isn’t being irrational, they are just loud because the process offers them no other outlet. Put in place a structured channel where everyone can make an evidence-based argument and you’ll find the noise level drops and the conversation improves.

Then there is the matter of resource scarcity in a venture studio. I don’t see it as a bug so much as a feature. If you have plenty of resources a team will put off making hard calls. But constraints compel you to decide. The best product thinking I have come across has been from teams that simply could not afford to waste time building something wrong.

We can’t deny the Bezos framework has its merits, but in a regulated market you have to add a third category that product teams tend to overlook: decisions that are technically reversible yet practically not. Take consumer fintech, for instance. You could change the way a fee is put before the user, sure. But once they have been used to it one way, making that switch will undermine your credibility, and you won’t get that trust back. On paper it is reversible; in practice the price of reversal is so steep it might as well be permanent.

That is why I put a compliance and trust-impact screen on things before I call them Type 2. If a decision has any bearing on your regulatory standing or how you handle user data, or if it goes to the heart of the product’s relationship with the customer, I treat it as a Type 1 even if you could technically walk it back. It entails more review and longer cycle times, but I am fine with that. The other option is to run headlong into a corner from which there is no exit.

I do have some reservations about the framework when it comes to decision velocity though. In our world the danger is not moving too fast, it is the classification process turning into an impediment. You will see teams mark off everything as Type 1 to avoid being held to account for their actions. I make a point of challenging that by drawing a line between what truly has a compliance or trust risk and what merely feels important. Be honest and most of those are still Type 2.

You run into trouble with exit criteria once a project is underway because of commitment bias. You have put in the time, you have your story, and by then your mind is all too good at rationalising why the early signals are not telling you the whole truth. A pre-mortem can be of some use, but I have found nothing as sound as to set your exit criteria before you even put pen to paper on the success ones. It compels you to define what failure is while you are still dispassionate about the result.

So when I start an initiative I make a point of putting down three things: the leading indicators I should see come a certain checkpoint; the hard floor where we walk away no matter the narrative; and the circumstances that would warrant us to pick up the pace instead of plodding along. I include that last one so the exit criteria don’t seem like a purely defensive measure. It is a way of showing what a green light is, turning the whole thing into a tool for decision-making rather than something to be feared.

Take a B2B product we were building in the studio for the mid-market, for example. We said we would need three letters of intent from qualified prospects in ten weeks of outreach to stay the course. Come week twelve we had one LOI and two “very interested” parties who had been very interested for six weeks and were going nowhere. The team was for extending the timeline, arguing the sales cycle was running long and the relationships were there.

We put it to rest. The relationships may have been genuine enough, but the point of having an exit criterion is to inoculate you against that sort of logic. In B2B the distinction between being interested and being committed is everything; the former is cheap. We moved on to another segment and saw better traction in a month. That first track might have panned out in the end, but “eventually” is a word you can’t afford in early-stage development.