Beware, Activity and Productivity are eerily similar.

My co-founder and I united with the idea to extend human capabilities in jobs that keep the world running: manufacturing, electricity, utilities etc. It’s been 3 weeks, and I think we had it wrong.

Neither of us are from this industry (I just graduated this year, and him, the year before), the idea was ambitious to say the least. We managed to get on call with close to 20 different people from automotive plants, food plants, semiconductor fabs, maintenance contractors etc, in a span of 2 and a half weeks in an industry neither of us have any right to demand people’s time in. That sounds like quite a productive thing to do. But that alone doesn’t tell the full story.

Two seemingly unrelated phenomenon, that in hindsight, can be correlated to one trap we fell in.
Throughout the journey, I had this constant sense of confusion: We learnt a bunch of stuff about the industry from each of the calls we took but it didn’t feel like any of them answered “what should we do next” well enough. I just told myself that’s just how the process is. We are trying to build a big time tech company one call at a time… we’re bound to feel confused.
On the other hand, I noticed that I am not being as resourceful as I usually can be. I felt like I was far more resourceful when I was a software dev intern working at a small startup. This realization was causing a lot of turmoil within me, because I felt like I had “lost” a certain ability that I once used to take pride in.

The “conventional” wisdom that failed (?) us
Cut to 2.5 weeks and a rough couple of days. I now have a good grasp of what was going wrong, and why it took 2 weeks to even get here. I can say with a lot of confidence that It started from us constantly hearing “talk to your users”. That’s conventional startup wisdom, yes, but it’s one that is very easily miscommunicated.

I feel like a useful way to think of startups at the early stages is to think of it as a research lab, where you form a bunch of (serial/parallel) hypothesis and run experiments to resolve each of them into some insight that can dictate the next course of action. The idea is that your lab is able to eventually go through enough of these learning points and end up with an impactful outcome. It seems very intuitive now, but isn’t as obvious when we are going through the motions of it. Some people like to call these hypotheses, bets, some call them ideas, or maybe even hunches, but I find that calling them hypothesis and subjecting it to the scientific method sits well with my model of the world.

umm… what do I do now?
One of the most problematic areas in our journey so far is that, before every conversation, you have the mammoth task of “build a company” in front of you, you are not sure what you want to understand from that call, and how it dictates what to do next. This then leads to calls which generate a lot of facts but not enough insights to help us decide what to do next. We often felt more confused after some calls than before.
I have come to realize that it’s much better if you segment the large task of company building, and convert it to a sequential list of hypothesis to test / update (the most critical ones invalidated as soon as possible). Then, gaining clarity and being resourceful while you’re at it gets a lot easier.

The trap
The trap that we fell into is clear as day: We had many hypotheses that we didn’t really attempt to use to shape our next course of action and incoming information wasn’t enough to align us in a clear direction, or reduce complexity along any axis.

Each (productive) conversation, in theory, can give you an insight with which you can modify existing hypotheses or create new ones. I have come to believe that moving through these uncertainities fast and using that to form decisions on what to do next, is productivity for startups in the early stage. Generating customer calls is part of productivity, but without the nuance of “generate insights that help you move forward”, we only managed to emulate what a productive startup does though that wasn’t our intention.

The solution
Knowing what the problem is, the solution is very intuitive: maintaining relevant state and operating on top of it. Think of the startup again, this time, as a state machine: take the current hypothesis and internal state of knowns/unknowns/relevant data as input, run it through relevant experiments, and output patches to the internal state, hypotheses or generate new hypotheses altogether.

Simply put, being clear about what we know, what we don’t know, and what we need to know to take the next step is how I think you can side step this trap. Then everything you do within the scope of these experiments: research, calls, MVPs, pilots, all make a lot of sense and provide a condusive environment for maximum productivity. This constrainted problem space enables you to become “relentlessly resourceful” within that set scope, because you are optimizing for a defined objective function that is much narrower than “build a company”. I believe constraint is where creativity can really take it’s course.

Of course, this isn’t easy to do. The hard part is to know what the highest leverage question is, that can make the course easy for you. Going after questions at random probably isn’t going to be very useful.

Discovery calls are still very important when you don’t yet know what questions matter. But at some point during any good discovery process (which I believe ours was), you are gonna form intuitions about how the product should look and what the market is like. At that point, it’s important that you switch gears into the state machine. This point is something we came by a long time ago but we never really did anything about it.

Conventional wisdom is not lies though
The funny thing is, we hoped to reach this clarity through lots of conversations without understanding these underlying nuances. Just the frustration that conventional wisdom is failing me (news flash, it wasn’t really) is what got me into thinking these things through. So it comes full circle to the fact that “talk to users” is a indeed a good idea, not because you immediately attain wisdom to build great startups. But because you are more likely to figure out the underlying nuances talking to users than If you don’t.

Oh, and I cannot get over how similar what I have put down here is, to https://www.technologyreview.com/2026/10/02/1145639/dont-be-fooled-llms-dont-reason/. The article is essentially about reasoning as a framework: holding an epistemic state internally, updating that state with evidence and using that to drive decisions. It is not surprising to see the author correlate this framework as the source of the suprising display of “creativity” from AlphaGo.